If you are addressed on this message, it means you have open issues
that need to be resolved for 2.5. Some of these issues are
documentation, others are code issues. This information comes from
PEP 356. The best way to get me to stop bugging you is to close out
these tasks. :-)
Note the next
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
BTW, and intended as offer for compromise, should we instead
add the Win32 codes to the errno module (or a new winerrno
module) ?! I can write a parser that takes winerror.h and
generates the module code.
Instead won't help: the breakage will
Guido van Rossum wrote:
On 5/6/06, Vladimir Yu. Stepanov [EMAIL PROTECTED] wrote:
[proposing a total ordering between types]
It Ain't Gonna Happen. (From now on, I'll write this as IAGH.)
In Python 3000, we'll actually *remove* ordering between arbitrary
types as a feature; only types that
Josiah Carlson wrote:
And you can actually compare str and unicode, so, if you have a str that
is greater than the unicode, you run into this issue. With unicode
becoming str in Py3k, we may not run into this issue much then, unless
bytes are comparable to str, in which case we end up witht
Hi,
I'd like to backport the patches I've done to the trunk regarding
universal binary support for OSX and endian issues in Mac specific
modules.
The last set seems easy enough, all of those are clearly bugfixes.
I'm not sure if the universal binary patches are acceptable for
backport
Sounds like an all-round good plan to me.
On 5/11/06, Ronald Oussoren [EMAIL PROTECTED] wrote:
Hi,
I'd like to backport the patches I've done to the trunk regarding
universal binary support for OSX and endian issues in Mac specific
modules.
The last set seems easy enough, all of those are
On 5/11/06, Vladimir 'Yu' Stepanov [EMAIL PROTECTED] wrote:
If for Python-3000 similar it will be shown concerning types
str(), int(), complex() and so on, and the type of exceptions
will strongly vary, it will make problematic redefinition of
behavior of function of sorting.
Not really.
Guido van Rossum wrote:
On 5/11/06, Vladimir 'Yu' Stepanov [EMAIL PROTECTED] wrote:
If for Python-3000 similar it will be shown concerning types
str(), int(), complex() and so on, and the type of exceptions
will strongly vary, it will make problematic redefinition of
behavior of function of
Neal Norwitz wrote:
Martin: msilib -- Martin/Andrew is this done?
That's done, yes.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Ronald Oussoren wrote:
The rationale for this is simple: Apple seems to pick up a recent
copy of python for every new major release of OSX (Python 2.2.x for
Jaguar, Python 2.3.0 for Panther, Python 2.3.5 for Tiger) and is
therefore likely to use Python 2.4.x for the next release of the
Edward Loper wrote:
It might be useful in some cases to have a keyword argument to
sort/sorted that says to ignore exceptions arising from comparing
elements, and leaves the ordering of non-comparable values undefined.
Why? Far better to use a key (or cmp if you really want) that imposes a
I'm about to write some code to manage sets, and wanted to float a few
thoughts here because I have various ideas about how to implement what I
want to do, and I think one of them could be done by changing Python's set
type in useful and backward compatible way.
Apologies if this is discussed in
Hm... Without reading though all this, I expect that you'd be better
off implementing this for yourself without attempting to pull the
standard library sets into the picture (especially since sets.py is
obsolete as of 2.4; set and frozenset are now built-in types). You're
really after rather
A quick followup to my own posting:
I meant to say something about implementing __rand__() and pop(). I'd
either add another optional function argument to the constructor. It would
return a random element from the universe. Then for __rand__() and pop(),
you'd call until it (hopefully!) returned
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido Hm... Without reading though all this, I expect that you'd be
Guido better off implementing this for yourself without attempting to pull
Guido the standard library sets into the picture (especially since sets.py
Guido is obsolete as of
Guido Hm... Without reading though all this, I expect that you'd be
Guido better off implementing this for yourself without attempting to pull
Guido the standard library sets into the picture (especially since sets.py
Guido is obsolete as of 2.4; set and frozenset are now built-in types).
Guido
This is fine with me.
Note that 2.4.4 won't be out until after 2.5.0, so it's a couple of
months off yet.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Hello everyone!
We have been encountering several deadlocks in a threaded Python
application which calls subprocess.Popen (i.e. fork()) in some of its
threads.
This has occurred on Python 2.4.1 on a 2.4.27 Linux kernel.
Preliminary analysis of the hang shows that the child process blocks
upon
I use PyThreadState_SetAsyncExc to stop a python thread but there are
situations when the thread doesn't stop and continues executing
normally. After some debugging, I realized that the problem is that
PyThreadState_SetAsyncExc was called when the thread was inside a
native extension, that for
Gabriel Becedillas wrote:
PyThreadState_SetAsyncExc was called when the thread was inside a
native extension, that for some reason calls PyErr_Clear.
Maybe PyThreadState_SetAsyncExc should set a flag that
says this is an async exception, don't clear it, and
have PyErr_Clear take notice of that
Gabriel Becedillas wrote:
Does anybody see any problem with this approach ?, Does anybody have a
cleaner/better solution ?
I don't think there *is* a solution: asynchronous exceptions and thread
cancellation just cannot work.
In the specific case, the caller of PyErr_Clear will continue its
21 matches
Mail list logo
