PEP 234 mention
https://sourceforge.net/p/python/mailman/python-iterators/ but the
project mailing list archives are marked as "hidden".
Looks like projects admin and developers can get the "hidden link", but
I think it would be nice to "unhide" the archives if someone is still
admin there and if it's possible, to "unbreak" the link from the PEP.
Now Python 3.11 development is open and I am removing some deprecated
I am considering `configparser.ParseError.filename` property that is
deprecated since Python 3.2.
My random thoughts about it:
* It has been deprecated long enough.
* But the maintenance burden is low enough.
* If we don't remove long deprecated stuff like this, Python 4.0 will
be a big breaking change.
* Change DeprecationWarning to FutureWarning and wait one more version.
* DeprecationWarning is suppressed by default to hide noise from end users.
* But sudden breaking change is more annoying to end users.
I am not proposing to change PEP 387 "Backwards Compatibility Policy".
This is just a new convention.
* Stop suppressing DeprecationWarning by default
* Use at least one PendingDeprecationWarning and one DeprecationWarning.
* More than two PendingDeprecationWarning periods is preferred.
How do you think?
Inada Naoki <songofacandy(a)gmail.com>
We are preparing a PEP and we would like to start some early discussion
about one of the main aspects of the PEP.
The work we are preparing is to allow the interpreter to produce more
fine-grained error messages, pointing to
the source associated to the instructions that are failing. For example:
Traceback (most recent call last):
File "test.py", line 14, in <module>
File "test.py", line 12, in lel3
return lel2(x) / 23
File "test.py", line 9, in lel2
return 25 + lel(x) + lel(x)
File "test.py", line 6, in lel
return 1 + foo(a,b,c=x['z']['x']['y']['z']['y'], d=e)
TypeError: 'NoneType' object is not subscriptable
The cost of this is having the start column number and end column number
information for every bytecode instruction
and this is what we want to discuss (there is also some stack cost to
re-raise exceptions but that's not a big problem in
any case). Given that column numbers are not very big compared with line
numbers, we plan to store these as unsigned chars
or unsigned shorts. We ran some experiments over the standard library and
we found that the overhead of all pyc files is:
* If we use shorts, the total overhead is ~3% (total size 28MB and the
extra size is 0.88 MB).
* If we use chars. the total overhead is ~1.5% (total size 28 MB and the
extra size is 0.44MB).
One of the disadvantages of using chars is that we can only report columns
from 1 to 255 so if an error happens in a column
bigger than that then we would have to exclude it (and not show the
highlighting) for that frame. Unsigned short will allow
the values to go from 0 to 65535.
Unfortunately these numbers are not easily compressible, as every
instruction would have very different offsets.
There is also the possibility of not doing this based on some build flag on
when using -O to allow users to opt out, but given the fact
that these numbers can be quite useful to other tools like coverage
measuring tools, tracers, profilers and the such adding conditional
logic to many places would complicate the implementation considerably and
will potentially reduce the usability of those tools so we prefer
not to have the conditional logic. We believe this is extra cost is very
much worth the better error reporting but we understand and respect
other points of view.
Does anyone see a better way to encode this information **without
complicating a lot the implementation**? What are people thoughts on the
Thanks in advance,
Regards from cloudy London,
Pablo Galindo Salgado
Now that we are in the beta period for 3.10 is very important that we make
sure that all
improvements, new APIs and deprecations are reflected in the 3.10 what's
If you have worked on:
* Make a PEP that affects Python 3.10.
* A new feature/class/function/argument/option...
* Deprecating something.
* Remove something.
* Improve something important.
Please, make sure is reflected on the What's new document for Python 3.10.
Users normally don't
read the changelog directly and learn about what's available from the
What's New document so
you *absolutely* want your work to be reflected there. *Small* tutorials
and small code samples
and descriptions are a fantastic thing to add as well.
Specially for deprecations and removals, this is our public window to the
world so that learn what's
coming or how to port code to Python 3.10.
Thanks for helping to make Python3.10 a great release.
Regards from sunny London,
Pablo Galindo Salgado
In these last few months, I have been in the process of healing from some
pretty heavy past trauma. And now that I am on the road to recovery, I want
to share my journey with the Python community in hopes that it may reach
those that are struggling with their own mental health battles, as many of
us are during these dark and difficult times.
Trigger warning that it includes a decent amount of highly personal
content, so only check it out if you are okay with that:
To anyone that would limit my employment opportunities as a result of
having had these struggles, *that's perfectly okay*. I kept the post in the
private section because I was originally in fear of discriminate. However,
I have reached an important conclusion: *I would not want to work for your
company if you discriminate against people who have overcome past struggles*
--Kyle R. Stanley, Python Core Developer (what is a core dev?
*Pronouns: they/them **(why is my pronoun here?*
That's this bit:
except (A, B):
bpo-43149 currently calls it an "exception group", but that conflicts with PEP 654 -- Exception Groups and except*
... except A, B:
Traceback (most recent call last):
SyntaxError: exception group must be parenthesized
exception classinfo must be parenthesized (classinfo so named from the parameter to issubclass)
exception sequence must be parenthesized
From Thomas Wouters, on behalf of and with full support of the Python Steering Council:
This discussion seems to have died down a little, but I still want to make a few things clear:
Yes, this is a political decision. Very many decisions are political. The existence of an open-source project is inherently political. The decision to try and make python-dev more welcoming, more open, more helpful is also a political decision -- one that the SC feels is absolutely necessary for the long-term health of the Python language. Not wanting to be bothered by political decisions is a political decision; it’s a decision that you’re happy with politics as they are. I’m afraid you can’t avoid politics.
This isn’t just about ‘master’ being rooted in slavery. This is about what the community sees and does. As I mentioned before, we’re not leading the pack in this, we’re merely following along with others (like, say, Django). There are undoubtedly other terms and practices that are genuinely offensive, and the decision on how to handle them will be taken on a case-by-case basis, weighing the cost and the benefit in each case.
While you may feel the benefit of this change is small and that it has no real impact, we believe that there is little cost to making this change. We believe this change, while a minor inconvenience to some, helps demonstrate our commitment to acting in the best interests of Python's future. Failure to make a small sacrifice, such as this, signals that the Python core development community would be unlikely to undertake real change for greater benefits.
This isn’t happening because GitHub/Microsoft made a political decision. It’s happening because it is incredibly easy to make this move, many projects have already done this, and it reflects badly on any project not making this change.
Speaking for the whole SC in this,
It’s with great pleasure that I announce that python-docs-theme has been released to PyPI.
Thanks to the hard work and patience of Olga Bulat, @obulat, Python’s doc theme is now responsive. Many thanks to everyone who has contributed to this release by filing issues, writing PRs, reviewing PRs, and testing the theme. It was a great team effort.
Here are the highlights from the CHANGELOG.rst:
- Make the theme responsive (#46) Contributed by Olga Bulat.
- Use Python 3.8 for the Github Actions (#71) Contributed by Stéphane Wirtel.
- Use default pygments theme (#68) Contributed by Aaron Carlisle.
- Test Github action to validate the theme against docsbuild scripts. (#69) Contributed by Julien Palard.
- Add the copy button to pycon3 highlighted code blocks. (#64) Contributed by Julien Palard.
CPython is slow. We all know that, yet little is done to fix it.
I'd like to change that.
I have a plan to speed up CPython by a factor of five over the next few
years. But it needs funding.
I am aware that there have been several promised speed ups in the past
that have failed. You might wonder why this is different.
Here are three reasons:
1. I already have working code for the first stage.
2. I'm not promising a silver bullet. I recognize that this is a
substantial amount of work and needs funding.
3. I have extensive experience in VM implementation, not to mention a
PhD in the subject.
My ideas for possible funding, as well as the actual plan of
development, can be found here:
I'd love to hear your thoughts on this.