Ethan Furman added the comment:
Well, with all the changes to inspect to properly locate attributes in the
class and metaclass mro, __objclass__ is necessary to get the home class
correct (without it inspect thinks it lives in the EnumMeta metaclass
Ethan Furman added the comment:
The proposed text is something along the lines of:
__objclass__: 1) Indicates this callable requires an instance of the given type
(or a subclass) as its first positional argument; e.g. CPython sets this for
unbound methods that are implemented in C rather than
Ethan Furman added the comment:
Attached patch combines Paul's, Antoine's, and Nick's suggestions/observations.
--
___
Python tracker
<http://bugs.pyt
Changes by Ethan Furman :
--
keywords: +patch
Added file: http://bugs.python.org/file32298/issue19331.stoneleaf.01.patch
___
Python tracker
<http://bugs.python.org/issue19
Changes by Ethan Furman :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue19331>
___
___
Python-bugs-list mailing list
Unsubscrib
Ethan Furman added the comment:
Stefan, do the other tests in PydocWithMetaClasses continue to work on your
FreeBSD 9.0 box without docstrings? Because they all fail on my Linux Ubuntu
13.04 box.
--
___
Python tracker
<http://bugs.python.
Ethan Furman added the comment:
Actually, you @skipif clued me in as to what was happening with the other pydoc
tests and their skipif clauses.
Added appropriate skipifs to the new tests and mimicked the docstring
in/exclusion. All tests now passing with and without docstrings, with and
Changes by Ethan Furman :
Added file: http://bugs.python.org/file32321/issue19331.stoneleaf.02.patch
___
Python tracker
<http://bugs.python.org/issue19331>
___
___
Pytho
Changes by Ethan Furman :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue19281>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ethan Furman added the comment:
Would it make sense to have the presence of a non-None __doc__ be a deciding
factor? How often does an instance have a docstring where one would want the
class info instead?
--
___
Python tracker
<h
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 s
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
<h
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
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,
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
Ethan Furman added the comment:
Personally, I would rather see a RuntimeError raised.
--
___
Python tracker
<http://bugs.python.org/issue19414>
___
___
Python-bug
Ethan Furman added the comment:
Raymond, please don't be so concise.
Is the code unimportant because the scenario is so rare, or something else?
--
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/is
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
Changes by Ethan Furman :
--
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue15873>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.py
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
<http://bugs.python.org/issu
Ethan Furman added the comment:
changeset ca909a3728d3
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
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
<http://bugs.python.org/issue19
Ethan Furman added the comment:
Also see Issue18720 for those details.
--
___
Python tracker
<http://bugs.python.org/issue19624>
___
___
Python-bugs-list mailin
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 rele
Ethan Furman added the comment:
Yes, that test should pass when this issue is resolved.
I can't tell from your comment what you are trying to do to resolve it, but the
course of action I had in mind was to have the `type` meta-class make a final
examination of the type it was creating, a
Ethan Furman added the comment:
Thank you for your efforts, Amitava. Please also sign a Contributor's License
Agreement so we can actually use your code. :)
http://www.python.org/psf/contrib/
--
___
Python tracker
<http://bugs.py
Ethan Furman added the comment:
Should this patch also go into the 3.3 branch? It only went into 3.4.
If yes, how should I go about doing that?
--
assignee: -> ethan.furman
___
Python tracker
<http://bugs.python.org/issu
Ethan Furman added the comment:
Cool, leaving it closed.
--
versions: -Python 3.3
___
Python tracker
<http://bugs.python.org/issue18780>
___
___
Python-bug
Changes by Ethan Furman :
--
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue22121>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ethan Furman :
--
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue22122>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ethan Furman :
--
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue22123>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ethan Furman added the comment:
We should be able to add enough smarts to handle both cases.
--
___
Python tracker
<http://bugs.python.org/issue22121>
___
___
Ethan Furman added the comment:
This is not a regression. json only deals with standard types (int, str,
etc.), and Enum is not a standard type.
Enum was introduced in 3.4, so corresponding changes were made to json to
support int and float subclasses, of which IntEnum is one.
In other
Ethan Furman added the comment:
One argument against fixing: If we do fix in 2.7.9 then any program targeting
it will be unable to target 3.0-3.3, as those versions do not have the fix from
3.4.
--
___
Python tracker
<http://bugs.python.
Ethan Furman added the comment:
Can you give an example of the code you were having problems with?
--
assignee: -> ethan.furman
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issu
Changes by Ethan Furman :
--
nosy: +barry, eli.bendersky
___
Python tracker
<http://bugs.python.org/issue22339>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ethan Furman added the comment:
My apologies for the confusion, and thanks for tracking it down.
I'll get the patch in, but I'm curious how you actually use these Enums? Is
this a way to easily handle multiple aliases?
--
___
Python trac
Ethan Furman added the comment:
Right. We can still use the alias machinery to accomplish this task for us,
and avoid the metaclass hacking:
-- python2 sample code
# -*- coding: utf-8 -*-
from enum import Enum
class MultiValueEnum(Enum):
def __new__
Ethan Furman added the comment:
You could do the same kind of check in __new__, but consider this:
class StrValues(MultiValueEnum):
one = ('One'
'one',
'1')
two = ('two',
'Two',
'2'
Ethan Furman added the comment:
http://hg.python.org/cpython/rev/4135f3929b35
http://hg.python.org/cpython/rev/cdd412347827
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bug
Changes by Ethan Furman :
--
assignee: ethan.furman -> docs@python
nosy: +docs@python
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python
Changes by Ethan Furman :
--
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue22504>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ethan Furman :
--
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue22506>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ethan Furman added the comment:
Enums have a definition order to aid in the use-case of auto-numbering, and to
make displays consistent. However, the basic Enum type is unordered.
If you need/want your particular enum type to be ordered, mix-in the ordered
magic methods.
--
assignee
Ethan Furman added the comment:
Yes, we're sure. ;)
Enums have a definition order to aid in the use-case of auto-numbering, and to
make displays consistent. However, the basic Enum type is unordered.
I do not see a serial number as being an intrinsic property of an enum --
outside of
Changes by Ethan Furman :
--
stage: -> test needed
___
Python tracker
<http://bugs.python.org/issue22506>
___
___
Python-bugs-list mailing list
Unsubscrib
Ethan Furman added the comment:
More just a note to myself to research this further, to see exactly what does
and does not get inherited. Any tests added will likely be more comprehensive
than your example.
--
___
Python tracker
<h
New submission from Ethan Furman:
First, the behavior for pwd.struct_passwd:
-
--> pwd.getpwuid(1000)
pwd.struct_passwd(pw_name='ethan', pw_passwd='x', pw_uid=1000, pw_gid=1000,
pw_gecos='Ethan Furman,,,', pw_dir=&
Ethan Furman added the comment:
Test added.
--
keywords: +patch
stage: -> needs patch
Added file: http://bugs.python.org/file36752/issue22513.stoneleaf.01.patch
___
Python tracker
<http://bugs.python.org/issu
Ethan Furman added the comment:
Thanks, Serhiy.
--
resolution: -> not a bug
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ethan Furman added the comment:
What would be the result of
Counter({'a':1, 'b':2}) < Counter({'a':2, 'b':1})
?
--
nosy: +ethan.furman
___
Python
Ethan Furman added the comment:
set's don't have values, and you are wanting to implement the partial ordering
based on the values. (side-note: how does partial-ordering work for sets?)
> That is, one counter will be considered smaller-or-equal to another if for any
> i
Ethan Furman added the comment:
That is certainly a better definition. If you carefully reread your original
post you will see that you wrote something different ('any' instead of
'every'). Also, your OP uses '__lt__' but talks about 'less-t
Ethan Furman added the comment:
I think the final call is Raymond's (whether to accept the patch), but go
ahead. Worst case scenario is you'll have your own thoroughly tested
PartiallyOrderedCounter you can use in your own code. :)
--
nosy: +rhettinger
type: ->
Ethan Furman added the comment:
Curiousity question: What happens if you try to sort a list of partially
ordered Counters?
--
___
Python tracker
<http://bugs.python.org/issue22
Ethan Furman added the comment:
If it is so specialized as to only be needed in complex combinatorial
calculations, does it belong in the general-purpose part of the language?
After all, we have the math and cmath modules for more specialized arithmetic
operations
Ethan Furman added the comment:
--> s1 = set([1])
--> s2 = set([1, 2])
--> s3 = set([1, 2, 3])
--> s4 = set([2])
--> s5 = set([2, 3])
--> s6 = set([3])
--> l = [s1, s2, s3, s4, s5, s6]
--> sorted(l)
[{1}, {2}, {1, 2}, {3}, {2, 3}, {1, 2, 3}]
--> s1 < s4
False
Ethan Furman added the comment:
I'll go with +0.5. :)
If this goes in, I think a missing key in either Counter should default to 0
for purposes of the ordering.
--
stage: -> test needed
___
Python tracker
<http://bugs.python.org
Ethan Furman added the comment:
That does seem odd -- how can you have 'b' of something?
--
___
Python tracker
<http://bugs.python.org/issue22515>
___
___
Ethan Furman added the comment:
I have to disagree. The intent is clearly expressed in the docs [1]. However,
if I have a need to deal with partial amounts (say, 2.5 apples because I gave
half of one to my horse ;), Counter will still work with that:
--> treats = Counter({'car
Ethan Furman added the comment:
[1] https://docs.python.org/3/library/collections.html#collections.Counter
--
___
Python tracker
<http://bugs.python.org/issue22
New submission from Ethan Furman:
According to the docs [1]:
> Counter objects have a dictionary interface except that they return a
> zero count for missing items instead of raising a KeyError
Which a simple test confirms:
--> Counter()['b']
0
However, if the key is pres
Ethan Furman added the comment:
Exactly what operation is unary minus supposed to be? It seems to act like
absolute value.
--
___
Python tracker
<http://bugs.python.org/issue22
Ethan Furman added the comment:
I, myself, wrote:
-
> At least, it will until we fix that bug. ;)
Happily, reading the whole documentation revealed that non-integer values are
allowed, so it's not a bug. :)
--
___
Python
Ethan Furman added the comment:
Ignore that last comment -- I don't know what I did yesterday, but unary minus
is working as expected today. :/
--
___
Python tracker
<http://bugs.python.org/is
Ethan Furman added the comment:
Testing the patch...
--
___
Python tracker
<http://bugs.python.org/issue22515>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ethan Furman added the comment:
In going through the tests I have found an edge-case that I am unsure of how to
handle:
Counter(a=1) < Counter(a=1, b=1)
On the one hand, they both have the same value for 'a'; on the other hand, the
second counter has more elements...
So shou
Changes by Ethan Furman :
--
stage: test needed -> patch review
___
Python tracker
<http://bugs.python.org/issue22515>
___
___
Python-bugs-list mailing list
Un
Ethan Furman added the comment:
I am not a mathematician -- feel free to include the answer with your hints. ;)
If my analogy is correct, this situation is similar to
{1} < {1, 2}
Which is True. Can someone verify that I am corr
Ethan Furman added the comment:
New patch attached.
--
Added file: http://bugs.python.org/file36794/issue22515.stoneleaf.patch.01
___
Python tracker
<http://bugs.python.org/issue22
Ethan Furman added the comment:
We are not "rushing into code", we are getting some code, and tests, written to
help define what we are talking about.
So far the feedback has given some more tests to add, and some things to change
(such as only comparing with other Counters)
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, and for
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]
'mi
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,
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
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 me
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 inher
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
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 __ind
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, wh
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
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
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, t
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
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, and if
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 revi
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:
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 re
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",
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
<http://bugs.python.org/issue20094>
___
___
Python-bugs-list m
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
<http://bugs.python.
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
<http://bugs.python.org/issue19
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 "", line 1, in
TypeError
Ethan Furman added the comment:
I can live with the deprecation route. I'll create a patch today or tomorrow
for that.
--
___
Python tracker
<http://bugs.python.org/is
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
<http://bugs.python.org/is
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 wa
1001 - 1100 of 1868 matches
Mail list logo
