This issue describes some corner cases in PEP 572 (assignment expressions) syntax that haven’t been implemented yet. The PEP currently says:
"The two invalid cases listed above raise TargetScopeError, a new subclass of SyntaxError (with the same signature).”
The PEP doesn’t really go into the rationale for why a new exception is being defined, and in the issue I’ve argued that we should just raise SyntaxError in those cases. To me, “TargetScopeError” is pretty obscure and doesn’t give users an obvious clue as to what’s going wrong, without searching the interwebs.
Nick argues (apologies if I’m misrepresenting you!):
"I believe our main motivation for separating it out was the fact that even though TargetScopeError is a compile-time error, the affected code is syntactically fine - there are just issues with unambiguously inferring the intended read/write location for the affected target names. (Subclassing SyntaxError is then a pragmatic concession to the fact that "SyntaxError" also de facto means "CompilationError”)”
Serhiy points out that we have IndentationError and TabError subclasses of SyntaxError, but those feel different to me because the exception names themselves are clear and descriptive, and lead to obvious actionable remedies.
Guido then suggests we take the discussion here, thus this email.
It would be a very minor update to the PEP, but I think it’s useful to resolve before the last push for PEP 572 implementation gets completed.
Rather than just a vote, if you have a rationale for one over the other, I’d love to hear it. Feel free to weigh in here or on the issue.
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__.
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__.
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
2019-06-03 I have created PR https://github.com/python/cpython/pull/13772 ,
which adds IPv6 scoped addresses support to ipaddress module.
It is very critical to everyone, who is dealing with IPv6 networking. For
example, in salt project they use patched module.
So, it would be very nice to have my changes merged and avoid such a
Pull request passed review, but stopped at core review stage.
I wrote reminder comment at bugtracker without any result, also I can not
reach pmoody (a maintainer of ipaddress module).
Here is link to the bug - https://bugs.python.org/issue34788.
Please, pay attention to this issue.
is a simple doc change for difflib, which I approved some months ago.
But I don't know the current workflow well enough to finish it myself.
- Does something special need to be done for doc changes?
- Since this is a 1st-time contributor, does it need a change to the ACKS file?
- Anything else?
I'm sure this is all obvious after you've done it once, but I haven't.
So I'll watch and do it myself next time ;-)
Victor's experiments into a register-based virtual machine live here:
I'd like to revive them, if for no other reason to understand what he
did. I see no obvious way to collect them all as a massive diff. For
the moment, I downloaded each commit and am applying them oldest to
newest (against 3.3, which I think was Victor's base), correcting
issues as I go along. Still, that is going to take a good long while.
If there's an easier way to do this, I'm all ears.
I've updated the text of PEP 588 (https://www.python.org/dev/peps/pep-0588/)
with several items under "Migration Plan" section:
- Hire a professional project manager to help ensure the success of the
- Create a playground issue tracker on GitHub to experiment and test the
- The work on new CLA host is currently stalled. (more details:
- We've created a new Python Triage team, taking advantage of GitHub's beta
Triage role. We need a better guideline/criteria on how to promote people
to the Python triage team.
- A test repo containing proposed GitHub labels have been created by Carol
Willing. It can be reviewed at:
are welcome. I would suggest discussing the labels in Discourse
<https://discuss.python.org/> under core-workflow category.
- we should create a separate branch on GitHub with info about the new
workflow. This should be done ahead of the actual migration, not after.
Please re-read PEP 588 in its entirety. Any questions or concerns about PEP
588 can be discussed here in python-dev, or Discourse under core-workflow
(FYI, I'm cross-posting this from core-mentorship. If you'd like to reply,
please do so there.)
Following the recent discussion on core-mentorship about beginning
contribution, the difficulties it entails and how to improve the situation,
I'd like to start a process of improving the situation.
As a first step, I'd like to collect as many stories about beginning to
contribute to Python. This includes stories about failures to do so; in
fact, those would be most useful!
I'm intentionally leaving this very open; I'd like to hear anything people
have to tell about their experiences, with as little guidance as possible.
Specifically, at this point, I'm not (yet) looking for specific suggestions
for how to improve the situation.
So, following Guido's call (on core-mentorship) to publicly post such
stories, please help us collect as many such accounts as possible! Post
your own stories, and more importantly, reach out to others who could share
their own stories and ask them to do so!
Those who feel that posting publicly would require too much work, or just
don't feel comfortable doing so, are invited to write to me personally;
I'll use the information anonymously if asked to.
- Tal Einat