In Python 2.5 `0or` was accepted by the Python parser. It became an
error in 2.6 because "0o" became recognizing as an incomplete octal
number. `1or` still is accepted.
On other hand, `1if 2else 3` is accepted despites the fact that "2e" can
be recognized as an incomplete floating point number. In this case the
tokenizer pushes "e" back and returns "2".
Shouldn't it do the same with "0o"? It is possible to make `0or` be
parseable again. Python implementation is able to tokenize this example:
$ echo '0or' | ./python -m tokenize
1,0-1,1: NUMBER '0'
1,1-1,3: NAME 'or'
1,3-1,4: OP '['
1,4-1,5: OP ']'
1,5-1,6: NEWLINE '\n'
2,0-2,0: ENDMARKER ''
On other hand, all these examples look weird. There is an assymmetry:
`1or 2` is a valid syntax, but `1 or2` is not. It is hard to recognize
visually the boundary between a number and the following identifier or
keyword, especially if numbers can contain letters ("b", "e", "j", "o",
"x") and underscores, and identifiers can contain digits. On both sides
of the boundary can be letters, digits, and underscores.
I propose to change the Python syntax by adding a requirement that there
should be a whitespace or delimiter between a numeric literal and the
webmaster has already heard from 4 people who cannot install it.
I sent them to the bug tracker or to python-list but they seem
not to have gone either place. Is there some guide I should be
sending them to, 'how to debug installation problems'?
If one goes to httWhps://www.python.org/downloads
<https://www.python.org/downloads> from a Windows browser, the default
download URL is for the 32-bit installer instead of the 64-bit one.
I wonder why is this still the case?
Shouldn't we encourage new Windows users (who may not even know the
distinction between the two architectures) to use the 64-bit version of
Python, since most likely they can?
If this is not the correct forum for this, please let me know where I can
direct my question/feature request, thanks.
Happy New Year everyone!
I would like to start a thread here for wider feedback on my proposal to
change the return type of the addition operation between a datetime
subclass and a timedelta. Currently, adding a timedelta to a subclass of
datetime /always/ returns a datetime rather than an instance of the
I have an open PR implementing this, PR #10902
<https://github.com/python/cpython/pull/10902>, but I know it's a major
change so I did not want to move forward without more discussion. I
first brought this up on datetime-SIG
, and we decided to move the discussion over here because the people
most likely to object to the change would be on this list and not on
In addition to the datetime-SIG thread, you may find a detailed
rationale for the change in bpo-35364
<https://bugs.python.org/issue35364#msg331065> , and a rationale for
why we would want to (and arguably already /do/) support subclassing
datetime in bpo-32417 <https://bugs.python.org/issue32417#msg331353> .
A short version of the strongest rationale for changing how this works
is that it is causing inconsistencies in how subclassing is handled in
alternate constructors of datetime. For a given subclass of datetime
(which I will call DateTimeSub), nearly all alternate constructors
already support subclasses correctly - DateTimeSub.fromtimestamp(x) will
return a DateTimeSub, for example. However, because DateTimeSub +
timedelta returns datetime, any alternate constructor implemented in
terms of timedelta additions will leak that implementation detail by
returning a datetime object instead of the subclass. The biggest problem
is that datetime.fromutc is defined in terms of timedelta addition, so
DateTimeSub.now() returns a DateTimeSub object, but
DateTimeSub.now(timezone.utc) returns a datetime object! This is one of
the most annoying things to work around when building a datetime
subclass, and I don't know of any situation where someone /wants/ their
subclass to be lost on addition with a timedelta.
From my understanding, this has been discussed before and the original
objection was that this implementation assumes that the datetime
subclass has a constructor with the same (or a sufficiently similar)
signature as datetime. This may be a legitimate gripe, but unfortunately
that ship has sailed long ago. All of datetime's alternate constructors
make this assumption. Any subclass that does not meet this requirement
must have worked around it long ago (or they don't care about alternate
Thanks for your attention, I look forward to your replies.
Now that regular dicts are ordered and compact, it makes more sense for the _asdict() method to create a regular dict (as it did in its early days) rather than an OrderedDict. The regular dict is much smaller, much faster, and has a much cleaner looking repr. It would also help namedtuple() stay in sync with dataclasses which already take advantage of the ordering feature of regular dicts.
The question is how to be go about making the change in a way gives the most benefit to users as soon as possible and that creates the least disruption.
Option 1) Add a deprecation notice to 3.8, make no code change in 3.8, and then update the code in 3.9. This has several issues: a) it doesn't provide an executable DeprecationWarning in 3.8, b) it isn't really a deprecation, and c) it defers the benefits of the change for another release.
Option 2) Add a deprecation notice to 3.8, add a DeprecationWarning to the _asdict() method, and make the actual improvement in 3.9. The main issue here is that it will create a lot of noise for normal uses of the _asdict() method which are otherwise unaffected by the change. The typical use cases for _asdict() are to create keyword arguments and to pass named tuple data into functions or methods that expect regular dictionaries. Those use cases would benefit from seeing the change made sooner and would suffer in the interim from their code slowing down for warnings that aren't useful.
Option 3). Add a deprecation notice to 3.8 and have the _asdict() method create a subclass of OrderedDict that issues warnings only for the methods and attributes that will change (move_to_end, popitem, __eq__, __dict__, __weakref__). This is less noisy but it adds a lot of machinery just to make a notification of a minor change. Also, it fails to warn that the data type will change. And it may create more confusion than options 1 and 4 which are simpler.
Option 4) Just make the change directly in 3.8, s/OrderedDict/dict/, and be done will it. This gives users the benefits right away and doesn't annoy them with warnings that they likely don't care about. There is some precedent for this. To make namedtuple class creation faster, the *verbose* option was dropped without any deprecation period. It looks like no one missed that feature at all, but they did get the immediate benefit of faster import times. In the case of using regular dicts in named tuples, people will get immediate and significant space savings as well as a speed benefit.
My recommendation is Option 4 as being less disruptive and more beneficial than the other options. In the unlikely event that anyone is currently depending on the reordering methods for the output of _asdict(), the remediation is trivially simple: nt._asdict() -> OrderedDict(nt.as_dict()).
What do you all think?
---------- Forwarded message ---------
From: Steve Holden <steve(a)holdenweb.com>
Date: Thu, Jan 31, 2019 at 11:05 AM
Subject: Re: [Python-Dev] How about updating OrderedDict in csv and
configparser to regular dict?
To: INADA Naoki <songofacandy(a)gmail.com>
And I see that such a patch is now merged. Thanks, Raymond!
https://bugs.python.org/issue15248 is about situations like the following:
Traceback (most recent call last):
File "<pyshell#4>", line 2, in <module>
TypeError: 'tuple' object is not callable
The original poster requested that the error message be augmented with
something like "(missing preceding comma?)"
Ezio Melotti suggested a FAQ entry like
(I think such entries below in a separate doc and will try to post on
python-ideas when I have a prototype.)
Serhiy Storchaka suggested a compiler SyntaxWarning and uploaded a
proof-of-concept diff that handled the above and many similar cases. The
diff is based on the idea that while we can only positively identify
'callables' at runtime, we *can* negatively identify many non-callables
when compiling. Ditto for subscriptables and indexables.
Serhiy concluded with
"This patch was inspired by usability improvements in GCC 8.
I haven't created a pull request because I have doubts about that this
should be in the compiler rather of a third-party linter. But if several
other core developers will support this idea I'll continue working in
I was impressed with how clear and readable the patch is and consider it
a plausible enhancement. I would like other core developers to comment.
Terry Jan Reedy
csv.DictReader uses OrderedDict by default, from Python 3.6.
But it doesn't make sense anymore, like namedtuple._asdict().
How about changing default dict type back to regular dict.
Python is widely used for handling learge data. So I think
changing default dict type to OrderedDict was performance
and memory usage regression in 3.6.
Additionally, configparser uses OrderedDict by default from Python 3.6 too.
I am not sure about `parser['section1'] == parser['section2']` is not used yet.
But we broke it once in 3.6 by changing dict to OrderedDict. Are there any
issue report caused by this backward incompatibility?
And I think performance and memory efficiency is not so important for
configparser, unlike csv.
* +1 about changing csv.DictReader's default dict type
* +0.5 about changing configparser's default dict type.
How do you think?
INADA Naoki <songofacandy(a)gmail.com>
Hi Python community folk!
As we've done for the past many years, Python is hoping to participate
in Google Summer of Code. This is a neat program where students write
code over the (northern hemisphere) summer under the tutelage of open
source mentors and get paid: we provide the project ideas, mentors and
choose the students, Google provides the program framework and the money
to pay students. You can read more about GSoC here:
Python participates as an "umbrella org" where many different smaller
projects ("sub orgs") that use Python can take part under our banner.
You can also participate separately, but for people who've never done it
before and want help or for whom the paperwork is a hassle, you're
welcome to join up with us and let us show you the ropes!
It's really fun, and we've gotten lots of new contributors to
Python-based projects over the years, taking in as many as 70+ students
in a single year. Last year we only had 15, though, so we've got lots
of space for new mentors and new projects.
We didn't have any projects for core python last year as there were no
for the projects, so if anyone is interested in mentoring this year let us
You can also send questions to gsoc-admins(a)python.org (or just hit reply
to this email!)