Mailman 3 November 2013 - Python-ideas

PEP 451 (import API refactoring) and C extension loading
by Nick Coghlan 03 Nov '13

03 Nov '13

Eric Snow's PEP 451 that refactors the import plugin API to move more boilerplate responsibility to the import system has come along nicely, and is now almost certain to make the beta 1 deadline. One of the guiding elements of that design has been the discussion we had a while ago on this list about making more information available to C extensions about how they're being loaded - the ModuleSpec objects in PEP 451 are a key piece in fulfilling that goal. However, I'm *not* confident it's going to be possible to work through all the issues involved in actually refactoring the dynamic loading infrastructure to use the new plugin model in the time we have left before feature freeze, particularly since getting the code aspects of PEP 451 completely bedded down is going to take some time (e.g. it opens up additional possibilities for the runpy API), and there are several other things that still need to happen prior to the beta (like getting ensurepip committed and completing the follow-on work). So, here's my current thinking: the PEP 451 refactoring makes it far more feasible to experiment with alternative C extension loading techniques through cffi, so I'd like to postpone actually changing the default extension loading system to Python 3.5. The idea of adding cffi itself to the standard library has been discussed, in which case we might even be able to move all of that ugly extension management code out of C and into Python permanently, rather than just as part of third party experiments. Thoughts? (cc'ing Stefan directly, since Cython is the most likely venue for such experiments) Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

2 2

Making datetime __str__ and isoformat more consistent
by Skip Montanaro 02 Nov '13

02 Nov '13

http://bugs.python.org/issue19475 I was told to come here. Is there some reason that datetime objects' __str__ and isoformat methods shouldn't emit microseconds in all cases for consistency? As things stand, datetime.strptime() can't reliably parse what those methods emit. Details on the above (close) ticket. Here's what I'm talkin' 'bout: >>> import datetime >>> dt1 = datetime.datetime(2013, 10, 30, 14, 26, 50) >>> dt2 = datetime.datetime(2013, 10, 30, 14, 26, 50, 1234) >>> datetime.datetime.strptime(str(dt1), "%Y-%m-%d %H:%M:%S") datetime.datetime(2013, 10, 30, 14, 26, 50) >>> datetime.datetime.strptime(str(dt2), "%Y-%m-%d %H:%M:%S") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/bin/python27/lib/python2.7/_strptime.py", line 328, in _strptime data_string[found.end():]) ValueError: unconverted data remains: .001234 >>> datetime.datetime.strptime(str(dt2), "%Y-%m-%d %H:%M:%S.%f") datetime.datetime(2013, 10, 30, 14, 26, 50, 1234) >>> datetime.datetime.strptime(str(dt1), "%Y-%m-%d %H:%M:%S.%f") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/bin/python27/lib/python2.7/_strptime.py", line 325, in _strptime (data_string, format)) ValueError: time data '2013-10-30 14:26:50' does not match format '%Y-%m-%d %H:%M:%S.%f' Do others agree with me that consistency in this situation is better than the current behavior? Thx, Skip Montanaro

10 19

Support os.path.join for Windows paths on Posix
by Ryan Gonzalez 02 Nov '13

02 Nov '13

The recent thread/post/whatever on os.path.join has gotten me thinking. Say I wanted to join a Windows path...on Ubuntu. This is what I get: ryan@DevPC-LX:~$ python Python 2.7.3 (default, Sep 26 2013, 20:03:06) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.path.join('C:\\', 'x.jpg') 'C:\\/x.jpg' >>> Isn't something wrong there? My idea: check for \'s in the path. If there are any, assume \ is the path separator, not /. -- Ryan

9 14

Where did we go wrong with negative stride?
by Guido van Rossum 02 Nov '13

02 Nov '13

In the comments of http://python-history.blogspot.com/2013/10/why-python-uses-0-based-indexing… were some complaints about the interpretation of the bounds for negative strides, and I have to admin it feels wrong. Where did we go wrong? For example, "abcde"[::-1] == "edcba" as you'd expect, but there is no number you can put as the second bound to get the same result: "abcde"[:1:-1] == "edc" "abcde"[:0:-1] == "edcb" but "abcde":-1:-1] == "" I'm guessing it all comes from the semantics I assigned to negative stride for range() long ago, unthinkingly combined with the rules for negative indices. Are we stuck with this forever? If we want to fix this in Python 4 we'd have to start deprecating negative stride with non-empty lower/upper bounds now. And we'd have to start deprecating negative step for range() altogether, recommending reversed(range(lower, upper)) instead. Thoughts? Is NumPy also affected? -- --Guido van Rossum (python.org/~guido)

33 135

Round-tripping datetime's str
by Ethan Furman 02 Nov '13

02 Nov '13

Issue15873 [1] talks about adding the ability for datetime.datetime (and friends?) to accept a string to create the relevant object (and not just numbers). Thoughts? [1] http://bugs.python.org/issue15873 -- ~Ethan~

2 1

Allow attribute references for decimalinteger
by אלעזר 01 Nov '13

01 Nov '13

There's an unnecessary corner case regarding integer literals and attributes: >>> 1..real 1.0 >>> 1.0.real 1.0 >>> 1..real 1.0 >>> 1. .real 1.0 >>> .1.real 0.1 >>> 1 .real 1 >>> (1).real 1 >>> 1.real File "<stdin>", line 1 1.real ^ SyntaxError: invalid syntax Why does it fail? To my human eyes it seems (almost) completely unambiguous. Is it a lexing thing? I couldn't find an explanation (or any reference at all, although there should be) in the docs. The only ambiguity I can see is 1.j - but the desired meaning is clear: 1j (just like 1.0j). It may confuse beginners; it made me believe that there's no such thing as 1.__class__ a couple of years ago. I guess it's bad for code generators too. I suggest making "1.identifier" legal, and adding `j` and `J` properties to numbers.Number to mean the sensible thing (so 0.j is not a special syntax as it today). Elazar

8 14