Ethan Furman added the comment:
Final (hopefully! ;) patch.
I stuck the toc reference in datatypes.
If no more edits are necessary I'll commit on Friday (three days from now).
--
Added file: http://bugs.python.org/file30548/pep-0435.12.stoneleaf.
Ethan Furman added the comment:
Well, that made me laugh first thing in the morning!
I had nuked and redone my clone, and yeah, forgot to re-add the files. :/
Trying again...
Commit message was okay?
--
___
Python tracker
<http://bugs.python.
Ethan Furman added the comment:
Enum members have two pieces of easily accessible information: `name` and
`value`. The name is taken from the attribute the value is assigned to; the
value, obviously, is the value assigned.
The question, then, is what should happen when the function syntax is
Ethan Furman added the comment:
I haven't seen any discouraging words regarding the decorator. If no one has
any compelling reasons why it shouldn't be added, I'll craft a version and put
it in (only real difference with Nick's would be catching all the duplicates at
once
Ethan Furman added the comment:
Nick, in your example it looks like json is using the __str__ for int, but the
__repr__ for float -- is this correct?
--
assignee: -> ethan.furman
nosy: +eli.bendersky, ethan.furman
___
Python tracker
&l
Ethan Furman added the comment:
I have no problem with leaving __str__ as the inherited type's, and just
keeping the __repr__ as the enum add-on; this could be one of the differences
between a pure Enum and a hybrid Enum.
Is it safe to change the json behaviour back to using __str_
Ethan Furman added the comment:
Eric,
The pickle support is solely in Enum. No changes were made to pickles.
--
___
Python tracker
<http://bugs.python.org/issue18
Ethan Furman added the comment:
I was unable to find any references to previous problems with json and floats.
A quick-n-dirty patch yields the following:
--> from json import dumps, loads
--> from enum import Enum
--> class FE(float, Enum):
... pass
...
--> class Test(FE):
...
Changes by Ethan Furman :
--
nosy: +ezio.melotti, rhettinger
___
Python tracker
<http://bugs.python.org/issue18264>
___
___
Python-bugs-list mailing list
Unsub
Ethan Furman added the comment:
Here's the relevant routine from _json.c:
-
static PyObject *
encoder_encode_float(PyEncoderObject *s, PyObject *obj)
{
/* Return the JSON representation of a PyFloat */
double i = PyFloat_AS_DOUBLE(obj);
Ethan Furman added the comment:
I'd be in favor of the __protocol__ route first and the PEP 443 route second.
The problem with just tacking in `str(int(value))` or `str(float(value))` is
where does it stop? StrEnum, TupleEnum, BytesEnum, ComplexEnum,
SomeOtherInterestingConstantEnum
Ethan Furman added the comment:
On 06/21/2013 07:49 PM, Guido van Rossum wrote:
> Eli Bendersky added the comment:
>>
>> Practically speaking, what should be done to make enum play well with JSON
>> without writing new PEPs? I think we still want to convert those stdlib
>
Ethan Furman added the comment:
Guido van Rossum added the comment:
>
> Yes for float() -- but for str() it would seem redundant? (Or what's
> the context?)
If a user has
class Color(StrEnum):
red = 'ff'
green = '00ff00'
bl
Changes by Ethan Furman :
--
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue18281>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ethan Furman :
--
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue18303>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ethan Furman added the comment:
For the curious, here are all the tracebacks:
--> json.dumps(a)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.3/json/__init__.py", line 236, in dumps
return _default_encoder.encode(obj)
File &
Changes by Ethan Furman :
--
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue18173>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ethan Furman added the comment:
It doesn't look like xuanji has signed a CLA.
Should we create a new issue, and have someone else create a new patch, and let
this issue just be about the docs?
--
nosy: +ethan.furman
___
Python tracker
Ethan Furman added the comment:
unique() added to enum.py; tests added; docs updated.
If no complaints within a few days I'll push them through.
--
keywords: +patch
Added file: http://bugs.python.org/file30722/unique.stoneleaf.01.patch
___
P
Changes by Ethan Furman :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue18042>
___
___
Python-bugs-list mailing list
Unsubscri
Ethan Furman added the comment:
Integrated comments.
--
Added file: http://bugs.python.org/file30730/unique.stoneleaf.02.patch
___
Python tracker
<http://bugs.python.org/issue18
Changes by Ethan Furman :
--
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue18305>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ethan Furman added the comment:
So making this a speed-up for generic objects using __iadd__ is out.
The only question remaining is: is it worth special casing a few specific
objects (list, tuple, str) to optimise performance?
The str question has already been answered: it's special cas
Changes by Ethan Furman :
--
assignee: -> ethan.furman
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue18508>
___
___
Python-bugs-list mai
New submission from Ethan Furman:
While working on issue #18508 I stumbled across this:
Traceback (most recent call last):
...
File "/usr/local/lib/python3.4/enum.py", line 417, in __new__
if value in cls._value2member_map:
TypeError: unhashable type: 'list'
I'l
Ethan Furman added the comment:
Commenting further:
some_key in dict
is conceptually the same as
some_key in dict.keys()
which /would/ return False for an unhashable key -- at least it did in 2.x; for
3.x you have to say
some_key in list(dict.keys())
which seems like a step
Changes by Ethan Furman :
--
title: dict.__contains__ raises exception instead of returning False ->
dict.__contains__ and dict.keys().__contains__ raises exception instead of
returning False
___
Python tracker
<http://bugs.python.org/issu
Changes by Ethan Furman :
--
assignee: ethan.furman ->
versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issu
Changes by Ethan Furman :
--
keywords: +patch
stage: -> patch review
Added file: http://bugs.python.org/file30986/issue18510.stoneleaf.01.patch
___
Python tracker
<http://bugs.python.org/issu
Ethan Furman added the comment:
Cleaner patch.
--
Added file: http://bugs.python.org/file30987/issue18510.stoneleaf.02.patch
___
Python tracker
<http://bugs.python.org/issue18
Changes by Ethan Furman :
--
assignee: -> ethan.furman
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue18545>
___
___
Python-bugs-list mai
Changes by Ethan Furman :
--
assignee: -> ethan.furman
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue18635>
___
___
Python-bugs-list mai
Ethan Furman added the comment:
Ah, so the Enum class has the mixin class as wall as / instead of the Enum
member (which should find it via normal attribute lookup).
I have no problem with that. I'll need to make a couple more changes to the
code, add a test, etc., etc.
It won'
Ethan Furman added the comment:
I'll check you patch later against big numbers (which is where I had
difficulties). If it works I'll try to make it more complete. If it doesn't,
I've been working on just extraction the Enum member's value and using that
(work
Ethan Furman added the comment:
I don't think my idea of always extracting .value is grandiose (and didn't take
that long to implement on the Python side), but it is definitely forcing me to
learn more about C and how Python is put together.
It this point I have successfully imp
Ethan Furman added the comment:
I also admit to being curious as to the reason it is useful, especially since
it is, at this point, an implementation detail.
Even so, it still makes more sense to have that attribute on the class instead
of the instance
Ethan Furman added the comment:
Eli, your method is good. I thought I had tried something similar but I
obviously had the wrong PyLong constructor.
I'll get it implemented.
--
___
Python tracker
<http://bugs.python.org/is
Ethan Furman added the comment:
Thanks for the offer, Eli, but I almost have the tests done. :)
--
___
Python tracker
<http://bugs.python.org/issue18264>
___
___
Ethan Furman added the comment:
Okay, patch attached with C code (thanks, Eli!), more python code, and some new
tests.
Only the `int` case is handled.
--
Added file: http://bugs.python.org/file31141/issue18264.stoneleaf.01.patch
___
Python tracker
Ethan Furman added the comment:
Well, aside from not having a clue as to what Chris is trying to do, should we
make _member_type_ public? The only reason I put it there was to aid
introspection -- Enum does not use it.
--
___
Python tracker
<h
Ethan Furman added the comment:
I don't understand.
Type checks are already performed throughout the code (int, float, True, False,
NaN, Inf, etc.).
What will opereator.index buy us?
--
___
Python tracker
<http://bugs.python.org/is
Ethan Furman added the comment:
This patch handles both float and int subclasses, and includes
fixes/improvements from the review.
--
Added file: http://bugs.python.org/file31155/issue18264.stoneleaf.02.patch
___
Python tracker
<h
Ethan Furman added the comment:
Forgot to add float tests. Included in this patch.
--
Added file: http://bugs.python.org/file31156/issue18264.stoneleaf.03.patch
___
Python tracker
<http://bugs.python.org/issue18
Ethan Furman added the comment:
Hopefully the final patch. :)
--
Added file: http://bugs.python.org/file31172/issue18264.stoneleaf.04.patch
___
Python tracker
<http://bugs.python.org/issue18
Ethan Furman added the comment:
Forgot to back out core dump tests before creating previous patch. This one
even passes the tests. :/
--
Added file: http://bugs.python.org/file31173/issue18264.stoneleaf.05.patch
___
Python tracker
<h
Ethan Furman added the comment:
I'll plan on committing no sooner than Friday unless somebody else has
comments/corrections.
Thanks, Eli.
--
___
Python tracker
<http://bugs.python.org/is
Ethan Furman added the comment:
> Eli Bendersky added the comment:
>
> Make sure to run the test(s) in refleak mode . . .
How extensive should testing be?
I plan on always running the refleak mode tests (now that I know how ;) .
Should I also run non-refleak tests?
Should I run tes
New submission from Ethan Furman:
help(), when used on an enum member or class, returns almost nothing. I
suspect the custom __dir__ is at fault, but whatever is causing the problem
needs fixing.
--
assignee: ethan.furman
messages: 194714
nosy: barry, eli.bendersky, ethan.furman
Ethan Furman added the comment:
With custom __dir__:
Help on class Enum in module enum:
Enum =
Without custom __dir__:
Help on class Enum in module enum:
class Enum(builtins.object)
| Generic enumeration.
|
| Derive from this
Ethan Furman added the comment:
Sorry, sorry.
Long week, felt like more than two days, mild sense of unease and stress due to
non-functioning Release Schedule on python.org, and wanting to get Enum used
/somewhere/ in the stdlib before 3.4 is locked down.
Making help() better would be a
Ethan Furman added the comment:
So what do we want Enum's __dir__ to report?
Normally we see things like __eq__, __dict__, __getnewargs__, etc.
For IntEnum there would be __abs__, __floor__, __div__, etc.
Do we want to worry about those kinds of differences? I think we do.
And if
Ethan Furman added the comment:
Huh. I just checked `help(Color)` on my proposed __dir__ and got the two-line,
rather useless, response. Perhaps help() is broken with all custom __dir__s.
--
___
Python tracker
<http://bugs.python.org/issue18
Ethan Furman added the comment:
Issue18738 created.
--
___
Python tracker
<http://bugs.python.org/issue18720>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Ethan Furman:
While `.format()` works fine with enum, %-formatting does not:
--> class AF(enum.IntEnum):
... IPv4 = 1
... IPv6 = 2
...
--> AF.IPv4
--> '%s' % AF.IPv4
'AF.IPv4'
--> '%r' % AF.IPv4
''
--> '%d
Changes by Ethan Furman :
--
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue18606>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ethan Furman added the comment:
'{:}'.format(AF.IPv4) is incorrect, but '{:10}'.format(AF.IPv4) behaves as it
should.
--
___
Python tracker
<http://bug
Ethan Furman added the comment:
Looks like Objects/unicodeobject.c needs the same enhancement that
Modules/_json.c received: convert int/float subclasses into actual ints/floats
before continuing.
--
___
Python tracker
<http://bugs.python.
Ethan Furman added the comment:
Gotcha. I'm on it.
--
assignee: -> ethan.furman
___
Python tracker
<http://bugs.python.org/issue18738>
___
___
Python-bug
Ethan Furman added the comment:
The %-formatting needs to be handled by str, correct?
What is '{:}' supposed to mean?
--
___
Python tracker
<http://bugs.python.o
Ethan Furman added the comment:
Which is the same as '%s', yes? In that case, the current behavior of
'{:}'.format(AF.IPv4) is correct, isn't it?
--
___
Python tracker
<http:
Ethan Furman added the comment:
> Eric V. Smith added the comment:
>
> I think that specifying __format__() would be best, except then you need to
> decide what sort of format specification language you want to support, and
> deal with all of the implementation details. Or,
Ethan Furman added the comment:
> Eric V. Smith added the comment:
>
> For the format version, what gets called is:
>
> int_subclass.__format__('d'), which is int.__format__(int_subclass,
> 'd'), which produces '1', assuming int(int_subclass) is 1
Ethan Furman added the comment:
> Eric V. Smith added the comment:
>
> I assumed we'd want it to look like the str() version of itself, always. But
> it's debatable.
An IntEnum's str and repr should be (and any format or % codes that are the
equivalent) the Enu
Ethan Furman added the comment:
Okay, I see your points. I can certainly agree with going with the str
representation when no numeric code is specified. But, if a numeric code is
specified (x, b, d, etc.) then the numeric value should be used.
Agreed
Ethan Furman added the comment:
On 08/14/2013 11:55 AM, Eli Bendersky wrote:
>
> I'm not sure I understand. The discrepancy between {:} and {:10} is clearly
> a problem.
Ah, you're right.
--
___
Python tracker
<http://bugs
Ethan Furman added the comment:
What I'm hoping is to get agreement on what the behavior should be (unspecified
format codes use str or repr, specified
numeric codes use the value), and then persuade folks that int (or PyLong) is
where that behavior should be kept (so int
is sub
Ethan Furman added the comment:
--> class Test(enum.IntEnum):
... one = 1
... two = 2
...
--> '{}'.format(Test.one)
'Test.one'
--> '{:d}'.format(Test.one)
'1'
--> '{:}'.format(Test.one)
'Test.one'
--> '{:
Ethan Furman added the comment:
So what you're saying is that '{:}' is empty, but '{:10}' is not?
--
___
Python tracker
<http:
Ethan Furman added the comment:
> In order to avoid that logic, and cause more format specifiers to result in
> str-like behavior, we'll need to implement an __format__ somewhere (IntEnum,
> I guess) that makes the "int or str" decision.
If this is the way format i
Ethan Furman added the comment:
Drat. IntEnum is supposed to be a drop-in replacement for int. I guess I'll
have to consider more than just the letter
code to decide whether to go with int.__format__ or str.__format__.
--
___
Python tr
Ethan Furman added the comment:
+def __format__(self, *args, **kwargs):
+return self.__class__._member_type_.__format__(self.value, *args,
**kwargs)
+
With this in the Enum class all members simply forward formatting to the
mixed-in type, meaning that IntEnum behaves exactly like
Ethan Furman added the comment:
> Eli Bendersky added the comment:
> Naturally, compatibility with % formatting is desired. '%s' is str, '%i' is
> int().
Can we solve that one on this issue, or do we need to make another?
--
_
Ethan Furman added the comment:
> Eric V. Smith added the comment:
>
> I think the answers should be:
>
> - Formats as int if the length of the format spec is >= 1 and it ends in
> one of "bdoxX" (the int presentation types).
Hmmm. How about defining the charac
Ethan Furman added the comment:
> Eric V. Smith added the comment:
>> Ethan Furman added the comment:
>>
>>> Hmmm. How about defining the characters that will be supported for string
>>> interpretation, and if there are any other
>>> characters in fo
Ethan Furman added the comment:
> Eric V. Smith added the comment:
>
> But a datetime format string can end in "0", for example.
>
>>>> format(datetime.datetime.now(), '%H:%M:%S.00')
> '20:25:27.00'
Not a problem, because once the digi
Ethan Furman added the comment:
Eric, please do not feel your time has been wasted. I greatly appreciate the
knowledge you shared and I learned much.
I feel very strongly that, as much as possible, an Enum should Just Work.
Requiring users to write their own __format__ any time they create
Ethan Furman added the comment:
This patch contains the previous patch, plus a fix and tests for %i, %d, and %u
formatting, and tests only for %f formatting (nothing to fix there, but don't
want it breaking in the future ;) .
--
Added file: http://bugs.python.org/file31311/issue
Changes by Ethan Furman :
--
assignee: -> ethan.furman
___
Python tracker
<http://bugs.python.org/issue18745>
___
___
Python-bugs-list mailing list
Unsubscri
Ethan Furman added the comment:
Tests look good to me.
--
nosy: +barry, eli.bendersky
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issu
Ethan Furman added the comment:
Eli Bendersky added the comment:
>
> The whole point of IntEnum and replacing stdlib constants with it was
> friendly str & repr out of the box.
Sure, friendly str and repr plus an nice way to work them in code.
> This means that "just
Ethan Furman added the comment:
Eric V. Smith added the comment:
>
> this gives the (to me) surprising results of:
>
>>>> format(S.a)
> 'S.a'
>>>> format(S.a, '10')
> 'S.a'
>>>> format(S.a, '10s')
>
Changes by Ethan Furman :
--
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue18788>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ethan Furman added the comment:
Serhiy Storchaka added the comment:
>
> I'm proposing to split this issue on two issues. One for C-style formatting
> (I guess everyone agree that '%i' % should return decimal
> representation of its numerical value) and other
Ethan Furman added the comment:
I'll get my patch separated and over here when I get back home (on a business
trip at the moment).
--
___
Python tracker
<http://bugs.python.org/is
Changes by Ethan Furman :
--
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue17741>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ethan Furman added the comment:
Stefan Behnel wrote:
> ... I still wonder why I'm the one writing all the patches ...
I imagine for the same reasons that I offered to write Enum: I had definite
ideas about how it should be, it is sometimes easier to explain with working
code than wi
Ethan Furman added the comment:
Okay, simple fix, patch and tests attached.
--
keywords: +patch
nosy: +ncoghlan
stage: -> patch review
Added file: http://bugs.python.org/file31492/issue18780.stoneleaf.01.patch
___
Python tracker
&l
Ethan Furman added the comment:
The added tests for inf, -inf, and nan are good.
The refactoring of the dictionary tests are not good. The reason is that
before _json.c was fixed (issue18264) it would return the string value of an
IntEnum instead of the string value of the IntEnum member&#
Ethan Furman added the comment:
On 08/14/2013 09:27 PM, on PyDev, Nick Coghlan wrote:
> For enums, I believe they should be formatted like their
> base types (so !s and !r will show the enum name, anything without
> coercion will show the value).
I agree. While one of the big reaso
Ethan Furman added the comment:
Final (hopefully ;) patch attached. Thanks, Eli, for your comments and help.
--
Added file: http://bugs.python.org/file31538/issue18738.stoneleaf.04.patch
___
Python tracker
<http://bugs.python.org/issue18
Ethan Furman added the comment:
Thanks, Eric, for teaching me a bunch about format. :)
--
___
Python tracker
<http://bugs.python.org/issue18738>
___
___
Pytho
Ethan Furman added the comment:
Okay, the final final patch. ;)
--
Added file: http://bugs.python.org/file31539/issue18738.stoneleaf.05.patch
___
Python tracker
<http://bugs.python.org/issue18
Ethan Furman added the comment:
Eli Bendersky added the comment:
>
> Another issue is _intenum_converter. Ethan - do you think it belongs in the
> enum module as a helper function or something of the sort?
I'm fine with it being a non-public member of enum, although if we ha
Ethan Furman added the comment:
Fixed formatting in patch. ;)
--
Added file: http://bugs.python.org/file31541/issue18745.stoneleaf.02.patch
___
Python tracker
<http://bugs.python.org/issue18
Ethan Furman added the comment:
I've done some more investigation today but I can't tell if the issue is solely
in help or if it's some wierd
interaction between help and _EnumMeta.
--
___
Python tracker
<http://bugs.pyt
Ethan Furman added the comment:
Nope, not yet. And even a simple dummy metaclass with a custom __dir__ worked
fine.
--
___
Python tracker
<http://bugs.python.org/issue18
Ethan Furman added the comment:
What I know for sure:
1) if something is added to dir() that does not live in __dict__, help()
breaks.
2) if a certain something or some things are removed from dir(), help()
breaks. I'm not yet certain which somethings
apply
Ethan Furman added the comment:
>From my layman's perspective they are all not numbers -- you can't add 5 to
>any of them and get a number back that is 5
more than you started with.
By I have no problem with your proposed name -- I&#x
Changes by Ethan Furman :
--
nosy: +eli.bendersky, ethan.furman
___
Python tracker
<http://bugs.python.org/issue16938>
___
___
Python-bugs-list mailing list
Unsub
Ethan Furman added the comment:
I wonder if it would be better to have inspect.classify_class_attrs be improved
instead?
--
___
Python tracker
<http://bugs.python.org/issue16
701 - 800 of 1868 matches
Mail list logo
