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