-----BEGIN PGP SIGNED MESSAGE-----
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
jabber / xmpp:firstname.lastname@example.org _/_/ _/_/ _/_/_/_/_/
. _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
On Thu, 23 Dec 2010 19:41:33 +0100 (CET)
eric.araujo <python-checkins(a)python.org> wrote:
> def __index__(self):
> - """index(self)"""
> + """someobject[self]"""
This is misleading as to what the method actually does, as you can read
in the implementation:
> return int(self)
In 2008, I proposed a patch to raise a Python exception on SIGSEVG
signal. In some cases, it's possible to catch the exception, log it, and
continue the execution. But because in some cases, the Python internal
state is corrupted, the idea was rejected (see the issue #3999).
Someone asked me to display the Python backtrace on SIGSEGV, instead of
raising an exception. I implemented this idea in issue #8863. After 9
versions, I think that the patch is ready for inclusion. It catchs
SIGSEGV, SIGFPE, SIGBUS and SIGILL signals, and also display the Python
backtrace on fatal errors. Because some operating systems have their own
fault handler (eg. Ubuntu with apport), Dave Malcolm asked me to add an
option disable the Python handler. That's why I added the
PYTHONNOFAULTHANDLER environment variable (we all love long variable
names!). For an OS vendor, it looks like an environment variable is more
practical than a command line option. Eg. Mandriva sets
PYTHONDONTWRITEBYTECODE for the whole system.
Raymond Hettinger asked me on IRC to write an email about the new
environment variable, so here is the question: do you agree to add the
I have this defect here http://bugs.python.org/issue10296
ctypes catches BreakPoint error on windows 32
that I posted a while back and had no response to. This is ctypes. Would anyone care to take a look?
On 12/22/2010 8:46 AM, Georg Brandl wrote:
> Am 22.12.2010 02:15, schrieb Nick Coghlan:
>> On Wed, Dec 22, 2010 at 6:18 AM, Georg Brandl<georg(a)python.org> wrote:
>>> Since PEP 3003, the Moratorium on Language Changes, is in effect, there
>>> are no changes in Python's syntax and built-in types in Python 3.2.
>> Minor nit - we actually did tweak a few of the builtin types a bit
>> (mostly the stuff to improve Sequence ABC conformance and to make
>> range objects more list-like)
> Indeed, I'll fix this wording for the next announcement. (And I will
> mention SSL, sorry Antoine).
If you're only going to mention some vague "some builtins had minor
changes", then I'm fine with that. If you're going to enumerate all such
changes, that will be a bigger job. There were 2 such changes I'm aware
of: str.format_map (#6081) and the addition of alternate ("#")
formatting to float, complex and decimal (#7094) __format__ methods.
For this announcement I don't think it's necessary to list them all.
Hello! I need to inform people I'm changing my online identity. Domain
phd.pp.ru will die Dec 27 (I'll try to reregister it to extend its life
for a few months). My new personal domain will be phdru.name, primary
email will be "phd" (in case one makes a mistake and write "phdru" two
times - the address is an alias for "phd").
The new domain is already delegated, email and site works. I'm working
on changing all my email subscriptions.
Oleg Broytman http://phd.pp.ru/ phd(a)phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
Something I noticed after installing the 3.2 beta on my Windows 7
laptop is that the start menu shortcuts aren't particularly search
friendly. Searching loses the heirarchical information, so attempting
to directly locate "pyt" provides two separate "Python Command Line"
shortcuts, with no indicator as to which one will start which version.
Given the changing dynamics of the desktop launch menus to better
support direct access as an alternative to hierarchical navigation,
would it be reasonable to consider including the major version number
in the start menu shortcut names?
(Question is mainly for Martin, obviously, but I'm also curious if
anyone else has encountered the same thing)
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia