Currently a raw literal cannot end in a single backslash (e.g. in
r"C:\User\"). Although there are reasons for this. It is an old gotcha,
and there are many closed issues about it. This question is even
included in FAQ.
The most common workarounds are:
I tried to experiment. It was easy to make the parser allowing a
trailing backslash character. It was more difficult to change the Python
implementation in the tokenizer module. But this change breaks existing
code in more sites than I expected. 14 Python files in the stdlib (not
counting tokenizer.py) will need to be fixed. In all cases it is a
If only one type of quotes is used in a string, we can just use
different kind of quotes for creating a string literal and remove escaping.
If different types o quotes are used in different parts of a string, we
can use implicit concatenation of string literals created with different
quotes (in any case a regular expression is long and should be split on
several lines on semantic boundaries).
You can also use triple quotes if the string contain both type of quotes
4. In rare cases a multiline raw string literals can contain both `'''`
and `"""`. In this case you can use implicit concatenation of string
literals created with different triple quotes.
See https://github.com/python/cpython/pull/15217 .
I do not think we are ready for such breaking change. It will break more
code than forbidding unrecognized escape sequences, and the required
fixes are less trivial.
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
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
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