Change by skreft :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue33159>
___
___
Python-bugs-
New submission from skreft :
PEP 473 was recently rejected
(https://mail.python.org/pipermail/python-dev/2019-March/156692.html) because
it was too broad and was suggested to be broken down in smaller issues.
This issue is requesting the addition of the optional attribute `name` to
skreft added the comment:
@r.david.murray where do you see that those functions are only defined for
ascii? There's nothing in the online docs stating that and furthermore
`formataddr` has supported non-ascii names since version 3.3. RFC 2822 is
however mentioned in the docstrings.
New submission from skreft :
The docs
(https://docs.python.org/3/library/email.util.html#email.utils.formataddr) say
that formataddr is the inverse of parseaddr, however non-ascii email addresses
are treated differently in both methods.
parseaddr will return non-ascci addresses, whereas
skreft added the comment:
Note also, that lib2to3 will parse invalid f-strings like f"hello {", whereas
ast.parse will raise a SyntaxError exception.
See below for reproduction cases:
In [2]: lib2to3.tests.support.parse_string('f"hello {"')
Out[2]: Node(file_i
skreft added the comment:
@Steven lib2to3 is no longer specifically for python 2 code, it also parses
python 3 code and is the building block of tools like YAPF.
See Eli's comment on this https://bugs.python.org/issue23894: "AFAIK lib2to3
has been repurposed to parse Python 3 as
New submission from skreft :
Currently f-strings are parsed just as regular strings by lib2to3. However,
this has the problem that the invariant of a string node being a literal is now
broken.
This poses two problems. On one hand, if I want to compare that two string
nodes are equivalent I
New submission from skreft :
Implement PEP 473.
--
messages: 314546
nosy: skreft
priority: normal
severity: normal
status: open
title: Implement PEP 473
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue33
skreft added the comment:
One possible refactor would be.
import operator
def logical_or(self, other, context=None):
return self._logical_op(other, operator.__or__, context)
def logical_xor(self, other, context=None):
return self._logical_op(other, operator.__xor__
skreft added the comment:
Hi all again:
in the original posting of this issue, I asked what would be the best way to
address this issue. Additionally I proposed to use existing tools to check the
current code. These tools could be easily added to the tests in a non failing
mode, so
New submission from skreft :
By using tools like clonedigger is possible to spot some repeated code.
One file that caught my attention is Lib/decimal.py. It has many portions of
duplicated code.
Here is an example:
def logical_or(self, other, context=None):
"""
New submission from skreft :
In Python 2.7, there are many patterns of the form
for x in mapping.(keys()|values()|items()):
#code
when the iterator version of those method could be used.
Is there any reason for using those methods?
I see that in some other parts of the code the iterator
New submission from skreft :
Hi all, I was reading Python's source code and was surprised to find many PEP 8
errors.
The file that I found specially non PEP8 compliant is
Lib/encodings/punnycode.py, but there are many others that are not compliant.
I think that this issue should be addr
13 matches
Mail list logo
