Hi all,
I think that PEP 573 is ready to be accepted, to greatly improve the state
of extension modules in CPython 3.9.
https://www.python.org/dev/peps/pep-0573/
It has come a long way since the original proposal and went through several
iterations and discussions by various interested people, effectively
reducing its scope quite a bit. So this is the last call for comments on
the latest version of the PEP, before I will pronounce on it. Please keep
the discussion in this thread.
Stefan
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
What do people think of the idea of requiring all deprecations specifying a version that the feature will be removed in (which under our annual release cadence would be at least the third release from the start of the deprecation, hence the deprecation being public for 2 years)? And that we also follow through with that removal?
Now I'm not suggesting it **must** be in three feature releases. A deprecation could be set to Python 4 if people truly feel keeping the code is as easy it gets in terms of maintenance and there's enough usage to warrant such a potential indefinite deprecation/maintenance while keeping the code and docs alive (basically "there are better ways to do this, but this works fine, too, if you were already using it"). But what I am trying to avoid is the semi-regular discussion we seem to have of what is or is not reasonable to deprecate and leave versus deprecate and eventually remove because we didn't specify what the eventual plan was for a deprecation. Also feel like it would help users to know specifically what the plan is with a deprecation rather than wondering if something will get removed in the next feature release or not because we left off a specific removal version.
If people are amenable to this idea I will update PEP 387 (which I plan to start a discussion about post-SC election) and I would also plan to add a warnings._deprecate() which I roughly outlined once at https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/103….
Today I discovered the this struct
typedef struct{
const char* name;
int basicsize;
int itemsize;
unsigned int flags;
PyType_Slot *slots; /* terminated by slot==0. */
} PyType_Spec;
with "PyTypeSlot *slots" being on line 190 of object.h causes a problem when compiled with code that brings in Qt. Qt has macro definitions of slots.
With a cursory preprocessing of the file I was working with, using the handy gcc options -dM -E, I found that
slots was defined to nothing
#define slots
and hence caused problems when object.h was brought into the mix.
I will try to make a simple reproducer tomorrow. I know this probably could be solved by header file inclusion re-ordering,
or in some cases #undef'ing slots before including Python.h, but I also thought the Python dev team would like to know
about this issue.
Tom
Hello!
Did we take a decision of what comes after 3.9?
Do we have a PEP for that decision? (couldn't find it)
(not arguing in favor of one or another, just want to know the
rationale behind it)
Thanks!
--
. Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org.ar/
Twitter: @facundobatista
Hi all,
The database backing buildbot.python.org has been reset in order to
clean out old workers and builders, and to allow some relationships to
be created properly to allow future cleanups without resetting
everything. This does unfortunately mean that old links are going to
be broken, including those to particular workers or builders since
they have all been renumbered.
Apologies for the inconvenience,
Zach
