On 09.04.13 23:29, victor.stinner wrote:
http://hg.python.org/cpython/rev/53879d380313
changeset: 83216:53879d380313
parent: 83214:b7f2d28260b4
user:Victor Stinner victor.stin...@gmail.com
date:Tue Apr 09 21:53:09 2013 +0200
summary:
Add fast-path in
On 12.04.13 15:55, Eli Bendersky wrote:
The enumeration value names are available through the class members::
for member in Colors.__members__:
... print(member)
red
green
blue
This is unnecessary because enumerations are iterable.
Colors.__members__ is equal to
On 13.04.13 15:43, Eli Bendersky wrote:
On Sat, Apr 13, 2013 at 1:31 AM, Serhiy Storchaka storch...@gmail.comwrote:
On 12.04.13 15:55, Eli Bendersky wrote:
There is some ambiguity in the term enumeration values. On the one hand,
it's the singleton instances of the enumeration class
On 13.04.13 03:13, Glenn Linderman wrote:
On 4/12/2013 3:59 PM, Guido van Rossum wrote:
class Insect(Enum):
wasp = 1
bee = 1
ant = 2
We'd have Insect.wasp == Insect.bee Insect.ant but Insect.wasp is
not Insect.bee.
can't define two names in the same enum to have the same
On 22.04.13 15:52, eli.bendersky wrote:
http://hg.python.org/cpython/rev/c9674421d78e
changeset: 83494:c9674421d78e
user:Eli Bendersky eli...@gmail.com
date:Mon Apr 22 05:52:16 2013 -0700
summary:
Simplify the code of get_attrib_from_keywords somewhat.
-
26.04.13 11:00, Greg Ewing написав(ла):
However, there's a worse problem with defining enum
inheritance that way. The subtype relation for extensible
enums works the opposite way to that of classes.
To see this, imagine a function expecting something
of type Colors. It knows what to do with
26.04.13 18:50, Larry Hastings написав(ла):
On 04/26/2013 12:34 AM, Greg Ewing wrote:
Or if, as Guido says, the only sensible things to use
as enum values are ints and strings, just leave anything
alone that isn't one of those.
The standard Java documentation on enums:
26.04.13 11:00, Greg Ewing написав(ла):
However, there's a worse problem with defining enum
inheritance that way. The subtype relation for extensible
enums works the opposite way to that of classes.
To see this, imagine a function expecting something
of type Colors. It knows what to do with
26.04.13 05:13, Nick Coghlan написав(ла):
With a merged design, it becomes *really* hard to give the instances
custom behaviour, because the metaclass will somehow have to
differentiate between namespace entries that are intended to be
callables, and those which are intended to be instances of
Thank you for your answers, Barry. Eli already answered me most of my
questions.
20.04.13 22:18, Barry Warsaw написав(ла):
On Apr 13, 2013, at 11:31 AM, Serhiy Storchaka wrote:
The str and repr of the enumeration class also provides useful information::
print(Colors)
Colors {red
29.04.13 21:14, Glenn Linderman написав(ла):
1) Enum could be subclassed to provide different, sharable, types of
behaviors, then further subclassed to provide a number of distinct sets
of values with those behaviors.
You can use a multiclass inheritance for this.
2) Enum could be subclassed
30.04.13 00:59, Ethan Furman написав(ла):
In the Planet example we saw the possibility of specifying arguments to
enum item __init__:
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,
16.05.13 08:20, Georg Brandl написав(ла):
On behalf of the Python development team, I am pleased to announce the
releases of Python 3.2.5 and 3.3.2.
The releases fix a few regressions in 3.2.4 and 3.3.1 in the zipfile, gzip
and xml.sax modules. Details can be found in the changelogs:
It
18.05.13 10:06, raymond.hettinger написав(ла):
http://hg.python.org/cpython/rev/1b760f926846
changeset: 83823:1b760f926846
user:Raymond Hettinger pyt...@rcn.com
date:Sat May 18 00:05:20 2013 -0700
summary:
Undo the deprecation of _asdict().
Why?
18.05.13 19:37, richard.oudkerk написав(ла):
http://hg.python.org/cpython/rev/0648e7fe7a72
changeset: 83829:0648e7fe7a72
user:Richard Oudkerk shibt...@gmail.com
date:Sat May 18 17:35:19 2013 +0100
summary:
Use PY_FORMAT_SIZE_T because Visual Studio does not understand %zd
18.05.13 23:00, Serhiy Storchaka написав(ла):
18.05.13 19:37, richard.oudkerk написав(ла):
http://hg.python.org/cpython/rev/0648e7fe7a72
changeset: 83829:0648e7fe7a72
user:Richard Oudkerk shibt...@gmail.com
date:Sat May 18 17:35:19 2013 +0100
summary:
Use PY_FORMAT_SIZE_T
20.05.13 01:33, Benjamin Peterson написав(ла):
2013/5/19 Demian Brecht demianbre...@gmail.com:
It seems like external docs is standard throughout the stdlib. Is
there an actual reason for this?
ernal
One is legacy. It certainly wasn't possible with the old LaTeX doc
system.
Do you know that
20.05.13 16:12, Ethan Furman написав(ла):
As a quick reminder, PEP 409 allows this:
try:
...
except AnError:
raise SomeOtherError from None
so that if the exception is not caught, we get the traditional single
exception traceback, instead of the new:
During
21.05.13 10:17, Hrvoje Niksic написав(ла):
On 05/20/2013 05:15 PM, Ethan Furman wrote:
1) Do nothing and be happy I use 'raise ... from None' in my own
libraries
2) Change the wording of 'During handling of the above exception,
another exception occurred' (no ideas as to what at
the moment)
21.05.13 12:28, Hrvoje Niksic написав(ла):
On 05/21/2013 10:36 AM, Serhiy Storchaka wrote:
The above exception was converted to the following exception:
...
That makes it clear that the conversion was explicit and (hopefully)
intentional, and that the latter exception supersedes
21.05.13 13:05, Hrvoje Niksic написав(ла):
On 05/21/2013 11:56 AM, Serhiy Storchaka wrote:
try:
x = d['key']
except KeyError:
x = fallback('key')
def fallback(key):
if key not in a:
raise BusinessError(...)
return 1 / a[key] # possible TypeError
20.05.13 18:46, Antoine Pitrou написав(ла):
I think it is a legitimate case where to silence the original
exception. However, the binascii.Error would be more informative if it
said *which* non-base32 digit was encountered.
Please open a new issue for this request (note that no other binascii
28.05.13 16:07, Nick Coghlan написав(ла):
On Tue, May 28, 2013 at 10:31 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le Tue, 28 May 2013 22:15:25 +1000,
Nick Coghlan ncogh...@gmail.com a écrit :
* moved the main executable source file from Modules to a separate
Apps directory
Sounds fine (I
29.05.13 21:00, Eric Snow написав(ла):
Critically sensitive performance subjects
* interpreter start-up time
* module import overhead
* attribute lookup overhead (including MRO traversal)
* function call overhead
* instance creation overhead
* dict performance (the underlying namespace type)
*
Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt,
*.py, *.c and *.h files. I think it would be worthwhile to update the
source code and documentation for more modern RFCs.
For example for updating RFC3548 to RFC4648 there is an issue #16995.
821: Simple Mail Transfer
08.06.13 10:03, Ethan Furman написав(ла):
Indeed, and it is already in several different ways. But it would be
nice to have a pickle example in the docs that worked with doctest.
I ended up doing what Barry did:
from test.test_enum import Fruit
from pickle import dumps, loads
08.06.13 11:23, Benjamin Peterson написав(ла):
2013/6/8 Serhiy Storchaka storch...@gmail.com:
Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt,
*.py, *.c and *.h files. I think it would be worthwhile to update the source
code and documentation for more modern RFCs.
Just
08.06.13 11:42, M.-A. Lemburg написав(ла):
On 08.06.2013 09:45, Serhiy Storchaka wrote:
Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py,
*.c and *.h files. I
think it would be worthwhile to update the source code and documentation for
more modern RFCs.
Thanks
By mistake some local files were added to the list. Here's an updated
list. It now also contains low-case references.
Attached also a script used to generate this list.
3: Documentation conventions. (Obsoleted by RFC0010)
Lib/test/math_testcases.txt
10: Documentation conventions. (Obsoleted
08.06.13 11:47, Ethan Furman написав(ла):
In this case it is better to exclude a code example from doctests or
add auxiliary code (i.e. as Steven suggested) to pass the doctest.
Are you saying there is something wrong about what I have in place now?
I would think that one line showing
14.06.13 11:46, Antoine Pitrou написав(ла):
On Fri, 14 Jun 2013 07:06:49 +0200 (CEST)
raymond.hettinger python-check...@python.org wrote:
http://hg.python.org/cpython/rev/5accb0ac8bfb
changeset: 84116:5accb0ac8bfb
Fix comment blocks. Adjust blocksize to a power-of-two for better divmod
14.06.13 04:18, brett.cannon написав(ла):
http://hg.python.org/cpython/rev/af27c661d4fb
changeset: 84115:af27c661d4fb
user:Brett Cannon br...@python.org
date:Thu Jun 13 21:18:43 2013 -0400
summary:
Move test_pep352 over to unittest.main()
You forgot about:
from
14.03.14 07:59, Brian Curtin написав(ла):
On Thu, Mar 13, 2014 at 8:29 PM, Terry Reedy tjre...@udel.edu wrote:
Now that no warnings is a serious goal for 3.4+, I will report them should
they recur.
If we're at no warnings, and no warnings is a serious goal, warnings
should be errors.
26.02.14 11:40, Serhiy Storchaka написав(ла):
Let's choose the least confusing names.
See discussions at:
http://bugs.python.org/issue3081
http://bugs.python.org/issue16447
http://bugs.python.org/issue20440
http://comments.gmane.org/gmane.comp.python.devel/145346
Poll results:
Py_(X)SETREF
26.02.14 11:40, Serhiy Storchaka написав(ла):
Let's choose the least confusing names.
See discussions at:
http://bugs.python.org/issue3081
http://bugs.python.org/issue16447
http://bugs.python.org/issue20440
http://comments.gmane.org/gmane.comp.python.devel/145346
Updated poll results
26.03.14 03:43, Ethan Furman написав(ла):
%s is a string.
%U is unicode?
If so, then %s should only be used when it is certain the string in
question has no unicode in it?
%s is UTF-8 encoded string.
___
Python-Dev mailing list
27.03.14 00:16, Guido van Rossum написав(ла):
Yeah, so the pyftp fix is to keep track of how many timers were
cancelled, and if the number exceeds a threshold it just recreates the
heap, something like
heap = [x for x in heap if not x.cancelled]
heapify(heap)
See also
26.05.14 10:59, raymond.hettinger написав(ла):
+result = [(elem, i) for i, elem in zip(range(n), it)]
Perhaps it is worth to add simple comment explaining why this is not
equivalent to just list(zip(it, range(n))). Otherwise it can be
unintentionally optimized in future.
04.06.14 04:17, Steven D'Aprano написав(ла):
Would either of these trade-offs be acceptable while still claiming
Python 3.4 compatibility?
My own feeling is that O(1) string indexing operations are a quality of
implementation issue, not a deal breaker to call it a Python. I can't
see any
04.06.14 10:03, Chris Angelico написав(ла):
Right, which is why I don't like the idea. But you don't need
non-ASCII characters to blink an LED or turn a servo, and there is
significant resistance to the notion that appending a non-ASCII
character to a long ASCII-only string requires the whole
04.06.14 17:02, Paul Moore написав(ла):
On 4 June 2014 14:39, Serhiy Storchaka storch...@gmail.com wrote:
I think than breaking O(1) expectation for indexing makes the implementation
significant incompatible with Python. Virtually all string operations in
Python operates with indices.
I don't
04.06.14 18:38, Paul Sokolovsky написав(ла):
Any non-trivial text parsing uses indices or regular expressions (and
regular expressions themself use indices internally).
I keep hearing this stuff, and unfortunately so far don't have enough
time to collect all that stuff and provide detailed
04.06.14 19:52, MRAB написав(ла):
In order to avoid indexing, you could use some kind of 'cursor' class to
step forwards and backwards along strings. The cursor could include
both the codepoint index and the byte index.
So you need different string library and different regular expression
04.06.14 17:49, Paul Sokolovsky написав(ла):
On Thu, 5 Jun 2014 00:26:10 +1000
Chris Angelico ros...@gmail.com wrote:
On Thu, Jun 5, 2014 at 12:17 AM, Serhiy Storchaka
storch...@gmail.com wrote:
04.06.14 10:03, Chris Angelico написав(ла):
Right, which is why I don't like the idea. But you
04.06.14 20:05, Paul Sokolovsky написав(ла):
On Wed, 04 Jun 2014 19:49:18 +0300
Serhiy Storchaka storch...@gmail.com wrote:
html.HTMLParser, json.JSONDecoder, re.compile, tokenize.tokenize
don't use iterators. They use indices, str.find and/or regular
expressions. Common use case is quickly
05.06.14 01:04, Terry Reedy написав(ла):
PS. You do not seem to be aware of how well the current PEP393
implementation works. If you are going to write any more about it, I
suggest you run Tools/Stringbench/stringbench.py for timings.
AFAIK stringbench is ASCII-only, so it likely is compatible
05.06.14 00:21, Terry Reedy написав(ла):
On 6/4/2014 3:41 AM, Jeff Allen wrote:
Jython uses UTF-16 internally -- probably the only sensible choice in a
Python that can call Java. Indexing is O(N), fundamentally. By
fundamentally, I mean for those strings that have not yet noticed that
they
05.06.14 03:03, Greg Ewing написав(ла):
Serhiy Storchaka wrote:
html.HTMLParser, json.JSONDecoder, re.compile, tokenize.tokenize don't
use iterators. They use indices, str.find and/or regular expressions.
Common use case is quickly find substring starting from current
position using str.find
04.06.14 23:50, Glenn Linderman написав(ла):
3) (Most space efficient) One cached entry, that caches the last
codepoint/byte position referenced. UTF-8 is able to be traversed in
either direction, so next/previous codepoint access would be
relatively fast (and such are very common operations,
05.06.14 05:25, Terry Reedy написав(ла):
I mentioned it as an alternative during the '393 discussion. I more than
half agree that the FSR is the better choice for CPython, which had no
particular attachment to UTF-16 in the way that I think Jython, for
instance, does.
Yes, I remember. I thing
11.06.14 05:28, Antoine Pitrou написав(ла):
close() should indeed be idempotent on all bundled IO class
implementations (otherwise it's a bug), and so should it preferably on
third-party IO class implementations.
There are some questions about close().
1. If object owns several resources,
I submitted a number of patches which fixes currently broken
Unicode-disabled build of Python 2.7 (built with --disable-unicode
configure option). I suppose this was broken in 2.7 when C
implementation of the io module was introduced.
http://bugs.python.org/issue21833 -- main patch which
24.06.14 14:50, Victor Stinner написав(ла):
2014-06-24 13:04 GMT+02:00 Skip Montanaro s...@pobox.com:
I can't see any reason to make a backwards-incompatible change to
Python 2 to only support Unicode. You're bound to break somebody's
setup. Wouldn't it be better to fix bugs as Serhiy has done?
25.06.14 00:03, Jim J. Jewett написав(ла):
It would be good to fix the tests (and actual library issues).
Unfortunately, some of the specifically proposed changes (such as
defining and using _unicode instead of unicode within python code)
look to me as though they would trigger problems in the
24.06.14 22:54, Ned Deily написав(ла):
Benefit:
- Fixes documented feature that may be of benefit to users of Python in
applications with very limited memory available, although there aren't
any open issues from users requesting this (AFAIK). No benefit to the
overwhelming majority of Python
25.06.14 16:29, Victor Stinner написав(ла):
2014-06-25 14:58 GMT+02:00 Serhiy Storchaka storch...@gmail.com:
Other benefit: patches exposed several bugs in code (mainly errors in
backporting from 3.x).
Oh, interesting. Do you have examples of such bugs?
In posixpath branches for unicode
26.06.14 02:28, Nick Coghlan написав(ла):
OK, *that* sounds like an excellent reason to keep the Unicode disabled
builds functional, and make sure they stay that way with a buildbot: to
help make sure we're not accidentally running afoul of the implicit
interoperability between str and unicode
30.07.14 02:45, antoine.pitrou написав(ла):
http://hg.python.org/cpython/rev/79a5fbe2c78f
changeset: 91935:79a5fbe2c78f
parent: 91933:fbd104359ef8
user:Antoine Pitrou solip...@pitrou.net
date:Tue Jul 29 19:41:11 2014 -0400
summary:
Issue #22003: When initialized from a
30.07.14 06:59, Serhiy Storchaka написав(ла):
30.07.14 02:45, antoine.pitrou написав(ла):
http://hg.python.org/cpython/rev/79a5fbe2c78f
changeset: 91935:79a5fbe2c78f
parent: 91933:fbd104359ef8
user:Antoine Pitrou solip...@pitrou.net
date:Tue Jul 29 19:41:11 2014 -0400
30.07.14 16:59, Antoine Pitrou написав(ла):
Le 30/07/2014 02:11, Serhiy Storchaka a écrit :
30.07.14 06:59, Serhiy Storchaka написав(ла):
30.07.14 02:45, antoine.pitrou написав(ла):
http://hg.python.org/cpython/rev/79a5fbe2c78f
changeset: 91935:79a5fbe2c78f
parent: 91933:fbd104359ef8
31.07.14 00:23, Antoine Pitrou написав(ла):
Le 30/07/2014 15:48, Serhiy Storchaka a écrit :
I meant that David's approach is conceptually simpler, which makes it
easier to review.
Regardless, there is no exclusive-OR here: if you can improve over the
current version, there's no reason
Should new enum types added recently to collect module constants be
documented at all? For example AddressFamily is absent in socket.__all__
[1].
[1] http://bugs.python.org/issue20689
___
Python-Dev mailing list
Python-Dev@python.org
15.08.14 08:50, Nick Coghlan написав(ла):
* add bytes.zeros() and bytearray.zeros() as a replacement
b'\0' * n and bytearray(b'\0') * n look good replacements to me. No need
to learn new method. And it works right now.
* add bytes.iterbytes(), bytearray.iterbytes() and
Currently most functions which accepts string argument which then passed
to C function as NUL-terminated string, reject strings with embedded NUL
character and raise TypeError. ValueError looks more appropriate here,
because argument type is correct (str), only its value is wrong. But
this is
Builting open(), io classes, os and os.path functions and some other
functions in the stdlib support bytes paths as well as str paths. But
many functions doesn't. There are requests about adding this support
([1], [2]) in some modules. It is easy (just call os.fsdecode() on
argument) but I'm
19.08.14 20:02, Guido van Rossum написав(ла):
The official policy is that we want them to go away, but reality so far
has not budged. We will continue to hold our breath though. :-)
Does it mean that we should reject all propositions about adding bytes
path support in existing functions (in
On 26.09.14 01:17, Antoine Pitrou wrote:
Fortunately, Python's subprocess has its `shell` argument default to
False. However, `os.system` invokes the shell implicitly and is
therefore a possible attack vector.
Fortunately dash (which is used as /bin/sh in Debian and Ubuntu) is not
vulnerable.
On 06.10.14 00:24, Greg Ewing wrote:
anatoly techtonik wrote:
That's a cool stuff. `bytes-like object` is really a much better name
for users.
I'm not so sure. Usually when we talk about an xxx-like object we
mean one that supports a certain Python interface, e.g. a file-like
object is one
On 20.11.14 21:58, Antoine Pitrou wrote:
To me generator_return sounds like the addition to generator syntax
allowing for return statements (which was done as part of the yield
from PEP). How about generate_escape?
Or may be generator_stop_iteration?
On 25.12.14 05:56, Sky Kok wrote:
Anyway, sometimes when people review my patches for CPython, they send
me a notice through Rietveld Code Review Tool which later will send an
email to me. However, my GMail spam filter is aggressive so the email
will always be classified as spam because it fails
On 10.12.12 03:44, Raymond Hettinger wrote:
The current memory layout for dictionaries is
unnecessarily inefficient. It has a sparse table of
24-byte entries containing the hash value, key pointer,
and value pointer.
Instead, the 24-byte entries should be stored in a
dense table referenced by
On 25.01.15 17:08, Antoine Pitrou wrote:
On Sat, 24 Jan 2015 21:10:51 -0500
Neil Girdhar mistersh...@gmail.com wrote:
To finish PEP 448, I need to update the grammar for syntax such as
{**x for x in it}
Is this seriously allowed by the PEP? What does it mean exactly?
I would understand this
On 17.02.15 23:25, Barry Warsaw wrote:
I'm not sure sys.getfilesystemencoding() is the right encoding, rather than
sys.getdefaultencoding(), if you're talking about the encoding of the shebang
line rather than the encoding of the resulting pyz filename.
On POSIX sys.getfilesystemencoding() is
On 13.02.15 12:07, Victor Stinner wrote:
TL,DR: are you ok to add 800 lines of C code for os.scandir(), 4x
faster than os.listdir() when the file type is checked?
You can try to make Python implementation faster if
1) Don't set attributes to None in constructor.
2) Implement scandir as:
def
On 13.02.15 12:07, Victor Stinner wrote:
* C implementation: scandir is at least 3.5x faster than listdir, up
to 44.6x faster on Windows
Results on Windows was obtained in the becnhmark that doesn't drop disk
caches and runs listdir before scandir.
On 26.01.15 00:59, Guido van Rossum wrote:
Interestingly, the non-dict versions can all be written today using a
double-nested comprehension, e.g. {**x for x in it} can be written as:
{x for x in xs for xs in it}
{x for xs in it for x in xs}
But it's not so straightforward for
On 10.02.15 04:06, Ethan Furman wrote:
return func(*(args + fargs), **{**keywords, **fkeywords})
We don't use [*args, *fargs] for concatenating lists, but args + fargs.
Why not use + or | operators for merging dicts?
___
Python-Dev mailing
On 09.02.15 14:48, raymond.hettinger wrote:
https://hg.python.org/cpython/rev/dc820b44ce21
changeset: 94572:dc820b44ce21
user:Raymond Hettinger pyt...@rcn.com
date:Mon Feb 09 06:48:29 2015 -0600
summary:
Mirco-optimizations to reduce register spills and reloads observed on
On 13.02.15 05:41, Ethan Furman wrote:
So there are basically two choices:
1) always use the type of the most-base class when creating new instances
pros:
- easy
- speedy code
- no possible tracebacks on new object instantiation
cons:
- a subclass that
On 14.02.15 03:12, Ethan Furman wrote:
The third choice is to use different specially designed constructor.
class A(int):
-- class A(int):
... def __add__(self, other):
... return self.__make_me__(int(self) + int(other))
... def __repr__(self):
... return 'A(%d)' %
On 14.02.15 01:03, Neil Girdhar wrote:
Now the derived class knows who is asking for a copy. In the case of
defaultdict, for example, he can implement __make_me__ as follows:
def __make_me__(self, cls, *args, **kwargs):
if cls is dict: return default_dict(self.default_factory, *args,
On 15.02.15 10:47, Paul Moore wrote:
On 15 February 2015 at 08:14, Paul Moore p.f.mo...@gmail.com wrote:
Maybe it would be better to
put something on PyPI and let it develop outside the stdlib first?
The only place where a .pyz file can't easily be manipulated with
the stdlib zipfile module
On 15.02.15 18:21, Thomas Wouters wrote:
which requires that extension modules are stored uncompressed (simple)
and page-aligned (harder, as the zipfile.ZipFile class doesn't directly
support page-aligning anything
It is possible to add this feature to ZipFile. It can be useful because
will
Different patterns for TypeError messages are used in the stdlib:
expected X, Y found
expected X, found Y
expected X, but Y found
expected X instance, Y found
X expected, not Y
expect X, not Y
need X, Y found
X is required, not Y
Z must be X, not Y
Z
On 21.03.15 13:03, Victor Stinner wrote:
The \ is useful, it indicates that you cannot use keywords.
Wouldn't it confuse users?
If you want to drop \, modify the function to accept keywords.
Yes, this is a solution. But parsing keyword arguments is slower than
parsing positional
On 21.03.15 13:46, Nick Coghlan wrote:
On 19 March 2015 at 19:28, Serhiy Storchaka storch...@gmail.com wrote:
Here is list of my ready for review patches. It is incomplete and contains
only patches for which I don't expect objections or long discussion. Most
of them are relative easy and need
On 15.03.15 07:52, Ethan Furman wrote:
So how do we fix it? There are a couple different options:
- modify IntEnum pickle methods to return the name only
- modify IntEnum pickle methods to pickle just like the int they represent
The first option has the advantage that in 3.4 and above,
Here is list of my ready for review patches. It is incomplete and
contains only patches for which I don't expect objections or long
discussion. Most of them are relative easy and need only formal review.
Most of them wait for a review many months.
https://bugs.python.org/issue23681
понеділок, 09-бер-2015 10:18:50 ви написали:
On Mon, Mar 9, 2015 at 10:10 AM, Serhiy Storchaka storch...@gmail.com wrote:
понеділок, 09-бер-2015 09:52:01 ви написали:
On Mon, Mar 9, 2015 at 2:07 AM, Serhiy Storchaka storch...@gmail.com
And to be ideal drop-in replacement IntEnum should
On 09.03.15 17:48, Neil Girdhar wrote:
So you agree that the ideal solution is composition, but you prefer
inheritance in order to not break code?
Yes, I agree. There is two advantages in the inheritance: larger
backward compatibility and simpler implementation.
Then,I think the big
On 09.03.15 10:19, Maciej Fijalkowski wrote:
Not all your examples are good.
* float(x) calls __float__ (not __int__)
* re.group requires __eq__ (and __hash__)
* I'm unsure about OSError
* the % thing at the very least works on pypy
Yes, all these examples are implementation defined and
On 06.03.15 14:53, Victor Stinner wrote:
I propose to ignore BrokenPipeError in Popen.__exit__, as done in
communicate(), for convinience:
http://bugs.python.org/issue23570
Serhiy wants to keep BrokenPipeError, he wrote that file.close()
should not ignore write errors (read the issue for
If you have ready patches that wait for review and committing, tell me.
Send me no more than 5 links to issues per person (for first time) in
private and I'll try to make reviews if I'm acquainted with affected
modules or areas.
___
Python-Dev
On 09.03.15 08:12, Ethan Furman wrote:
On 03/08/2015 11:07 PM, Serhiy Storchaka wrote:
If you don't call isinstance(x, int) (PyLong_Check* in C).
Most conversions from Python to C implicitly call __index__ or __int__, but
unfortunately not all.
[snip examples]
Thanks, Serhiy, that's what
On 09.03.15 06:33, Ethan Furman wrote:
I guess it could boil down to: if IntEnum was not based on 'int', but instead
had the __int__ and __index__ methods
(plus all the other __xxx__ methods that int has), would it still be a drop-in
replacement for actual ints? Even when
being used to talk
There are many special names used in Python core and the stdlib, but
absent in the documentation index [1]. If you see names that are defined
or used in the module or area maintained by you, please add references
to these names to the index and document them if it is needed.
Repeat the lists
On 30.03.15 04:22, victor.stinner wrote:
https://hg.python.org/cpython/rev/bc2a22eaa0af
changeset: 95269:bc2a22eaa0af
user:Victor Stinner victor.stin...@gmail.com
date:Mon Mar 30 03:21:06 2015 +0200
summary:
Issue #23752: When built from an existing file descriptor,
On 01.04.15 07:52, Davin Potts wrote:
I am personally interested in seeing all tests pass on OpenBSD and am willing
to put forth effort to help that be so. I would be happy to be added to any
issues that get opened against OpenBSD. That said, I have concerns about the
nature of when and how
On 27.03.15 02:16, Victor Stinner wrote:
2015-03-19 10:28 GMT+01:00 Serhiy Storchaka storch...@gmail.com:
https://bugs.python.org/issue23502
Tkinter doesn't support large integers (out of 32-bit range)
closed
(note: the title was different, pprint: added support for mapping proxy)
My
On 28.03.15 11:39, Victor Stinner wrote:
Can you please take a look at the following issue and try to reproduce it?
http://bugs.python.org/issue23771
The following tests sometimes hang on x86 Ubuntu Shared 3.x and
AMD64 Debian root 3.x buildbots:
- test_notify_all() of
301 - 400 of 1143 matches
Mail list logo
