Changes by Ethan Furman et...@stoneleaf.us:
--
assignee: - ethan.furman
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18635
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't make
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
(works fine on the Python side
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 imported Enum
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
Changes by Ethan Furman et...@stoneleaf.us:
--
assignee: - ethan.furman
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18545
Changes by Ethan Furman et...@stoneleaf.us:
--
keywords: +patch
stage: - patch review
Added file: http://bugs.python.org/file30986/issue18510.stoneleaf.01.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18508
Ethan Furman added the comment:
Cleaner patch.
--
Added file: http://bugs.python.org/file30987/issue18510.stoneleaf.02.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18508
Changes by Ethan Furman et...@stoneleaf.us:
--
assignee: - ethan.furman
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18508
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'll wrap it in a try-except
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 et...@stoneleaf.us:
--
title: dict.__contains__ raises exception instead of returning False -
dict.__contains__ and dict.keys().__contains__ raises exception instead of
returning False
___
Python tracker rep
Changes by Ethan Furman et...@stoneleaf.us:
--
assignee: ethan.furman -
versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18510
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 cased
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18305
___
___
Python-bugs-list
Ethan Furman added the comment:
Integrated comments.
--
Added file: http://bugs.python.org/file30730/unique.stoneleaf.02.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18042
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 rep
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
___
Python
Changes by Ethan Furman et...@stoneleaf.us:
--
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18042
___
___
Python-bugs-list
Ethan Furman added the comment:
For the curious, here are all the tracebacks:
-- json.dumps(a)
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python3.3/json/__init__.py, line 236, in dumps
return _default_encoder.encode(obj)
File /usr/lib/python3.3/json
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18173
___
___
Python-bugs-list
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18303
___
___
Python-bugs-list
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18281
___
___
Python-bugs-list
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, etc
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
constants to IntEnums
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'
blue = 'ff'
..
..
..
oh. `str
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
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 instead of one
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 rep
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 rep...@bugs.python.org
http://bugs.python.org/issue18264
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):
... one = 1.0
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ezio.melotti, rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18264
___
___
Python
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:
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 rep...@bugs.python.org
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.patch
Ethan Furman added the comment:
Hopefully the last update. :)
--
Added file: http://bugs.python.org/file30512/pep-0435.11.stoneleaf.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17947
Ethan Furman added the comment:
Hopefully the final bit of code, plus docs.
Code changes:
_names_ are reserved
Doc changes (different from the PEP):
examples of AutoEnum, UniqueEnum, and OrderedEnum
--
Added file: http://bugs.python.org/file30504/pep-0435.08.stoneleaf.patch
Changes by Ethan Furman et...@stoneleaf.us:
Removed file: http://bugs.python.org/file30504/pep-0435.08.stoneleaf.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17947
Changes by Ethan Furman et...@stoneleaf.us:
Added file: http://bugs.python.org/file30505/pep-0435.08.stoneleaf.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17947
Changes by Ethan Furman et...@stoneleaf.us:
Removed file: http://bugs.python.org/file30505/pep-0435.08.stoneleaf.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17947
Ethan Furman added the comment:
Apologies for the noise -- was having trouble getting the correct patch
attached. :/
--
Added file: http://bugs.python.org/file30506/pep-0435.09.stoneleaf.patch
___
Python tracker rep...@bugs.python.org
http
Ethan Furman added the comment:
So, which is better?
To have a @unique class decorator as part of the module, or to have a
UniqueEnum recipe in the docs?
A decorator is immediately usable, but requires remembering an extra line of
code.
An example requires being put into a local utility
Ethan Furman added the comment:
Good idea, thanks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17947
___
___
Python-bugs-list mailing list
Ethan Furman added the comment:
Doc updates are in.
I removed the 'unique, constant' from the first line of the intro, as neither
of those things are necessarily true.
--
Added file: http://bugs.python.org/file30511/pep-0435.10.stoneleaf.patch
Ethan Furman added the comment:
Hmm -- I was confusing member names with member values; I'll put 'unique' back
in.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17947
Ethan Furman added the comment:
Working on documentation...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17947
___
___
Python-bugs-list
Ethan Furman added the comment:
Wow. I definitely felt like an apprentice after reading the changes. Thanks,
Eli, that looks worlds better!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17947
Ethan Furman added the comment:
This is certainly an effective method, but it places safety off by default. I
would rather have a system that was from duplicates by default but had an easy
override.
The method I had in place in my original code was something like:
class Color(Enum, options
Ethan Furman added the comment:
I'm not giving up hope yet. Plenty of Python features no longer work the way
they did when their PEP was accepted. ;)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18042
Ethan Furman added the comment:
Oh. Well, I like your decorator. :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18042
___
___
Python-bugs
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18011
___
___
Python-bugs-list
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18009
___
___
Python-bugs-list
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18001
___
___
Python-bugs-list
Ethan Furman added the comment:
Your interest if fixing Python is appreciated, but you need to verify that a
bug actually exists first:
Python 2.7.3 (default, Sep 26 2012, 21:51:14)
[GCC 4.7.2] on linux2
Type help, copyright, credits or license for more information.
-- class RawConfigParser
Ethan Furman added the comment:
Antoine, do you want to pursue, or can we close this?
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3489
Ethan Furman added the comment:
David, is this still a need? Or, put another way, has Python change enough in
the last 11 years that you can now do what you wanted?
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8297
___
___
Python-bugs-list
Ethan Furman added the comment:
Got the pickle issues worked out. Added super to the metaclass' __new__.
Checking for illegal names of members and raising ValueError if any are found
(I know, I know, safety checks! But such an enum is broken from the getgo so I
see no reason to allow those
Ethan Furman added the comment:
So the repr will look like:
Color.red: 'red'
?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17961
Ethan Furman added the comment:
Another approach to handling this, and other, issues is to allow options to
EnumMeta. My original aenum code had the default Enum class as unordered, no
duplicates allowed, non-indexable, etc., but then allowed options to be passed
in such as DUPLICATES
Ethan Furman added the comment:
Make it simpler:
class EnumMeta():
allow_subclass = False
class MyEnumMeta(EnumMeta):
allow_subclass = True
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17954
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17961
___
___
Python-bugs-list
Ethan Furman added the comment:
After more thought, I think we should leave the shortened version of
_StealthProperty as is.
The reasoning being that if _StealthProperty does the __getattr__ lookup
itself, and fails, it will return an AttributeError... and then Python will use
__getattr__
Ethan Furman added the comment:
In flufl.enum integers also made since as that was the default back-end data
type.
Currently, the functional method allows a type declaration. The behavior there
could be tweaked such that no specification meant no value (a truly valueless
enum!), type=int
Ethan Furman added the comment:
Not trying to push, but if I don't write it down now, I'll forget later. ;)
What does adding new members gain us? If I have a func xyz() that's expecting
a Color, a MoreColor will work sometimes and blow up other times.
Or are you saying that we may have
Ethan Furman added the comment:
I believe Guido will be happy to replace the frame hack once we have something
better, such as a way to implicitly (or explicitly in the case of helper
functions) pass the calling module's name.
Maybe a global __calling_module__ that a function can look
Ethan Furman added the comment:
Here's the latest patch.
Note that the functional API portion is broken, and I'll get back to that this
evening. Please only comment on the working code. ;)
I'll make that _MemborOrProperty name change then as well.
--
Added file: http
Ethan Furman added the comment:
Eli,
The original _StealthProperty checked to see if it was being called on instance
or class, and if it was the class it invoked __getattr__ to attempt a lookup
for an enum member. Your version does not check, but, ironically, the
exception raised
Ethan Furman added the comment:
regrtest framework now supported (had to change the module name I was passing
in from '__main__' to __name__).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17947
Ethan Furman added the comment:
I'm sure this is a dumb question, but I have lots of them so thought I'd share.
Can this issue be resolved simply by making the `_get_mixins` method
`get_mixins`?
--
nosy: +ethan.furman
___
Python tracker rep
New submission from Ethan Furman:
PEP-0435 has been approved!
Now for lots of code review.
--
assignee: docs@python
components: Documentation, Library (Lib), Tests
files: ref435.py
hgrepos: 189
messages: 188812
nosy: barry, docs@python, eli.bendersky, stoneleaf
priority: normal
Ethan Furman added the comment:
Here it is (I hope ;) .
--
keywords: +patch
Added file: http://bugs.python.org/file30192/pep-435.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17947
Ethan Furman added the comment:
Incorporated comments.
--
Added file: http://bugs.python.org/file30195/pep-0435_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17947
Changes by Ethan Furman et...@stoneleaf.us:
--
hgrepos: -189
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17947
___
___
Python-bugs-list mailing
Ethan Furman added the comment:
More adjustments due to review.
--
Added file: http://bugs.python.org/file30202/pep-0435_3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17947
Ethan Furman added the comment:
Round 4. I wonder if I should have used two digits to number the patches. ;)
--
Added file: http://bugs.python.org/file30209/pep-0435_4.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Ethan Furman added the comment:
Thanks, Benjamin. Looking at that patch I realize the fix was way beyond my
current core-hacking skills.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17853
New submission from Ethan Furman:
In playing with metaclasses for the ongoing Enum saga, I tried having the
metaclass insert an object into the custom dict (aka namespace) returned by
__prepare__; this object has the same name as the to-be-created class.
An example:
class Season(Enum
Ethan Furman added the comment:
One more data point to truly demonstrate that something is wrong:
-- def test():
... class Season(Enum):
... print(locals())
... Season = locals()['Season']
... print(locals())
...
-- test()
{'Season
Ethan Furman added the comment:
On 04/27/2013 02:01 PM, Mark Dickinson wrote:
Mark Dickinson added the comment:
Isn't this just a consequence of Python's usual name-lookup rules? In this
code:
def test():
class Season(Enum):
SPRING = Season()
the class
Ethan Furman added the comment:
I guess the question is:
Because Python can no longer know if the name has been inserted via __prepare__
it has to go through the whole CLOSURE
business, but will changing the LOAD_DEREF to a LOAD_GLOBAL (only for items
inside a class def) do the trick
Ethan Furman added the comment:
Perhaps you and Benjamin should discuss that. :)
I just read a thread on core-mentors about when a bug is fixed or not --
considering that the behavior is plain wrong,
that workarounds will still work even if the bug is fixed, why shouldn't we fix
it even
Ethan Furman added the comment:
Nick, thanks for the explanation.
Benjamin, I was referring to Nick taking 3.3 and 3.2 off the issue and leaving
3.4, and you reversing it. ;)
Sorry for the confusion -- I just reread my post and the words there didn't
match the ideas in my head at the time
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +stoneleaf
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17576
___
___
Python-bugs-list
Ethan Furman added the comment:
As Ian Kelly said on Python-List:
quote
Micro-benchmarks like the ones [jmf] have been reporting are *useful*
when it comes to determining what operations can be better optimized,
but they are not *important* in and of themselves. What is important
Ethan Furman added the comment:
There is one typo and one error in the first paragraph of the patch:
When raising a new exception (rather than
using to bare ``raise`` to re-raise the
^ should be an 'a'
exception currently being handled), the
implicit exception chain can be made
New submission from Ethan Furman:
On Windows multiprocessing has a well known limitation: because there is no
fork() new shells must be invoked, and if the call that ultimately starts
multiprocessing is not guarded by an `if __name__ == '__main___'` check an
infinite loops results and you
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +stoneleaf
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16131
___
___
Python-bugs-list
Ethan Furman added the comment:
RC2 has just been released. Any chance of this getting in to the final
release? Nobobdy has pointed out any problems with the last update...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Ethan Furman added the comment:
R. David Murray wrote:
I rewrote the section a bit differently than you did in your patch...if you
think my changes are not an improvement please let me know.
This line is incorrect:
A class which defines its own :meth:`__hash__` that explicitly raises
Ethan Furman added the comment:
Ethan Furman wrote:
Ethan Furman added the comment:
R. David Murray wrote:
I rewrote the section a bit differently than you did in your patch...if you
think my changes are not an improvement please let me know.
This line is incorrect:
A class which
Ethan Furman added the comment:
Can we also get this committed before 3.3.0 final?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15209
Ethan Furman added the comment:
Any problems with the current doc patch? If not, can it be applied before RC1?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15209
Ethan Furman added the comment:
Any problems with the current doc patch? If not, can it be applied before RC1?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14954
Ethan Furman added the comment:
Any problems with the current doc patch? If not, can it be applied before RC1?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14617
Ethan Furman added the comment:
Chris Jerdonek wrote:
Here is an example on a paragraph with line breaks between paragraphs:
s/paragraph/text/
def wrap_paras(text, width=70, **kwargs):
... lines = [line for para in text.splitlines()
... for line in wrap(para, width
Ethan Furman added the comment:
The documentation says, Returns a list of output lines; an empty list is not
a list of lines.
--
nosy: +stoneleaf
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15510
Ethan Furman added the comment:
Not sure I would worry about fixing it in 2.7, although I don't have strong
feelings about that.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15510
Ethan Furman added the comment:
Antoine Pitrou wrote:
Antoine Pitrou added the comment:
an empty list is not a list of lines
Really?
.splitlines()
[]
Really.
-- ''.split('\n')
['']
--
___
Python tracker rep...@bugs.python.org
http
1701 - 1800 of 1854 matches
Mail list logo
