Python-Dev January 2019

python-dev@python.org

55 participants
27 discussions

by Facundo Batista

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

2 months, 2 weeks

congrats on 3.5! Alas, windows 7 users are having problems installing it

by Laura Creighton

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

6 months, 3 weeks

why is not 64-bit installer the default download link for Windows?

by Cosimo Lupo

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

9 months, 3 weeks

Return type of datetime subclasses added to timedelta

by Paul Ganssle

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

1 year, 2 months

How to update namedtuple asdict() to use dict instead of OrderedDict

by Raymond Hettinger

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

1 year, 2 months

Fwd: How about updating OrderedDict in csv and configparser to regular dict?

by Steve Holden

---------- 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! > >>

1 year, 2 months

Add more SyntaxWarnings?

by Terry Reedy

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

1 year, 2 months

How about updating OrderedDict in csv and configparser to regular dict?

by INADA Naoki

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>

1 year, 2 months

Summer of Code 2019 Mentors

by Matthew Lagoe

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!)

1 year, 2 months

[ANN] "compiler" package resurrected

by Paul Sokolovsky

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

1 year, 2 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev January 2019