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
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
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
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
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
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?
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
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.
- Ł
🍝 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.
ᐧ
