x86 Windows Server 2003 [SB] 3.x: 3 tests failed, test___all__ test_gc test_ssl
x86 Windows7 3.x: 3 tests failed, test___all__ test_gc test_ssl
x86 Gentoo Non-Debug 3.x: 3 tests failed, test_logging
x86 Gentoo 3.x: 2 tests failed, test_logging test_urllib2net
x86 Ubuntu Shared 3.x: 1 test failed, test_logging
AMD64 Windows7 SP1 3.x: 4 tests failed, test___all__ test_gc
AMD64 OpenIndiana 3.x: 1 test failed, test_logging
AMD64 Ubuntu LTS 3.x: 1 test failed, test_logging
AMD64 FreeBSD 9.0 3.x: 1 test failed, test_logging
Can someone please look at these failures? (I don't have time for this
In the context PyPy, we've recently seen again the issue of "x is y"
not being well-defined on immutable constants. I've tried to
summarize the issues and possible solutions in a mail to pypy-dev 
and got some answers already. Having been convinced that the core is
a language design issue, I'm asking for help from people on this list.
(Feel free to cross-post.)
To summarize: the issue is a combination of various optimizations that
work great otherwise. For example we can store integers directly in
lists of integers, so when we read them back, we need to put them into
fresh W_IntObjects (equivalent of PyIntObject). We solved temporarily
the issue of "I'm getting an object which isn't ``is``-identical to
the one I put in!" by making all equal integers ``is``-identical.
This required hacking at ``id(x)`` as well to keep the requirement ``x
is y <=> id(x)==id(y)``. This is getting annoying for strings, though
-- how do you compute the id() of a long string? Give a unique long
integer? And if we do the same for tuples, what about their id()?
The long-term solution that seems the most stable to me would be to
relax the requirement ``x is y <=> id(x)==id(y)``. If we can get away
with only ``x is y <= id(x)==id(y)`` then it would allow us to
implement ``is`` in a consistent way (e.g. two strings with equal
content would always be ``is``-identical) while keeping id()
reasonable (both in terms of complexity and of size of the resulting
long number). Obviously ``x is y <=> id(x)==id(y)`` would still be
true if any of ``x`` or ``y`` is not an immutable "by-value" built-in
This is clearly a language design issue though. I can't really think
of a use case that would break if we relax the requirement, but I
might be wrong. It seems to me that at most some modules like pickle
which use id()-keyed dictionaries will fail to find some
otherwise-identical objects, but would still work (even if tuples are
"relaxed" in this way, you can't have cycles with only tuples).
On 05/05/2013 10:07 AM, � wrote:> I'm chiming in late, but am I the only one who's really bothered by the syntax?
> class Color(Enum):
> red = 1
> green = 2
> blue = 3
No, you are not only one that's bothered by it. I tried it without assignments until I discovered that bugs are way too
easy to introduce. The problem is a successful name lookup looks just like a name failure, but of course no error is
raised and no new enum item is created:
--> class Color(Enum):
... red, green, blue
--> class MoreColor(Color):
... red, orange, yellow
--> type(MoreColor.red) is MoreColor
<MoreColor.orange: 4> # value should be 5
About the closest you going to be able to get is something like:
e, _next = _next, _next + 1
red = e()
green = e()
blue = e()
and you can keep using `e()` for all your enumerations, since you don't care what actual value each enumeration member
happens to get.
PEP 435 is ready for final review. A lot of the feedback from the last few
weeks of discussions has been incorporated. Naturally, not everything could
go in because some minor (mostly preference-based) issues did not reach a
consensus. We do feel, however, that the end result is better than in the
beginning and that Python can finally have a useful enumeration type in the
I'm attaching the latest version of the PEP for convenience. If you've read
previous versions, the easiest way to get acquainted with the recent
changes is to go through the revision log at http://hg.python.org/peps
A reference implementation for PEP 435 is available at
Kind regards and happy weekend.
Split off from the PEP 435 - requesting pronouncement thread.
Think I've come up with a system that works for my auto-numbering case
without knowing the internals of enum_type. Patch passes all existing test
cases. The patch does two things:
1. Finds the first non-Enum class on the MRO of the new class and uses that
as the enum type.
2. Instead of directly setting the _name and _value of the enum_item, it
lets the Enum class do it via Enum.__init__(). Subclasses can override
this. This gives Enums a 2-phase construction just like other classes.
diff -r 758d43b9f732 ref435.py
--- a/ref435.py Fri May 03 18:59:32 2013 -0700
+++ b/ref435.py Sun May 05 13:43:56 2013 +1000
@@ -116,7 +116,17 @@
if bases[-1] is Enum:
obj_type = bases
- obj_type = bases[-1].__mro__ # e.g. (IntEnum, int,
+ obj_type = None
+ for base in bases:
+ for c in base.__mro__:
+ if not issubclass(c, Enum):
+ obj_type = c
+ if obj_type is not None:
obj_type = object
# save enum items into separate mapping so they don't get baked
@@ -143,8 +153,7 @@
enum_item = object.__new__(enum_class)
enum_item = obj_type.__new__(enum_class, value)
- enum_item._value = value
- enum_item._name = e
+ enum_item.__init__(e, value)
enum_map[e] = enum_item
enum_class.__aliases__ = aliases # non-unique enums names
enum_class._enum_names = enum_names # enum names in definition
@@ -232,6 +241,10 @@
raise ValueError("%s is not a valid %s" % (value, cls.__name__))
+ def __init__(self, name, value):
+ self._name = name
+ self._value = value
return "<%s.%s: %r>" % (self.__class__.__name__, self._name,
__slots__ = ()
def __new__(cls, value):
if value is Ellipsis:
i = cls._auto_number
i = cls._auto_number = 0
i = cls._auto_number = value
cls._auto_number += 1
return int.__new__(cls, i)
class AutoIntEnum(AutoInt, IntEnum):
def __init__(self, name, value):
super(AutoIntEnum, self).__init__(name, int(self))
a = ...
b = 3
c = ...
a = ...
b = ...
c = ...
---------- Run ----------
<Enum 'TestAutoIntEnum'> [<TestAutoIntEnum.a: 0>, <TestAutoIntEnum.b: 3>,
<Enum 'TestAutoIntEnum2'> [<TestAutoIntEnum2.a: 0>, <TestAutoIntEnum2.b:
1>, <TestAutoIntEnum2.c: 2>]
On 2013-02-26, 16:25 GMT, Terry Reedy wrote:
> On 2/21/2013 4:22 PM, Matej Cepl wrote:
>> as my method to commemorate Aaron Swartz, I have decided to port his
>> html2text to work fully with the latest python 3.3. After some time
>> dealing with various bugs, I have now in my repo
>> https://github.com/mcepl/html2text (branch python3) working solution
>> which works all the way to python 3.2 (inclusive;
>> https://travis-ci.org/mcepl/html2text). However, the last problem
>> remains. This
>> <li>Run this command:
>> <pre>ls -l *.html</pre></li>
>> should lead to
>> * Run this command:
>> ls -l *.html
>> * ?
>> but it doesn’t. It leads to this (with python 3.3 only)
>> * Run this command:
>> ls -l *.html
>> * ?
>> Does anybody know about something which changed in modules re or
>> http://docs.python.org/3.3/whatsnew/changelog.html between 3.2 and
>> 3.3, which could influence this script?
> Search the changelob or 3.3 misc/News for items affecting those two
> modules. There are at least 4.
> It is faintly possible that the switch from narrow/wide builds to
> unified builds somehow affected that. Have you tested with 2.7/3.2 on
> both narrow and wide unicode builds?
So, in the end, I have went the long way and bisected cpython to
find the commit which broke my tests, and it seems that the
culprit is http://hg.python.org/cpython/rev/123f2dc08b3e so it is
clearly something Unicode related.
Unfortunately, it really doesn't tell me what exactly is broken
(is it a known regression) and if there is known workaround.
Could anybody suggest a way how to find bugs on
http://bugs.python.org related to some particular commit (plain
search for 123f2dc0 didn’t find anything).
P.S.: Crossposting to python-devel in hope there would be
somebody understanding more about that particular commit. For
that I have also intentionally not trim the original messages to
http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
When you're happy that cut and paste actually works I think it's
a sign you've been using X-Windows for too long.
-- from /. discussion on poor integration between KDE and
I've just read a few dozen enum-related emails, and there are so many more.
I would like to form an opinion about the proposal(s), but I feel I don't
know what the actual issues are anymore.
In the past, somebody usually presented a summary of the issues so far,
and that was a good point for late comers to get up to speed and weigh in.
(It can be here or in the PEP.) It is also a good point to focus the
discussion (which seems to have wandered quite far from sensible Pythonic
design in places).
Thanks in advance,
In order for the Enum convenience function to be pickleable, we have this line of code in the metaclass:
enum_class.__module__ = sys._getframe(1).f_globals['__name__']
This works fine for Cpython, but what about the others?