Facundo Batista added the comment:
I think that the Spec disallows additional whitespace to not allow, for
example, "2. 34" as "2.34", or "10 e-12".
I don't see any harm in having " 2.34" or "5.73\n" as good input
values, as long we remove
Facundo Batista added the comment:
Already fixed in the trunk and 2.5 maintenance branch.
--
nosy: +facundobatista
resolution: -> out of date
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Facundo Batista added the comment:
Mark Dickinson:
> The other option that maintains full compliance with the
> specification is to do what we like with Decimal.__new__
> (e.g. allowing leading and trailing whitespace), but
> make sure that there's a fully conforming to-numb
Facundo Batista added the comment:
Why not just double the size? The "doubling + 1024" address some
specific issue? If so, it should be commented.
Also, do you have an example of a marshal.dumps() that suffers from this
issue?
Thank you!
--
nosy: +facu
Facundo Batista added the comment:
Already fixed in trunk and 2.5 branch.
--
nosy: +facundobatista
resolution: -> out of date
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Facundo Batista:
--
nosy: +facundobatista
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1819>
__
___
Python-bugs-list mailing list
Unsubs
Facundo Batista added the comment:
Yes, something was bad with my test. Now I have the same behaviour.
Sorry for the noise.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Facundo Batista added the comment:
Don't follow you:
>>> class C:
a = 42
list(a for _ in 'x')
>>>
Works here! (Python 2.5.1 on win32)
--
nosy: +facundobatista
__
Tracker <[EMAIL PROTECTED
Facundo Batista added the comment:
No news after two years and a half. Considering the arguments of Raymond
after S. Kochen brought the issue back up, I'd close the patch as rejected.
Feel free to bring this issue to python-dev, and if there's real need,
we can always open the patch b
Facundo Batista added the comment:
If those two are obsolete, we may add a DeprecationWarning in 2.6 and
hide/remove them in 2.7.
What do you think?
--
nosy: +facundobatista
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/is
Facundo Batista added the comment:
os.popen* are deprecated, we should use subprocess now... could you
please try what happens with this alternate example I'm attaching?
Thank you!
--
nosy: +facundobatista
Tracker <[EMAIL PROTECTED
Facundo Batista added the comment:
Boo, I forgot the attach, :p
Added file: http://bugs.python.org/file9213/using_subprocess.py
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/is
Facundo Batista added the comment:
Great! So it's fixed, :)
--
resolution: -> out of date
status: open -> closed
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Facundo Batista added the comment:
Fixed in r60073.
Regarding the flag, you're right: maybe these classes should deal it in
other way... but maybe there're reasons to do this.
If you want to push a better structure for this flag, feel free to raise
the issue in python-dev.
Anyway
Facundo Batista added the comment:
Martin:
I'll close this as it's marked as invalid, and nobody answered since two
years ago.
If you think that your first patch is a good solution (Fredrik agreed,
good enough for me).
If you want, reopen the bug and assign it to me, and I'
Facundo Batista added the comment:
The last patch (exception_pickling_26.diff) applies cleanly, and all the
tests run ok.
System:
Python 2.6a0 (trunk:60073M, Jan 19 2008, 11:41:33)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
--
nosy: +facundobatista
Facundo Batista added the comment:
A lot of water passed around this bridge, but I don't know if this is fixed:
In the trunk right, now:
>>> v = 7.0 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1
>>> v
7.9964
>>> p = struct.pack( ">f"
Facundo Batista added the comment:
Only left the version 3.0, as the OP said it's not so important as to
break possible previous working code.
--
nosy: +facundobatista
versions: -Python 2.4, Python 2.5, Python 2.6
__
Tracker <[EMAIL PROTECTED
Facundo Batista added the comment:
Yes, not it works ok!
Thanks John for the testing example, and Carson for the report.
--
nosy: +facundobatista
resolution: -> out of date
status: open -> closed
_
Tracker <[EMAIL PROTECTE
Facundo Batista added the comment:
Bloody fingers. I meant that *now" it works ok.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1675533>
_
___
Facundo Batista added the comment:
Applied in r60087, with some change added in the help of the trace.py.
Thank you!
--
nosy: +facundobatista
resolution: -> fixed
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://
Facundo Batista added the comment:
Fixed in r60090.
Thanks Juanjo for your contribution!
Please sign and send in a contributor form whenever you have time; the
forms are at http://www.python.org/psf/contrib/ .
--
resolution: -> fixed
status: open ->
Facundo Batista added the comment:
Ralf, could you please submit the unit test that Guido suggested? Please
change also the 10x to 3x.
We could then apply this, :)
Thank you very much!
--
nosy: +facundobatista
__
Tracker <[EMAIL PROTECTED]>
Facundo Batista added the comment:
It's already fixed in the trunk (2.6 will have timeout for httplib and
other TCP libraries).
--
nosy: +facundobatista
resolution: -> out of date
status: open -> closed
__
Tracker <[EMAIL PRO
Facundo Batista added the comment:
Boosted priority: if changed, we should do it *before* 2.6 hits the street.
--
nosy: +facundobatista
priority: -> urgent
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Facundo Batista added the comment:
Closed issue 1924 as duplicate of this one, but I'm copying here the
text from David, as it's very explanative:
"""
I ran across this bug in some legacy production code when numbers got high:
>>> '%i' % 2e9
'
Facundo Batista added the comment:
Duplicates #1742669 (copied this text to there)
--
nosy: +facundobatista
resolution: -> duplicate
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Facundo Batista added the comment:
Can anybody reproduce this in 2.5? If yes, update the "version";
otherwise we can close it.
--
nosy: +facundobatista
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Facundo Batista added the comment:
Christian: you can not do that, as you *must* increase the size.
Anyway, I think that is a good idea to not let it duplicate after some
point. Which point? It's arbitrary.
You suggested 512KB, but I think that is too low.
*My* arbitrary point is, whe
Facundo Batista added the comment:
[EMAIL PROTECTED]:~$ time python -c "import
re;re.search(r'a(b[^b]*b|[^c])*cxxx','abbcacacabbcabbcacabbcacac')"
real0m2.510s
user0m2.308s
sys 0m0.028s
[EMAIL PROTECTED]:~$
This
Facundo Batista added the comment:
This is not a bug report.
I've run your code, didn't see any exception, and works as expected (in
linux and win2k).
Please, if still happens to you, provide what are you doing to reproduce
the issue, what do you expect to happen, and the system wh
Facundo Batista added the comment:
Applied in r60602. Thank you very much!
Note that I had to apply the patch by hand... I think that the problem
was in the header: if I get a svn diff, it starts differently than you
patch:
[EMAIL PROTECTED]:~/devel/reps/python/trunk$ svn diff -r 60601
Lib
Facundo Batista added the comment:
I'm +0 to make Decimal(Rational(x,y)) available.
I'd make it something like:
Decimal(R) == Decimal(R.numerator) / Decimal(R.denominator)
Note, as Raymond says, that this division implies the use of the
context. So the following will NOT b
Facundo Batista added the comment:
I'm +0 regarding this.
If this will go in, a comment should explicit all this in the code, as
this behaviour doesn't come from Decimal spec or the PEP.
Thanks!
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Facundo Batista added the comment:
Commited in r60622.
Thank you!!
--
nosy: +facundobatista
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Facundo Batista added the comment:
Thanks Mark!
Shall this issue be closed?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1979>
__
___
Python-bugs-list
Facundo Batista added the comment:
It seems that it's more a problem related to your environment. It could
be a problem in the installation, execution of the program, or even in
the XP itself.
In any case, you should ask for help in the python list, or in #python
at irc.freenod
Facundo Batista added the comment:
O_TEXT is not obsolete, as the behaviour is different even in a win2k.
>>> a = open("ubuntu-6.06.1-server-i386.iso")
>>> len(a.read())
46424
>>> a = open("ubuntu-6.06.1-server-i386.iso", "rb")
>&g
Facundo Batista added the comment:
So, the general agreement is that:
- After receiven the 302, it's ok to generate a GET request.
- There's a problem with the generated GET request (there should not be
a Content-Length field in the headers)
Right?
If this is ok, I'll fix it.
Facundo Batista added the comment:
Fixed in r60648, in the trunk.
Now the content-length and content-type headers are removed from from
the headers in the redirection.
Thank you all!
--
resolution: -> fixed
status: open -> closed
__
Tracker &
Facundo Batista added the comment:
Fixed in r60645. Thank you!
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2026>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Facundo Batista:
--
keywords: +easy
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2043>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Facundo Batista:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2049>
__
___
Python-bugs-list mailing list
Unsubs
Facundo Batista added the comment:
How can we test it? What can we do to "see" it?
--
nosy: +facundobatista
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Facundo Batista added the comment:
It's fixed in the trunk.
If in doubt, always you can check in the state-of-the-art docs:
http://docs.python.org/dev/
Thanks!
--
nosy: +facundobatista
resolution: -> out of date
status: open -> closed
___
Facundo Batista added the comment:
Moved this to the Meta Tracker
(http://psf.upfronthosting.co.za/roundup/meta), issue 187.
Thanks!
--
nosy: +facundobatista
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTE
Facundo Batista added the comment:
Already fixed: http://docs.python.org/dev/tutorial/errors.html
--
nosy: +facundobatista
resolution: -> out of date
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Facundo Batista:
A remainder.
--
assignee: facundobatista
components: Library (Lib)
messages: 62389
nosy: facundobatista
severity: normal
status: open
title: Implement __format__ for Decimal
versions: Python 3.0
__
Tracker <[EM
Facundo Batista added the comment:
The issue #2006 (asyncore loop lacks timers and work tasks) was closed
as duplicate of this one... noting this just for reference.
--
nosy: +facundobatista
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Changes by Facundo Batista:
--
nosy: +facundobatista
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2114>
__
___
Python-bugs-list mailing list
Unsubs
Facundo Batista added the comment:
Because of Giampaolo suggestion, that is reviewing all these
asyncore/asynchat issues.
--
nosy: +facundobatista
resolution: -> duplicate
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://
Changes by Facundo Batista:
--
nosy: +facundobatista
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2115>
__
___
Python-bugs-list mailing list
Unsubs
Facundo Batista added the comment:
Please, be my guest!
Thanks!
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2110>
__
___
Python-bugs-list mailing list
Unsubs
Facundo Batista added the comment:
Fixed in r60877, as of the description in my last comment.
--
resolution: -> fixed
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Changes by Facundo Batista:
Removed file: http://bugs.python.org/file9445/test_inspect.py.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1916>
__
___
Pyth
Changes by Facundo Batista:
Removed file: http://bugs.python.org/file9444/test_inspect.py.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1916>
__
___
Pyth
Facundo Batista added the comment:
Fixed in r60878. Thanks everybody!
--
nosy: +facundobatista
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Facundo Batista added the comment:
Fixed in r60884. Thank you all very much!
--
nosy: +facundobatista
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Facundo Batista:
--
assignee: -> facundobatista
nosy: +facundobatista
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2051>
__
___
P
Changes by Facundo Batista:
--
assignee: -> facundobatista
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1224>
__
___
Python-bugs-list mailing li
Facundo Batista added the comment:
Fixed in r60885. Thanks everybody!
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Facundo Batista added the comment:
In short:
>>> long(100 * 146.95)
14694L
This is NOT a bug, but a behaviour of binary floating point:
>>> 146.95
146.94
In binary you can not express this number exactly.
>>> 146.95 * 100
14694.9998
When yo
Facundo Batista added the comment:
Paul, %d will accept large floats, I need to review Gabriel's patch;
your proposition will break too much code.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.or
Facundo Batista added the comment:
Applied in r60974.
Maciek, please push that alternative way of handling this limit on
python-dev, that could lead to a better handling in the future.
But, so far, we have a limit a little upper, and tested.
Thank you all!
--
resolution: -> accep
Facundo Batista added the comment:
Applied in r60975. Thanks!
--
resolution: -> accepted
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Facundo Batista added the comment:
Applied in r60976. Thank you all!
--
nosy: +facundobatista
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Facundo Batista added the comment:
The functionality already exists.
--
nosy: +facundobatista
resolution: -> out of date
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Facundo Batista:
Removed file: http://bugs.python.org/file9191/patch.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1858>
__
___
Python-bugs-
Facundo Batista added the comment:
Applied in r60983. Thank you all!
--
nosy: +facundobatista
resolution: -> accepted
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Facundo Batista added the comment:
As Martin says, the functionality is present. If still you think we have
a new method here, please raise a discussion in python-dev regarding this.
Thank you!
--
nosy: +facundobatista
resolution: -> out of date
status: open ->
Facundo Batista added the comment:
On 2008/2/23, Guido van Rossum said in python-dev
> According to the docstring it's only meant to be used with sched.py.
> Please don't try to make it work with threads!
Anyway, this module will be removed, or at least its API hidden, in 3.0.
Facundo Batista added the comment:
Duplicate of #1524825
--
nosy: +facundobatista
resolution: -> duplicate
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Changes by Facundo Batista:
--
keywords: +easy -patch
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1524825>
_
___
Python-bugs-list mailing list
Facundo Batista added the comment:
As Raymond says, it's not a Python issue, but an extension one.
--
nosy: +facundobatista
resolution: -> rejected
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Facundo Batista added the comment:
Added test case in r61024.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1746071>
_
___
Python-bugs-list mailing list
Facundo Batista added the comment:
Applied in r61040. Thanks you all!
--
resolution: -> accepted
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Facundo Batista added the comment:
Applied in r61067.
Thank you!
--
nosy: +facundobatista
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Facundo Batista added the comment:
IDLE works in a server/client configuration with itself. Most probably
the firewall is blocking IDLE's connections.
Best way to try this is full disabling the firewall, and trying.
If it works, remember to activate the firewall back, and configu
Facundo Batista added the comment:
Applied in r61072.
Raymond, I stole this from you, because I had the same conclusion and it
was very needed for the buildbot.
Thank you all!
--
nosy: +facundobatista
resolution: -> accepted
status: open ->
Facundo Batista added the comment:
Same here, Ubuntu on x86 32b.
Doing first a "make clean", ./configure runs ok.
But then, in the "make":
...
File "/home/facundo/devel/reps/python/py3k/Lib/locale.py", line 479,
in setlocale
return _setlocale(category, loc
Facundo Batista added the comment:
Closing because it isn't clear if it's a bug (describe why do you think
it's wrong the actual state) or a feature request (describe what exactly
do you want/propose for the future).
Note that most probably urllib and urllib2 will be
Facundo Batista added the comment:
Gregory, you're keeping this as a recordatory (it passed almost five
years and a lot of water under "long" bridge), or can be closed?
Thank you!
--
nosy: +facundobatista
Tracker <[EMAIL
Facundo Batista added the comment:
spawnv is deprecated, use sobprocess instead.
And please, if you say to find the same issue in subprocess, provide a
test case to check what you say.
Thanks!!
--
nosy: +facundobatista
resolution: -> out of date
status: open ->
Facundo Batista added the comment:
import mechanisms and absolute and relative imports were reviewed recently.
Please verify if you still have an issue regarding this.
Thank you!
--
nosy: +facundobatista
resolution: -> out of date
status: open ->
Facundo Batista added the comment:
Raymond disapproved it, Skip discouraged it, and Nick didn't push it any
more, all more than two years ago.
Nick, please, if you feel this is worthwhile, raise the discussion in
python-dev.
--
nosy: +facundobatista
resolution: -> rejecte
Facundo Batista added the comment:
Documentation had several updates in these 2+ years.
Now it says:
"""
If __new__() returns an instance of cls, then the new instance’s
__init__() method will be invoked like __init__(self[, ...]), where self
is the new instance and the remainin
Facundo Batista added the comment:
If there's no objections, I'd make the traceback parameter optional in
the post_mortem method, making it default to sys.exc_info()[2].
Thanks!
--
assignee: -> facundobatista
nosy: +facundobatista
_
Tr
Facundo Batista added the comment:
Sorry, I misunderstood you. I assign this to myself to give it a try.
--
assignee: -> facundobatista
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
New submission from Facundo Batista:
What?
Why you say that? What are you doing? What do you get? What do you
expect? In which version of Python and in which Platform are you working?
--
nosy: +facundobatista
resolution: -> rejected
status: open ->
Changes by Facundo Batista:
Removed file: http://bugs.python.org/file9610/py-itimer-0.1.1.tar.gz
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2240>
__
___
Pyth
Facundo Batista added the comment:
Assigning as the platform.py file says.
The patch is straightforward, I'm only concerned with backward
compatibility...
--
assignee: -> lemburg
nosy: +facundobatista
__
Tracker <[EMAIL PROTEC
Facundo Batista added the comment:
Already fixed. Thanks Kenji for the report, Gabriel for the patch in the
other issue, and Alexander for noticing this "duplicateness".
--
resolution: -> duplicate
status: open -> closed
_
Tracker &
Facundo Batista added the comment:
Added this functionality in r61312.
--
resolution: -> accepted
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Facundo Batista <[EMAIL PROTECTED]> added the comment:
Already fixed in the trunk. Thanks for the report!
--
nosy: +facundobatista
resolution: -> out of date
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Changes by Facundo Batista <[EMAIL PROTECTED]>:
--
assignee: -> facundobatista
nosy: +facundobatista
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Facundo Batista <[EMAIL PROTECTED]> added the comment:
Should we close this?
--
nosy: +facundobatista
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Facundo Batista <[EMAIL PROTECTED]>:
--
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2272>
__
__
Facundo Batista <[EMAIL PROTECTED]> added the comment:
I was suffering of the same error, so:
make clean: ok
make update:
svn update tools/pygments
svn: requerimiento REPORT falló en '/projects/!svn/vcc/default'
svn: Target path does not exist
make: *** [update] Error 1
Facundo Batista <[EMAIL PROTECTED]> added the comment:
I really don't understand *why* it's a bug.
Is anywhere in the Language Reference that says that 1 should be the
same object that another 1?
Or do you mean that they *should* be the same object for speed and/or
memory reaso
Facundo Batista <[EMAIL PROTECTED]> added the comment:
I took a look at it...
It's not as not-complicated as I original thought.
The way would be to adapt the Py_UniversalNewlineFread() function to
*not* process the normal separators (like \n or \r), but the passed one.
A cri
201 - 300 of 372 matches
Mail list logo