Hello!
This list (which I co-admin, with Georg) is getting less and less
traffic as months pass by. See:
https://mail.python.org/pipermail/python-porting/
The interwebs has been collecting ton of resources about porting py2
to 3 during these years. Any not-yet-answered question surely can be
done in a list with more participants.
Can we kill this list?
Thanks! Regards,
--
. Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org.ar/
Twitter: @facundobatista
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'?
Laura
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.
Cosimo
--
Cosimo Lupo
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
datetime subclass.
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
<https://mail.python.org/archives/list/datetime-sig@python.org/thread/TGB3VZ…>
[1], 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
datetime-SIG.
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> [2], 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> [3].
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
constructors).
Thanks for your attention, I look forward to your replies.
Best,
Paul
[1]
https://mail.python.org/archives/list/datetime-sig@python.org/thread/TGB3VZ…
[2] https://bugs.python.org/issue35364#msg331065
[3] https://bugs.python.org/issue32417#msg331353
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?
Raymond
---------- 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:
>>> [(1,2,3)
(4,5,6)]
Traceback (most recent call last):
File "<pyshell#4>", line 2, in <module>
(4,5,6)]
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
https://docs.python.org/3/faq/programming.html#why-am-i-getting-an-unboundl…
(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.
https://developers.redhat.com/blog/2018/03/15/gcc-8-usability-improvements/
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
this direction."
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
Hi,
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.
I'm
* +1 about changing csv.DictReader's default dict type
* +0.5 about changing configparser's default dict type.
How do you think?
Regards,
--
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:
https://summerofcode.withgoogle.com/
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
mentors
for the projects, so if anyone is interested in mentoring this year let us
know asap!
You can also send questions to gsoc-admins(a)python.org (or just hit reply
to this email!)
Hello,
I'm sorry for posting here and not to python-announce, somehow I think
(perhaps naively) that it may be of interest to people who are
interested in Python development. At the very least, creation of the
original package is (very likely, I didn't trace up to that) was
discussed on python-dev, its removal was discussed on python-dev, so
why revival of it can't be noted here?
Because, turns out, in old good times, there was a bytecode compiler
written in Python, and even as a part of stdlib. Well, actually it's
still there in the latest 2.7 release, with a proud notice: "Remove
in Python3". The point is that I'm with Python since 1.5 times, and
never knew about this package. I'd generally consider that to be
something to be ashamed and hush of, but unfortunately I found that to
be recurring pattern: people interested in playing with a Python
compiler discover "by a chance" and "suddenly" that they should look no
beyond the stdlib for their (usually pretty simple for starters) needs
- oftentimes, after they already started on the more effortful path
(I faithfully spent 2 days on trying to extract a bytecode compiler
from PyPy first).
With that intro, here's it - the port of Python2 compiler package
(https://docs.python.org/2/library/compiler.html) to Python3:
https://github.com/pfalcon/python-compiler
Currently, it generates bytecode compatible with CPython3.5, and is
able to compile its entire Lib/ (which includes not just stdlib modules
per se, but also tests, and the real "teeth-cracking" stuff is there of
course), except for test_super.py, for which current implementation's
teeth are indeed too weak yet.
Now that it passes the compile-stdlib test, the idea is to refactor
it into something which can be easily played with and extended. We'll
see how it goes.
As one of the example of what's intended to be easily done with it, see
thread
https://mail.python.org/pipermail/python-dev/2019-January/155991.html .
I started it when updating the codegen for Python3, but also shows the
intended purpose - it would easy to analyze if an except handler body
contains "del exc" and if not, skip generating superfluous bytecode.
--
Best regards,
Paul mailto:pmiscml@gmail.com
