On May 01, 2013, at 11:54 AM, Larry Hastings wrote:
>On 04/30/2013 11:29 PM, Ethan Furman wrote:
>> On 04/30/2013 11:18 PM, Barry Warsaw wrote:
>>> On Apr 28, 2013, at 11:50 PM, Ethan Furman wrote:
>>>
But as soon as:
type(Color.red) is Color # True
type(MoreColo
On May 02, 2013, at 11:44 AM, Greg Ewing wrote:
>Barry Warsaw wrote:
>> Why isn't getattr() for lookup by name
>> good enough?
>
>Because it will find things that are not enum items,
>e.g. '__str__'.
Why does that matter?
-Barry
___
Python-Dev mailing
On May 01, 2013, at 11:04 AM, Eli Bendersky wrote:
>Actually, in flufl.enum, IntEnum had to define a magic __value_factory__
>attribute, but in the current ref435 implementation this isn't needed, so
>IntEnum is just:
>
>class IntEnum(int, Enum):
>'''
>Class where every instance is a subcl
On May 01, 2013, at 08:47 PM, Georg Brandl wrote:
>Wait a moment... it might not be immediately useful for IntEnums (however,
>that's because base Enum currently defines __int__ which I find questionable),
And broken. And unnecessary. :)
>>> class Foo(Enum):
... a = 'a'
... b = 'b'
...
>>>
On 05/02/2013 07:57 AM, Barry Warsaw wrote:
On May 01, 2013, at 11:54 AM, Larry Hastings wrote:
On 04/30/2013 11:29 PM, Ethan Furman wrote:
On 04/30/2013 11:18 PM, Barry Warsaw wrote:
On Apr 28, 2013, at 11:50 PM, Ethan Furman wrote:
But as soon as:
type(Color.red) is Color #
On 05/02/2013 07:57 AM, Barry Warsaw wrote:
On May 01, 2013, at 11:54 AM, Larry Hastings wrote:
On 04/30/2013 11:29 PM, Ethan Furman wrote:
On 04/30/2013 11:18 PM, Barry Warsaw wrote:
On Apr 28, 2013, at 11:50 PM, Ethan Furman wrote:
But as soon as:
type(Color.red) is Color #
On Thu, May 2, 2013 at 7:58 AM, Barry Warsaw wrote:
> On May 02, 2013, at 11:44 AM, Greg Ewing wrote:
>
>>Barry Warsaw wrote:
>>> Why isn't getattr() for lookup by name
>>> good enough?
>>
>>Because it will find things that are not enum items,
>>e.g. '__str__'.
>
> Why does that matter?
I claim i
On May 01, 2013, at 03:11 PM, Ethan Furman wrote:
>The reason __int__ is there is because pure Enums should be using plain ints
>as their value 95% or more of the time, and being able to easily convert to a
>real int for either database storage, wire transmission, or C functions is a
>Good Thing.
On May 02, 2013, at 08:42 AM, Larry Hastings wrote:
>So, for the second time: How can Color.red and MoreColor.red be the same
>object when they are of different types?
It's a moot point now given Guido's pronouncement.
-Barry
___
Python-Dev mailing lis
On Thu, May 2, 2013 at 8:54 AM, Barry Warsaw wrote:
> On May 01, 2013, at 03:11 PM, Ethan Furman wrote:
>
> >The reason __int__ is there is because pure Enums should be using plain
> ints
> >as their value 95% or more of the time, and being able to easily convert
> to a
> >real int for either dat
On Thu, May 2, 2013 at 8:57 AM, Barry Warsaw wrote:
> On May 02, 2013, at 08:42 AM, Larry Hastings wrote:
>
> >So, for the second time: How can Color.red and MoreColor.red be the same
> >object when they are of different types?
>
> It's a moot point now given Guido's pronouncement.
>
Correct. Th
On Wed, 2013-05-01 at 23:54 +1000, Nick Coghlan wrote:
>
> However, I like the idea of a rich "stat" object, with "path.stat()"
> and "path.cached_stat()" accessors on the path objects.
>
Since it seems there is some support for my proposal, I just posted to
python-ideas to get an idea how much
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?
--
~Ethan~
___
Python-
2013/5/2 Ethan Furman :
> 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?
Regardless of that, perhaps we sho
On Thu, 2 May 2013 15:48:14 -0400
Benjamin Peterson wrote:
> 2013/5/2 Ethan Furman :
> > 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 f
On Thu, May 2, 2013 at 1:10 PM, Antoine Pitrou wrote:
> On Thu, 2 May 2013 15:48:14 -0400
> Benjamin Peterson wrote:
> > 2013/5/2 Ethan Furman :
> > > In order for the Enum convenience function to be pickleable, we have
> this
> > > line of code in the metaclass:
> > >
> > > enum_class.__mod
Am 02.05.2013 22:10, schrieb Antoine Pitrou:
> On Thu, 2 May 2013 15:48:14 -0400
> Benjamin Peterson wrote:
>> 2013/5/2 Ethan Furman :
>> > In order for the Enum convenience function to be pickleable, we have this
>> > line of code in the metaclass:
>> >
>> > enum_class.__module__ = sys._getfr
On Thu, 2 May 2013 13:15:00 -0700
Eli Bendersky wrote:
> > Two things that were suggested in private:
> >
> > 1) ask users to pass the module name to the convenience function
> > explicitly (i.e. pass "seasonmodule.Season" instead of "Season" as the
> > class "name"). Guido doesn't like it :-)
> >
On Thu, May 2, 2013 at 12:07 PM, Ethan Furman wrote:
> 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?
This
On Thu, May 2, 2013 at 1:22 PM, Antoine Pitrou wrote:
> On Thu, 2 May 2013 13:15:00 -0700
> Eli Bendersky wrote:
> > > Two things that were suggested in private:
> > >
> > > 1) ask users to pass the module name to the convenience function
> > > explicitly (i.e. pass "seasonmodule.Season" instead
On May 02, 2013, at 10:18 PM, Georg Brandl wrote:
>5) accept that convenience-created enums have restrictions such as no
>picklability and point them out in the docs?
That would work fine for me, but ultimately I'm with Guido. I just don't want
to have to pass the module name in.
-Barry
___
On Thu, May 2, 2013 at 1:18 PM, fwierzbi...@gmail.com
wrote:
> On Thu, May 2, 2013 at 12:07 PM, Ethan Furman wrote:
>> 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__
On Thu, 2 May 2013 13:33:21 -0700
Eli Bendersky wrote:
> On Thu, May 2, 2013 at 1:22 PM, Antoine Pitrou wrote:
>
> > On Thu, 2 May 2013 13:15:00 -0700
> > Eli Bendersky wrote:
> > > > Two things that were suggested in private:
> > > >
> > > > 1) ask users to pass the module name to the conveni
On Thu, May 2, 2013 at 9:07 PM, Ethan Furman wrote:
> 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?
It's
On Thu, May 2, 2013 at 1:39 PM, Barry Warsaw wrote:
> On May 02, 2013, at 10:18 PM, Georg Brandl wrote:
>
> >5) accept that convenience-created enums have restrictions such as no
> >picklability and point them out in the docs?
>
> That would work fine for me, but ultimately I'm with Guido. I jus
> Actually, there's Gregory's scandir() implementation (returning a
> generator to be able to cope with large directories) on it's way:
>
> http://bugs.python.org/issue11406
>
> It's already been suggested to make it return a tuple (with d_type).
> I'm sure a review of the code (especially the Wind
On Thu, May 2, 2013 at 1:39 PM, Guido van Rossum wrote:
> On Thu, May 2, 2013 at 1:18 PM, fwierzbi...@gmail.com
> wrote:
> > On Thu, May 2, 2013 at 12:07 PM, Ethan Furman
> wrote:
> >> In order for the Enum convenience function to be pickleable, we have
> this
> >> line of code in the metaclass
On Thu, 2 May 2013 13:48:24 -0700
Eli Bendersky wrote:
> On Thu, May 2, 2013 at 1:39 PM, Barry Warsaw wrote:
>
> > On May 02, 2013, at 10:18 PM, Georg Brandl wrote:
> >
> > >5) accept that convenience-created enums have restrictions such as no
> > >picklability and point them out in the docs?
>
> > > On Thu, 2 May 2013 13:15:00 -0700
> > > Eli Bendersky wrote:
> > > > > Two things that were suggested in private:
> > > > >
> > > > > 1) ask users to pass the module name to the convenience function
> > > > > explicitly (i.e. pass "seasonmodule.Season" instead of "Season" as
> the
> > > > >
On 05/02/2013 01:52 PM, Eli Bendersky wrote:
Back to my question from before, though - do we have a real technical
limitation of having something like
inspect.what_module_am_i_now_in() that's supposed to work for all Python code?
By which you really mean inspect.what_module_was_I_called_from(
On Thu, 2 May 2013 13:52:29 -0700
Eli Bendersky wrote:
>
> Back to my question from before, though - do we have a real technical
> limitation of having something like inspect.what_module_am_i_now_in()
> that's supposed to work for all Python code?
I already gave an answer (e.g. the debugger case
On Thu, May 2, 2013 at 2:05 PM, Ethan Furman wrote:
> On 05/02/2013 01:52 PM, Eli Bendersky wrote:
>
>>
>> Back to my question from before, though - do we have a real technical
>> limitation of having something like
>> inspect.what_module_am_i_now_**in() that's supposed to work for all
>> Python
On Thu, May 2, 2013 at 2:10 PM, Antoine Pitrou wrote:
> On Thu, 2 May 2013 13:52:29 -0700
> Eli Bendersky wrote:
> >
> > Back to my question from before, though - do we have a real technical
> > limitation of having something like inspect.what_module_am_i_now_in()
> > that's supposed to work for
On May 02, 2013, at 10:57 PM, Antoine Pitrou wrote:
>On Thu, 2 May 2013 13:48:24 -0700
>> The problem with (5) is this: you use some library that exports an
>> enumeration, and you want to use pickling. Now you depend on the way the
>> library implemented - if it used the convenience API, you can'
2013/5/2 Eli Bendersky :
>
>
>
> On Thu, May 2, 2013 at 1:10 PM, Antoine Pitrou wrote:
>>
>> On Thu, 2 May 2013 15:48:14 -0400
>> Benjamin Peterson wrote:
>> > 2013/5/2 Ethan Furman :
>> > > In order for the Enum convenience function to be pickleable, we have
>> > > this
>> > > line of code in th
On Thu, 2 May 2013 14:16:34 -0700
Barry Warsaw wrote:
> On May 02, 2013, at 10:57 PM, Antoine Pitrou wrote:
>
> >On Thu, 2 May 2013 13:48:24 -0700
> >> The problem with (5) is this: you use some library that exports an
> >> enumeration, and you want to use pickling. Now you depend on the way the
On Thu, 2 May 2013 14:15:40 -0700
Eli Bendersky wrote:
>
> Sorry, but I do find the argument "let's not have a convenience syntax
> because enums created with such syntax won't pickle properly from within a
> debugger" not convincing enough :-)
Eli, it would be nice if you stopped with this clai
2013/5/2 Guido van Rossum
> On Thu, May 2, 2013 at 1:18 PM, fwierzbi...@gmail.com
> wrote:
> > On Thu, May 2, 2013 at 12:07 PM, Ethan Furman
> wrote:
> >> In order for the Enum convenience function to be pickleable, we have
> this
> >> line of code in the metaclass:
> >>
> >> enum_class.__m
> Eli, it would be nice if you stopped with this claim.
>
> I'm not advocating "not having a convenience syntax", I'm advocating
> having a convenience syntax which is *class-based* rather than
> function-based.
>
> Debuggers are beside the point: there are two kinds of "convenience
> syntax" on t
On 3 May 2013 08:34, "guido.van.rossum" wrote:
>
> http://hg.python.org/peps/rev/26947623fc5d
> changeset: 4870:26947623fc5d
> user:Guido van Rossum
> date:Thu May 02 14:11:08 2013 -0700
> summary:
> Add time(), call_at(). Remove call_repeatedly(). Get rid of
add_*_handler() r
On Thu, May 2, 2013 at 1:18 PM, fwierzbi...@gmail.com
wrote:
> On Thu, May 2, 2013 at 12:07 PM, Ethan Furman wrote:
>> 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__
On 3 May 2013 08:00, "Eli Bendersky" wrote:
>
> > Eli, it would be nice if you stopped with this claim.
>>
>>
>> I'm not advocating "not having a convenience syntax", I'm advocating
>> having a convenience syntax which is *class-based* rather than
>> function-based.
>>
>> Debuggers are beside the
On Thu, May 2, 2013 at 4:14 PM, Nick Coghlan wrote:
> I would suggest moving the field names into the class header for a class
> based convenience API:
>
> class Animal(Enum, members='cat dog'): pass
Would you propose the same for namedtuple?
--
--Guido van Rossum (python.org/~guido)
__
Guido van Rossum wrote:
you should do some other check,
e.g. "if x in Color:".
So you don't think it's important to have an easy
way to take user input that's supposed to be a
Color name and either return a Color or raise
a ValueError?
--
Greg
___
Py
Eli Bendersky wrote:
TypeError: Cannot subclass enumerations
This message might be better phrased as "cannot extend
enumerations", since we're still allowing subclassing
prior to defining members.
--
Greg
___
Python-Dev mailing list
Python-Dev@pytho
On 05/02/2013 04:45 PM, Greg Ewing wrote:
Eli Bendersky wrote:
TypeError: Cannot subclass enumerations
This message might be better phrased as "cannot extend
enumerations", since we're still allowing subclassing
prior to defining members.
I like it, thanks!
--
~Ethan~
_
On Thu, May 2, 2013 at 4:50 PM, Ethan Furman wrote:
> On 05/02/2013 04:45 PM, Greg Ewing wrote:
>
>> Eli Bendersky wrote:
>>
>> TypeError: Cannot subclass enumerations
>>>
>>
>> This message might be better phrased as "cannot extend
>> enumerations", since we're still allowing subclassing
>> pri
On May 03, 2013, at 09:14 AM, Nick Coghlan wrote:
>> The other issue is your proposal to have a class-based convenience syntax
>akin to (correct me if I got this wrong):
>>
>> class Animal(Enum):
>> __values__ = 'cat dog'
>
>I would suggest moving the field names into the class header for a clas
On 05/02/2013 04:43 PM, Greg Ewing wrote:
Guido van Rossum wrote:
you should do some other check,
e.g. "if x in Color:".
So you don't think it's important to have an easy
way to take user input that's supposed to be a
Color name and either return a Color or raise
a ValueError?
I don't believ
On Fri, May 3, 2013 at 9:57 AM, Ethan Furman wrote:
> On 05/02/2013 04:43 PM, Greg Ewing wrote:
>>
>> Guido van Rossum wrote:
>>>
>>> you should do some other check,
>>> e.g. "if x in Color:".
>>
>>
>> So you don't think it's important to have an easy
>> way to take user input that's supposed to b
On Thu, May 2, 2013 at 11:37 AM, Steven D'Aprano wrote:
> On 02/05/13 08:54, Nick Coghlan wrote:
>
>> If enums had an "as_dict" method that returned an ordered dictionary, you
>> could do:
>>
>> class MoreColors(Enum):
>> locals().update(Colors.as_dict())
>
>
>
> Surely that is an implementat
An exchange in one of the enum threads prompted me to write down
something I've occasionally thought about regarding locals(): it is
currently severely underspecified, and I'd like to make the current
CPython behaviour part of the language/library specification. (We
recently found a bug in the inte
On May 03, 2013, at 11:06 AM, Nick Coghlan wrote:
>> User input should qualify, and using getattr(EnumClass, user_input) will get
>> you an AttributeError instead of a ValueError if user_input is not valid,
>> but surely you don't mind that small difference. ;)
>
int(getattr(C(), "__str__"))
2013/5/2 Nick Coghlan :
> An exchange in one of the enum threads prompted me to write down
> something I've occasionally thought about regarding locals(): it is
> currently severely underspecified, and I'd like to make the current
> CPython behaviour part of the language/library specification. (We
On 03/05/13 11:29, Nick Coghlan wrote:
An exchange in one of the enum threads prompted me to write down
something I've occasionally thought about regarding locals(): it is
currently severely underspecified, and I'd like to make the current
CPython behaviour part of the language/library specificat
On 5/2/2013 9:29 PM, Nick Coghlan wrote:
An exchange in one of the enum threads prompted me to write down
something I've occasionally thought about regarding locals(): it is
currently severely underspecified, and I'd like to make the current
CPython behaviour part of the language/library specific
Am 02.05.2013 23:57, schrieb Eli Bendersky:
>> Eli, it would be nice if you stopped with this claim.
>
>
> I'm not advocating "not having a convenience syntax", I'm advocating
> having a convenience syntax which is *class-based* rather than
> function-based.
>
> Debuggers are bes
57 matches
Mail list logo
