-----BEGIN PGP SIGNED MESSAGE-----
When mailing there, I get this error. Not sure where to report.
Final-Recipient: rfc822; sdrees(a)sdrees.de
Remote-MTA: dns; stefan.zinzdrees.de
Diagnostic-Code: smtp; 550 5.1.1 <sdrees(a)sdrees.de>: Recipient address
rejected: User unknown in local recipient table
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
jabber / xmpp:email@example.com _/_/ _/_/ _/_/_/_/_/
. _/_/ _/_/ _/_/ _/_/ _/_/
"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-----
In Python 3.2, PyUnicode_Resize() expects a number of Py_UNICODE units,
whereas Python 3.3 expects a number of characters.
It is tricky to convert a number of Py_UNICODE units to a number of
characters, so it is diffcult to provide a backward compatibility
PyUnicode_Resize() function taking a number of Py_UNICODE units in Python 3.3.
Should we rename PyUnicode_Resize() in Python 3.3 to avoid surprising bugs?
The issue only concerns Windows with non-BMP characters, so a very rare use
The easiest solution is to do nothing in Python 3.3: the API changed, but it
doesn't really matter. Developers just have to be careful on this particular
issue (which is not well documented today).
I've volunteered to be the Release Manager for Python 3.4. The FLUFL
has already given it his Sloppy Wet Kiss Of Approval, and we talked to
Georg and he was for it too. There's no formal process for selecting
the RM, so I may already be stuck with the job, but I thought it best to
pipe up on python-dev in case someone had a better idea.
But look! I'm already practicing: NO YOU CAN'T CHECK THAT IN. How's
that? Needs work?
I look forward to seeing how the sausage is made,
On Tue, 22 Nov 2011 13:38:03 +0100
giampaolo.rodola <python-checkins(a)python.org> wrote:
> diff --git a/Misc/ACKS b/Misc/ACKS
> --- a/Misc/ACKS
> +++ b/Misc/ACKS
> @@ -11,7 +11,7 @@
> PS: In the standard Python distribution, this file is encoded in UTF-8
> and the list is in rough alphabetical order by last names.
> -Matt Mulsow
> +Chris Clark
> Rajiv Abraham
"The list is in rough alphabetical order by last names".
I'm trying to rewrite PyUnicode_EncodeDecimal() to upgrade it to the new
Unicode API. The problem is that the function is not accessible in Python nor
tested. Should we document and test it, leave it unchanged and deprecate it,
or simply remove it?
Python has a PyUnicode_EncodeDecimal() function. It was used in Python 2 by
int, long and complex constructors. In Python 3, the function is no more used:
it has been replaced by PyUnicode_TransformDecimalToASCII() in Python <= 3.2
and _PyUnicode_TransformDecimalAndSpaceToASCII() in Python 3.3.
PyUnicode_EncodeDecimal() goes into an unlimited loop if there is more than
one unencodable character. It's a known bug and there is a patch:
PyUnicode_EncodeDecimal() is undocumented and not tested:
Stefan Krah uses PyUnicode_EncodeDecimal() in its cdecimal project.
See also "Malformed error message from float()" issue:
Python 3.3 has now 3 encoders to decimal:
- _PyUnicode_TransformDecimalAndSpaceToASCII() (new in 3.3)
_PyUnicode_TransformDecimalAndSpaceToASCII() replaces also Unicode spaces with
ASCII spaces. PyUnicode_EncodeDecimal() and
PyUnicode_TransformDecimalToASCII() take Py_UNICODE* strings.
PyUnicode_EncodeDecimal() requires an output buffer and it has no argument for
the size of the output buffer. It is unsafe: it leads to buffer overflow if the
buffer is too small.
I haven't seen any strong objections, so I would like to go ahead and
commit PEP 3155 (*) soon. Is anyone against it?
(*) "Qualified name for classes and functions"
I was looking through the errors which occur when running the test suite of
Django's py3k branch under Python 3, and one particular set of errors caught my
eye which is unrelated to the bytes/str dance. These errors occur in some Django
utility code, which supplies a SimpleLazyObject (new-style) class . This
implements a proxy, which is initialised using a callable. The callable returns
the object to be wrapped, and it's called when needed to set up the wrapped
The SimpleLazyObject needs to pretend to be the class of the wrapped object,
e.g. for equality tests. This pretending is done by declaring __class__ as a
property in SimpleLazyObject which fetches and returns the __class__ attribute
of the wrapped object. This approach doesn't work in Python 3, however: the
property named __class__ doesn't show up in the class dict of SimpleLazyObject,
and moreover, there are restrictions on what you can set __class__ to - e.g.
Python complains if you try and set a __class__ attribute on the instance to
anything other than a new-style class.
What's the simplest way in Python 3 of implementing the equivalent approach to
pretending to be a different class? Any pointers appreciated.
Thanks and regards,
With the PEP 393, the Py_UNICODE is now deprecated and scheduled for removal
in Python 4. PyUnicode_AsUnicode() and PyUnicode_AsUnicodeAndSize() functions
are still commonly used on Windows to get the string as wchar_t* without
having to care of freeing the memory: it's a borrowed reference (pointer).
I would like to add a new PyUnicode_AsWideChar() function which would return
the borrowed reference, exactly as PyUnicode_AsUnicode(). The problem is that
"PyUnicode_AsWideChar" already exists in Python 3.2, as
Do you have an suggestion for a name of such function?