PyDict_GetItem() and PyDict_SetItem() don't call __getitem__ and __setitem__
for dict subclasses. Is there a reason for that?
I found this surprising behaviour when I replaced a dict by a custom dict
checking the key type on set. But my __setitem__ was not called because the
function using the dict was implemented in C (and I didn't know that ;-)).
I had announced this to import-sig already; now python-dev.
I have now written an implementation of PEP 382, and fixed some details
of the PEP in the process. The implementation is available at
With this PEP, a Python package P can consist of either a P/__init__.py
directory and module, or multiple P.pyp directories, or both. Using a
directory suffix resulted from the following requirements/observations:
- people apparently prefer an approach where a directory has to be
declared as a Python package (several people commented this after
my PyConDE talk, expressing dislike of how Java packages are
- people also commented that any declaration should indicate that this
is about Python, hence the choice of .pyp as the directory suffix.
- in choosing between a file marker inside of the directory (e.g.
zope-interfaces.pyp) and a directory suffix, the directory suffix
wins for simplicity reasons. A file marker would have to have a
name which wouldn't matter except that it needs to be unique - which
is a confusing requirement that people likely would fail to meet.
In the new form, the PEP was much easier to implement than in the first
version (plus I understand import.c better now).
This implementation now features .pyp directories, zipimporter support,
documentation and test cases.
As the next step, I'd like to advance this to ask for pronouncement.
Given it returns an eternal object, and it's almost always used
temporarily (for attribute lookup, string joining, etc.), it would seem
more practical for it to return a borrowed reference.
Hello Dev Teem,
Guido told me to send you this idea...
Improving productivity is one of my Strength. Please check a very small
module i'v made for improving the debugger traceback. See the
pybettererror.py on sourceforge:
It's hard to find something to complain about in python. This one was a too
good idea to keep for myself.
Martin Goudreau from Montreal
> branch: 2.7
> user: Petri Lehtinen <petri(a)digip.org>
> date: Sun Oct 30 13:55:02 2011 +0200
> Avoid unnecessary recursive function calls (closes #10519)
> branch: 2.7
> user: Jesus Cea <jcea(a)jcea.es>
> date: Mon Oct 31 16:02:12 2011 +0100
> Closes #13283: removal of two unused variable in locale.py
I thought that patches that clean up code but don’t fix actual bugs were
not done in stable branches. Has this changed?
(The first commit quoted above may be a performance fix, which would be
There is a backwards compatibility issue with PEP 393 and Unicode exceptions:
the start and end indices: are they Py_UNICODE indices, or code point indices?
On the one hand, these indices are used in formatting error messages such as
"codec can't encode character \u%04x in position %d", suggesting they
indices into the string (counting code points).
On the other hand, they are used by error handlers to lookup the character,
and existing error handlers (including the ones we have now) use
PyUnicode_AsUnicode to find the character. This suggests that the indices
should be Py_UNICODE indices, for compatibility (and they currently do
work in this way).
The indices can only be different if the string is an UCS-4 string, and
Py_UNICODE is a two-byte type (i.e. on Windows).
So what should it be?
As a compromise, it would be possible to convert between these indices,
by counting the non-BMP characters that precede the index if the indices
might differ. That would be expensive to compute, but provide backwards
compatibility to the C API. It's less clear what backwards compatibility
to Python code would require - most likely, people would use the indices
for slicing operations (rather than performing an UTF-16 conversion and
performing indexing on that).
On 11/4/2011 4:08 PM, raymond.hettinger wrote:
> - .. note::
> + Like file objects, shelve objects should closed explicitly to assure
> + that the peristent data is flushed to disk.
Missing "be" there, I think: "should be closed".
Le vendredi 4 novembre 2011 18:23:26, martin.v.loewis a écrit :
> changeset: 73353:9191f804d376
> parent: 73351:2bec7c452b39
> user: Martin v. Löwis <martin(a)v.loewis.de>
> date: Fri Nov 04 18:23:06 2011 +0100
> Port code page codec to Unicode API.
Oh please, try to avoid introducing tabs when a file uses spaces. All C files
are supposed to use an indentation of 4 spaces.