Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #81560 > unrolled thread

bug or feature in enum34 py2.7 backport?

Back to article view | Back to comp.lang.python

Contents

  bug or feature in enum34 py2.7 backport? Mark Summerfield <list@qtrac.plus.com> - 2014-11-26 03:29 -0800
    Re: bug or feature in enum34 py2.7 backport? random832@fastmail.us - 2014-11-26 09:05 -0500
    Re: bug or feature in enum34 py2.7 backport? Chris Angelico <rosuav@gmail.com> - 2014-11-27 01:40 +1100
      Re: bug or feature in enum34 py2.7 backport? Mark Summerfield <list@qtrac.plus.com> - 2014-11-26 07:14 -0800
        Re: bug or feature in enum34 py2.7 backport? Chris Angelico <rosuav@gmail.com> - 2014-11-27 02:17 +1100
    Re: bug or feature in enum34 py2.7 backport? random832@fastmail.us - 2014-11-26 10:32 -0500
    Re: bug or feature in enum34 py2.7 backport? Chris Angelico <rosuav@gmail.com> - 2014-11-27 02:46 +1100
    Re: bug or feature in enum34 py2.7 backport? Ethan Furman <ethan@stoneleaf.us> - 2014-11-26 08:58 -0800
    Re: bug or feature in enum34 py2.7 backport? Terry Reedy <tjreedy@udel.edu> - 2014-11-26 16:16 -0500

#81560 — bug or feature in enum34 py2.7 backport?

Hi,

Here are two programs both executed with Python 2.7 with the enum34 backport and their output. Is this a bug or intended behavior? (It may well be intended to help ensure that the class name is ASCII for Python 2; but maybe it would be nicer to check a unicode to see if it is ASCII and if so, use it, and otherwise raise a more helpful exception?)

# t1.py
from __future__ import print_function
import enum
print(enum.version)
A = enum.Enum("A", "b c")
print(A.b, A.c)

$ python2 t1.py 
(1, 0, 3)
A.b A.c

# t2.py
from __future__ import print_function
from __future__ import unicode_literals
import enum
print(enum.version)
A = enum.Enum("A", "b c")
print(A.b, A.c)

$ python2 t2.py 
(1, 0, 3)
Traceback (most recent call last):
  File "t2.py", line 5, in <module>
    A = enum.Enum("A", "b c")
  File "/usr/local/lib/python2.7/dist-packages/enum/__init__.py", line 326, in __call__
    return cls._create_(value, names, module=module, type=type)
  File "/usr/local/lib/python2.7/dist-packages/enum/__init__.py", line 434, in _create_
    enum_class = metacls.__new__(metacls, class_name, bases, classdict)
  File "/usr/local/lib/python2.7/dist-packages/enum/__init__.py", line 188, in __new__
    enum_class = super(EnumMeta, metacls).__new__(metacls, cls, bases, classdict)
TypeError: type() argument 1 must be string, not unicode

[toc] | [next] | [standalone]

#81566

On Wed, Nov 26, 2014, at 06:29, Mark Summerfield wrote:
> TypeError: type() argument 1 must be string, not unicode

If this is a bug, maybe it is one in type() itself - I get the same
error with type('X', (object,), dict(a=1))

[toc] | [prev] | [next] | [standalone]

#81570

On Thu, Nov 27, 2014 at 1:05 AM,  <random832@fastmail.us> wrote:
> On Wed, Nov 26, 2014, at 06:29, Mark Summerfield wrote:
>> TypeError: type() argument 1 must be string, not unicode
>
> If this is a bug, maybe it is one in type() itself - I get the same
> error with type('X', (object,), dict(a=1))

I'd say that's a limitation, not a bug. A lot of stuff in Python 2
depends on identifiers being ASCII-only byte strings, including -
apparently - parts of the core code. Suggestion: Switch to Python 3,
or if you can't do that, pass your identifiers through str(). When you
do eventually switch to Py3, that won't do anything, but in Py2, it'll
force them to be byte strings. As long as they are actually
ASCII-only, that'll solve your problem.

ChrisA

[toc] | [prev] | [next] | [standalone]

#81582

I only mentioned it since I noticed it. I actually use Python 3 so it isn't a problem for me, but sometimes I have to teach Python 2.7 and I wanted to cover enum because it is so much nicer and easier to debug than FOO = 1 etc.

However, the problem is that enum's function API doesn't play nicely with unicode literals. One solution is to use the class API instead:


from __future__ import print_function
from __future__ import unicode_literals
import enum
print(enum.version)
class A(enum.Enum):
   b = 1
   c = 2
print(A.b, A.c) 


On Wednesday, November 26, 2014 2:41:16 PM UTC, Chris Angelico wrote:
> On Thu, Nov 27, 2014 at 1:05 AM,  <fastmail.us> wrote:
> > On Wed, Nov 26, 2014, at 06:29, Mark Summerfield wrote:
> >> TypeError: type() argument 1 must be string, not unicode
> >
> > If this is a bug, maybe it is one in type() itself - I get the same
> > error with type('X', (object,), dict(a=1))
> 
> I'd say that's a limitation, not a bug. A lot of stuff in Python 2
> depends on identifiers being ASCII-only byte strings, including -
> apparently - parts of the core code. Suggestion: Switch to Python 3,
> or if you can't do that, pass your identifiers through str(). When you
> do eventually switch to Py3, that won't do anything, but in Py2, it'll
> force them to be byte strings. As long as they are actually
> ASCII-only, that'll solve your problem.
> 
> ChrisA

[toc] | [prev] | [next] | [standalone]

#81584

On Thu, Nov 27, 2014 at 2:14 AM, Mark Summerfield <list@qtrac.plus.com> wrote:
> I only mentioned it since I noticed it. I actually use Python 3 so it isn't a problem for me, but sometimes I have to teach Python 2.7 and I wanted to cover enum because it is so much nicer and easier to debug than FOO = 1 etc.
>
> However, the problem is that enum's function API doesn't play nicely with unicode literals. One solution is to use the class API instead:
>
>
> from __future__ import print_function
> from __future__ import unicode_literals
> import enum
> print(enum.version)
> class A(enum.Enum):
>    b = 1
>    c = 2
> print(A.b, A.c)

Yeah, because now "class A" is not a literal, and is therefore not
affected by the unicode_literals directive. But I think that notation
looks just fine anyway, so that would probably be the cleanest
solution.

ChrisA

[toc] | [prev] | [next] | [standalone]

#81585

On Wed, Nov 26, 2014, at 09:40, Chris Angelico wrote:
> I'd say that's a limitation, not a bug. A lot of stuff in Python 2
> depends on identifiers being ASCII-only byte strings, including -
> apparently - parts of the core code.

But why shouldn't the type constructor do the conversion (and any
validation of being ASCII-only) when parsing the arguments? The root
cause seems to be that it parses its arguments with "SO!O!:type"
(typeobject.c, line 2097). Does anyone know what problems would be
caused, in general, by having S do a conversion if provided with a
unicode object?

It seems like if it is a bug to reject long where int is accepted, it
should be likewise considered a bug to reject ASCII-only unicode where
str is accepted.

[toc] | [prev] | [next] | [standalone]

#81588

On Thu, Nov 27, 2014 at 2:32 AM,  <random832@fastmail.us> wrote:
> But why shouldn't the type constructor do the conversion (and any
> validation of being ASCII-only) when parsing the arguments? The root
> cause seems to be that it parses its arguments with "SO!O!:type"
> (typeobject.c, line 2097). Does anyone know what problems would be
> caused, in general, by having S do a conversion if provided with a
> unicode object?
>
> It seems like if it is a bug to reject long where int is accepted, it
> should be likewise considered a bug to reject ASCII-only unicode where
> str is accepted.

Hmm, that sounds like it would be a feature improvement, rather than a
bug fix. But you could take that up with the release manager.

ChrisA

[toc] | [prev] | [next] | [standalone]

#81604

[Multipart message — attachments visible in raw view] — view raw

On 11/26/2014 07:32 AM, random832@fastmail.us wrote:
> 
> It seems like if it is a bug to reject long where int is accepted, it
> should be likewise considered a bug to reject ASCII-only unicode where
> str is accepted.

While I agree, I don't know if there are currently any parts of core 2.7 that follow that philosophy -- and if there
aren't, it's extremely unlikely to change now.

However, enum34 has now been updated to handle unicode class names.  Thanks for the bug report.  :)

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#81610

On 11/26/2014 10:32 AM, random832@fastmail.us wrote:

> It seems like if it is a bug to reject long where int is accepted,

I do not believe that is universally true is 2.7.  But even if it is...
Short ints were, value-wise, a subset of longs.  Thus, for example, 
binary operations could always convert the int to long and continue.  In 
3.0, short ints were removed and long renamed int.

> should be likewise considered a bug to reject ASCII-only unicode where
> str is accepted.

That would require an O(n) check.  Bytes and unicode have an ascii 
overlap when bytes are interpreted as ascii chars, but neither is a 
subset of the other.  Mixed binary operations were removed in 3.x.

-- 
Terry Jan Reedy

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web