I think it's important to remember that many novice programmers today learn
python as their first language.
While i don't think the python tutorial is the right place for teaching how
to program, i also think it would be best if it didn't make too many
assumptions on the reader's knowledge.
When it comes to the basics, assuming one already knows another language
isn't very beneficial anyway, in my opinion. If all one is looking for is a
table comparing a known thing with its python equivalent, there are many of
those on the internet already and in much more compact form.
Since "How To" guide is not organized well, it is very tempting to
write all details in tutorial.
I have seen may pull requests which "improve" tutorial by describe
more details and make
the tutorial more perfect.
But adding more and more information into tutorial makes it slower to
learn Python by reading tutorial.
10+ years ago, Python is far less popular in Japan and reading
tutorial is the best way to learn Python to me.
But now Python is popular and there are many free/paid good books and
tutorials on the Web.
Some of them would be more new user friendly than official tutorial.
Then, should official Python tutorial become detailed guide to Python?
Or should we keep new user learning Python as targeted reader?
There is ongoing issue for example: https://bugs.python.org/issue42179
Chaining exception was added in tutorial. Current tutorial mention to
bpo-42179 proposes to add mention to `__context__` to make the
tutorial more accurate about implicit chaining.
And https://github.com/python/cpython/pull/23160 is the pull request
to mention `__context__`.
On the other hand, I want to remove confusion by removing mention to
Because I don't think `__context__` and `__cause__` is important for new users.
See https://github.com/python/cpython/pull/23162 for my proposal.
Inada Naoki <songofacandy(a)gmail.com>
I’m not on this list. But I have offered to help - if there are tasks that need to be done to help this I can help put the weight of a commercial entity behind it whether that involves assigning our developers to work on this, helping pay for external developers to do so, or assisting with access to machine resources.
For the record there are multiple illumos distributions and most are both free and run reasonably well in virtual machines. Claiming that developers don’t have access as a reason to discontinue the port is a bit disingenuous. Anyone can get access if they want and if they can figure out how to login and use Linux then this should be pretty close to trivial for them.
What’s more likely is that some group of developers aren’t interested in supporting stuff they don’t actively use. I get it. It’s easier to work in a monoculture. But in this case there are many many more users of this that would be impacted than a naive examination of downloads will show.
Of course this all presumes that the core Python team still places value on being a cross platform portable tool. I can help solve most of the other concerns - except for this one.
I propose to drop the Solaris support in Python to reduce the Python
I wrote a draft PR to show how much code could be removed (around 700
lines in 65 files):
In 2016, I asked if we still wanted to maintain the Solaris support in
Python, because Solaris buildbots were failing for longer than 6
months and nobody was able to fix them. It was requested to find a
core developer volunteer to fix Solaris issues and to set up a Solaris
Four years later, nothing has happened. Moreover, in 2018, Oracle laid
off the Solaris development engineering staff. There are around 25
open Python bugs specific to Solaris.
I see 3 options:
* Current best effort support (no change): changes only happen if a
core dev volunteers to review and merge a change written by a
* Schedule the removal in 2 Python releases (Python 3.12) and start to
announce that Solaris support is going to be removed
* Remove the Solaris code right now (my proposition): Solaris code
will have to be maintained outside the official Python code base, as
Solaris has a few specific features visible at the Python level:
select.devpoll, os.stat().st_fstype and stat.S_ISDOOR().
While it's unclear to me if Oracle still actively maintains Solaris
(latest release in 2018, no major update since 2018), Illumos and
OpenSolaris (variants or "forks") still seem to be active.
In 2019, a Solaris blog post explains that Solaris 11.4 still uses
Python 2.7 but plans to migrate to Python 3, and Python 3.4 is also
available. These two Python versions are no longer supported.
The question is if the Python project has to maintain the Solaris
specific code or if this code should now be maintained outside Python.
What do you think? Should we wait 5 more years? Should we expect a
company will offer to maintain the Solaris support? Is there a
motivated core developer to fix Solaris issue? As I wrote, nothing has
happened in the last 4 years...
Night gathers, and now my watch begins. It shall not end until my death.
I am Manak Wadhwa. I have a good hand in python language, ML Algorithms, Web Dev (HTML5, CSS3, JS, PHP, AJAX, Bootstrap, JQuery). I want to contribute to python org can someone help as which repository should i start with or work on.
The engines of the secret release manager machine have finished producing a
new pre-release. Go get it here:
*Major new features of the 3.10 series, compared to 3.9*
Python 3.10 is still in development. This releasee, 3.10.0a2 is the second
of six planned alpha releases. Alpha releases are intended to make it
easier to test the current state of new features and bug fixes and to test
the release process. During the alpha phase, features may be added up until
the start of the beta phase (2021-05-03) and, if necessary, may be modified
or deleted up until the release candidate phase (2021-10-04). Please keep
in mind that this is a preview release and its use is not recommended for
Many new features for Python 3.10 are still being planned and written.
Among the new major new features and changes so far:
PEP 623 -- Remove wstr from Unicode
PEP 604 -- Allow writing union types as X | Y
PEP 612 -- Parameter Specification Variables
PEP 626 -- Precise line numbers for debugging and other tools.
(Hey, fellow core developer, if a feature you find important is missing
from this list, let Pablo know.)
The next pre-release of Python 3.10 will be 3.10.0a3, currently scheduled
*And now for something completely different *
The cardinality (the number of elements) of infinite sets can be one of the
most surprising results of set theory. For example, there are the same
amount of even natural numbers than natural numbers (which can be even or
odd). There is also the same amount of rational numbers than natural
numbers. But on the other hand, there are more real numbers between 0 and 1
than natural numbers! All these sets have infinite cardinality but turn out
that some of these infinities are bigger than others. These infinite
cardinalities normally are represented using aleph numbers. Infinite sets
are strange beasts indeed.
Regards from cold London,
Pablo Galindo Salgado
Re: symbol for lookup
Whatever happened to the proposal of using . as prefix?
If memory serves, the main objection was about it being hard to see, but is
it really? We use fixed width fonts for a reason, and there are other
places a dot is quite critical (has any php programmer ever mistaken a .=
for a = ?) without it's size ever causing issues.
I think . is visible enough while being aesthetically inoffensive. Am i
missing some problem or important past objection to it?
first of all, I'm a big fan of the changes being proposed here since in my
code I prefer the 'union' style of logic over the OO style.
I was curious, though, if there are any plans for the match operator to
support async stuff. I'm interested in the problem of waiting on multiple
asyncio tasks concurrently, and having a branch of code execute depending
on the task.
Currently this can be done by using asyncio.wait, looping over the done set
and executing an if-else chain there, but this is quite tiresome. Go has a
select statement (https://tour.golang.org/concurrency/5) that looks like
fmt.Println("Received from ch1")
fmt.Println("Received from ch2")
Speaking personally, this is a Go feature I miss a lot when writing asyncio
code. The syntax is similar to what's being proposed here. Although it
could be a separate thing added later, async match, I guess.
> Message: 2
> Date: Thu, 22 Oct 2020 09:48:54 -0700
> From: Guido van Rossum <guido(a)python.org>
> Subject: [Python-Dev] Pattern matching reborn: PEP 622 is dead, long
> live PEP 634, 635, 636
> To: Python-Dev <python-dev(a)python.org>
> Content-Type: multipart/alternative;
> Content-Type: text/plain; charset="UTF-8"
> After the pattern matching discussion died out, we discussed it with the
> Steering Council. Our discussion ended fairly positive, but there were a
> lot of problems with the text. We decided to abandon the old PEP 622 and
> break it up into three parts:
> - PEP 634: Specification
> - PEP 635: Motivation and Rationale
> - PEP 636: Tutorial
> This turned out to be more work than I had expected (basically we wrote all
> new material) but we've finally made it to a point where we can request
> feedback and submit the new version to the SC for approval.
> While the text of the proposal is completely different, there aren't that
> many substantial changes:
> - We changed walrus patterns ('v := p') to AS patterns ('p as v').
> - We changed the method of comparison for literals None, False, True to use
> 'is' instead of '=='.
> - SyntaxError if an irrefutable case is followed by another case block.
> - SyntaxError if an irrefutable pattern occurs on the left of '|', e.g.
> 'x | [x]'.
> - We dropped the `@sealed` decorator and everything aimed at static type
>  An irrefutable pattern is one that never fails, notably a wildcard or a
> capture. An irrefutable case has an irrefutable pattern at the top and no
> guard. Irrefutability is defined recursively, since an '|' with an
> irrefutable pattern on either side is itself irrefutable, and so is an AS
> pattern with an irrefutable pattern before 'as'.
> The following issues were specifically discussed with the SC:
> - Concerns about side effects and undefined behavior. There's now some
> specific language about this in a few places (giving the compiler freedom
> to optimize), and a section "Side Effects and Undefined Behavior".
> - Footgun if `case NAME:` is followed by another case. This is now a
> - Adding an 'else' clause. We decided not to add this; motivation in PEP
> - Alternative 'OR' symbol. Not changed; see PEP 635.
> - Alternative wildcard symbol. Not changed, but Thomas wrote PEP 640 which
> proposes '?' as a general assignment target. PEP 635 has some language
> against that idea.
> - Alternative indentation schemes. We decided to stick with the original
> proposal; see PEP 635.
> - Marking all capture variables with a sigil. We all agreed this was a bad
> idea; see PEP 635.
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*