Python-Dev July 2019

python-dev@python.org

67 participants
41 discussions

Boundaries between numbers and identifiers

by Serhiy Storchaka

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 following keyword.

19 hours, 6 minutes

About "python-porting" mail list

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

1 year, 2 months

Adding a toml module to the standard lib?

by Bastian Venthur

Hi, I'd like to discuss the idea to add a module to parse TOML [toml-lang] to Python's standard library. PEP-0518 -- Specifying Minimum Build System Requirements for Python Projects [pep] suggests to store build system dependencies in `pyproject.toml`, yet Python itself does not support this format. Various packaging related projects like pip and pipenv already support PEP-0518 and vendored one of the existing TOML libraries in order to read `pyproject.toml` files. Besides that, TOML seems a better alternative to .cfg/.ini, .json -- both of which are already supported by Python's standard lib and parsing/dumping TOML properly is tricky enough to solve it properly [requirements]. There are a couple of TOML implementations out there [toml, pytoml, tomlkit] and one would have to find out which one to prefer and migrate into the stdlib. If the result of this discussion is leaning towards adding TOML, I'd volunteer to do it. This includes: coordinating with the maintainer of the chosen library, writing the PEP (hopefully with some help) and maintain the module for at least two years. Cheers, Bastian [toml-lang]: https://github.com/toml-lang/toml [pep]: https://www.python.org/dev/peps/pep-0518 [pip]: https://github.com/pypa/pip [pipenv]: https://github.com/pypa/pipenv [toml]: https://github.com/uiri/toml [pytoml]: https://github.com/avakar/pytoml [tomlkit]: https://github.com/sdispater/tomlkit [requirements]: https://devguide.python.org/stdlibchanges/#requirements -- Dr. Bastian Venthur http://venthur.de Debian Developer venthur at debian org

1 year, 4 months

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

1 year, 7 months

python3 -bb and hash collisions

by Daniel Holth

set([u"foo", b"foo]) will error because the two kinds of string have the same hash, and this causes a comparison. Is that correct?

1 year, 7 months

Snapshot formats in tracemalloc vs profiler

by Yonatan Zunger

Hi everyone, Something occurred to me while trying to analyze code today: profiler and cProfiler emit their data in pstats format, which various tools and libraries consume. tracemalloc, on the other hand, uses a completely separate format which nonetheless contains similar data. In fact, in many non-Python applications I've worked in, heap and CPU profiles were always emitted in identical formats, which allowed things like visual representations of stack traces where memory is allocated, and these have proven quite useful in practice and allowed lots of sharing of tools across many applications. Is there a particular design reason why these formats are different in Python right now? Would it make sense to consider allowing them to match, e.g. having a tracemalloc.dump_pstats() method? Yonatan

1 year, 8 months

typing: how to use names in result-tuples?

by Christian Tismer

Hi friends, I am meanwhile the PySide maintainer at The Qt Company, and we are trying to make the mapping from Qt functions to Python functions as comparable as possible. One problem are primitive pointer variables: In Qt, it is natural to use "sometype *varname" to make a mutable variable. In Python, you have to turn such a thing into a result-tuple. Example: void QPrinter::getPageMargins(qreal *left, qreal *top, \ qreal *right, qreal *bottom, QPrinter::Unit unit) const (meanwhile deprecated, but a good example) is mapped to the Python signature def getPageMargins(self, \ unit: PySide2.QtPrintSupport.QPrinter.Unit) \ -> typing.Tuple[float, float, float, float]: ... NOW my question: ---------------- I would like to retain the variable names in Python! The first idea is to use typing.NamedTuple, but I get the impression that this would be too much, because I would not only need to create an extra named tuple definition for every set of names, but also invent a name for that named tuple. What I would like to have is something that looks like def getPageMargins(self, \ unit: PySide2.QtPrintSupport.QPrinter.Unit) \ -> typing.NamedTuple[left: float, top: float, \ right:float, bottom:float]: ... but that is obviously not a named tuple. Possible would be to derive a name from the function, so maybe a definition could be used like class PageMargingResult(NamedTuple): left: float top: float right: float bottom: float but then I would have some opaque PageMargingResult type. This would work, but as said, this is a bit too much, since I only wanted something like a tuple with names. What do you suggest to do here? Something what I am missing? Cheers -- Chris -- Christian Tismer :^) tismer(a)stackless.com Software Consulting : http://www.stackless.com/ Karl-Liebknecht-Str. 121 : https://github.com/PySide 14482 Potsdam : GPG key -> 0xFB7BEE0E phone +49 173 24 18 776 fax +49 (30) 700143-0023

1 year, 8 months

What is a public API?

by Serhiy Storchaka

I thought that the name in a module is in the public interface if: * It doesn't start with an underscore and the module does not have __all__. * It is included in the module's __all__ list. * It is explicitly documented as a part of the public interface. help() uses more complex rules, but it believes __all__ if it defined. But seems there are different views on this. * Raymond suggested to add an underscore the two dozens of names in the calendar module not included in __all__. https://bugs.python.org/issue28292#msg347758 I do not like this idea, because it looks like a code churn and makes the code less readable. * Gregory suggests to document codecs.escape_decode() despite it is not included in __all__. https://bugs.python.org/issue30588 I do not like this idea, because this function always was internal, its only purpose was implementing the "string-escape" codec which was removed in Python 3 (for reasons). In Python 3 it is only used for supporting the old pickle protocol 0. Could we strictly define what is considered a public module interface in Python?

1 year, 8 months

Comparing dict.values()

by Kristian Klette

Hi! During the sprints after EuroPython, I made an attempt at adding support for comparing the results from `.values()` of two dicts. Currently the following works as expected: ``` d = {'a': 1234} d.keys() == d.keys() d.items() == d.items() ``` but `d.values() == d.values()` does not return the expected results. It always returns `False`. The symmetry is a bit off. In the bug trackers[0] and the Github PR[1], I was asked to raise the issue on the python-dev mailing list to find a consensus on what comparing `.values()` should do. I'd argue that Python should compare the values as expected here, or if we don't want to encourage that behaviour, maybe we should consider raising an exception. Returning just `False` seems a bit misleading. What are your thoughts on the issue? Best regards, Kristian Klette [0]: https://bugs.python.org/issue37585 [1]: https://github.com/python/cpython/pull/14737

1 year, 8 months

[RELEASE] Python 3.8.0b3 is now available for testing

by Łukasz Langa

This time without delays, I present you Python 3.8.0b3: https://www.python.org/downloads/release/python-380b3/ <https://www.python.org/downloads/release/python-380b3/> This release is the third of four planned beta release previews. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. The next pre-release of Python 3.8 will be 3.8.0b4, the last beta release, currently scheduled for 2019-08-26. Call to action We strongly encourage maintainers of third-party Python projects to test with 3.8 during the beta phase and report issues found to the Python bug tracker <https://bugs.python.org/> as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (2019-09-30). Our goal is have no ABI changes after beta 3 and no code changes after 3.8.0rc1, the release candidate. To achieve that, it will be extremely important to get as much exposure for 3.8 as possible during the beta phase. Please keep in mind that this is a preview release and its use is not recommended for production environments. Last beta coming Beta 4 can only be released if all “Release blocker” and “Deferred blocker” issues on bugs.python.org <http://bugs.python.org/> for 3.8.0 are resolved. Please prioritize those for the next four weeks. Acknowledgements Thanks to our binary builders, Ned and Steve, who were very quick today to get the macOS and Windows installers ready. The Windows story in particular got pretty magical, it’s now really fully automatic end-to-end. Thanks to Victor for vastly improving the reliability of multiprocessing tests since Beta 2. Thanks to Pablo for keeping the buildbots green. - Ł

1 year, 8 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev July 2019