Ethan Furman added the comment:
Discussion started on PyDev.
While working on that I realized/remembered that the main reason to get this in
now is that without it a user *cannot* change how pickling works -- (s)he can
write the methods, but they will be ignored
Ethan Furman added the comment:
Many comments, Eli's and Serhey's code changes incorporated.
--
Added file: http://bugs.python.org/file34173/issue20653.stoneleaf.02.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20653
Ethan Furman added the comment:
Antoine,
If the mixed-in class defines __reduce_ex__, and the Enum class defines
__reduce__, pickle will see that the Enum class has both, and will call the
_ex__ method. It is, therefore, the preferred method (at least by pickle,
which is what we
Ethan Furman added the comment:
Yeah, I was confused by that when I first read it as well. The 2.7 docs are
even worse in that regard (so there has been some progress :).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Ethan Furman added the comment:
Antoine commented:
--
The pickle docs don't mention __reduce_ex__ as being preferred, as in you
should
use this one, on the contrary.
Are we reading the same docs?
http://docs.python.org/dev/library/pickle.html#object.__reduce_ex__
Ethan Furman added the comment:
On 02/21/2014 11:26 AM, Antoine Pitrou wrote:
Are we reading the same comments?
LOL, apparently not.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20653
Ethan Furman added the comment:
When I implemented pickle support I did not have a complete understanding of
the pickle protocols nor how to best use them. As a result, I picked
__getnewargs__ and only supported protocols 2 and 3 (4 didn't exist yet).
Serhiy came along and explained a bunch
Changes by Ethan Furman et...@stoneleaf.us:
--
Removed message: http://bugs.python.org/msg211739
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20679
Ethan Furman added the comment:
When I implemented pickle support I did not have a complete understanding of
the pickle protocols nor how to best use them. As a result, I picked
__getnewargs__ and only supported protocols 2 and 3 (4 didn't exist yet).
Serhiy came along and explained a bunch
Ethan Furman added the comment:
When I implemented pickle support I did not have a complete understanding of
the pickle protocols nor how to best use them. As a result, I picked
__getnewargs__ and only supported protocols 2 and 3 (4 didn't exist yet).
Serhiy came along and explained a bunch
Ethan Furman added the comment:
More explanation:
__getnewargs__ is not used by pickle protocol 0 and 1; to support those
protocols we need __reduce_ex__. Since __reduce_ex__ works for 0, 1, 2, 3, 4,
... there's no reason to have both __reduce_ex__ *and* __getnewargs__
Ethan Furman added the comment:
Larry,
If I make changes to the patch, should I reverse the original and then commit
one new one so you only have one to merge in, or do you mind having two to do?
--
___
Python tracker rep...@bugs.python.org
http
Ethan Furman added the comment:
Thanks for your comments, Eli, I'll work on getting better comments in the code.
The qualname comment is partially related to the pickling changes as it's
necessary for protocol 4 (I forgot to put that comment in on the previous
pickling change that addressed
Ethan Furman added the comment:
Can we do that? If a doc change can make it so we're not locked in to
supporting __getnewargs__ I could live with that.
Although, to be honest, I'd rather get the change in *and* have a doc warning
that pickling specifics are subject to change in 3.5. Really
Ethan Furman added the comment:
And it is now possible to override and pickle by name if your custom subclass
so chooses.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20653
Ethan Furman added the comment:
Patch allows subclass to override __reduce_ex__, which is useful if a mixed-in
type does not have proper pickle support.
--
Added file: http://bugs.python.org/file34138/issue20653.stoneleaf.01.patch
___
Python tracker
Ethan Furman added the comment:
Proposal to switch to pickle by name rejected, but Enum now allows
__reduce_ex__ to be overwridden in subclasses.
--
priority: release blocker - normal
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
New submission from Ethan Furman:
587fd4b91120: Better pickle support for Enum subclasses.
--
assignee: larry
messages: 211552
nosy: ethan.furman, larry
priority: release blocker
severity: normal
stage: commit review
status: open
title: 3.4 cherry-pick: 587fd4b91120 improve Enum
Ethan Furman added the comment:
I agree that pickling by name is the better solution.
Serhiy, could you explain how the un-pickling works with protocol 4?
--
assignee: - ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18652
___
___
Python-bugs-list
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11406
___
___
Python-bugs-list
Ethan Furman added the comment:
The only thing I hate more than being wrong is being wrong because Python isn't
acting the way I think it should. :/
So, __qualname__ is not set properly when using the function API (although it
has nothing to do with manually setting __module__ (I removed
Ethan Furman added the comment:
Serhiy commented:
-
Actually they don't pickle due to wrong __module__. After adding
NEI.__module__ = NamedInt.__module__ = __name__
PicklingError no longer raised for enum class.
If you were to look at the `_make_class_unpicklable
Ethan Furman added the comment:
I do not recall if it was or not. The main difference would be in how aliases
were handled. For example, if W and Z were the same value on system A, but
different on system B, then going from A - B via pickle W and Z would still be
the same using the current
Ethan Furman added the comment:
Because I didn't know how to make it work with 0 and 1. Thank you! I'll get
that in today.
--
stage: committed/rejected - patch review
status: closed - open
___
Python tracker rep...@bugs.python.org
http
Ethan Furman added the comment:
Okay, I went with __reduce__ since we don't ever use the pickle protocol
information.
I added a test for class-nested Enums since protocol 4 supports it.
I left the test for test_subclasses_without_getnewargs alone as the point of
that test is to make sure
Ethan Furman added the comment:
I also removed the protocol 2 warning from the docs, and added this note:
.. note::
With pickle protocol version 4 it is possible to easily pickle enums
nested in other classes.
--
___
Python tracker rep
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20543
___
___
Python-bugs-list
Ethan Furman added the comment:
The version 2 docs:
http://docs.python.org/2/library/pickle.html#object.__reduce_ex__:
-
The object class implements both __reduce__() and __reduce_ex__();
however, if a subclass overrides
Ethan Furman added the comment:
Ethan commented:
I left the test for test_subclasses_without_getnewargs alone as the point of
that test is to make sure that _make_class_unpicklable is working properly,
not to see if we can somehow get any of it to pickle.
Serhiy replied
Ethan Furman added the comment:
Thanks for the hints, Georg!
--
Added file: http://bugs.python.org/file33945/issue20386.stoneleaf.04.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20386
New submission from Ethan Furman:
enum34, the Enum backport, specifically uses `protocol=HIGHEST_PROTOCOL`, while
the current enum tests just use the default.
Running the enum34 test expose an issue with pickle protocol 4
Ethan Furman added the comment:
Working on fixing tests now. Not sure I can fix pickle (at least not in time
for RC1).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20534
Ethan Furman added the comment:
Thanks, Antoine, that was what I needed.
--
assignee: - ethan.furman
keywords: +patch
stage: needs patch - patch review
Added file: http://bugs.python.org/file33949/issue20534.stoneleaf.01.patch
___
Python tracker rep
Ethan Furman added the comment:
Serhiy, the minimum supported pickle protocol is 2. Now testing all protocols
from 2 to HIGHEST_PROTOCOL, inclusive.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20534
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20457
___
___
Python-bugs-list
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20467
___
___
Python-bugs-list
Ethan Furman added the comment:
Well, so far I have tried:
:class:`IntEnum`
:class:`.IntEnum`
:class:`~IntEnum`
:class:`enum.IntEnum`
:class:`.enum.IntEnum`
:class:`~enum.IntEnum`
:class:`~.enum.IntEnum`
and probably some others I have forgotten; nothing is giving me a link
Ethan Furman added the comment:
IntEnum is not a class in the socket module.
How do I make a link into another rst document?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20386
New submission from Ethan Furman:
While trying to update the socket documentation it was brought to my attention
that Enum and IntEnum are not defined as classes as far as the docs are
concerned [1].
[1] http://bugs.python.org/issue20386#msg209473
--
assignee: ethan.furman
messages
Ethan Furman added the comment:
Okay, staying with SocketKind.
This patch also has a very small doc enhancement.
--
keywords: +patch
Added file: http://bugs.python.org/file33735/issue20386.stoneleaf.03.patch
___
Python tracker rep...@bugs.python.org
Ethan Furman added the comment:
Here's a patch for the test.
--
Added file: http://bugs.python.org/file33706/issue20386.stoneleaf.test.patch.01
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20386
Ethan Furman added the comment:
Complete patch with new test, fixed tests, and regression fix.
Doc patch still needed.
--
stage: test needed - patch review
Added file: http://bugs.python.org/file33707/issue20386.stoneleaf.patch.02
___
Python tracker
Ethan Furman added the comment:
The containers are there to help with discoverability. If you want to know
what all the (common) AF values are you can either do
[name for name in dir(socket) if name.isupper() and name.startswith('AF_')]
or
list(socket.AddressFamily
Ethan Furman added the comment:
How do we feel about SockType instead? (Just a short round of bike-shedding,
promise! ;)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20386
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20284
___
___
Python-bugs-list
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18574
___
___
Python-bugs-list
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12704
___
___
Python-bugs-list
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7776
___
___
Python-bugs-list
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17814
___
___
Python-bugs-list
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17811
___
___
Python-bugs-list
Ethan Furman added the comment:
Depracation warning is in place for 3.4.
When 3.5 is tagged I'll switch it an error.
--
stage: patch review - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19995
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1820
___
___
Python-bugs-list
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20230
___
___
Python-bugs-list
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16508
___
___
Python-bugs-list
Ethan Furman added the comment:
For anyone paying really close attention, I've already switched the
assertEquals to assertEqual. ;)
--
Added file: http://bugs.python.org/file33414/issue19995.stoneleaf.04.patch
___
Python tracker rep
Ethan Furman added the comment:
Could somebody explain this?
===
ethan@media:~/source/python/issue19995_depr$ ./python -W error
Python 3.4.0b1 (default:2f81f0e331f6+, Jan 9 2014, 20:30:18)
[GCC 4.7.3] on linux
Type
Ethan Furman added the comment:
I was travelling yesterday and wasn't sure about the time stamp. Looks like I
missed the 12-hour cutoff. Let me know if I should backout the commit.
--
___
Python tracker rep...@bugs.python.org
http
Ethan Furman added the comment:
I think the code-breakage issue is that although this is a bug now, it did not
use to be a bug. (Or maybe it was always a bug, but nobody noticed -- I don't
know when hex() and oct() were introduced.)
Basically, having %o and %x work with floats
Ethan Furman added the comment:
I'll switch it to a deprecation warning instead sometime this week.
The changes to datamodel.rst and tarfile.py should stay, I think.
test_format and test_unicode will both verify current* behavior and check for
the deprecation warning, and unicodeobject.c
Ethan Furman added the comment:
Better doc enhancement thanks to R. David Murray (thanks!).
--
Added file: http://bugs.python.org/file33289/issue19995.stoneleaf.03.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19995
Ethan Furman added the comment:
I can see why we wouldn't want to make this change in a point release, but this
is a feature release we're talking about and this seems like buggy behavior:
-- hex(3.14)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: 'float' object
Ethan Furman added the comment:
I can live with the deprecation route. I'll create a patch today or tomorrow
for that.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19995
Ethan Furman added the comment:
In issue19995, in msg206339, Guido exhorted:
[Ethan claimed] it is possible to want a type that can be used as an
index or slice but that is still not a number
I'm sorry, but this requirement is absurd. An index
Ethan Furman added the comment:
Ran full test suite; some errors came up in test_format from the following test
lines:
testformat(%#x, 1.0, 0x1)
testformat(%x, float(big), 123456___, 6)
testformat(%o, float(big), 123456__, 6)
testformat(%x
Ethan Furman added the comment:
I have the following as part of the patch for that issue:
-
diff -r b668c409c10a Doc/reference/datamodel.rst
--- a/Doc/reference/datamodel.rst Sat Dec 28 20:37:58 2013 +0100
+++ b/Doc/reference
New submission from Ethan Furman:
Following errors occur about half the time:
==
ERROR: test_anydbm_creation (test.test_dbm.TestCase-dbm.ndbm)
--
Traceback
Ethan Furman added the comment:
Actually, make that about 1/5 of the time.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20094
___
___
Python
Ethan Furman added the comment:
I updated it as I liked your wording better. :) Doing more testing to see if
anything else needs fixing before I make the next patch for the tracker on that
issue.
--
___
Python tracker rep...@bugs.python.org
http
New submission from Ethan Furman:
In order to create a coherent integer type class both __int__ and __index__
must be defined or the resulting instances will behave inconsistently in
different places.
For example, if __index__ is not defined then the class cannot be used in
slices
Ethan Furman added the comment:
Enhancement portion split off into issue20092.
Attached patch includes doc change, tests, and code changes.
If I'm overstepping my bounds, I'm sure somebody will slap me with a fish. ;)
--
keywords: +patch
stage: test needed - patch review
title: hex
Ethan Furman added the comment:
True. I meant similar in that Python will use what's available to fill in the
blank:
class has __eq__ but user tried != ? use __eq__ and invert result
class has __index__ but user tried int() ? use __index__
Ethan Furman added the comment:
Thank you everyone for increasing my understanding. :)
Terry J Reedy wrote:
[snip everything I now agree with, which is most of Terry's comment]
3. Every core usage of __int__ looks for __index__ also. Int() does not
do this now, but '%d
New submission from Ethan Furman:
Using Enum to illustrate:
-- class Grade(enum.Enum):
... A = 4
... B = 3
... C = 2
... D = 1
... F = 0
... def __index__(self):
... return self._value_
-- ['miserable'][Grade.F]
'miserable'
-- '%x
Ethan Furman added the comment:
Guido van Rossum opined:
I still think the problem is with your class design.
You shouldn't want a hex representation for a value
that's not an integer.
Well, in fairness I only supported it because bool does, and I was trying to
have
Ethan Furman added the comment:
Victor Stinner commented:
-
I never understood the difference between long (__int__ method)
and index (__index__ method). Is the difference on the behaviour
of floating point numbers?
__index__ was originally added so that non-int
Ethan Furman added the comment:
Did I mention __index__ is an unfortunate name for the current trend for this
method?
Stefan Krah commented:
--
memoryview, struct and probably also array.array accept __index__.
When you say accept __index__ do you mean for use as indices
Ethan Furman added the comment:
Hmmm...
Well, much as I hate to say it, it's sounding like the correct solution here is
to have %o and %x work when __index__ is available, instead of the other way
around. :(
.format is not an issue because one must specify one's own if inheriting from
Ethan Furman added the comment:
Eric V. Smith commented:
If you were going to make this change, I'd think you'd have to look
for __index__ and then __int__.
Does the order matter? Are there any types (and should there be) that would
have both and return different
Ethan Furman added the comment:
Antoine Pitrou opined:
--
I'm with Guido: it doesn't really make sense to allow __index__ but not
__int__ on
a type. So trying __index__ in str.format() sounds like a distraction.
-- hex(3.14) # calls __index__
Traceback (most recent
Ethan Furman added the comment:
Ethan Furman previously stated:
---
So the complete list of spcecifiers then is d, i, o, u, U, and c [1], and they
should work if __index__ works.
Okay, so 'd' then should be considered a conversion operation, whilst the
others
Ethan Furman added the comment:
Antoine, if I understand you correctly, you are saying that any type that
defines __index__ is an integer, and should therefore also define __int__, in
which case Python can just use __int__ and not worry about __index__?
Here's the problem with that:
-- '%x
Ethan Furman added the comment:
Antoine,
Does that mean you are reducing your previous statement of
So trying __index__ in str.format() sounds like a distraction.
to using __index__ for %d, %i, and %u is not correct, but is correct for %c,
%o, %x, and %X
Ethan Furman added the comment:
Thank you, Victor and Serhiy, for your pointers into the code.
I'm hoping we have general agreement about %c, %o, %x, and %X and having them
use __index__ only (using __int__ would open the door to float conversions).
I still have a question about %i, though
New submission from Ethan Furman:
In Py3k __hex__ and __oct__ were removed, and hex() and oct() switched to use
__index__.
hex() and oct() should be using __int__ instead.
Having read through PEP 357 [1] I see that __index__ is /primarily/ concerned
with allowing arbitrary objects to be used
Ethan Furman added the comment:
For the record, the true/false values of my Logical type do convert to int,
just not the unknown value.
I agree using __int__ is dubious because of float (and Decimal, etc.), which
means really the only clean way to solve the issue (definitely for me
Ethan Furman added the comment:
Just tried installing 2.6.6 on Windows 7 with compile checked and make default
unchecked and did not observe any problems (although it did scroll by at high
speed, and the windows didn't stay open for me to peruse).
However, since we are no longer releasing
Ethan Furman added the comment:
Check out socket.py for an example of constants being changed over to IntEnum.
Feel free to ask more questions! :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19624
Ethan Furman added the comment:
Also see Issue18720 for those details.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19624
___
___
Python-bugs
Ethan Furman added the comment:
changeset ca909a3728d3
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19249
Ethan Furman added the comment:
Done and done.
--
stage: test needed - patch review
Added file: http://bugs.python.org/file32572/issue19249.stoneleaf.02.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19249
Ethan Furman added the comment:
Given that __eq__ isn't adding anything, I think removing it is a fine option.
--
keywords: +patch
Added file: http://bugs.python.org/file32548/issue19249.stoneleaf.01.patch
___
Python tracker rep...@bugs.python.org
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15873
___
___
Python-bugs-list
Ethan Furman added the comment:
How's this? I liked Barry's simpler Overriding Principle combine with Nick's
simpler Class Names.
--
Added file: http://bugs.python.org/file32444/issue19331.stoneleaf.03.patch
___
Python tracker rep
Ethan Furman added the comment:
Do we currently have any data structures in Python, either built-in or in the
stdlib, that aren't documented as raising RuntimeError if the size changes
during iteration? list, dict, set, and defaultdict all behave this way.
If not, I think OrderedDict should
Ethan Furman added the comment:
Ah, right you are: list just acts wierd. ;)
So the question then becomes is OrderedDict more like a list or more like a
dict?
It seems to me that OrderedDict is more like a dict.
--
___
Python tracker rep
Ethan Furman added the comment:
The further from dict it goes, the more there is to remember. Considering the
work around is so simple, I just don't think it's worth it:
for key in list(ordered_dict):
if some_condition:
del ordered_dict[key]
A simple list around
Ethan Furman added the comment:
Firstly, you're not copying the entire dict, just its keys. [1]
Secondly, you're only copying the keys when you'll be adding/deleting keys from
the dict.
Thirdly, using the list idiom means you can use OrderedDicts, defaultdicts,
dicts, sets, and most likely
Ethan Furman added the comment:
Nikolaus, in reply to your question about more to remember:
Even though I may not use it myself, if it is allowed then at some point I will
see it in code; when that happens the sequence of events is something like:
1) hey, that won't work
2) oh, wait
Ethan Furman added the comment:
Personally, I would rather see a RuntimeError raised.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19414
1401 - 1500 of 1854 matches
Mail list logo
