Python-Dev July 2019

python-dev@python.org

67 participants
40 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

5 months, 2 weeks

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

6 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

9 months, 3 weeks

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?

9 months, 3 weeks

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

10 months, 3 weeks

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

10 months, 3 weeks

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?

10 months, 4 weeks

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

11 months, 1 week

[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. - Ł

11 months, 1 week

🍝 New keyword in bpo: `newcomer friendly`

by Mariatta

🍝 copy-pasta from core-mentorship mailing list. There is now a “newcomer friendly” keyword in bpo. My hope is that going forward, we can tag issues that are suitable for first time contributors with this keyword. It would be great for experienced contributors already familiar with our workflow to not work on issues tagged with newcomer friendly and leave that to new contributors. I’ve added the keyword to Devguide’s Triaging section, with additional guideline of what can be tagged as newcomer friendly. Typically it should be straightforward, well-defined issue, and low-risk. https://devguide.python.org/triaging.html#keywords Thanks. ᐧ

11 months, 1 week

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