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
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
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
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 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__"))
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 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
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 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 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 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 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~
_
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
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
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)
__
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 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: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
> 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
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
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
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
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 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'
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 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, 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 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: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 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, 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
> 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, 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
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, 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 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 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: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 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, 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 :-)
> >
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, 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
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
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
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-
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
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 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 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 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 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 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 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 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 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: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
57 matches
Mail list logo
