On Sun, 28 Apr 2013 17:29:35 -0700
Ethan Furman wrote:
>
> Not only is this inconsistent with the rest of Python*, but it's going to be
> a PITA for data storage/retrieval:
>
> datastore = dbf.Table('storage.dbf', 'event_name C(50); date D; season
> SEASON')
>
> def retrieve_record(
On 28Apr2013 19:46, Ethan Furman wrote:
| int, float, and bool all have object constructors that take the
| given string and return a matching instance; int /may/ return a
| pre-existing instance, bool /will/ return a pre-existing instance.
I think Guido's already pointed out this:
>>> bool('F
Steven D'Aprano wrote:
On 29/04/13 10:29, Ethan Furman wrote:
- bool(1)# True
- int('11') # 11
- str(var) # whatever var had in it, now as a str
I think that's a red herring, because you're comparing the use of the
object constructor with look-up by name.
How does what bool
On Sun, Apr 28, 2013 at 09:02:15PM -0700, Ethan Furman wrote:
> Two examples:
>
> - the first few integers (up to 256 now, I think) are pre-created by the
> interpreter; when you do `int('7')` you are not getting a brand-new, never
> before used, integer 7 object, you're getting a cached in
Am 28.04.2013 22:36, schrieb Ethan Furman:
>>> Example enumeration:
>>>
>>> class Seasons(Enum): SPRING = 1 SUMMER = 2 AUTUMN = 3 WINTER = 4
>>>
>>> days_in_year = 365
>>>
>>> @property def avg_temp(self): return (75, 92, 66, 33)[int(self)+1] #
>>> enums are 1-based
>>>
>>>
>>> Definite Issue
On Sunday, April 28, 2013, Ethan Furman wrote:
>
> Enums are the same: they could return brand new instances every time, and
> programs using `==` to compare will keep on working. That they don't is an
> implementation detail.
>
Whoa. In this case the identity property is not justban implementati
On 4/28/2013 9:09 PM, Guido van Rossum wrote:
(2a. We could also allow Color('red') is Color.red, but that could be
confusing, and we can already do that with getattr(Color, 'red'), and
bool('False') doesn't return False anyway, so let's not do that.)
Glad you made this pronouncement in this wa
[re-directing back to python-dev]
On 04/28/2013 08:42 PM, Davis Silverman wrote:
as a not super experienced python developer, when i see Season('AUTUMN') it
looks like im creating an a Season object. I
understand your resoning, that it acts like a boolean singleton, however, i
feel it would co
Ethan Furman writes:
> I would hope that you would pay more attention to my arguments and
> rationale than to poorly chosen names.
I do. Nevertheless, it requires conscious effort. It's quite
appropriate for you to ask that of me, but ... do you think you're
doing Python any good to ask more
On Sun, Apr 28, 2013 at 3:28 PM, Nick Coghlan wrote:
> Functions are descriptors, so this rule already covers ordinary methods. The
> slight concern I have with making the duck typed exclusion only descriptors
> (rather than descriptors and callables) is that it means things like
> functools.parti
On 04/28/2013 06:52 PM, Steven D'Aprano wrote:
On 29/04/13 10:29, Ethan Furman wrote:
On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman wrote:
- should an enum item be selectable via __call__ instead of __getitem__
(i.e. Season(3) is AUTUMN)
D
On 04/28/2013 07:10 PM, Stephen J. Turnbull wrote:
@Ethan: I have real trouble sympathizing with your point of view
because you consistently pluralize your Enum names. AUTUMN *is not* a
SeasonZZ, it is an element of the *collection* Seasons. OTOH, AUTUMN
*is* a Season (look Ma, no ZZ!)
I wou
Steven D'Aprano writes:
> >>- should an enum item be selectable via __call__ instead of __getitem__
> >> (i.e. Seasons(3) is AUTUMN)
> >
> > No opinion.
>
> Does anyone know why this is even an issue? Is this pure
> bike-shedding over the API, or are there technical reasons for
> choo
On 29/04/13 10:29, Ethan Furman wrote:
On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman wrote:
- should an enum item be selectable via __call__ instead of __getitem__
(i.e. Seasons(3) is AUTUMN)
Does anyone know why this is even an issue? Is t
On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman wrote:
- should an enum item be selectable via __call__ instead of __getitem__
(i.e. Seasons(3) is AUTUMN)
Does anyone know why this is even an issue? Is this pure bike-shedding over the
API, or
On 4/28/2013 4:37 PM, Steven D'Aprano wrote:
I have also suggested that that the enum package provide a decorator
which can be used to explicitly flag values to *not* be turned into
enum values. See here:
http://mail.python.org/pipermail/python-dev/2013-April/125641.html
Even if the Enum class
On Sun, Apr 28, 2013 at 7:37 PM, Steven D'Aprano wrote:
> I have also suggested that that the enum package provide a decorator
> which can be used to explicitly flag values to *not* be turned into
> enum values. See here:
>
> http://mail.python.org/pipermail/python-dev/2013-April/125641.html
In t
On 29/04/13 06:02, Guido van Rossum wrote:
My opinions added
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman wrote:
Definite Issues:
- should enum items be of the type of the Enum class? (i.e. type(SPRING)
is Seasons)
IMO Yes.
+1
- should an enum item be selectable via __call__
On 04/28/2013 02:29 PM, Antoine Pitrou wrote:
On Sun, 28 Apr 2013 13:02:11 -0700
Guido van Rossum wrote:
- for the above two, how should they be included/excluded?
IMO Everything should be enumerated except
(a) things with a __get__() method (i.e. descriptors)
(b) __dunder__ names
I th
On Mon, 29 Apr 2013 08:28:34 +1000
Nick Coghlan wrote:
> On 29 Apr 2013 07:32, "Antoine Pitrou" wrote:
> >
> > On Sun, 28 Apr 2013 13:02:11 -0700
> > Guido van Rossum wrote:
> > >
> > > > - for the above two, how should they be included/excluded?
> > >
> > > IMO Everything should be enumerated
On 29 Apr 2013 07:32, "Antoine Pitrou" wrote:
>
> On Sun, 28 Apr 2013 13:02:11 -0700
> Guido van Rossum wrote:
> >
> > > - for the above two, how should they be included/excluded?
> >
> > IMO Everything should be enumerated except
> > (a) things with a __get__() method (i.e. descriptors)
> > (b
On Sun, 28 Apr 2013 13:02:11 -0700
Guido van Rossum wrote:
>
> > - for the above two, how should they be included/excluded?
>
> IMO Everything should be enumerated except
> (a) things with a __get__() method (i.e. descriptors)
> (b) __dunder__ names
I think it would be nice to define regular
Guido van Rossum wrote:
On Saturday, April 27, 2013, Greg Ewing wrote:
class Planet(Enum):
MERCURY = (3.303e+23, 2.4397e6)
VENUS = (4.869e+24, 6.0518e6)
EARTH = (5.976e+24, 6.37814e6)
def __init__(self, mass, radius):
self.mass = mass
On 04/28/2013 01:02 PM, Guido van Rossum wrote:
My opinions added
Mine also now added.
Example enumeration:
class Seasons(Enum):
SPRING = 1
SUMMER = 2
AUTUMN = 3
WINTER = 4
days_in_year = 365
@property
def avg_temp(self):
return (75, 92, 66, 33
My opinions added
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman wrote:
> Example enumeration:
>
> class Seasons(Enum):
> SPRING = 1
> SUMMER = 2
> AUTUMN = 3
> WINTER = 4
>
> days_in_year = 365
>
> @property
> def avg_temp(self):
> return (75, 92, 66, 33)[int(
Example enumeration:
class Seasons(Enum):
SPRING = 1
SUMMER = 2
AUTUMN = 3
WINTER = 4
days_in_year = 365
@property
def avg_temp(self):
return (75, 92, 66, 33)[int(self)+1] # enums are 1-based
Definite Issues:
- should enum items be of the type of the Enu
Hi all,
I've just read a few dozen enum-related emails, and there are so many more.
I would like to form an opinion about the proposal(s), but I feel I don't
know what the actual issues are anymore.
In the past, somebody usually presented a summary of the issues so far,
and that was a good point
On 04/27/2013 09:20 PM, Guido van Rossum wrote:
On Saturday, April 27, 2013, Greg Ewing wrote:
class Planet(Enum):
MERCURY = (3.303e+23, 2.4397e6)
VENUS = (4.869e+24, 6.0518e6)
EARTH = (5.976e+24, 6.37814e6)
MARS= (6.421e+23, 3.3972e6)
JUPITER = (1.9e+27, 7.1
On 04/27/2013 08:59 PM, Greg Ewing wrote:
It's possible to make it work, I think. The __call__ method
of the metaclass is going to have to do something special
anyway, so that Planet(3) can look up and return an existing
instance instead of making a new one. And if it doesn't make
a new instance
29 matches
Mail list logo
