Since dict is ordered in CPython 3.6, it can be used instead of
OrderedDict in some places (e.g. for implementing simple limited
caches). But since this is implementation detail, it can't be used in
the stdlib unconditionally. Needed a way to check whether dict is ordered.
Actually there are two levels of "ordering".
1. Dict without deletions is iterated in the order of adding items.
Raymond's original compact dict implementation satisfied this claim.
2. In addition the order is preserved after deletion operations. Naoki's
implementation satisfies this more strong claim.
A number of builtin iterator classes (but not all builtin iterator
classes) are registered with the Iterator ABC in
Lib/_collections_abc.py. But isinstance(it, Iterable) check works
without explicit registration, because Iterable has __subclasshook__
that checks iterator methods. Is there a need in explicit
registrations? Or their can be safely removed?
PEP 7 requires CPython to use C code conforming to the venerable C89
standard. Traditionally, we've been stuck with C89 due to poor C support
in MSVC. However, MSVC 2013 and 2015 implement the key features of C99.
C99 does not offer anything earth-shattering; here are the features I
think we'd find most interesting:
- Variable declarations can be on any line: removes possibly the most
annoying limitation of C89.
- Inline functions: We can make Py_DECREF and Py_INCREF inline functions
rather than unpleasant macros.
- C++-style line comments: Not an killer feature but commonly used.
In summary, some niceties that would make CPython hacking a little more
So, what say you to updating PEP 7 to allow C99 features for Python 3.6
(in so much as GCC and MSVC support them)?
I'm sure this has a simple explanation (and is probably only of historical
interest at this point), but ...
While starting to port the Python Sybase module to Python 3, among other
hurdles, I noticed that RO is no longer defined. Looking in structmember.h,
I see that most of the macros defined there are missing a PY_ prefix. Given
that these are macros which are likely to be used by extension modules and
are thus really part of the C API, shouldn't they have PY_ or _PY_
prefixes? This file got its start in 1990, so would surely have been around
for the great renaming
Looking at the documentation on defining new types, I saw no mention of
these peculiarly named constants, though they are clearly documented.
Can someone please review the patch attached to:
The patch seems safe and well defined, but it would be nice to have
more reviews on it.
It's a crash (assertion error) in Python >= 3.4 which occurs
"sometimes" in asyncio.
when developing my dedent tool, I stumbled over the following
In dedent, I had the line
from __future__ import print_function
Later in the script, I do some
and I was surprised:
The exec() script inherited the __future__ statement!
It behaved like the future statement were implicitly there.
Is that a bug or a feature?
You can try the effect by "pip install dedent" and adding
the future statement there.
I'd like to know if this is a bug (and I think so)
Christian Tismer :^) tismer(a)stackless.com
Software Consulting : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://github.com/PySide
14482 Potsdam : GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776 fax +49 (30) 700143-0023