Antoine Pitrou added the comment:
> I like the footnote idea.
Me too.
> I wonder if it would also be worth marking which functions are Posix
> (Availability: posix) and therefore likely to be available on all unix
> systems.
POSIX has optional APIs, hasn't it?
---
Changes by Antoine Pitrou :
--
nosy: +barry, ncoghlan
___
Python tracker
<http://bugs.python.org/issue11235>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Looks good to me. I guess it needs Georg's approval, though.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/is
Changes by Antoine Pitrou :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue11244>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> If I do "c:\python27\python run_nose.py" it works correctly. If I do
> "nosetests" I get the process explosion. Maybe the bug is in how
> distutils and nose work from the command line? I'm confused.
The bug is in nose its
Antoine Pitrou added the comment:
The culprit is r82043: "Issue #9011: Remove buggy and unnecessary ST->AST
compilation code".
--
assignee: -> mark.dickinson
nosy: +pitrou
___
Python tracker
<http://bugs.py
Antoine Pitrou added the comment:
The problem is that the "UNARY_NEGATIVE + LOAD_CONST" optimization, which
occurs first in bytecode order, inserts a NOP and prevents the tuple
optimization to work.
--
___
Python tracker
<http://bu
Antoine Pitrou added the comment:
Ouch. Obviously test_peephole doesn't have enough tests...
--
___
Python tracker
<http://bugs.python.org/issue11244>
___
___
Antoine Pitrou added the comment:
Here is a patch that enables advanced (recursive) constant folding.
Example:
python -c "import dis; f=lambda x: x in
{(3*-5)+(-1-6),(1,-2,3)*2,None};dis.dis(f)"
With 3.1:
1 0 LOAD_FAST0 (x)
3
Antoine Pitrou added the comment:
> Okay, committed to py3k in r88440. Does this need backporting?
Certainly.
--
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
Le samedi 19 février 2011 à 10:45 +, Mark Dickinson a écrit :
> Mark Dickinson added the comment:
>
> Unassigning. I don't think that r82043 is the *real* culprit here; that
> bugfix just happened to expose a deficiency in the peeph
Antoine Pitrou added the comment:
Well, it's up to Georg to decide if it goes before 3.2. But I don't see the
hurry: the online docs are rebuilt daily anyway.
--
assignee: pitrou -> georg.brandl
___
Python tracker
<http:/
Antoine Pitrou added the comment:
Sure it should be a blocker?
--
nosy: +georg.brandl, pitrou
___
Python tracker
<http://bugs.python.org/issue11249>
___
___
Pytho
Antoine Pitrou added the comment:
Well, isn't Py_tp_doc characteristically bound to a constant char *, so that
the problem doesn't manifest itself?
--
___
Python tracker
<http://bugs.python.o
Changes by Antoine Pitrou :
--
nosy: -pitrou
___
Python tracker
<http://bugs.python.org/issue11234>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> > Sounds like a blocker to me. Martin, will you be able to provide a patch
> > before final?
>
> The attached patch works fine for me.
Is there some documentation somewhere for all this?
--
Antoine Pitrou added the comment:
> >>> Sounds like a blocker to me. Martin, will you be able to provide a patch
> >>> before final?
> >>
> >> The attached patch works fine for me.
> >
> > Is there some documentation somewhere for all t
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue11250>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
priority: normal -> critical
___
Python tracker
<http://bugs.python.org/issue11254>
___
___
Python-bugs-list mailing list
Un
Changes by Antoine Pitrou :
--
nosy: +pitrou
stage: -> patch review
versions: -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
Here is the first patch adapted for py3k.
--
Added file: http://bugs.python.org/file20810/faster-find-library1-py3k.diff
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
Actually, re.escape is probably still needed around name.
--
___
Python tracker
<http://bugs.python.org/issue11258>
___
___
Antoine Pitrou added the comment:
You also need to a test to Lib/test/test_socket.py.
--
___
Python tracker
<http://bugs.python.org/issue11127>
___
___
Python-bug
Changes by Antoine Pitrou :
--
nosy: +giampaolo.rodola, orsenthil
stage: -> patch review
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6
___
Python tracker
<http://bugs.python.org/issu
Changes by Antoine Pitrou :
--
assignee: -> giampaolo.rodola
nosy: +giampaolo.rodola
___
Python tracker
<http://bugs.python.org/issue11259>
___
___
Python-
Changes by Antoine Pitrou :
--
assignee: -> giampaolo.rodola
nosy: +giampaolo.rodola
___
Python tracker
<http://bugs.python.org/issue11257>
___
___
Python-
Changes by Antoine Pitrou :
--
assignee: -> georg.brandl
versions: +Python 2.7 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue11184>
___
___
Py
Antoine Pitrou added the comment:
Patch looks good to me.
--
nosy: +pitrou
stage: -> patch review
versions: +Python 3.3 -Python 3.1
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
> Fixed by r87729.
This only addresses the compress() and decompress() functions, but e.g. crc32()
and adler32() are also touched by this issue.
--
versions: -Python 2.6, Python 3.1, Python 3.2
___
Python trac
Antoine Pitrou added the comment:
> Fixed by r87728.
This only addresses the compress() and decompress() functions, but e.g. crc32()
and adler32() are also touched by this issue.
--
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
Thank you for the patch! Committed in r88460 (3.3) and r88461 (3.2).
2.7 would need more surgery in order for this to be fixed, see #8651 and #8650.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> pending
Antoine Pitrou added the comment:
Committed in r88484 (3.x), r88485 (3.2).
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Antoine Pitrou :
Following r88460 (issue10276), test_zlib crashes on the Snow Leopard buildbot
(apparently in the new "test_big_buffer" test case).
--
messages: 129002
nosy: ixokai, ned.deily, pitrou
priority: critical
severity: normal
status: open
title:
Antoine Pitrou added the comment:
I've tried INT_MAX and it didn't change anything.
--
___
Python tracker
<http://bugs.python.org/issue11277>
___
___
Antoine Pitrou added the comment:
I was a bit optimistic concerning 32-bit Windows. I had to do some changes, in
part because off_t is 32-bit there. The final patch is committed in r88486
(tested under 32-bit and 64-bit Linux and Windows
Antoine Pitrou added the comment:
Backported in r88487 to 3.2, and in r88488 to 2.7.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7
___
Python tracker
<http://bug
Changes by Antoine Pitrou :
--
nosy: +jcea, ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue11279>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pitrou added the comment:
> Does it matter that _4G < UINT_MAX?
You mean _4G > UINT_MAX, right?
Yes, it matters, otherwise that defeats the point of the test :)
--
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Well, it's not a patch, just a traceback :)
--
___
Python tracker
<http://bugs.python.org/issue11277>
___
___
Python-bugs-l
Antoine Pitrou added the comment:
> File: issue11277.patch.
> Hmm. Two non-register constants and equal code on 32 and 64 bit.
> Does Python has a '64 bit' switch or the like - PY_SSIZE_T_MAX is not
> preprocessor-clean, i would guess.
Er, how is this patch
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
nosy: +pitrou
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2833>
__
___
Python-bugs-list mailin
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
I've just discovered that the patch in r62847 doesn't clean up the
exception state if the except clause does not mention a local variable,
e.g. "except MyException" instead o
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
This bug should be reopened, the patch does not fix it when the except
clause does not assign the exception to a local variable (that is,
"except KeyError" rather than "except KeyError as e").
Another can of wo
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Small typo in the snippet above, this should obviously read:
try:
raise Exception("foo")
except Exception as e:
try: raise KeyError("caught")
except Ke
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
As Amaury said, lexically nested exception handlers make re-raising
behaviour buggy. In Py3k, a workaround is to instead write:
try:
raise Exception("foo")
except Exception as :
try: raise KeyError("
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> Currently, when creating a new Thread object, there is no good way of
> getting that thread's get_ident() value.
Well, how about doing it at the beginning of its run() method, e.g. in a
Thread subclass:
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
This is a complementary patch that should fix the remaining cases
(funnily doctest was relying on the old behaviour).
Unfortunately #2833 still remains, and would probably need some
discussion on the ML for proper resolution.
Adde
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
I don't think so. As Amaury pointed in #2833, the original re-raising
behaviour which got changed by fixing the present bug was rather broken
in its own way.
Anyway, I think the question better be asked on the ML because any
solut
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10424/better_exc_cleanup.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Patch removed, there are still some unsolved cases :-)
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Just found another funny example. This one fails also before r62847.
def except_yield():
try:
raise Exception("foo")
except:
yield 1
raise
list(except_yield())
In Py3k (with or without
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Well, it's true that get_ident() will always give you a reliable number
while currentThread() can play dirty games on you at shutdown. The thing
is the Thread object is dereferenced before the OS thread actually
terminates, so it
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is a hopefully complete patch using the same approach as before.
However I'm now convinced that another approach would be better in order
to solve both this bug and the various re-raising issues. It would
involve replacing
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Or, if you want to educate people at all cost, the TypeError raised by
bin() when trying it on a float object could include in its message the
binary representation of the float object "for
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
I'm not sure about the educational value of letting obscure bugs
creeping in when someone passes a float where an int is expected :-)
Your vis() function looks appropriate for the task of educating people,
why should its behaviou
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Well it's quite simple. Imagine you have a function f() which takes an
integer parameter named x, and somewhere applies bin() to this parameters.
Right now, if you call f(1.0) instead of f(1), you will get a TypeError,
which
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> I think you are mistaken. Python always distinguished between floats
> and integers
Sorry, my bad.
> For example, if
> bin is used inside f() only to produce some log output, but
> otherwise f() works on any nu
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> I read the proposal as
> producing the true mathematical radix 2 representation of a float
> rather than its 64-bit memory layout.
The term "layout" was probably badly chosen.
Still, the explicit moti
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> What would you say to adding float-capable bin/oct/hex (+ maybe tobase)
> to the math module?
Why not indeed.
However, as I said, if the intent is float-specific (and it is, unless
there is another inexact numeric type whic
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> Better to just build-out bin() and be done with it.
Ok, someone has to take a decision anyway.
However, if you do that, it should be probably decided first what
happens for hex() and oct(). Do they still disallow floats
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
This patch implements the proposal outlined on the py3k mailing-list
here: http://mail.python.org/pipermail/python-3000/2008-May/013740.html
It solves both #2507 and #2833, and even improves re-raising semantics
in several cases (s
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
A clean solution is now proposed in #3021.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
A clean solution to both #2507 and #2833 is now proposed in #3021.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Shall the method be called isprintable() or simply printable()? For the
record, in the io classes, the writable()/readable() convention was chosen.
--
nosy: +pitrou
___
Python tracker &
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
You should investigate and try to diagnose where the speed difference
comes from. ISTM the RLock class is implemented in Python while the Lock
class is simply an alias to the builtin native lock type, which could
explain most
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
You are right, I had forgotton about lower()/islower().
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
test_shutil fails with the following error under some AIX 5.3 machine:
==
FAIL: test_on_error (__main__.Test
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is a working patch.
I've also added a try/finally block, because otherwise the following
tests in regrtest.py couldn't run properly (@test was unremovable
because of wrong permissions).
--
keywords: +patch
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Apparently it dates back to this commit:
http://hg.pitrou.net/public/cpython/trunk/rev/56254b99fb78
Perhaps someone should ask the original author. But indeed I'm not sure
why it's testing such implementation details. The
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
With or without my patch, bare "raise" inside a "finally" statement
raises a "RuntimeError: no active exception to re-raise". (except, of
course, when the try/finally is itself enclosed in an except bloc
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
(an unexpected side effect of my patch is that the interpreter has
become 5-10% faster under Linux, witnessed with pystone and pybench. I
don't know the explanation)
___
Python tracker <[E
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Ok, it makes sense to have the same behaviour for except and finally
blocks then. As for the syntax error, I'm still not convinced. The point
of Py3k is to change semantics: people should expect some incompatible
changes. Also t
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is a newer patch that also adapts the behaviour of finally blocks
as suggested by Adam Olsen. Note that I had to change some things in the
way 'with' statements are compiled and executed.
Added file: http://bugs.pyth
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
I recommend not letting this issue rot too much :) Eating 20+ seconds to
read the contents of a 10MB binary file in one pass is not very good
marketing-wise, and the betas are coming soon...
___
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Thanks for the fixes.
By the way, I don't know much about non-blocking streams, but it seems
to me that "optimal" non-blocking read() would require that the chunks
we ask to the OS are block-aligned, which is not the cas
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Yup. However, if you try it, you'll probably notice that it decreases
performance of normal (blocking) reads as well :-)
Anyway, non-blocking file objects are pretty much second-class citizens
in Py3k right now, so my remark was
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is a new patch against SVN trunk. Nothing changed, except that I
updated pybench to test keyword arguments as well.
Added file: http://bugs.python.org/file10590/namedparam2.patch
___
Python t
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
This is an implementation of the Py_SETREF and Py_XSETREF macros
proposed in http://mail.python.org/pipermail/python-dev/2008-May/079862.html
As an example, I added a few conversions among the extension modules.
--
comp
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
FWIW, I also wanted to propose for Py_INCREF(op) to evaluate as (op), so
that it can be used as return or assignment value, e.g.:
return Py_INCREF(result);
or:
self->var = Py_INCREF(obj);
but it's perhaps a bit more
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Benjamin, the patch is against py3k, also it might also apply cleanly on
trunk...
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
And here is a patch adding a new test in pybench as suggested by
Marc-Andre Lemburg.
Added file: http://bugs.python.org/file10600/pybench.patch
___
Python tracker <[EMAIL PROTECTE
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
In py3k, pybench wrongly detects UCS2 builds as UCS4. Patch attached.
--
components: Demos and Tools
files: pybench_ucs.patch
keywords: patch
messages: 68076
nosy: pitrou
severity: normal
status: open
title: Wrong unicod
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le jeudi 12 juin 2008 à 20:26 +, Marc-Andre Lemburg a écrit :
> Doesn't chr(10) raise an exception in UCS2 builds ?
No, it returns a 2-character string.
> Note that sys.maxunicode is not available in Python 2.1
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> Which hopefully is the proper surrogate sequence :)
Well at least that's what the doc string says!
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Are you sure the keys for those list objects aren't just equal to others
you insert in the dict?
Witness:
>>> d = {}
>>> d[1] = 'a'
>>> d
{1: 'a'}
>>> d[1.0] = 'b'
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
The current behaviour is useful in that most of time, it is convenient
to let OptionParser display a standard error message and bail out.
However, having an attribute on the OptionParser object (e.g.
exit_on_errors) to be able to chang
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Is this issue still valid?
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Is it useful to keep this bug open? Does it correspond to a real-world
use case?
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Do you really need to expose Py_UNICODE_SIZE? There is already
sys.maxunicode, unless I'm missing something.
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<ht
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
This patch is an experiment in making faster some of the most common
comparisons (str vs. str, int vs. int). I don't know if it may bring
noticeable speedups in real-world situations, but here are the synthetic
benchmark nu
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Hmm, so it seems that in some UCS4 builds, sizeof(Py_UNICODE) could end
up being more than 4 if the native int type is itself larger than 32
bits; although the latter is probably quite rare (64-bit platforms are
usually either LP64 or
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le vendredi 13 juin 2008 à 20:18 +, Marc-Andre Lemburg a écrit :
> AFAIK, only Crays have this problem, but apart from that: I'd consider
> it a bug if sizeof(Py_UCS4) != 4.
Perhaps a #error can be added to that effec
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
This patch implements implicit except chaining (__context__) as per PEP
3134, or not quite. The difference is that PyErr_Set* functions do set
the __context__ attribute, otherwise I think it would make an annoying
discrepancy b
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
If it's fixed in 2.6 and 3.0, it shouldn't be release blocker anymore,
now should it?
___
Python tracker <[EMAIL PROTECTED]>
<http://
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Guido, thanks for your comments. Here is a new patch addressing them.
Added file: http://bugs.python.org/file10627/context2.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
I had the following intermittent failure under py3k:
[...]
test_multiprocessing
Process Process-24:
Traceback (most recent call last):
File "/home/antoine/py3k/context/Lib/multiprocessing/process.py", line
237, in _bootst
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> The original text file was an IRC log. Shoving Charles Dickens' "Great
> Expectations" 17 times in a text file and then parsing it doesn't show
> this problem for some weird reason.
I'd say the
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Talking about performance, why use a loop to escape special characters
when you could use a regular expression to escape them all at once?
--
nosy: +pitrou
___
Python tracker <[EMAIL
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3112>
___
___
Python
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3113>
___
___
Python
3801 - 3900 of 16792 matches
Mail list logo
