Re: [Python-Dev] NoneType(None) raises exception
On Thu, 25 Apr 2013 16:09:41 -0700 Ethan Furman wrote: > We just fixed NoneType() to return None instead of raising an exception. > > Another use-case for calling NoneType is working with ORMs: > > result = [] > for field in row: > type = get_type(field) # returns int, bool, str, NoneType, ... > result.append(type(field)) I don't understand what the use case is. If you already have a value of None, why do you call NoneType on it again? Perhaps you should write: if not isinstance(type, field): field = type(field) Rehatds Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] NoneType(None) raises exception
On Fri, Apr 26, 2013 at 1:09 AM, Ethan Furman wrote: > We just fixed NoneType() to return None instead of raising an exception. > > Another use-case for calling NoneType is working with ORMs: > > result = [] > for field in row: > type = get_type(field) # returns int, bool, str, NoneType, ... > result.append(type(field)) Having it return NoneType there seems a strange thing to do, as have a None field makes no sense. Why would you have a column that can only contain the value None? What is returning NoneType at that point supposed to signify? If it's supposed to signify that the value is NULL, I think the above code is a very strange way of handling that. get_type(field) should reasonably return the type of the column, not the type of the value you got, as that would be just type(field) and doing type(field)(field) is a bit pointless. :-) //Lennart ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
Steven D'Aprano wrote: I don't think iscallable will work, since that descriptors like staticmethod and classmethod aren't callable. Nor are properties. Hmmm, maybe we should look for a __get__ method as well? Enums of descriptors would seem to fall into the seriously-weird category as well. Or if, as Guido says, the only sensible things to use as enum values are ints and strings, just leave anything alone that isn't one of those. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
Piotr Duda wrote: There is at least one more problem, enum inheritance, given: class Colors(Enum): red = 1 green = 2 blue = 3 class MoreColors(Color): cyan = 4 magenta = 5 yellow = 6 what type is MoreColors.red? Given the implementation we're considering, it would probably be Colors. However, there's a worse problem with defining enum inheritance that way. The subtype relation for extensible enums works the opposite way to that of classes. To see this, imagine a function expecting something of type Colors. It knows what to do with red, green and blue, but not anything else. So you *can't* pass it something of type MoreColors, because not all values of type MoreColors are of type Colors. On the other hand, you *can* pass a value of type Colors to something expecting MoreColors, because every value of Colors is also in MoreColors. Moreover, suppose we have another type: class YetMoreColors(Colors): orange = 4 purple = 5 pink = 6 Now suppose a function expecting Colors gets an enum with the integer value 4. How should it be interpreted? Is it cyan or orange? What about if you write it to a database column and read it back? These considerations suggest to me that subclassing enums should be disallowed, or at least not officially supported. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
26.04.13 11:00, Greg Ewing написав(ла): However, there's a worse problem with defining enum inheritance that way. The subtype relation for extensible enums works the opposite way to that of classes. To see this, imagine a function expecting something of type Colors. It knows what to do with red, green and blue, but not anything else. So you *can't* pass it something of type MoreColors, because not all values of type MoreColors are of type Colors. This is why enums are not subclassable in other languages (i.e. Java). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 26/04/13 18:00, Greg Ewing wrote: However, there's a worse problem with defining enum inheritance that way. The subtype relation for extensible enums works the opposite way to that of classes. To see this, imagine a function expecting something of type Colors. It knows what to do with red, green and blue, but not anything else. So you *can't* pass it something of type MoreColors, because not all values of type MoreColors are of type Colors. On the other hand, you *can* pass a value of type Colors to something expecting MoreColors, because every value of Colors is also in MoreColors. Moreover, suppose we have another type: class YetMoreColors(Colors): orange = 4 purple = 5 pink = 6 Now suppose a function expecting Colors gets an enum with the integer value 4. How should it be interpreted? Is it cyan or orange? What about if you write it to a database column and read it back? There are many places where Python demands an actual int, not a subclass. See the recent thread "Semantics of __int__, index". There's no reason why a function that expects a Color *must* accept subclasses as well. If it can, great. If it can't, document it and move on. It's not Color's responsibility to know everything about every subclass. Invert your thinking: the subclasses are in charge, not Color. Color can't be expected to give a value to 4. Only the subclass that defines it can. This is only a problem if you believe that subclassing == taxonomy hierarchy. It isn't. http://pyvideo.org/video/879/the-art-of-subclassing -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 26/04/2013 06:21, Ethan Furman wrote: On 04/25/2013 08:14 PM, Greg wrote: On 26/04/2013 1:28 p.m., Ethan Furman wrote: Interesting idea, but why does Day(3) have to be disallowed to make it work? Because it's ambiguous. Which day of the week is number 3? It depends on where you start. Ah. I should perhaps point out that the numbers assigned to the values initially are just to establish the relative ordering. They wouldn't be directly accessible once the values are created. To get an integer value corresponding to a Day value, you would have to do arithmetic: Day.wednesday - Day.sunday --> 3 That would make it very hard to do data storage and retrieval. I think that if the definition of Day says wednesday = 3 then Day(3) should return Day.wednesday, but if it's a circular enum then <, etc, should be disallowed. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 04/26/2013 12:34 AM, Greg Ewing wrote: Or if, as Guido says, the only sensible things to use as enum values are ints and strings, just leave anything alone that isn't one of those. The standard Java documentation on enums: http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html has an example enum of a "Planet", a small record type containing mass and radius--each of which are floats. I don't know whether or not it constitutes good programming, but I'd be crestfallen if Java enums were more expressive than Python enums ;-) FWIW I'm +0.5 on "the enum metaclass ignores callables and descriptors". This seems reasonably Pythonic, much more so than "ignore everything except ints and strings". And as long as we're special-casing it I think we should opt for flexibility. Certainly I see nothing wrong with enums of float, complex, Decimal, and Fraction, so I don't see a good place to draw the line with a whitelist. //arry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2013-04-19 - 2013-04-26) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3949 (+21) closed 25674 (+32) total 29623 (+53) Open issues with patches: 1760 Issues opened (43) == #16316: Support xz compression in mimetypes module http://bugs.python.org/issue16316 reopened by eric.araujo #17192: libffi-3.0.13 import http://bugs.python.org/issue17192 reopened by r.david.murray #17798: IDLE: can not edit new file names when using -e http://bugs.python.org/issue17798 opened by roger.serwy #17799: settrace docs are wrong about "c_call" events http://bugs.python.org/issue17799 opened by nedbat #17800: Add gc.needs_finalizing() to check if an object needs finalisi http://bugs.python.org/issue17800 opened by ncoghlan #17802: html.HTMLParser raises UnboundLocalError: http://bugs.python.org/issue17802 opened by bmispelon #17803: Calling Tkinter.Tk() with a baseName keyword argument throws U http://bugs.python.org/issue17803 opened by y-fujii #17804: streaming struct unpacking http://bugs.python.org/issue17804 opened by pitrou #17805: No such class: multiprocessing.pool.AsyncResult http://bugs.python.org/issue17805 opened by tkf #17806: Add keyword args support to str/bytes.expandtabs() http://bugs.python.org/issue17806 opened by ezio.melotti #17807: Generator cleanup without tp_del http://bugs.python.org/issue17807 opened by pitrou #17808: No code example for Event object in threading module http://bugs.python.org/issue17808 opened by amysyk #17809: FAIL: test_expanduser when $HOME ends with / http://bugs.python.org/issue17809 opened by koobs #17810: Implement PEP 3154 (pickle protocol 4) http://bugs.python.org/issue17810 opened by alexandre.vassalotti #17811: Improve os.readv() and os.writev() documentation and docstring http://bugs.python.org/issue17811 opened by Nikratio #17812: Quadratic complexity in b32encode http://bugs.python.org/issue17812 opened by serhiy.storchaka #17814: Popen.stdin/stdout/stderr documentation should mention object http://bugs.python.org/issue17814 opened by Nikratio #17816: Weak*Dictionary KeyErrors during callbacks http://bugs.python.org/issue17816 opened by Nils.Bruin #17818: aifc.Aifc_read/Aifc_write.getparams can return a namedtuple http://bugs.python.org/issue17818 opened by Claudiu.Popa #17819: removes need for CONFIG_SITE external configuration http://bugs.python.org/issue17819 opened by cavallo71 #17822: Save on Close windows (IDLE) http://bugs.python.org/issue17822 opened by Guilherme.Simões #17823: 2to3 fixers for missing codecs http://bugs.python.org/issue17823 opened by serhiy.storchaka #17824: pty.spawn handles errors improperly http://bugs.python.org/issue17824 opened by niemeyer #17825: Indentation.offset and SyntaxError.offset mismatch http://bugs.python.org/issue17825 opened by flox #17826: Setting a side_effect on mock from create_autospec doesn't wor http://bugs.python.org/issue17826 opened by michael.foord #17827: Document codecs.encode and codecs.decode http://bugs.python.org/issue17827 opened by ncoghlan #17828: More informative error handling when encoding and decoding http://bugs.python.org/issue17828 opened by ncoghlan #17829: csv.Sniffer.snif doesn't set up the dialect properly for a csv http://bugs.python.org/issue17829 opened by GhislainHivon #17831: urllib.URLopener.open breaks ActiveDirectory user http://bugs.python.org/issue17831 opened by Nataly.Glazyrina #17833: test_gdb broken PPC64 Linux http://bugs.python.org/issue17833 opened by David.Edelsohn #17834: Add Heap (and DynamicHeap) classes to heapq module http://bugs.python.org/issue17834 opened by allyourcode #17837: Support for building on ppc64p7 http://bugs.python.org/issue17837 opened by bkabrda #17838: Can't assign a different value for sys.stdin in IDLE http://bugs.python.org/issue17838 opened by Guilherme.Simões #17839: base64 module should use memoryview http://bugs.python.org/issue17839 opened by ncoghlan #17840: base64_codec uses assert for runtime validity checks http://bugs.python.org/issue17840 opened by ncoghlan #17841: Remove missing aliases from codecs documentation http://bugs.python.org/issue17841 opened by ncoghlan #17842: Add base64 module tests for a bytearray argument http://bugs.python.org/issue17842 opened by serhiy.storchaka #17843: Lib/test/testbz2_bigmem.bz2 trigger virus warnings http://bugs.python.org/issue17843 opened by christian.heimes #17844: Add link to alternatives for bytes-to-bytes codecs http://bugs.python.org/issue17844 opened by serhiy.storchaka #17845: Clarify successful build message http://bugs.python.org/issue17845 opened by brett.cannon #17846: Building Python on Windows - Supplementary info http://bugs.python.org/issue17846 opened by michael.kearney #17848: issue about compile with clang and build a
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
26.04.13 18:50, Larry Hastings написав(ла): On 04/26/2013 12:34 AM, Greg Ewing wrote: Or if, as Guido says, the only sensible things to use as enum values are ints and strings, just leave anything alone that isn't one of those. The standard Java documentation on enums: http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html has an example enum of a "Planet", a small record type containing mass and radius--each of which are floats. I don't know whether or not it constitutes good programming, but I'd be crestfallen if Java enums were more expressive than Python enums ;-) This example requires more than features discussed here. It requires an enum constructor. class Planet(Enum): MERCURY = Planet(3.303e+23, 2.4397e6) VENUS = Planet(4.869e+24, 6.0518e6) EARTH = Planet(5.976e+24, 6.37814e6) MARS= Planet(6.421e+23, 3.3972e6) JUPITER = Planet(1.9e+27, 7.1492e7) SATURN = Planet(5.688e+26, 6.0268e7) URANUS = Planet(8.686e+25, 2.5559e7) NEPTUNE = Planet(1.024e+26, 2.4746e7) def __init__(self, mass, radius): self.mass = mass # in kilograms self.radius = radius # in meters @property def surfaceGravity(self): # universal gravitational constant (m3 kg-1 s-2) G = 6.67300E-11 return G * self.mass / (self.radius * self.radius) def surfaceWeight(self, otherMass): return otherMass * self.surfaceGravity This can't work because the name Planet in the class definition is not defined. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 04/26/2013 08:50 AM, Larry Hastings wrote:
FWIW I'm +0.5 on "the enum metaclass ignores callables and
descriptors". This seems reasonably Pythonic, much more so than "ignore
everything except ints and strings". And as long as we're
special-casing it I think we should opt for flexibility. Certainly I see
nothing wrong with enums of float, complex, Decimal, and Fraction, so I
don't see a good place to draw the line with a whitelist.
A whitelist, if we go that route, should be on a per Enum basis -- so
something like:
class Planets(str, Enum):
PLUTO = 'it is too a planet!'
MERCURY = 'definitely a planet'
SATURN = 'darn big planet'
solar_mass = 82738273 # or some really big number
light_year = 1827499 # another really big number (of feet!)
def horrorscope(self, message):
return ('%s will be in retrograde... '
'don't communicate today.' % self)
and only PLUTO, MERCURY, and SATURN would be converted to enums.
--
~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On Fri, Apr 26, 2013 at 10:33 AM, Glenn Linderman wrote: > On 4/25/2013 9:19 PM, Guido van Rossum wrote: > > On Thu, Apr 25, 2013 at 8:39 PM, Glenn Linderman > wrote: > > an enumeration of objects whose class defines __call__ would > not be so weird. > > Seriously? You'd complexificate the basic usage in order to cater for > such an esoteric use case? The *only* use cases that matter at all for > enum values are ints and strings, and even the latter could be > considered a luxury when compared to other languages' enums. > > > No, I'd look for a solution/implementation that doesn't divide objects into > "plain" and "esoteric" cases. Py3 now treats everything as objects. So an > enumeration should be able to deal with any object as a value. I think you've lost track of the Zen of Python. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 04/26/2013 09:27 AM, Serhiy Storchaka wrote:
26.04.13 18:50, Larry Hastings написав(ла):
The standard Java documentation on enums:
http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html
This example requires more than features discussed here. It requires
an enum constructor.
class Planet(Enum):
MERCURY = Planet(3.303e+23, 2.4397e6)
[...]
This can't work because the name Planet in the class definition is not
defined.
It can't work because you inserted the word "Planet" there. If you omit
the word "Planet", this would work fine with something like the
metaclass instantiate-all-data-members behavior in flufl.enum 4.
Here is the hack, demonstrated in Python 3:
class Metaclass(type):
def __new__(cls, name, bases, namespace):
result = type.__new__(cls, name, bases, dict(namespace))
for name, value in namespace.items():
if not (callable(value) or name.startswith("__")):
value = result(name, value)
setattr(result, name, value)
return result
class Planet(metaclass=Metaclass):
MERCURY = (3.303e+23, 2.4397e6)
def __init__(self, name, value):
self.mass, self.radius = value
def surfaceGravity(self):
return 6.67300E-11 * self.mass / (self.radius ** 2)
def surfaceWeight(self, otherMass):
return otherMass * self.surfaceGravity()
print("If you weigh 175 pounds, on Mercury you'd weigh",
Planet.MERCURY.surfaceWeight(175))
//arry/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 04/26/2013 09:27 AM, Serhiy Storchaka wrote:
26.04.13 18:50, Larry Hastings написав(ла):
On 04/26/2013 12:34 AM, Greg Ewing wrote:
Or if, as Guido says, the only sensible things to use
as enum values are ints and strings, just leave anything
alone that isn't one of those.
The standard Java documentation on enums:
http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html
has an example enum of a "Planet", a small record type containing mass
and radius--each of which are floats. I don't know whether or not it
constitutes good programming, but I'd be crestfallen if Java enums were
more expressive than Python enums ;-)
This example requires more than features discussed here. It requires an
enum constructor.
This can't work because the name Planet in the class definition is not
defined.
The metaclass can define it easily:
- have generic helper class (I call mine `attrs`)
- __prepare__ creates an instance of the custom dict
- __prepare__ then inserts the helper class into the custom dict with
the same name as the (to be created) custom Enum type
- return the custom dict to Python
class is processed using custom dict
- __new__ gets the custom dict back from Python
- __new__ replaces all instances of the helper class with actual Enum
instances (which it creates on the spot)
- any other housekeeping necessary
- __new__ returns the new Enum type, complete with all Enum instances
Here's an example run:
8<--planets.py
from aenum import Enum
class Planet(Enum):
MERCURY = Planet(3.303e+23, 2.4397e6)
VENUS = Planet(4.869e+24, 6.0518e6)
EARTH = Planet(5.976e+24, 6.37814e6)
MARS= Planet(6.421e+23, 3.3972e6)
JUPITER = Planet(1.9e+27, 7.1492e7)
SATURN = Planet(5.688e+26, 6.0268e7)
URANUS = Planet(8.686e+25, 2.5559e7)
NEPTUNE = Planet(1.024e+26, 2.4746e7)
def __init__(self, mass, radius):
self.mass = mass # in kilograms
self.radius = radius # in meters
@property
def surfaceGravity(self):
# universal gravitational constant (m3 kg-1 s-2)
G = 6.67300E-11
return G * self.mass / (self.radius * self.radius)
def surfaceWeight(self, otherMass):
return otherMass * self.surfaceGravity
print(int(Planet.VENUS))
print(repr(Planet.VENUS))
print(Planet.VENUS.surfaceGravity)
8<--planets.py
8<--actual run
2
Planet('VENUS', 4.869e+24, 6051800.0, integer=2)
8.871391908774457
8<--actual run
--
~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 4/25/2013 9:19 PM, Guido van Rossum wrote: On Thu, Apr 25, 2013 at 8:39 PM, Glenn Linderman wrote: an enumeration of objects whose class defines __call__ would not be so weird. Seriously? You'd complexificate the basic usage in order to cater for such an esoteric use case? The *only* use cases that matter at all for enum values are ints and strings, and even the latter could be considered a luxury when compared to other languages' enums. No, I'd look for a solution/implementation that doesn't divide objects into "plain" and "esoteric" cases. Py3 now treats everything as objects. So an enumeration should be able to deal with any object as a value. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On Fri, Apr 26, 2013 at 10:36 AM, Guido van Rossum wrote: > On Fri, Apr 26, 2013 at 10:33 AM, Glenn Linderman > wrote: > > On 4/25/2013 9:19 PM, Guido van Rossum wrote: > > > > On Thu, Apr 25, 2013 at 8:39 PM, Glenn Linderman > > wrote: > > > > an enumeration of objects whose class defines __call__ would > > not be so weird. > > > > Seriously? You'd complexificate the basic usage in order to cater for > > such an esoteric use case? The *only* use cases that matter at all for > > enum values are ints and strings, and even the latter could be > > considered a luxury when compared to other languages' enums. > > > > > > No, I'd look for a solution/implementation that doesn't divide objects > into > > "plain" and "esoteric" cases. Py3 now treats everything as objects. So an > > enumeration should be able to deal with any object as a value. > > I think you've lost track of the Zen of Python. > I feel that this thread has lost track of it long ago. Some time back in the Enum discussions (some 350 messages ago or so), there was a proposal to have this: class Color(Enum): RED, BLUE, GREEN By doing some crazy-cool shenanigans. Although the syntax is great, it was rejected on the basis of being too magic. The recent proposals of folding Enum and EnumValue into one, having class members be instances of the class they're members of while supporting a bunch of other Enum requirements also go off the rails in terms of complexity and magic. In contrast, personally I feel the current proposal in PEP 435 has an appeal from the POV of simplicity. It really is a very nice separation of concerns between enum values and Enum as a container of such values. It even allows significant customization (IntEnum, etc) which is pretty simple to grok. It would be a shame to lose these for the sake of making Python a bit more like Java. Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
26.04.13 11:00, Greg Ewing написав(ла): However, there's a worse problem with defining enum inheritance that way. The subtype relation for extensible enums works the opposite way to that of classes. To see this, imagine a function expecting something of type Colors. It knows what to do with red, green and blue, but not anything else. So you *can't* pass it something of type MoreColors, because not all values of type MoreColors are of type Colors. On the other hand, you *can* pass a value of type Colors to something expecting MoreColors, because every value of Colors is also in MoreColors. I propose do not use an inheritance for extending enums, but use an import. class Colors(Enum): red = 1 green = 2 blue = 3 class MoreColors(Enum): from Colors import * cyan = 4 magenta = 5 yellow = 6 An inheritance we can use to limit a type of values. class Colors(int, Enum): # only int values red = 1 green = 2 blue = 3 Colors.viridity = green ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
26.04.13 05:13, Nick Coghlan написав(ла):
With a merged design, it becomes *really* hard to give the instances
custom behaviour, because the metaclass will somehow have to
differentiate between namespace entries that are intended to be
callables, and those which are intended to be instances of the enum.
This is not an easy problem to solve.
What if use mixins? Shouldn't it work without magic?
class ColorMethods:
def wave(self, n=1):
for _ in range(n):
print('Waving', self)
class Color(ColorMethods, Enum):
red = 1
white = 2
blue = 3
orange = 4
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
Thank you for your answers, Barry. Eli already answered me most of my
questions.
20.04.13 22:18, Barry Warsaw написав(ла):
On Apr 13, 2013, at 11:31 AM, Serhiy Storchaka wrote:
The str and repr of the enumeration class also provides useful information::
>>> print(Colors)
>>> print(repr(Colors))
Does the enumeration's repr() use str() or repr() for the enumeration values?
No, enumeration values have different reprs and strs.
Yes, values can have different reprs and strs (but ints haven't). What
of them uses repr of an enumeration item? I.e. what is str(Noises):
'' or ''?
class Noises(Enum)
dog = 'bark'
flufl.enum uses str(), but is it intentional? If yes, than it should be
specified in the PEP.
But if the value *is* important, enumerations can have arbitrary values.
Should enumeration values be hashable?
At least they should be comparable ("Iteration is defined as the sorted order
of the item values").
Given my previous responses, these questions should be already answered.
Eli and you have missed my first question. Should enumeration values be
hashable? If yes (flufl.enum requires hashability), then this should be
specified in the PEP. If no, then how you implements __getitem__? You
can use binary search (but values can be noncomparable) or linear search
which is not efficient.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On Fri, Apr 26, 2013 at 11:17 AM, Eli Bendersky wrote: > On Fri, Apr 26, 2013 at 10:36 AM, Guido van Rossum wrote: >> > On 4/25/2013 9:19 PM, Guido van Rossum wrote: >> I think you've lost track of the Zen of Python. > > I feel that this thread has lost track of it long ago. Perhaps. The thread certainly has lost focus -- there are separate subthreads about the ordering of items when iterating over the enum class and about the unification of the Enum and EnumValue classes, and perhaps others. > Some time back in the > Enum discussions (some 350 messages ago or so), there was a proposal to have > this: > > class Color(Enum): > RED, BLUE, GREEN > > By doing some crazy-cool shenanigans. Although the syntax is great, it was > rejected on the basis of being too magic. FWIW, I didn't think the syntax was great. "Great" syntax would have been something like enum Color: RED, BLUE, GREEN but introducing a new keyword isn't justifiable. > The recent proposals of folding Enum and EnumValue into one, having class > members be instances of the class they're members of while supporting a > bunch of other Enum requirements also go off the rails in terms of > complexity and magic. Yet the goal of the proposal is conceptual simplification: one class instead of two. Having class members that are also class instances is a non-issue. The complexity of the proposal is an implementation issue: we'd like to be able to define methods for the enum values, and the simplest way (for the user) to define methods for the enum values would be to allow def statements, possibly decorated, in the class. But now the implementation has to draw a somewhat murky line between which definitions in the class should be interpreted as enum value definitions, and which should be interpreted as method definitions. If we had access to the syntax used for the definition, this would be simple: assignments define items, def statements define methods. But at run time we only see the final object resulting from the definition, which may not even be callable in the case of certain decorators. I am still optimistic that we can come up with a rule that works well enough in practice (and the Zen rule to which I was referring was, of course, "practicality beats purity"). > In contrast, personally I feel the current proposal in PEP 435 has an appeal > from the POV of simplicity. It really is a very nice separation of concerns > between enum values and Enum as a container of such values. It even allows > significant customization (IntEnum, etc) which is pretty simple to grok. It > would be a shame to lose these for the sake of making Python a bit more like > Java. But it's not so much the "like Java" that matters to me. It's the realization that for the user who wants to define an enum type with some extra functionality, having a single class and putting the methods and the items in the same class is the simplest way to do it. The Java reference is just to point out that we're not exactly breaking new ground here. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Generator finalization and reference cycles
Hello, I have proposed a new generator finalization scheme in http://bugs.python.org/issue17807: it removes the tp_del from generator objects, instead electing to cleanup the generator (equivalent of calling close()) in the frame's tp_clean function. This way, generators with a try / finally block can be finalized even when they are part of reference cycles. This has stemmed from http://bugs.python.org/issue17468, which mentions a memory leak in Django due to uncollectable generators. Feedback welcome. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On Fri, Apr 26, 2013 at 2:41 PM, Guido van Rossum wrote: > On Fri, Apr 26, 2013 at 11:17 AM, Eli Bendersky wrote: > > On Fri, Apr 26, 2013 at 10:36 AM, Guido van Rossum > wrote: > >> > On 4/25/2013 9:19 PM, Guido van Rossum wrote: > >> I think you've lost track of the Zen of Python. > > > > I feel that this thread has lost track of it long ago. > > Perhaps. The thread certainly has lost focus -- there are separate > subthreads about the ordering of items when iterating over the enum > class and about the unification of the Enum and EnumValue classes, and > perhaps others. > I agree, and thanks for the thoughtful reply to my half-rant ;-) More comments below. > > > Some time back in the > > Enum discussions (some 350 messages ago or so), there was a proposal to > have > > this: > > > > class Color(Enum): > > RED, BLUE, GREEN > > > > By doing some crazy-cool shenanigans. Although the syntax is great, it > was > > rejected on the basis of being too magic. > > FWIW, I didn't think the syntax was great. "Great" syntax would have > been something like > > enum Color: > RED, BLUE, GREEN > > but introducing a new keyword isn't justifiable. > > > The recent proposals of folding Enum and EnumValue into one, having class > > members be instances of the class they're members of while supporting a > > bunch of other Enum requirements also go off the rails in terms of > > complexity and magic. > > Yet the goal of the proposal is conceptual simplification: one class > instead of two. > > But users are not exposed to two classes. And for us, implementors, keeping things separate is IMHO simplification. There's a conceptual difference between a value of an enumeration and a collection of such values. This difference helps, I think, make IntEnum possible relatively easily - we can actually have an enumerated value that is-a integer and can be used instead of integers in legacy code. This requirement will heap additional complexity on the alternative where the enum and enum value are unified into the same class. > Having class members that are also class instances is a non-issue. > > The complexity of the proposal is an implementation issue: we'd like > to be able to define methods for the enum values, and the simplest way > (for the user) to define methods for the enum values would be to allow > def statements, possibly decorated, in the class. But now the > implementation has to draw a somewhat murky line between which > definitions in the class should be interpreted as enum value > definitions, and which should be interpreted as method definitions. If > we had access to the syntax used for the definition, this would be > simple: assignments define items, def statements define methods. But > at run time we only see the final object resulting from the > definition, which may not even be callable in the case of certain > decorators. I am still optimistic that we can come up with a rule that > works well enough in practice (and the Zen rule to which I was > referring was, of course, "practicality beats purity"). > > > In contrast, personally I feel the current proposal in PEP 435 has an > appeal > > from the POV of simplicity. It really is a very nice separation of > concerns > > between enum values and Enum as a container of such values. It even > allows > > significant customization (IntEnum, etc) which is pretty simple to grok. > It > > would be a shame to lose these for the sake of making Python a bit more > like > > Java. > > But it's not so much the "like Java" that matters to me. It's the > realization that for the user who wants to define an enum type with > some extra functionality, having a single class and putting the > methods and the items in the same class is the simplest way to do it. > The Java reference is just to point out that we're not exactly > breaking new ground here. > My reference to Java was w.r.t. the static-typing-minded requirement that isinstance(Color.red, Color) == True. I don't think that 99% of use-cases will care about the type of Color.red, and those that do for obscure reasons can accept an obscure class (EnumValue-something) as long as they have something distinct to dispatch upon. Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
Guido van Rossum wrote: If we had access to the syntax used for the definition, this would be simple: assignments define items, def statements define methods. But at run time we only see the final object resulting from the definition, Another way we could tell the difference is if the def statement used a different protocol for making bindings than assignment. Suppose a def statement used in a class body called __defitem__, if it exists, instead of __setitem__. Then the metaclass would be able to do different things for defs and assignments. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
Eli Bendersky wrote: There's a conceptual difference between a value of an enumeration and a collection of such values. Not if you think of an enum as a type and a type as defining a set of values. From that point of view, the enum itself is already a collection of values, and introducing another object is creating an artificial distinction. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 4/26/2013 6:22 PM, Greg Ewing wrote: Guido van Rossum wrote: If we had access to the syntax used for the definition, this would be simple: assignments define items, def statements define methods. But at run time we only see the final object resulting from the definition, Another way we could tell the difference is if the def statement used a different protocol for making bindings than assignment. Suppose a def statement used in a class body called __defitem__, if it exists, instead of __setitem__. Then the metaclass would be able to do different things for defs and assignments. Well, some assignments could be for non-enumeration items, once you start allowing EnumItem in the list. Some method of grouping enumeration items, or grouping non-enumeration items would solve the problem. class Color( Enum ): Enum.__enumerationItems__( red=1, green=2, blue=3, ) # other methods and assignments ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 04/26/2013 06:37 PM, Greg Ewing wrote: Eli Bendersky wrote: There's a conceptual difference between a value of an enumeration and a collection of such values. Not if you think of an enum as a type and a type as defining a set of values. From that point of view, the enum itself is already a collection of values, and introducing another object is creating an artificial distinction. I agree (FWIW ;). It seems to me that the closest existing Python data type is bool. bool is a type and has exactly two members, which are static/singleton/only created once. Enum is a metatype which we use to create a type with a fixed number of members which are static/singleton/only created once. The salient differences: with Enum we name the type and the members with Enum the members are also attributes of the type As a concrete example, consider: class WeekDay(Enum): SUNDAY = 1 MONDAY = 2 TUESDAY = 3 WEDNESDAY = 4 THURSDAY = 5 FRIDAY = 6 SATURDAY = 7 If we follow bool's example, then like True and False are of type(bool), TUESDAY should be of type(WeekDay). -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 04/26/2013 11:17 AM, Eli Bendersky wrote: I feel that this thread has lost track of it long ago. Some time back in the Enum discussions (some 350 messages ago or so), there was a proposal to have this: class Color(Enum): RED, BLUE, GREEN By doing some crazy-cool shenanigans. Although the syntax is great, it was rejected on the basis of being too magic. Although explicit reasons were not mentioned (and perhaps not even consciously recognized -- *sigh* someday I hope to be that good), there are very good ones beyond "being too magic" -- way too easy to introduce bugs: name lookup success looks exactly like name lookup failure, but the consequences were drastically different: class Color(Enum): BLACK RED GREEN BLUE class MoreColor(Enum): BLACK CYAN MAGENTA YELLOW BLACK in MoreColor is a bug that cannot easily be detected as it is a successful name lookup; the consequence is that CYAN, MAGENTA, and YELLOW are now off by one. Not being Dutch, I had to smack into that one before I gave up on the idea. -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Destructors and Closing of File Objects
Guido van Rossum writes: > On Monday, April 15, 2013, Nikolaus Rath wrote: >> Brian Curtin > writes: >> > On Fri, Apr 12, 2013 at 12:04 AM, Nikolaus Rath >> > > >> wrote: >> >> [ Note: I already asked this on >> >> http://stackoverflow.com/questions/15917502 but didn't get any >> >> satisfactory answers] >> > >> > Sorry, but that's not a reason to repost your question to this list. >> > If you have to ask somewhere else, it would be python-list, aka, >> > comp.lang.python. >> >> I figured it belonged here because the question is really about the >> internal implementation of file objects, which to me didn't seem like a >> question about using Python. But I'll give it a few days and send >> another mail there if still haven't found the answer by then. > > You got your answer 16 hours ago on S.O. I guess you are referring to http://stackoverflow.com/a/15968516/293003 from Armin Ringo? , | On Windows, NamedTemporaryFile uses a Windows-specific extension | (os.O_TEMPORARY) to ensure that the file is deleted when it is closed. | This probably also works if the process is killed in any way. However | there is no obvious equivalent on POSIX, most likely because on POSIX | you can simply delete files that are still in use; it only deletes the | name, and the file's content is only removed after it is closed (in any | way). But indeed assuming that we want the file name to persist until | the file is closed, like with NamedTemporaryFile, then we need "magic". | | We cannot use the same magic as for flushing buffered files. What occurs | there is that the C library handles it (in Python 2): the files are FILE | objects in C, and the C guarantees that they are flushed on normal | program exit (but not if the process is killed). In the case of Python | 3, there is custom C code to achieve the same effect. But it's specific | to this use case, not anything directly reusable. [...] ` It's indeed very informative, but it doesn't fully address the question because of the _pyio module which certainly can't use any custom C code. Does that mean that when I'm using x = _pyio.BufferedWriter(), I could loose data in the write buffer when the interpreter exits without me calling x.close(), but when using x = io.BufferedWriter(), the buffer is guaranteed to get flushed? (Note: this isn't a complaint, just curiosity about the Python internals). Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
Steven D'Aprano writes: > On 26/04/13 13:22, Greg wrote: >> On 26/04/2013 3:12 p.m., Glenn Linderman wrote: >>> On 4/25/2013 7:49 PM, Nick Coghlan wrote: >> You couldn't create an enum of callables, but that would be a seriously weird thing to do anyway >>> >>> But aren't all classes callable? >> >> An enum of classes would be seriously weird as well, I think. > > > I don't think iscallable will work, since that descriptors like > staticmethod and classmethod aren't callable. Nor are properties. > > > I think a solution may be an explicit decorator that tells the > metaclass not to skip the object into an enum value: > > > class Insect(enum.Enum): > ant = 1 > bee = 2 > > @enum.skip > @classmethod > def spam(cls, args): > pass In this case, wouldn't it be nicer to "decorate" those attributes that are meant to be enum values? I think having to use the class keyword to define something that really doesn't behave like an ordinary class is pretty confusing, and the following syntax would be a lot easier to understand at first sight: class Insect(enum.Enum): ant = enum.EnumValue(1) bee = enum.EnumValue(2) @classmethod def spam(cls, args): pass def ham(self, args): pass Obviously, EnumValue() would automatically assign a suitable number. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Destructors and Closing of File Objects
There are no guarantees in life. On the other hand: Don't worry, be happy. On Fri, Apr 26, 2013 at 7:39 PM, Nikolaus Rath wrote: > Guido van Rossum writes: >> On Monday, April 15, 2013, Nikolaus Rath wrote: >>> Brian Curtin > writes: >>> > On Fri, Apr 12, 2013 at 12:04 AM, Nikolaus Rath >>> > > >>> wrote: >>> >> [ Note: I already asked this on >>> >> http://stackoverflow.com/questions/15917502 but didn't get any >>> >> satisfactory answers] >>> > >>> > Sorry, but that's not a reason to repost your question to this list. >>> > If you have to ask somewhere else, it would be python-list, aka, >>> > comp.lang.python. >>> >>> I figured it belonged here because the question is really about the >>> internal implementation of file objects, which to me didn't seem like a >>> question about using Python. But I'll give it a few days and send >>> another mail there if still haven't found the answer by then. >> >> You got your answer 16 hours ago on S.O. > > I guess you are referring to http://stackoverflow.com/a/15968516/293003 > from Armin Ringo? > > , > | On Windows, NamedTemporaryFile uses a Windows-specific extension > | (os.O_TEMPORARY) to ensure that the file is deleted when it is closed. > | This probably also works if the process is killed in any way. However > | there is no obvious equivalent on POSIX, most likely because on POSIX > | you can simply delete files that are still in use; it only deletes the > | name, and the file's content is only removed after it is closed (in any > | way). But indeed assuming that we want the file name to persist until > | the file is closed, like with NamedTemporaryFile, then we need "magic". > | > | We cannot use the same magic as for flushing buffered files. What occurs > | there is that the C library handles it (in Python 2): the files are FILE > | objects in C, and the C guarantees that they are flushed on normal > | program exit (but not if the process is killed). In the case of Python > | 3, there is custom C code to achieve the same effect. But it's specific > | to this use case, not anything directly reusable. > [...] > ` > > It's indeed very informative, but it doesn't fully address the question > because of the _pyio module which certainly can't use any custom C code. > Does that mean that when I'm using x = _pyio.BufferedWriter(), I could loose > data in the write buffer when the interpreter exits without me calling > x.close(), but when using x = io.BufferedWriter(), the buffer is > guaranteed to get flushed? > > (Note: this isn't a complaint, just curiosity about the Python > internals). > > > Best, > >-Nikolaus > > -- > »Time flies like an arrow, fruit flies like a Banana.« > > PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 04/26/2013 07:29 PM, Glenn Linderman wrote: On 4/26/2013 6:22 PM, Greg Ewing wrote: Guido van Rossum wrote: If we had access to the syntax used for the definition, this would be simple: assignments define items, def statements define methods. But at run time we only see the final object resulting from the definition, Another way we could tell the difference is if the def statement used a different protocol for making bindings than assignment. Suppose a def statement used in a class body called __defitem__, if it exists, instead of __setitem__. Then the metaclass would be able to do different things for defs and assignments. Well, some assignments could be for non-enumeration items, once you start allowing EnumItem in the list. Some method of grouping enumeration items, or grouping non-enumeration items would solve the problem. class Color( Enum ): Enum.__enumerationItems__( red=1, green=2, blue=3, ) # other methods and assignments Or, if we go with the metaclass magic of re-using the class/type name (and who doesn't love metaclass magic??): class Color(Enum): red = Color(1) green = Color(2) blue = Color 3) look_ma_not_an_enum = 4 -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
