On Tue, Nov 30, 2010 at 7:36 AM, Greg Ewing wrote:
> I don't see how the grouping can be completely separated
> from the value-naming. If the named values are to be
> subclassed from the base values, then you want all the
> members of a group to belong to the *same* subclass.
> You can't get that
On 11/28/2010 09:03 PM, Ron Adam wrote:
It does associate additional info to names and creates a nice dictionary to
reference.
>>> def name_values( FOO: 1,
BAR: "Hello World!",
BAZ: dict(a=1, b=2, c=3) ):
... return FOO, BAR, BAZ
...
>>> foo(1,2,3)
(1, 2, 3)
>>> foo.__annotations__
{'BAR'
I don't see how the grouping can be completely separated
from the value-naming. If the named values are to be
subclassed from the base values, then you want all the
members of a group to belong to the *same* subclass.
You can't get that by treating each named value on its
own and then trying to gr
Rob Cliffe wrote:
But when a frozen list a.k.a. tuple would be created - either directly,
or by setting a list's mutable flag to False which would really turn it
into a tuple - the size *would* be known.
But at that point the object consists of two memory blocks -- one
containing just the obj
On 11/27/2010 04:51 AM, Nick Coghlan wrote:
x = named_value("FOO", 1)
y = named_value("BAR", "Hello World!")
z = named_value("BAZ", dict(a=1, b=2, c=3))
print(x, y, z, sep="\n")
print("\n".join(map(repr, (x, y, z
print("\n".join(map(str, map(type, (x, y, z)
set_named_values(globals(),
On 28/11/2010 21:23, Greg Ewing wrote:
Rob Cliffe wrote:
But couldn't they be presented to the Python programmer as a single
type, with the implementation details hidden "under the hood"?
Not in CPython, because tuple items are kept in the same block
of memory as the object header. Because
On 29/11/2010 00:48, Nick Coghlan wrote:
On Mon, Nov 29, 2010 at 2:28 AM, Michael Foord
wrote:
For wrapping mutable types I'm tempted to say YAGNI. For the standard
library wrapping integers meets almost all our use-cases except for one
float. (At work we have a decimal constant as it happens.
On Mon, Nov 29, 2010 at 2:28 AM, Michael Foord
wrote:
> For wrapping mutable types I'm tempted to say YAGNI. For the standard
> library wrapping integers meets almost all our use-cases except for one
> float. (At work we have a decimal constant as it happens.) Perhaps we could
> require immutable
Rob Cliffe wrote:
But couldn't they be presented to the Python programmer as a single
type, with the implementation details hidden "under the hood"?
Not in CPython, because tuple items are kept in the same block
of memory as the object header. Because CPython can't move
objects, this means tha
On 28/11/2010 18:05, Steven D'Aprano wrote:
Michael Foord wrote:
Another 'optional' feature I omitted was Phillip J. Eby's suggestion
/ requirement that named values be pickleable. Email is clunky for
handling this, is there enough support (there is still some objection
that is sure) to reviv
Michael Foord wrote:
Another 'optional' feature I omitted was Phillip J. Eby's suggestion /
requirement that named values be pickleable. Email is clunky for
handling this, is there enough support (there is still some objection
that is sure) to revive the PEP or create a new one?
I think it d
On 28/11/2010 17:05, Michael Foord wrote:
[snip...]
It is sensible if flag values are only powers of 2; we could enforce
that or not... (Another one for the optional feature list.)
Another 'optional' feature I omitted was Phillip J. Eby's suggestion /
requirement that named values be pickleab
On 28/11/2010 16:28, Michael Foord wrote:
[snip...]
I don't think there are *many* competing features, in fact as far as
feature requests on python-dev go I think this is a relatively
straightforward one with a lot of *agreement* on the basic functionality.
We have had various discussions abo
On 28/11/2010 02:38, Nick Coghlan wrote:
On Sun, Nov 28, 2010 at 9:26 AM, Raymond Hettinger
wrote:
On Nov 27, 2010, at 12:56 PM, Glenn Linderman wrote:
On 11/27/2010 2:51 AM, Nick Coghlan wrote:
Not quite. I'm suggesting a factory function that works for any value,
and derives the parent cl
On 28/11/2010 03:20, Terry Reedy wrote:
On 11/27/2010 6:26 PM, Raymond Hettinger wrote:
Can I suggest that an enum-maker be offered as a third-party module
Possibly with competing versions for trial and testing ;-)
rather than prematurely adding it into the standard library.
I had same th
On 11/27/2010 6:26 PM, Raymond Hettinger wrote:
Can I suggest that an enum-maker be offered as a third-party module
Possibly with competing versions for trial and testing ;-)
rather than prematurely adding it into the standard library.
I had same thought.
--
Terry Jan Reedy
_
On Sun, Nov 28, 2010 at 9:26 AM, Raymond Hettinger
wrote:
>
> On Nov 27, 2010, at 12:56 PM, Glenn Linderman wrote:
>
>> On 11/27/2010 2:51 AM, Nick Coghlan wrote:
>>>
>>> Not quite. I'm suggesting a factory function that works for any value,
>>> and derives the parent class from the type of the su
On 11/27/2010 12:56 PM, Glenn Linderman wrote:
On 11/27/2010 2:51 AM, Nick Coghlan wrote:
Not quite. I'm suggesting a factory function that works for any value,
and derives the parent class from the type of the supplied value.
Nick, thanks for the much better implementation than I achieved; yo
On Nov 27, 2010, at 12:56 PM, Glenn Linderman wrote:
> On 11/27/2010 2:51 AM, Nick Coghlan wrote:
>>
>> Not quite. I'm suggesting a factory function that works for any value,
>> and derives the parent class from the type of the supplied value.
>
> Nick, thanks for the much better implementation
On 11/27/2010 2:51 AM, Nick Coghlan wrote:
Not quite. I'm suggesting a factory function that works for any value,
and derives the parent class from the type of the supplied value.
Nick, thanks for the much better implementation than I achieved; you
seem to have the same goals as my implementat
On Nov 27, 2010, at 02:01 PM, Michael Foord wrote:
>(Note that there is no *particular* hurry to get this into 3.2 - the beta is
>due imminently. I wouldn't object to it )
Indeed. I don't think the time is right to try to get this into 3.2.
-Barry
signature.asc
Description: PGP signature
On Sun, Nov 28, 2010 at 12:01 AM, Michael Foord
wrote:
> Very interesting proposal (typed named values rather than just named
> constants). It doesn't handle flag values, which I would still like, but
> that only really makes sense for integers (sets can be OR'd but their
> representation is alrea
On 27/11/2010 10:51, Nick Coghlan wrote:
On Thu, Nov 25, 2010 at 3:41 AM, Michael Foord
wrote:
Can you explain what you see as the difference?
I'm not particularly interested in type validation but I like the fact that
typical enum APIs allow you to group constants: the generated constant cla
On Thu, Nov 25, 2010 at 3:41 AM, Michael Foord
wrote:
> Can you explain what you see as the difference?
>
> I'm not particularly interested in type validation but I like the fact that
> typical enum APIs allow you to group constants: the generated constant class
> acts as a namespace for all the d
On 25/11/2010 03:46, Greg Ewing wrote:
On 25/11/10 12:38, average wrote:
Is immutability a general need that should have general solution?
Yes, I have sometimes thought this. Might be nice to have a "mutable"
attribute that could be read and could be changed from True to False,
though pre
On 25/11/2010 09:34, Glenn Linderman wrote:
So the following code defines constants with associated names that get
put in the repr.
I'm still a Python newbie in some areas, particularly classes and
metaclasses, maybe more.
But this Python 3 code seems to create constants with names ... works
On 25/11/2010 10:12, Nadeem Vawda wrote:
On Thu, Nov 25, 2010 at 11:34 AM, Glenn Linderman wrote:
So the following code defines constants with associated names that get put
in the repr.
The code you gave doesn't work if the constant() function is moved
into a separate module from the code that
On Thu, Nov 25, 2010 at 11:34 AM, Glenn Linderman wrote:
> So the following code defines constants with associated names that get put
> in the repr.
The code you gave doesn't work if the constant() function is moved
into a separate module from the code that calls it. The globals()
function, as I
So the following code defines constants with associated names that get
put in the repr.
I'm still a Python newbie in some areas, particularly classes and
metaclasses, maybe more.
But this Python 3 code seems to create constants with names ... works
for int and str at least.
Special case for
On 25/11/10 12:38, average wrote:
Is immutability a general need that should have general solution?
I don't think it really generalizes. Tuples are not just frozen
lists, for example -- they have a different internal structure
that's more efficient to create and access.
--
Greg
___
Is immutability a general need that should have general solution? By
generalizing the idea to lists/tuples, set/frozenset, dicts, and strings
(for example), it seems one could simplify the container classes, eliminate
code complexity, and perhaps improve resource utilization.
mark
___
On 24/11/2010 14:08, Nick Coghlan wrote:
On Wed, Nov 24, 2010 at 10:30 PM, Michael Foord
wrote:
Based on a non-exhaustive search, Python standard library modules currently
using integers for constants:
Thanks for that review. I think following up on the "NamedConstant"
idea may make more sens
2010/11/24 Steven D'Aprano :
> Nick Coghlan wrote:
>>
>> On Wed, Nov 24, 2010 at 10:30 PM, Michael Foord
>> wrote:
>>>
>>> Based on a non-exhaustive search, Python standard library modules
>>> currently
>>> using integers for constants:
>>
>> Thanks for that review. I think following up on the "Na
Nick Coghlan wrote:
On Wed, Nov 24, 2010 at 10:30 PM, Michael Foord
wrote:
Based on a non-exhaustive search, Python standard library modules currently
using integers for constants:
Thanks for that review. I think following up on the "NamedConstant"
idea may make more sense than pursuing enums
On Wed, Nov 24, 2010 at 10:30 PM, Michael Foord
wrote:
> Based on a non-exhaustive search, Python standard library modules currently
> using integers for constants:
Thanks for that review. I think following up on the "NamedConstant"
idea may make more sense than pursuing enums in their own right.
On 23/11/2010 14:16, Nick Coghlan wrote:
On Tue, Nov 23, 2010 at 11:50 PM, Michael Foord
wrote:
PEP 354 was rejected for two primary reasons - lack of interest and nowhere
obvious to put it. Would it be *so bad* if an enum type lived in its own
module? There is certainly more interest now, and
On Tue, Nov 23, 2010 at 9:35 PM, Raymond Hettinger
wrote:
> The least worst option is to do nothing at all.
For the standard library, I agree.
There are enough variants that are needed/desired in different
contexts, and there isn't a single clear winner. Nor is there any
compelling reason to ha
On Nov 23, 2010, at 3:41 PM, Greg Ewing wrote:
> While it may be possible to work around these things with
> sufficient levels of metaclass hackery and black magic, at
> some point one has to consider whether new syntax might
> be the least worst option.
The least worst option is to do nothing a
On 23/11/2010 21:15, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 16:10 -0500, Glyph Lefkowitz a écrit :
On Nov 23, 2010, at 10:01 AM, Antoine Pitrou wrote:
Well, it is easy to assign range(N) to a tuple of names when
desired. I
don't think an automatically-enumerating constant generator
Isaac Morland wrote:
In any case my
suggestion of a new keyword was not meant to be taken seriously.
I don't think it need be taken entirely as a joke, either.
All the proposed patterns for creating enums that I've seen
end up leaving something to be desired. They violate DRY
by requiring you t
Antoine Pitrou wrote:
Constants = make_constants('Constants', 'SOME_CONST OTHER_CONST',
values=range(1, 3))
Again, auto-enumeration is useless since it's trivial to achieve
explicitly.
But seeing as it's going to be a common thing to do, why not
make it the defau
Bill Janssen wrote:
The main purpose of that is to be able to catch type mismatches with
static typing, though. Seems kind of pointless for Python.
But catching type mismatches with dynamic typing doesn't
seem pointless for Python. There's nothing static about
the proposals being made here th
Antoine Pitrou wrote:
I think that asking for too many features would get in the way, and also
make the API quite un-Pythonic. If you want your values to be e.g.
OR'able, just choose your values wisely ;)
On the other hand it could be useful to have an easy way to
request power-of-2 value assi
On Tue, 23 Nov 2010, Bill Janssen wrote:
The main purpose of that is to be able to catch type mismatches with
static typing, though. Seems kind of pointless for Python.
The concept can work dynamically. In fact, the flufl.enum package which
has been discussed here makes each enumeration int
Antoine Pitrou wrote:
Well, it's been inherited by C-like languages, no doubt. Like braces and
semicolumns :)
The idea isn't confined to the C family. Pascal and many of the
languages inspired by it also have enumerated types.
--
Greg
___
Python-Dev
Antoine Pitrou wrote:
I don't understand why people insist on calling that an "enum". enum is
a C legacy and it doesn't bring anything useful as I can tell.
The usefulness is that they can have a str() or repr() that
displays the name of the value instead of an integer.
The bool type was adde
Antoine Pitrou wrote:
Python already has an enumeration capability. It's called range().
There's nothing else that C enums have. AFAICT, neither do enums in
other mainstream languages (assuming they even exist; I don't remember
Perl, PHP or Javascript having anything like that, but perhaps I'm
m
Oops.. x**2 should have been 2**x below.
On 11/23/2010 03:03 PM, Ron Adam wrote:
On 11/23/2010 12:07 PM, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 12:50 -0500, Isaac Morland a écrit :
Each enumeration is a type (well, OK, not in every language, presumably,
but certainly in many lan
Le mardi 23 novembre 2010 à 16:10 -0500, Glyph Lefkowitz a écrit :
>
> On Nov 23, 2010, at 10:01 AM, Antoine Pitrou wrote:
>
> > Well, it is easy to assign range(N) to a tuple of names when
> > desired. I
> > don't think an automatically-enumerating constant generator is
> > needed.
>
> I don't
On Nov 23, 2010, at 10:01 AM, Antoine Pitrou wrote:
> Well, it is easy to assign range(N) to a tuple of names when desired. I
> don't think an automatically-enumerating constant generator is needed.
I don't think that numerical enumerations are the only kind of constants we're
talking about. O
Antoine Pitrou wrote:
Constants = make_constants('Constants', 'SOME_CONST OTHER_CONST',
values=range(1, 3))
Again, auto-enumeration is useless since it's trivial to achieve
explicitly.
That doesn't make auto-enumeration "useless". Unnecessary, perhaps, but
not u
On Nov 23, 2010, at 10:37 AM, ben.cottr...@nominum.com wrote:
> I'd prefer not to think of the number of times I've made the following
> mistake:
>
> s = socket.socket(socket.SOCK_DGRAM, socket.AF_INET)
If it's any consolation, it's fewer than the number of times I have :).
(More fun, actuall
On 11/23/2010 12:07 PM, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 12:50 -0500, Isaac Morland a écrit :
Each enumeration is a type (well, OK, not in every language, presumably,
but certainly in many languages). The word "basic" is more important than
"types" in my sentence - the point
Le mardi 23 novembre 2010 à 11:34 -0800, Guido van Rossum a écrit :
> >> From a backward-compatibility perspective, what makes sense depends on
> >> whether they're used to implement existing constants (socket.AF_INET,
> >> etc.) or if they reserved for new features only.
> >
> > It's not only back
On 11/23/2010 11:34 AM, Guido van Rossum wrote:
The best example of the utility of enums even for Python is bool. I
resisted this for the longest time but people kept asking for it. Some
properties of bool:
(a) bool is a (final) subclass of int, and an int is acceptable in a
pinch where a bool i
On Tue, Nov 23, 2010 at 11:47 AM, Barry Warsaw wrote:
> On Nov 23, 2010, at 05:02 PM, Michael Foord wrote:
>
>>> * Enums are not subclassed from ints or strs. They are a distinct data type
>>> that can be converted to and from ints and strs. EIBTI.
>>
>>But if we are to use it *in* the standa
On Nov 23, 2010, at 11:52 AM, P.J. Eby wrote:
>This reminds me: a stdlib enum should support proper pickling and copying;
>i.e.:
>
>assert SomeEnum.anEnum is pickle.loads(pickle.dumps(SomeEnum.anEnum))
>
>This could probably be implemented by adding something like:
>
>def __reduce__(self):
On Nov 23, 2010, at 05:02 PM, Michael Foord wrote:
>> * Enums are not subclassed from ints or strs. They are a distinct data type
>>that can be converted to and from ints and strs. EIBTI.
>
>But if we are to use it *in* the standard library (as opposed to merely
>adding a module *to* the sta
On Nov 23, 2010, at 12:57 PM, Fred Drake wrote:
>>From a backward-compatibility perspective, what makes sense depends on
>whether they're used to implement existing constants (socket.AF_INET,
>etc.) or if they reserved for new features only.
As is usually the case, there's little reason to change
On Tue, Nov 23, 2010 at 10:06 AM, Antoine Pitrou wrote:
> Le mardi 23 novembre 2010 à 12:57 -0500, Fred Drake a écrit :
>> On Tue, Nov 23, 2010 at 12:37 PM, Antoine Pitrou wrote:
>> > Enumerations aren't a type at all (they have no distinguishing
>> > property).
>>
>> In any given language, this
Isaac Morland wrote:
> On Tue, 23 Nov 2010, Antoine Pitrou wrote:
>
> > Le mardi 23 novembre 2010 à 12:32 -0500, Isaac Morland a écrit :
> >> On Tue, 23 Nov 2010, Antoine Pitrou wrote:
> >>
> >>> We already have a bunch of bizarrely unrelated stuff in collections
> >>> (such as Callable), so we
Le mardi 23 novembre 2010 à 12:50 -0500, Isaac Morland a écrit :
> Each enumeration is a type (well, OK, not in every language, presumably,
> but certainly in many languages). The word "basic" is more important than
> "types" in my sentence - the point is that an enumeration capability is a
> v
Le mardi 23 novembre 2010 à 12:57 -0500, Fred Drake a écrit :
> On Tue, Nov 23, 2010 at 12:37 PM, Antoine Pitrou wrote:
> > Enumerations aren't a type at all (they have no distinguishing
> > property).
>
> In any given language, this may be true, or not. Whether they should
> be distinct in Pyth
On Tue, Nov 23, 2010 at 12:37 PM, Antoine Pitrou wrote:
> Enumerations aren't a type at all (they have no distinguishing
> property).
In any given language, this may be true, or not. Whether they should
be distinct in Python is core to the current discussion.
>From a backward-compatibility pers
On Tue, 23 Nov 2010, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 12:32 -0500, Isaac Morland a écrit :
On Tue, 23 Nov 2010, Antoine Pitrou wrote:
We already have a bunch of bizarrely unrelated stuff in collections
(such as Callable), so we could put enum there too.
Why not just "enum"
On Tue, 23 Nov 2010, Antoine Pitrou wrote:
We already have a bunch of bizarrely unrelated stuff in collections
(such as Callable), so we could put enum there too.
Why not just "enum" (i.e., "from enum import [...]" or "import
enum.[...]")? Enumerations are one of the basic kinds of types ove
Le mardi 23 novembre 2010 à 12:32 -0500, Isaac Morland a écrit :
> On Tue, 23 Nov 2010, Antoine Pitrou wrote:
>
> > We already have a bunch of bizarrely unrelated stuff in collections
> > (such as Callable), so we could put enum there too.
>
> Why not just "enum" (i.e., "from enum import [...]" o
On 23/11/2010 16:27, Barry Warsaw wrote:
On Nov 23, 2010, at 01:50 PM, Michael Foord wrote:
Right. As it happens I just submitted a patch to Barry Warsaw's enum package
(nice), flufl.enum [1], to allow namedtuple style creation of named
constants:
Thanks for the plug (and the nice patch).
FWI
At 11:31 AM 11/23/2010 -0500, Barry Warsaw wrote:
On Nov 23, 2010, at 03:15 PM, Michael Foord wrote:
>(Well, there is a third option that takes __name__ and sets the constants in
>the module automagically. I can understand why people would dislike that
>though.)
Personally, I think if you want
On Nov 23, 2010, at 03:15 PM, Michael Foord wrote:
>(Well, there is a third option that takes __name__ and sets the constants in
>the module automagically. I can understand why people would dislike that
>though.)
Personally, I think if you want that, then the explicit class definition is a
better
On Nov 23, 2010, at 01:50 PM, Michael Foord wrote:
>Right. As it happens I just submitted a patch to Barry Warsaw's enum package
>(nice), flufl.enum [1], to allow namedtuple style creation of named
>constants:
Thanks for the plug (and the nice patch).
FWIW, the documentation for the package is h
On 23/11/2010 15:37, ben.cottr...@nominum.com wrote:
On Tue, 23 Nov 2010 15:15:29 +, Michael Foord wrote:
There are still two reasonable APIs (unless you have changed your mind
and think that sticking with plain integers is best), of which I prefer
the latter:
SOME_CONST = Constant('SOME_CO
On Tue, 23 Nov 2010 15:15:29 +, Michael Foord wrote:
> There are still two reasonable APIs (unless you have changed your mind
> and think that sticking with plain integers is best), of which I prefer
> the latter:
>
> SOME_CONST = Constant('SOME_CONST', 1)
> OTHER_CONST = Constant('OTHER_CON
On 23/11/2010 16:05, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 15:40 +, Michael Foord a écrit :
On 23/11/2010 15:30, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 15:15 +, Michael Foord a écrit :
There are still two reasonable APIs (unless you have changed your mind
and thi
Le mardi 23 novembre 2010 à 15:40 +, Michael Foord a écrit :
> On 23/11/2010 15:30, Antoine Pitrou wrote:
> > Le mardi 23 novembre 2010 à 15:15 +, Michael Foord a écrit :
> >> There are still two reasonable APIs (unless you have changed your mind
> >> and think that sticking with plain inte
On 23/11/2010 15:30, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 15:15 +, Michael Foord a écrit :
There are still two reasonable APIs (unless you have changed your mind
and think that sticking with plain integers is best), of which I prefer
the latter:
SOME_CONST = Constant('SOME_CONS
Le mardi 23 novembre 2010 à 15:15 +, Michael Foord a écrit :
> There are still two reasonable APIs (unless you have changed your mind
> and think that sticking with plain integers is best), of which I prefer
> the latter:
>
> SOME_CONST = Constant('SOME_CONST', 1)
> OTHER_CONST = Constant('O
On 23/11/2010 15:01, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 08:52 -0600, Benjamin Peterson a écrit :
2010/11/23 Antoine Pitrou:
On Tue, 23 Nov 2010 14:24:18 +
Michael Foord wrote:
Well, for backwards compatibility reasons the new constants would have
to *behave* like the old on
Le mardi 23 novembre 2010 à 14:56 +, Michael Foord a écrit :
> On 23/11/2010 14:42, Antoine Pitrou wrote:
> > On Tue, 23 Nov 2010 14:24:18 +
> > Michael Foord wrote:
> >> Well, for backwards compatibility reasons the new constants would have
> >> to *behave* like the old ones (including ha
Le mardi 23 novembre 2010 à 08:52 -0600, Benjamin Peterson a écrit :
> 2010/11/23 Antoine Pitrou :
> > On Tue, 23 Nov 2010 14:24:18 +
> > Michael Foord wrote:
> >> Well, for backwards compatibility reasons the new constants would have
> >> to *behave* like the old ones (including having the sa
On 23/11/2010 14:42, Antoine Pitrou wrote:
On Tue, 23 Nov 2010 14:24:18 +
Michael Foord wrote:
Well, for backwards compatibility reasons the new constants would have
to *behave* like the old ones (including having the same underlying
value and comparing equal to it).
In many cases it is *l
2010/11/23 Antoine Pitrou :
> On Tue, 23 Nov 2010 14:24:18 +
> Michael Foord wrote:
>> Well, for backwards compatibility reasons the new constants would have
>> to *behave* like the old ones (including having the same underlying
>> value and comparing equal to it).
>>
>> In many cases it is *l
On Tue, 23 Nov 2010 14:24:18 +
Michael Foord wrote:
> Well, for backwards compatibility reasons the new constants would have
> to *behave* like the old ones (including having the same underlying
> value and comparing equal to it).
>
> In many cases it is *likely* that subclassing int is a b
On 23/11/2010 14:16, Nick Coghlan wrote:
On Tue, Nov 23, 2010 at 11:50 PM, Michael Foord
wrote:
PEP 354 was rejected for two primary reasons - lack of interest and nowhere
obvious to put it. Would it be *so bad* if an enum type lived in its own
module? There is certainly more interest now, and
On Tue, Nov 23, 2010 at 11:50 PM, Michael Foord
wrote:
> PEP 354 was rejected for two primary reasons - lack of interest and nowhere
> obvious to put it. Would it be *so bad* if an enum type lived in its own
> module? There is certainly more interest now, and if we are to use something
> like this
On 23/11/2010 13:41, Nick Coghlan wrote:
On Tue, Nov 23, 2010 at 2:46 AM, wrote:
On 04:24 pm, solip...@pitrou.net wrote:
On Mon, 22 Nov 2010 17:08:36 +0100
Hrvoje Niksic wrote:
On 11/22/2010 04:37 PM, Antoine Pitrou wrote:
+1. The problem with int constants is that the int gets printed, no
86 matches
Mail list logo
