On Thu, Apr 25, 2013 at 7:43 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 25 Apr 2013 04:19:36 +0200
Lennart Regebro rege...@gmail.com wrote:
On Thu, Apr 25, 2013 at 3:54 AM, Stephen J. Turnbull step...@xemacs.org
wrote:
RFC 4648 repeatedly refers to *characters*, without
Am 18.04.2013 17:02, schrieb Brett Cannon:
Today marks my 10 year anniversary as a core developer on Python. I
wrote a blog post to mark the occasion
(http://sayspy.blogspot.ca/2013/04/a-decade-of-commits.html), but I
wanted to personally thank python-dev for the past decade (and
whatever
Lennart Regebro writes:
Base64 is an encoding that transforms between 8-bit streams. Let it be
that. Don't try to shoehorn it into a completely different kind of
encoding.
By completely different kind of encoding do you mean codec?
I think that would be an unfortunate result. These
On Thu, Apr 25, 2013 at 8:57 AM, Stephen J. Turnbull step...@xemacs.org wrote:
I think that would be an unfortunate result. These operations on
streams are theoretically nicely composable. It would be nice if
practice reflected that by having a uniform API for all of these
operations
On Thu, Apr 25, 2013 at 4:57 PM, Stephen J. Turnbull step...@xemacs.org wrote:
Lennart Regebro writes:
Base64 is an encoding that transforms between 8-bit streams. Let it be
that. Don't try to shoehorn it into a completely different kind of
encoding.
By completely different kind of
Le Thu, 25 Apr 2013 08:38:12 +0200,
Lennart Regebro rege...@gmail.com a écrit :
On Thu, Apr 25, 2013 at 7:43 AM, Antoine Pitrou solip...@pitrou.net
wrote:
On Thu, 25 Apr 2013 04:19:36 +0200
Lennart Regebro rege...@gmail.com wrote:
On Thu, Apr 25, 2013 at 3:54 AM, Stephen J. Turnbull
Le Fri, 12 Apr 2013 05:55:00 -0700,
Eli Bendersky eli...@gmail.com a écrit :
To programmatically access enumeration values, use ``getattr``::
getattr(Colors, 'red')
EnumValue: Colors.red [value=1]
The PEP should mention how to get an enum from its raw value:
Colors[1]
On Thu, Apr 25, 2013 at 11:25 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le Thu, 25 Apr 2013 08:38:12 +0200,
Yes it is. Base64 takes 8-bit bytes and transforms them into another
8-bit stream that can be safely transmitted over various channels that
would mangle an unencoded 8-bit stream,
On 2013-04-25, at 11:25 , Antoine Pitrou wrote:
Besides, I would consider a RFC more authoritative than a
Wikipedia definition.
Base encoding of data is used in many situations to store or transfer
data in environments that, perhaps for legacy reasons, are restricted
to US-ASCII [1] data.
On Thu, Apr 25, 2013 at 2:42 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le Fri, 12 Apr 2013 05:55:00 -0700,
Eli Bendersky eli...@gmail.com a écrit :
To programmatically access enumeration values, use ``getattr``::
getattr(Colors, 'red')
EnumValue: Colors.red [value=1]
Le Thu, 25 Apr 2013 05:21:50 -0700,
Eli Bendersky eli...@gmail.com a écrit :
or:
Colors(1)
EnumValue: Colors.red [value=1]
This syntax was considered initially but then rejected because it's
confusing, and there already exists a way to lookup by value
(Colors[1]).
Le Thu, 25 Apr 2013 12:46:43 +0200,
Xavier Morel catch-...@masklinn.net a écrit :
On 2013-04-25, at 11:25 , Antoine Pitrou wrote:
Besides, I would consider a RFC more authoritative than a
Wikipedia definition.
Base encoding of data is used in many situations to store or
transfer
Le Thu, 25 Apr 2013 12:05:01 +0200,
Lennart Regebro rege...@gmail.com a écrit :
The Wikipedia page does talk about *text* and *characters* for
the result of base64 encoding.
So are saying that you want the Python implementation of base64
encoding to take 8-bit binary data in bytes format
On Thu, Apr 25, 2013 at 5:29 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le Thu, 25 Apr 2013 05:21:50 -0700,
Eli Bendersky eli...@gmail.com a écrit :
or:
Colors(1)
EnumValue: Colors.red [value=1]
This syntax was considered initially but then rejected because
On Thu, Apr 25, 2013 at 2:57 PM, Antoine Pitrou solip...@pitrou.net wrote:
I can think of many usecases where I want to *embed* base64-encoded
data in a larger text *before* encoding that text and transmitting
it over a 8-bit channel.
That still doesn't mean that this should be the default
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/25/2013 01:43 AM, Antoine Pitrou wrote:
On Thu, 25 Apr 2013 04:19:36 +0200 Lennart Regebro rege...@gmail.com
wrote:
On Thu, Apr 25, 2013 at 3:54 AM, Stephen J. Turnbull
step...@xemacs.org wrote:
RFC 4648 repeatedly refers to *characters*,
On Apr 25, 2013, at 03:34 PM, Lennart Regebro wrote:
In the case of JSON objects, they are intended for data exchange, and
hence in the end need to be byte strings.
Except that they're not.
http://bugs.python.org/issue10976
-Barry
___
Python-Dev
On 25/04/2013 14:34, Lennart Regebro wrote:
On Thu, Apr 25, 2013 at 2:57 PM, Antoine Pitrou solip...@pitrou.net wrote:
I can think of many usecases where I want to *embed* base64-encoded
data in a larger text *before* encoding that text and transmitting
it over a 8-bit channel.
That still
On Thu, Apr 25, 2013 at 10:07 AM, Barry Warsaw ba...@python.org wrote:
On Apr 25, 2013, at 03:34 PM, Lennart Regebro wrote:
In the case of JSON objects, they are intended for data exchange, and
hence in the end need to be byte strings.
Except that they're not.
On Thu, Apr 25, 2013 at 4:22 PM, MRAB pyt...@mrabarnett.plus.com wrote:
The JSON specification says that it's text. Its string literals can
contain Unicode codepoints. It needs to be encoded to bytes for
transmission and storage, but JSON itself is not a bytestring format.
OK, fair enough.
Le Thu, 25 Apr 2013 09:55:26 -0400,
Tres Seaver tsea...@palladion.com a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/25/2013 01:43 AM, Antoine Pitrou wrote:
On Thu, 25 Apr 2013 04:19:36 +0200 Lennart Regebro
rege...@gmail.com wrote:
On Thu, Apr 25, 2013 at 3:54 AM,
Le Thu, 25 Apr 2013 15:34:45 +0200,
Lennart Regebro rege...@gmail.com a écrit :
I don't agree that there is a significant difference between those
wordings in this context. The end result is the same: Things intended
to be handled/seen as textual should be unicode strings, things
intended
On 04/25/2013 06:03 AM, Eli Bendersky wrote:
The __call__ syntax has been repurposed for the convenience API:
-- Animals = Enum('Animals', 'ant bee cat dog')
-- Animals
Animals {ant: 1, bee: 2, cat: 3, dog: 4}
-- Animals.ant
EnumValue: Animals.ant [value=1]
-- Animals.ant.value
1
The
FWIW,
If we're going ahead with the plan to make Colors.red an instance of
Colors, maybe the class names used in examples should be singular,
i.e. isinstance(Color.red, Color)?
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
On Thu, Apr 25, 2013 at 8:46 AM, Ethan Furman et...@stoneleaf.us wrote:
On 04/25/2013 06:03 AM, Eli Bendersky wrote:
The __call__ syntax has been repurposed for the convenience API:
-- Animals = Enum('Animals', 'ant bee cat dog')
-- Animals
Animals {ant: 1, bee: 2, cat: 3, dog: 4}
--
On Thu, Apr 25, 2013 at 9:39 AM, Ethan Furman et...@stoneleaf.us wrote:
On 04/25/2013 09:34 AM, Eli Bendersky wrote:
On Thu, Apr 25, 2013 at 8:46 AM, Ethan Furman et...@stoneleaf.usmailto:
et...@stoneleaf.us wrote:
On 04/25/2013 06:03 AM, Eli Bendersky wrote:
The __call__
On 25/04/2013 15:22, MRAB wrote:
On 25/04/2013 14:34, Lennart Regebro wrote:
On Thu, Apr 25, 2013 at 2:57 PM, Antoine Pitrou solip...@pitrou.net wrote:
I can think of many usecases where I want to *embed* base64-encoded
data in a larger text *before* encoding that text and transmitting
it over
On 04/25/2013 09:34 AM, Eli Bendersky wrote:
On Thu, Apr 25, 2013 at 8:46 AM, Ethan Furman et...@stoneleaf.us
mailto:et...@stoneleaf.us wrote:
On 04/25/2013 06:03 AM, Eli Bendersky wrote:
The __call__ syntax has been repurposed for the convenience API:
-- Animals =
On Thu, Apr 25, 2013 at 5:27 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le Thu, 25 Apr 2013 15:34:45 +0200,
Lennart Regebro rege...@gmail.com a écrit :
I don't agree that there is a significant difference between those
wordings in this context. The end result is the same: Things intended
Lennart Regebro writes:
On Thu, Apr 25, 2013 at 4:22 PM, MRAB pyt...@mrabarnett.plus.com wrote:
The JSON specification says that it's text. Its string literals can
contain Unicode codepoints. It needs to be encoded to bytes for
transmission and storage, but JSON itself is not a
On Thu, 25 Apr 2013, Lennart Regebro wrote:
On Thu, Apr 25, 2013 at 4:22 PM, MRAB pyt...@mrabarnett.plus.com wrote:
The JSON specification says that it's text. Its string literals can
contain Unicode codepoints. It needs to be encoded to bytes for
transmission and storage, but JSON itself is
On Apr 23, 2013, at 03:44 PM, Antoine Pitrou wrote:
I'm having a problem with the proposed implementation. I haven't found
any mention of it, so apologies if this has already been discussed:
from flufl.enum import *
class C(Enum):
... a = 1
... b = 2
...
C.a.__class__
class
MRAB writes:
RFC 4648 says Base encoding of data is used in many situations to
store or transfer data in environments that, perhaps for legacy reasons,
are restricted to US-ASCII [1] data..
To me, US-ASCII is an encoding, so it appears to be talking about
encoding binary data
On Apr 23, 2013, at 01:20 PM, Philip Jenvey wrote:
Furthermore, you could define methods/fields on enum values, like Java's
enums.
There's no reason why you couldn't do this now, even with the class
separation. I've documented the customization protocol, so just add these
methods to the class
On Apr 23, 2013, at 10:24 AM, R. David Murray wrote:
isinstance(C.a, C)
False
isinstance(C(1), C)
False
It would really be better if instances were actual instances of the
class, IMO.
The first False looks correct to me, I would not expect an enum value to be
an instance of the class
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/25/2013 12:39 PM, Ethan Furman wrote:
Animals is a class. Giving Animals a parameter (such as 1 or 'ant')
should return the instance that matches.
Animals is *not* a class -- it just uses the class syntax as a convenient
way to set up the
On Apr 23, 2013, at 04:33 PM, Antoine Pitrou wrote:
That said, I don't see why it wouldn't make sense for an enum value to be an
instance of that class. It can be useful to write `isinstance(value,
MyEnumClass)`. Also, any debug facility which has a preference for writing
out class names would
On Apr 23, 2013, at 10:53 AM, R. David Murray wrote:
Ah. I'd be looking for a bug every time I saw isinstance(value,
myEnumClass). A better class name for values and an API for getting that
class from the EnumClass would be nice, though. (So that you could write
isinstance(value,
On Apr 25, 2013, at 11:42 AM, Antoine Pitrou wrote:
The PEP should mention how to get an enum from its raw value:
Colors[1]
EnumValue: Colors.red [value=1]
or:
Colors(1)
EnumValue: Colors.red [value=1]
No, this is a failed experiment. It's deprecated in flufl.enum and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Apr 25, 2013, at 03:02 PM, Tres Seaver wrote:
On 04/25/2013 12:39 PM, Ethan Furman wrote:
Animals is a class. Giving Animals a parameter (such as 1 or 'ant')
should return the instance that matches.
Animals is *not* a class -- it just uses
On 04/25/2013 12:02 PM, Tres Seaver wrote:
On 04/25/2013 12:39 PM, Ethan Furman wrote:
Animals is a class. Giving Animals a parameter (such as 1 or 'ant')
should return the instance that matches.
Animals is *not* a class -- it just uses the class syntax as a convenient
way to set up the names
On 04/25/2013 11:44 AM, Barry Warsaw wrote:
On Apr 23, 2013, at 03:44 PM, Antoine Pitrou wrote:
I'm having a problem with the proposed implementation. I haven't found
any mention of it, so apologies if this has already been discussed:
from flufl.enum import *
class C(Enum):
... a = 1
...
On Apr 25, 2013, at 01:18 PM, Ethan Furman wrote:
Ignore the single argument call syntax for Enums please. As Eli pointed
out, you have getitem syntax for this and the single argument call syntax
is deprecated. It will be removed in a future version of flufl.enum and
need not appear in
On Thu, Apr 25, 2013 at 2:17 PM, Barry Warsaw ba...@python.org wrote:
On Apr 25, 2013, at 01:18 PM, Ethan Furman wrote:
Ignore the single argument call syntax for Enums please. As Eli pointed
out, you have getitem syntax for this and the single argument call
syntax
is deprecated. It
On Apr 25, 2013, at 02:25 PM, Eli Bendersky wrote:
I think it's important to stress what this syntax is actually going to be
used for. No one (I hope) is actually going to write Animals(1) or
Animals[1]. They will write Animals.ant - this is what enums are for in the
first place! The way I see
On 04/25/2013 02:17 PM, Barry Warsaw wrote:
On Apr 25, 2013, at 01:18 PM, Ethan Furman wrote:
Ignore the single argument call syntax for Enums please. As Eli pointed
out, you have getitem syntax for this and the single argument call syntax
is deprecated. It will be removed in a future
On Thu, Apr 25, 2013 at 11:50 AM, Barry Warsaw ba...@python.org wrote:
On Apr 23, 2013, at 10:24 AM, R. David Murray wrote:
isinstance(C.a, C)
False
isinstance(C(1), C)
False
It would really be better if instances were actual instances of the
class, IMO.
The first False looks correct
On Apr 25, 2013, at 02:54 PM, Guido van Rossum wrote:
I don't know what's going on,
Mostly that this is my first opportunity to chime in on the subject.
but it feels like we had this same discussion a week ago, and I still
disagree. Disregarding, the C[i] notation, I feel quite strongly that in
On Apr 25, 2013, at 02:30 PM, Ethan Furman wrote:
-- class Animal(Enum):
... ant = 1
... bee = 2
... fly = 3
-- Animal(2) # should return Animal.bee
-- Animal('ant') # should return Animal.ant
It seems to me that storing the instances on the class as attributes is
mostly for
On Apr 21, 2013, at 09:12 PM, R. David Murray wrote:
Regardless of the specific values involved, it is pretty much guaranteed
that if anything other than definition order is used we *will* get bug
reports/enhancement requests to fix it, on a regular basis. We can choose
to live with that, but we
On Apr 22, 2013, at 10:55 AM, Tim Delaney wrote:
Would it be worthwhile storing a sorted version of the enum keys here? Or
do you think the current space vs speed tradeoff is better?
It's an implementation detail that doesn't bother me too much either way.
-Barry
signature.asc
Description:
On Thu, Apr 25, 2013 at 3:02 PM, Barry Warsaw ba...@python.org wrote:
On Apr 25, 2013, at 02:54 PM, Guido van Rossum wrote:
I don't know what's going on,
Mostly that this is my first opportunity to chime in on the subject.
but it feels like we had this same discussion a week ago, and I still
On Apr 22, 2013, at 10:42 AM, Nick Coghlan wrote:
On Mon, Apr 22, 2013 at 10:28 AM, Barry Warsaw ba...@python.org wrote:
On Apr 22, 2013, at 09:02 AM, Nick Coghlan wrote:
Iteration order matters a lot if you don't want people complaining about
enums being broken:
class Days(enum.Enum):
On 04/25/2013 02:25 PM, Eli Bendersky wrote:
On Thu, Apr 25, 2013 at 2:17 PM, Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
On Apr 25, 2013, at 01:18 PM, Ethan Furman wrote:
For me, the getitem syntax on a class seems odd and the call syntax is
TOOWTDI.
Not if you think of
On Apr 25, 2013, at 03:19 PM, Guido van Rossum wrote:
Clearly this is a trick question. :-)
A bit, yes. :)
I was told when this was brought up previously (a week ago?) that it
would be simple to make it truly the same class.
It didn't sound simple to me, but I haven't seen any actual code yet.
On Thu, Apr 25, 2013 at 3:29 PM, Barry Warsaw ba...@python.org wrote:
On Apr 25, 2013, at 03:19 PM, Guido van Rossum wrote:
I suppose you were going to propose to use isinstance() overloading,
but I honestly think that Color.red.__class__ should be the same
object as Color.
Yes, a custom
On Thu, 25 Apr 2013 14:37:29 -0700, Ethan Furman et...@stoneleaf.us wrote:
On 04/25/2013 02:25 PM, Eli Bendersky wrote:
On Thu, Apr 25, 2013 at 2:17 PM, Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
On Apr 25, 2013, at 01:18 PM, Ethan Furman wrote:
For me, the getitem
On 04/25/2013 03:07 PM, Barry Warsaw wrote:
On Apr 25, 2013, at 02:30 PM, Ethan Furman wrote:
-- class Animal(Enum):
... ant = 1
... bee = 2
... fly = 3
-- Animal(2) # should return Animal.bee
-- Animal('ant') # should return Animal.ant
It seems to me that storing the
On 04/25/2013 03:11 PM, Barry Warsaw wrote:
On Apr 21, 2013, at 09:12 PM, R. David Murray wrote:
Regardless of the specific values involved, it is pretty much guaranteed
that if anything other than definition order is used we *will* get bug
reports/enhancement requests to fix it, on a regular
On 04/25/2013 03:46 PM, R. David Murray wrote:
On Thu, 25 Apr 2013 14:37:29 -0700, Ethan Furman et...@stoneleaf.us wrote:
On 04/25/2013 02:25 PM, Eli Bendersky wrote:
On Thu, Apr 25, 2013 at 2:17 PM, Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
On Apr 25, 2013, at 01:18 PM,
On 04/25/2013 03:23 PM, Barry Warsaw wrote:
On Apr 22, 2013, at 10:42 AM, Nick Coghlan wrote:
On Mon, Apr 22, 2013 at 10:28 AM, Barry Warsaw ba...@python.org wrote:
On Apr 22, 2013, at 09:02 AM, Nick Coghlan wrote:
Iteration order matters a lot if you don't want people complaining about
On 4/25/2013 3:37 PM, Guido van Rossum wrote:
On Thu, Apr 25, 2013 at 3:29 PM, Barry Warsawba...@python.org wrote:
On Apr 25, 2013, at 03:19 PM, Guido van Rossum wrote:
I suppose you were going to propose to use isinstance() overloading,
but I honestly think that Color.red.__class__ should be
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))
if field is None, the
2013/4/25 Ethan Furman et...@stoneleaf.us:
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, ...
On 26/04/2013 00:09, 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, ...
On 4/25/2013 3:23 PM, Barry Warsaw wrote:
My point is, days of the week has a natural ordering, so why wouldn't you
use IntEnum for that? Problem solved.
While the ordering is natural, some implementations start from 0, some
start from 1, and on the naming side, some start from Sunday, and
On 26/04/13 09:56, MRAB wrote:
On the one hand, NoneType(None) seems a strange thing to do.
Only when you write it out like that as constants. It's no more,
or less, strange than str('spam') or int(1) or list([]). Why
would you do that?
But as soon as you think of it in general terms:
On 04/25/2013 04:26 PM, Glenn Linderman wrote:
My question is, once an enumeration is defined, is there a way, short of
element-by-element assignment, to import the
individual enumeration instances into the current namespace, so that I can say red
instead of Color.red ? I
understand the
On Thu, Apr 25, 2013 at 3:29 PM, Barry Warsawba...@python.org wrote:
I just can't get over the weirdness of a class having attributes which are
actual instances of itself.
I wonder how many programmers will even notice that
this characteristic exists.
Exactly the same weirdness occurs in
On 26/04/2013 00:59, Glenn Linderman wrote:
On 4/25/2013 3:23 PM, Barry Warsaw wrote:
My point is, days of the week has a natural ordering, so why wouldn't you
use IntEnum for that? Problem solved.
While the ordering is natural, some implementations start from 0, some
start from 1, and on
On 26/04/13 11:53, Ethan Furman wrote:
-- from Color import * # doesn't work in a function, though :(
Yeah, that would be nice. ;) A bit dangerous, though -- what if another module
does the same thing, but its Color is different?
It needs to put foo.Color in sys.modules, where foo is the
On 26/04/2013 01:27, Steven D'Aprano wrote:
On 26/04/13 09:56, MRAB wrote:
On the one hand, NoneType(None) seems a strange thing to do.
Only when you write it out like that as constants. It's no more,
or less, strange than str('spam') or int(1) or list([]). Why
would you do that?
None is a
On 26/04/13 13:03, MRAB wrote:
But there _is_ an ordering problem, in that the days wrap around.
Do we want a CircularEnum, then?
Ordering would be defined only up to the starting
value, which you would be required to specify when
doing anything where it mattered.
class Day(CircularEnum):
On 04/25/2013 05:27 PM, Steven D'Aprano wrote:
On 26/04/13 09:56, MRAB wrote:
On the other hand:
type(value)(value) == value
would return True for the built-in types (will certain exceptions, such
as when value is float(NaN)).
Not an exception, that works fine in 3.3:
value =
On 04/25/2013 06:03 PM, MRAB wrote:
On 26/04/2013 00:59, Glenn Linderman wrote:
On 4/25/2013 3:23 PM, Barry Warsaw wrote:
My point is, days of the week has a natural ordering, so why wouldn't you
use IntEnum for that? Problem solved.
While the ordering is natural, some implementations start
On 04/25/2013 06:23 PM, Greg Ewing wrote:
On 26/04/13 13:03, MRAB wrote:
But there _is_ an ordering problem, in that the days wrap around.
Do we want a CircularEnum, then?
Ordering would be defined only up to the starting
value, which you would be required to specify when
doing anything
On Apr 25, 2013, at 04:09 PM, 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, ...
On 4/25/2013 4:53 PM, Ethan Furman wrote:
On 04/25/2013 04:26 PM, Glenn Linderman wrote:
My question is, once an enumeration is defined, is there a way, short
of element-by-element assignment, to import the
individual enumeration instances into the current namespace, so that
I can say red
On Fri, Apr 26, 2013 at 8:29 AM, Barry Warsaw ba...@python.org wrote:
On Apr 25, 2013, at 03:19 PM, Guido van Rossum wrote:
Clearly this is a trick question. :-)
A bit, yes. :)
I was told when this was brought up previously (a week ago?) that it
would be simple to make it truly the same
On Thu, Apr 25, 2013 at 9:12 PM, MRAB pyt...@mrabarnett.plus.com wrote:
Only when you write it out like that as constants. It's no more,
or less, strange than str('spam') or int(1) or list([]). Why
would you do that?
None is a singleton, but instances of str, int, list, etc aren't. Why
can
On Thu, Apr 25, 2013 at 7:13 PM, Nick Coghlan ncogh...@gmail.com wrote:
I'm the one who said I didn't see any obvious barriers to the merger,
but I've realised there is one, and it's similar to one namedtuple
struggles with: how to handle method definitions.
With the current flufl.enum
On 04/25/2013 07:09 PM, Glenn Linderman wrote:
On 4/25/2013 4:53 PM, Ethan Furman wrote:
On 04/25/2013 04:26 PM, Glenn Linderman wrote:
My question is, once an enumeration is defined, is there a way, short of
element-by-element assignment, to import the
individual enumeration instances into
On Fri, Apr 26, 2013 at 12:38 PM, Guido van Rossum gu...@python.org wrote:
If the above syntax won't work, that isinstance() outcome isn't really
important. :-(
Can't we do some kind of callable check? There may be some weird
decorators that won't work, but they aren't likely to be useful in
On 4/25/2013 7:25 PM, Ethan Furman wrote:
On 04/25/2013 07:09 PM, Glenn Linderman wrote:
On 4/25/2013 4:53 PM, Ethan Furman wrote:
On 04/25/2013 04:26 PM, Glenn Linderman wrote:
My question is, once an enumeration is defined, is there a way,
short of element-by-element assignment, to import
On 26/04/2013 2:38 p.m., Guido van Rossum wrote:
Can't we do some kind of callable check? There may be some weird
decorators that won't work, but they aren't likely to be useful in
this context.
Another possible solution:
class Color:
red = 1
white = 2
blue = 3
orange = 4
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.
I should perhaps point out that the numbers assigned to the
values initially are
On 26/04/2013 3:06 p.m., Glenn Linderman wrote:
So what I'm hearing is that enumerations need to be a language feature,
rather than a module:
Can't combine Enum and EnumItem
Can't import into locals
The compiler could do those things, though.
Maybe we've found a use case for the recently
On 4/25/2013 8:22 PM, 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
On Thu, Apr 25, 2013 at 8:39 PM, Glenn Linderman v+pyt...@g.nevcal.com 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
On Fri, Apr 26, 2013 at 3:01 PM, Steven D'Aprano st...@pearwood.info wrote:
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
On 04/25/2013 07:13 PM, Nick Coghlan wrote:
On Fri, Apr 26, 2013 at 8:29 AM, Barry Warsaw ba...@python.org wrote:
On Apr 25, 2013, at 03:19 PM, Guido van Rossum wrote:
Clearly this is a trick question. :-)
A bit, yes. :)
I was told when this was brought up previously (a week ago?) that it
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
On 04/25/2013 10:01 PM, Steven D'Aprano wrote:
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
93 matches
Mail list logo
