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 fixes
24.06.14 14:50, Victor Stinner написав(ла):
2014-06-24 13:04 GMT+02:00 Skip Montanaro :
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?
According to
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 no
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 use
25.06.14 16:29, Victor Stinner написав(ла):
2014-06-25 14:58 GMT+02:00 Serhiy Storchaka :
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 and str should be
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 wh
30.07.14 02:45, antoine.pitrou написав(ла):
http://hg.python.org/cpython/rev/79a5fbe2c78f
changeset: 91935:79a5fbe2c78f
parent: 91933:fbd104359ef8
user:Antoine Pitrou
date:Tue Jul 29 19:41:11 2014 -0400
summary:
Issue #22003: When initialized from a bytes object, io.Byt
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
date:Tue Jul 29 19:41:11 2014 -0400
summary:
Issue
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 rea
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
https://mail.pyt
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 memoryview.iterbytes(
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 b
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 no
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 pa
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 a
On 25.01.15 17:08, Antoine Pitrou wrote:
On Sat, 24 Jan 2015 21:10:51 -0500
Neil Girdhar 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 as
{k: v for x in
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 dict
On 09.02.15 14:48, raymond.hettinger wrote:
https://hg.python.org/cpython/rev/dc820b44ce21
changeset: 94572:dc820b44ce21
user:Raymond Hettinger
date:Mon Feb 09 06:48:29 2015 -0600
summary:
Mirco-optimizations to reduce register spills and reloads observed on CLANG
and GCC.
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 mailin
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 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 needs/wan
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)' % sel
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,
**kwa
On 15.02.15 10:47, Paul Moore wrote:
On 15 February 2015 at 08:14, Paul Moore 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 is in writing a she
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 al
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 t
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 should
On 20.02.15 01:57, MRAB wrote:
Messages tend not to be complete sentences anyway, so I think that it
would be fitting to omit articles.
Thanks. This post was aroused by your note about articles on the tracker.
___
Python-Dev mailing list
Python-Dev@
On 20.02.15 18:11, Eric V. Smith wrote:
I asked about this years ago, and was told it was in case the type name
pointer was bad, and to limit the amount of garbage printed. Whether
that's an actual problem or not, I can't say. It seems more likely that
you'd get a segfault, but maybe if it was po
On 21.02.15 10:03, Guido van Rossum wrote:
IIRC there's a limited buffer used for the formatting.
For now formatting buffer is not limited. But other arguments are valid.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailm
On 21.02.15 16:26, Nick Coghlan wrote:
Likewise, although as Rob noted, it's sometimes to desirable to use
the "Z should be X, not Y" form if the shorter form would be
ambiguous.
Z is not always available.
Perhaps this should be a recommendation in both PEP 7 & 8? It's
exactly the kind of iss
Currently for some files converted to use Argument Clinic the generated
code is written into a separate file, for other files it is inlined.
I'm going to make a number of small enhancement to Argument Clinic to
generate faster code for parsing arguments (see for example issue23492).
Every such
/* Namespaces are one honking great idea -- let's do more of those! */
There are two ways to avoid name conflicts: prefixes and namespaces.
Programming languages that lacks namespaces (such as C) need to use
prefixes. For example: PROTOCOL_SSLv2, PROTOCOL_SSLv3, PROTOCOL_SSLv23.
Python used th
On 21.02.15 21:49, Ian Cordasco wrote:
So I like the latter (Protocol.SSLv2) but would qualify that with the
request that ssl.PROTOCOL_SSLv2 continue to work until Python 2 is
dead and libraries like requests, urllib3, httplib2, etc. no longer
need to support those versions.
Of course, ssl.PROT
On 21.02.15 20:04, steve.dower wrote:
https://hg.python.org/cpython/rev/307713759a62
changeset: 94720:307713759a62
parent: 94718:4f6f4aa0d80f
user:Steve Dower
date:Sat Feb 21 10:04:10 2015 -0800
summary:
Issue #23152: Renames attribute_data_to_stat to _Py_attribute_data
On 22.02.15 01:26, Steve Dower wrote:
Thanks! Fixed now.
Clinic removes the declaration of _Py_time_t_to_FILE_TIME.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.pyth
On 22.02.15 05:03, Nick Coghlan wrote:
On 22 February 2015 at 06:58, Brett Cannon wrote:
+1 to moving to a separate file for all .c files. Might be painful now but
the long-terms benefits are worth it.
Yeah, agreed. Originally I was a fan of having everything inline so I
could see them while
On 22.02.15 16:12, Steve Dower wrote:
Why does it do that?
Because it is in the section of generated code.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/ma
See topic "Unrecognized backslash escapes in string literals" in Python
list [1]. I agree that this is a problem, especially for novices (but
even experience users can make a typo). May be emit SyntaxWarning on
unrecognized backslash escapes? An exception is already raised on
invalid octal or h
On 23.02.15 21:22, Ethan Furman wrote:
This could be a completely stupid question, but how does the zip file know
where the individual files are? More to the
point, does the index work via relative or absolute offset? If absolute,
wouldn't the index have to be rewritten if the
zip portion of
On 24.02.15 21:01, Guido van Rossum wrote:
On Tue, Feb 24, 2015 at 10:50 AM, Paul Moore mailto:p.f.mo...@gmail.com>> wrote:
On 24 February 2015 at 18:24, Guido van Rossum mailto:gu...@python.org>> wrote:
> I'd specify that when the output argument is a file open for writing, it
is
>
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 mailin
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 details
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 t
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&#
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 can
понеділок, 09-бер-2015 10:18:50 ви написали:
> On Mon, Mar 9, 2015 at 10:10 AM, Serhiy Storchaka wrote:
> > понеділок, 09-бер-2015 09:52:01 ви написали:
> > > On Mon, Mar 9, 2015 at 2:07 AM, Serhiy Storchaka
> > > > And to be ideal drop-in replacement IntEnu
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 questio
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 h
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
Hav
How to document functions with optional positional parameters?
For example binascii.crc32(). It has two positional parameters, one is
mandatory, and one is optional with default value 0. With Argument
Clinic its signature is crc32(data, crc=0, /). In the documentation it
is written as crc32(da
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 arguments.
On 21.03.15 13:46, Nick Coghlan wrote:
On 19 March 2015 at 19:28, Serhiy Storchaka 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 only formal r
On 22.03.15 17:33, paul.moore wrote:
https://hg.python.org/cpython/rev/0b2993742650
changeset: 95126:0b2993742650
user:Paul Moore
date:Sun Mar 22 15:32:36 2015 +
summary:
#23657 Don't explicitly do an isinstance check for str in zipapp
As a result, explicitly support pa
On 26.03.15 10:08, victor.stinner wrote:
https://hg.python.org/peps/rev/7daf3bfd9586
changeset: 5741:7daf3bfd9586
user:Victor Stinner
date:Thu Mar 26 09:08:08 2015 +0100
summary:
New PEP 490: Chain exceptions at C level
+Python 3.5 introduces a new private ``_PyErr_ChainE
On 27.03.15 02:16, Victor Stinner wrote:
2015-03-19 10:28 GMT+01:00 Serhiy Storchaka :
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")
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 test_multiprocessing_
On 30.03.15 04:22, victor.stinner wrote:
https://hg.python.org/cpython/rev/bc2a22eaa0af
changeset: 95269:bc2a22eaa0af
user:Victor Stinner
date:Mon Mar 30 03:21:06 2015 +0200
summary:
Issue #23752: When built from an existing file descriptor, io.FileIO() now
only
calls fstat
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
Here is a statistic for most called PyObject_INIT or PyObject_INIT_VAR
for types (collected during running Python tests on 32-bit Linux).
typecount % acc.%
builtin_function_or_method 116012007 36.29% 36.29%
method 52465386
On 09.05.15 22:51, Larry Hastings wrote:
On 05/09/2015 12:01 PM, Serhiy Storchaka wrote:
Here is a statistic for most called PyObject_INIT or PyObject_INIT_VAR
for types (collected during running Python tests on 32-bit Linux).
Can you produce these statistics for a 64-bit build?
Sorry, no
On 10.05.15 02:25, Ian Cordasco wrote:
Can you share how you gathered them so someone could run them on a
64-bit build?
This is quick and dirty patch. It generates 8 GB log file!
patch --merge -p1 PyObject_INIT.log
python3 PyObject_INIT_stat.py PyObject_INIT.stat
Perhaps compiling with COUNT_
Here is comparable statistic collected from tests ran with an executable
buil with COUNT_ALLOCS.
typecount % acc.%
tuple 448855278 29.50% 29.50%
frame 203515969 13.38% 42.88%
str
On 10.05.15 21:28, Larry Hastings wrote:
In Python's argument parsing code (convertsimple in Python/getargs.c), a
couple of format units* accept "read-only bytes-like objects", aka
read-only buffer objects. They call a helper function called
convertbuffer() which uses the buffer protocol to extr
On 13.05.15 09:32, zach.ware wrote:
https://hg.python.org/cpython/rev/d3582826d24c
changeset: 96006:d3582826d24c
user:Zachary Ware
date:Wed May 13 01:21:21 2015 -0500
summary:
Issue #20172: Convert the winsound module to Argument Clinic.
+/*[clinic input]
+winsound.PlaySo
On 15.05.15 01:23, yury.selivanov wrote:
https://hg.python.org/cpython/rev/f0b10980b19e
changeset: 96056:f0b10980b19e
parent: 96054:15701e89d710
user:Yury Selivanov
date:Thu May 14 18:20:01 2015 -0400
summary:
inspect: Micro-optimize __eq__ for Signature, Parameter and
On 14.05.15 00:38, yury.selivanov wrote:
https://hg.python.org/cpython/rev/ee31277386cb
changeset: 96038:ee31277386cb
user:Yury Selivanov
date:Wed May 13 17:18:41 2015 -0400
summary:
inspect: Add __slots__ to BoundArguments.
Note that adding __slots__ breaks pickleability.
On 17.05.15 02:44, Ned Deily wrote:
In article <20150516183940.21146.77...@psf.io>,
serhiy.storchaka wrote:
https://hg.python.org/cpython/rev/7b350f712c0e
changeset: 96099:7b350f712c0e
parent: 96096:f0c94892ac31
parent: 96098:955dffec3d94
user: Serhiy Storchaka
09.09.17 21:46, Barry Warsaw пише:
One use case would be for PEP 553, where you could set the breakpoint
environment variable to the following in order to effectively disable it::
$ setenv PYTHONBREAKPOINT=noop
Are there other use cases? PEP 553 still is not approved, and you could
use o
16.09.17 12:39, Larry Hastings пише:
So why don't decorators allow arbitrary expressions? The PEP discusses
the syntax for decorators, but that whole debate only concerned itself
with where the decorator goes relative to "def", and what funny
punctuation might it use. It never says "decorator
05.09.17 16:02, INADA Naoki пише:
While I can't attend to sprint, I saw etherpad and I found
Neil Schemenauer and Eric Snow will work on startup time.
I want to share my current knowledge about startup time.
For bare (e.g. `python -c pass`) startup time, I'm waiting C
implementation of ABC.
B
27.09.17 15:56, Victor Stinner пише:
In bpo-29400, it was proposed to add the ability to trace not only
function calls but also instructions at the bytecode level. I like the
idea, but I don't see how to extend sys.settrace() to add a new
"trace_instructions: bool" optional (keyword-only?) parame
30.09.17 10:10, INADA Naoki пише:
https://github.com/python/cpython/commit/b24cd055ecb3eea9a15405a6ca72dafc739e6531
commit: b24cd055ecb3eea9a15405a6ca72dafc739e6531
branch: master
author: James Sexton
committer: INADA Naoki
date: 2017-09-30T16:10:31+09:00
summary:
bpo-30806 netrc.__repr__() is
02.10.17 16:26, Victor Stinner пише:
While "import module" is fast, maybe we should use sometimes a global
variable to cache the import.
module = None
def func():
global module
if module is None: import module
...
I optimized "import module", and I think it can be optimized even mo
03.10.17 06:29, INADA Naoki пише:
Before deferring re.compile, can we make it faster?
I profiled `import string` and small optimization can make it 2x faster!
(but it's not backward compatible)
Please open an issue for this.
I found:
* RegexFlag.__and__ and __new__ is called very often.
* _
03.10.17 06:29, INADA Naoki пише:
More optimization can be done with implementing sre_parse and
sre_compile in C.
But I have no time for it in this year.
And please don't do this! This would make maintaining the re module
hard. The performance of the compiler is less important than correctnes
03.10.17 17:21, Barry Warsaw пише:
What if the compiler could recognize constant arguments to re.compile() and do
the regex compilation at that point? You’d need a way to represent the
precompiled regex in the bytecode, and it would technically be a semantic
change since regex problems would
03.10.17 18:15, Guido van Rossum пише:
It's really not that hard. You just check the magic number and if it's
the new one, skip 4 words. No need to understand the internals of the
header.
Hence you should know all old magic numbers to determine if the read
magic number is the new one. Right?
26.09.17 23:47, Guido van Rossum пише:
I've read the current version of PEP 552 over and I think everything
looks good for acceptance. I believe there are no outstanding objections
(or they have been adequately addressed in responses).
Therefore I intend to accept PEP 552 this Friday, unless g
04.10.17 21:06, Barry Warsaw пише:
Victor brings up a good question in his review of the PEP 553 implementation.
https://github.com/python/cpython/pull/3355
https://bugs.python.org/issue31353
The question is whether $PYTHONBREAKPOINT should be ignored if -E is given?
I think it makes sense for
27.10.17 18:35, Guido van Rossum пише:
The "why" question is not very interesting -- it probably wasn't in PCRE
and nobody was familiar with it when we moved off PCRE (maybe it wasn't
even in Perl at the time -- it was ~15 years ago).
I didn't understand your description of \G so I googled it
The copy() methods of list, dict, bytearray, set, frozenset,
WeakValueDictionary, WeakKeyDictionary return an instance of the base
type containing the content of the original collection.
The copy() methods of deque, defaultdict, OrderedDict, Counter,
ChainMap, UserDict, UserList, WeakSet, Elem
26.10.17 12:24, Victor Stinner пише:
We are using Mailman 3 for the new buildbot-status mailing list and it
works well:
https://mail.python.org/mm3/archives/list/buildbot-sta...@python.org/
I prefer to read archives with this UI, it's simpler to follow
threads, and it's possible to reply on the
29.10.17 19:04, Guido van Rossum пише:
It's somewhat problematic. If I subclass dict with a different
constructor, but I don't overload copy(), how can the dict.copy() method
construct a correct instance of the subclass? Even if the constructor
signatures match, how can dict.copy() make sure it
According to the specification of format string syntax [1] (I meant
str.format(), not f-strings), both argument name and attribute name must
be Python identifiers.
But the current implementation is more lenient and allow arbitrary
sequences of characters while they don't contain '.', '[', ']',
Currently the implementation of re and curses related modules is sparsed
over several files:
re:
Lib/re.py
Lib/sre_compile.py
Lib/sre_constants.py
Lib/sre_parse.py
_sre:
Modules/_sre.c
Modules/sre_constants.h
Modules/sre.h
Modules/sre_lib.h
_curses:
Include
03.11.17 12:29, Nick Coghlan пише:
On 3 November 2017 at 20:01, Serhiy Storchaka wrote:
Since virtually all changes in these files at recent years have been made by
me, I don't think this will harm other core developers. Are there any
objections?
Sound fine to me (and you may want to a
03.11.17 16:36, Guido van Rossum пише:
> Maybe we should remove typing from the stdlib?
> https://github.com/python/typing/issues/495
I didn't use typing, but AFAIK the most used feature from typing is
NamedTuple. If move NamedTuple and maybe other convenient classes not
directly related to typ
04.11.17 19:30, Stefan Krah пише:
would it be possible to guarantee that dict literals are ordered in v3.7?
The issue is well-known and the workarounds are tedious, example:
https://mail.python.org/pipermail/python-ideas/2015-December/037423.html
If the feature is guaranteed now, people
05.11.17 20:39, Stefan Krah пише:
On Sun, Nov 05, 2017 at 01:14:54PM -0500, Paul G wrote:
2. Someone invents a new arbitrary-ordered container that would improve on the
memory and/or CPU performance of the current dict implementation
I would think this is very unlikely, given that the previou
05.11.17 21:20, Stefan Krah пише:
On Sun, Nov 05, 2017 at 09:01:40PM +0200, Serhiy Storchaka wrote:
Do you suggest to make dictionary displays producing OrderedDict
instead of dict?
No, this is essentially a language spec doc issue that would guarantee
the ordering properties of the current
05.11.17 21:30, Stefan Krah пише:
On Sun, Nov 05, 2017 at 09:09:37PM +0200, Serhiy Storchaka wrote:
05.11.17 20:39, Stefan Krah пише:
On Sun, Nov 05, 2017 at 01:14:54PM -0500, Paul G wrote:
2. Someone invents a new arbitrary-ordered container that would improve on the
memory and/or CPU
06.11.17 04:05, Nick Coghlan пише:
On the 12-weeks-to-3.7-feature-freeze thread, Jose Bueno & I both
mistakenly though the async/await deprecation warnings were missing
from 3.6.
They weren't missing, we'd just both forgotten those warnings were off
by default (7 years after the change to the de
1 - 100 of 1152 matches
Mail list logo
