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
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
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': 'Hello
On Tue, Nov 30, 2010 at 7:36 AM, Greg Ewing greg.ew...@canterbury.ac.nz 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*
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
On 28/11/2010 02:38, Nick Coghlan wrote:
On Sun, Nov 28, 2010 at 9:26 AM, Raymond Hettinger
raymond.hettin...@gmail.com 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
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
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
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
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
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 that
On Mon, Nov 29, 2010 at 2:28 AM, Michael Foord
fuzzy...@voidspace.org.uk 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
On 29/11/2010 00:48, Nick Coghlan wrote:
On Mon, Nov 29, 2010 at 2:28 AM, Michael Foord
fuzzy...@voidspace.org.uk 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
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 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 Thu, Nov 25, 2010 at 3:41 AM, Michael Foord
fuzzy...@voidspace.org.uk 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
On 27/11/2010 10:51, Nick Coghlan wrote:
On Thu, Nov 25, 2010 at 3:41 AM, Michael Foord
fuzzy...@voidspace.org.uk 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:
On Sun, Nov 28, 2010 at 12:01 AM, Michael Foord
fuzzy...@voidspace.org.uk 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
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 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
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 than I
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;
On Sun, Nov 28, 2010 at 9:26 AM, Raymond Hettinger
raymond.hettin...@gmail.com 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
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
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 Thu, Nov 25, 2010 at 11:34 AM, Glenn Linderman v+pyt...@g.nevcal.com 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
On 25/11/2010 10:12, Nadeem Vawda wrote:
On Thu, Nov 25, 2010 at 11:34 AM, Glenn Lindermanv+pyt...@g.nevcal.com 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
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 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
On 23/11/2010 14:16, Nick Coghlan wrote:
On Tue, Nov 23, 2010 at 11:50 PM, Michael Foord
fuzzy...@voidspace.org.uk 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
On Wed, Nov 24, 2010 at 10:30 PM, Michael Foord
fuzzy...@voidspace.org.uk 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
Nick Coghlan wrote:
On Wed, Nov 24, 2010 at 10:30 PM, Michael Foord
fuzzy...@voidspace.org.uk 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
2010/11/24 Steven D'Aprano st...@pearwood.info:
Nick Coghlan wrote:
On Wed, Nov 24, 2010 at 10:30 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
Based on a non-exhaustive search, Python standard library modules
currently
using integers for constants:
Thanks for that review. I think
On 24/11/2010 14:08, Nick Coghlan wrote:
On Wed, Nov 24, 2010 at 10:30 PM, Michael Foord
fuzzy...@voidspace.org.uk 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
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 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
On 23/11/2010 13:41, Nick Coghlan wrote:
On Tue, Nov 23, 2010 at 2:46 AM,exar...@twistedmatrix.com wrote:
On 04:24 pm, solip...@pitrou.net wrote:
On Mon, 22 Nov 2010 17:08:36 +0100
Hrvoje Niksichrvoje.nik...@avl.com wrote:
On 11/22/2010 04:37 PM, Antoine Pitrou wrote:
+1. The problem with
On Tue, Nov 23, 2010 at 11:50 PM, Michael Foord
fuzzy...@voidspace.org.uk 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
On 23/11/2010 14:16, Nick Coghlan wrote:
On Tue, Nov 23, 2010 at 11:50 PM, Michael Foord
fuzzy...@voidspace.org.uk 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
On Tue, 23 Nov 2010 14:24:18 +
Michael Foord fuzzy...@voidspace.org.uk 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
2010/11/23 Antoine Pitrou solip...@pitrou.net:
On Tue, 23 Nov 2010 14:24:18 +
Michael Foord fuzzy...@voidspace.org.uk 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
On 23/11/2010 14:42, Antoine Pitrou wrote:
On Tue, 23 Nov 2010 14:24:18 +
Michael Foordfuzzy...@voidspace.org.uk 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
Le mardi 23 novembre 2010 à 08:52 -0600, Benjamin Peterson a écrit :
2010/11/23 Antoine Pitrou solip...@pitrou.net:
On Tue, 23 Nov 2010 14:24:18 +
Michael Foord fuzzy...@voidspace.org.uk wrote:
Well, for backwards compatibility reasons the new constants would have
to *behave* like the
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 Foordfuzzy...@voidspace.org.uk wrote:
Well, for backwards compatibility reasons the new constants would have
to *behave* like the old
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 Pitrousolip...@pitrou.net:
On Tue, 23 Nov 2010 14:24:18 +
Michael Foordfuzzy...@voidspace.org.uk wrote:
Well, for backwards compatibility reasons the new
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 =
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 =
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 integers is
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
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_CONST',
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 =
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
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
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 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).
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 [...] or import
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 overall
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, Nov 23, 2010 at 12:37 PM, Antoine Pitrou solip...@pitrou.net 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
Le mardi 23 novembre 2010 à 12:57 -0500, Fred Drake a écrit :
On Tue, Nov 23, 2010 at 12:37 PM, Antoine Pitrou solip...@pitrou.net 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
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
very
Isaac Morland ijmor...@uwaterloo.ca 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
On Tue, Nov 23, 2010 at 10:06 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le mardi 23 novembre 2010 à 12:57 -0500, Fred Drake a écrit :
On Tue, Nov 23, 2010 at 12:37 PM, Antoine Pitrou solip...@pitrou.net wrote:
Enumerations aren't a type at all (they have no distinguishing
property).
In
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 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 standard
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 Tue, Nov 23, 2010 at 11:47 AM, Barry Warsaw ba...@python.org 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
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
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 backwards
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 is
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, actually,
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
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.
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 think that
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
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
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 added
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
___
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
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
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
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
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
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
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 at
On Tue, Nov 23, 2010 at 9:35 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
86 matches
Mail list logo
