[issue33159] Implement PEP 473
Change by skreft : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33159> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37797] Add name attribute to NameError
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 `NameError`. The idea of having a structured attribute is to allow tools to act upon these exceptions. For example you could imagine a test runner which detect typos and suggests the right name to use. There is a current PR (https://github.com/python/cpython/pull/6271) adding this functionality, but it may need to be rebased as it has been awaiting a reply since April last year. -- components: Interpreter Core messages: 349270 nosy: skreft priority: normal pull_requests: 14921 severity: normal status: open title: Add name attribute to NameError type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35222] email.utils.formataddr is not exactly the reverse of email.utils.parseaddr
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. The fact that `formataddr` is not really the inverse warrants at least a note or clarification in the docs. -- ___ Python tracker <https://bugs.python.org/issue35222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35222] email.utils.formataddr is not exactly the reverse of email.utils.parseaddr
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 formataddr will raise a
UnicodeError.
Below is an example:
In [1]: import email.utils as u
In [2]: u.parseaddr('skreft+ñandú@sudoai.com')
Out[2]: ('', 'skreft+ñandú@sudoai.com')
In [3]: u.formataddr(u.parseaddr('skreft+ñandú@sudoai.com'))
---
UnicodeEncodeErrorTraceback (most recent call last)
in ()
> 1 u.formataddr(u.parseaddr('skreft+ñandú@sudoai.com'))
/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/email/utils.py
in formataddr(pair, charset)
89 name, address = pair
90 # The address MUST (per RFC) be ascii, so raise a UnicodeError if
it isn't.
---> 91 address.encode('ascii')
92 if name:
93 try:
UnicodeEncodeError: 'ascii' codec can't encode character '\xf1' in position 7:
ordinal not in range(128)
--
components: email
messages: 329765
nosy: barry, r.david.murray, skreft
priority: normal
severity: normal
status: open
title: email.utils.formataddr is not exactly the reverse of
email.utils.parseaddr
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue35222>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33991] lib2to3 should parse f-strings
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_input, [Node(simple_stmt, [Leaf(3, 'f"hello {"'), Leaf(4,
'\n')]), Leaf(0, '')])
In [4]: ast.parse('f"hello {"')
Traceback (most recent call last):
File
"/Users/skreft/.virtualenvs/pyfaster/lib/python3.6/site-packages/IPython/core/interactiveshell.py",
line 2963, in run_code
exec(code_obj, self.user_global_ns, self.user_ns)
File "", line 1, in
ast.parse('f"hello {"')
File
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ast.py", line
35, in parse
return compile(source, filename, mode, PyCF_ONLY_AST)
File "", line 1
SyntaxError: f-string: expecting '}'
--
___
Python tracker
<https://bugs.python.org/issue33991>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33991] lib2to3 should parse f-strings
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 well - it has certainly gained quite a bit of support for that". I added the versions 3.6-3.8 as previous ones are not able to parse f-strings. -- versions: +Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33991> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33991] lib2to3 should parse f-strings
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 would need to do something like: def string_nodes_are_eqivalent(node1, node2): if is_f_string(node1) and is_f_string(node2): # This would require to parse the nodes using ast.parse return f_strings_are_equivalent(node1, node2) if not is_f_string(node1) and not is_f_string(node2): return ast.literal_eval(node1.value) == ast.literal_eval(node2.value) return False Note that ast.literal_eval does not accept f-strings. Also note that ast.parse returns an ast.JoinedString for f-strings, whose elements are either ast.Str or ast.FormattedValue, the latter being ast expressions. On the other hand, this has the problem of not being able to refactor the expressions inside an f-string. -- messages: 320687 nosy: skreft priority: normal severity: normal status: open title: lib2to3 should parse f-strings ___ Python tracker <https://bugs.python.org/issue33991> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33159] Implement PEP 473
New submission from skreft <skr...@gmail.com>: Implement PEP 473. -- messages: 314546 nosy: skreft priority: normal severity: normal status: open title: Implement PEP 473 versions: Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33159> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13364] Duplicated Code
skreft skr...@gmail.com 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__, context)
def logical_and(self, other, context=None):
return self._logical_op(other, operator.__and__, context)
def _logical_op(self, other, operation, context=None):
Applies a logical operation between self and other's digits.
if context is None:
context = getcontext()
other = _convert_other(other, raiseit=True)
if not self._islogical() or not other._islogical():
return context._raise_error(InvalidOperation)
# fill to context.prec
(opa, opb) = self._fill_logical(context, self._int, other._int)
# make the operation, and clean starting zeroes
result = .join([str(operation(int(a), int(b))) for a,b in
zip(opa,opb)])
return _dec_from_triple(0, result.lstrip('0') or '0', 0)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13364
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13362] Many PEP 8 errors
New submission from skreft skr...@gmail.com: 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 addressed, since Python's source code should be the model for good Pythonic code. I would love to contribute on this topic. But since many files would be modified I don't know how to proceed. I see two things that could help to reduce the non compliance of the code. One is to have a website showing the non compliances of each file. And the one I like the most is to have a special test that checks the compliance of the code. The only problem is that it would rely on the external tool pep8 (http://pypi.python.org/pypi/pep8). Let me know what you think. Sebastian -- messages: 147197 nosy: skreft priority: normal severity: normal status: open title: Many PEP 8 errors versions: Python 2.7, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13362 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13363] Many usages of dict.keys(), dict.values(), dict.items() when the iter version could be used
New submission from skreft skr...@gmail.com: 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 version is used. Here is the summary: Non iter version Iter version Keys 160 21 Values 35 23 Items 249 79 I sued the following command $ egrep -R for.*[.]iterkeys\(\) . | wc -l What's the position about this? Does it worth it to fix this? -- messages: 147199 nosy: skreft priority: normal severity: normal status: open title: Many usages of dict.keys(), dict.values(), dict.items() when the iter version could be used versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13363 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13364] Duplicated Code
New submission from skreft skr...@gmail.com:
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):
Applies an 'or' operation between self and other's digits.
if context is None:
context = getcontext()
other = _convert_other(other, raiseit=True)
if not self._islogical() or not other._islogical():
return context._raise_error(InvalidOperation)
# fill to context.prec
(opa, opb) = self._fill_logical(context, self._int, other._int)
# make the operation, and clean starting zeroes
result = .join([str(int(a)|int(b)) for a,b in zip(opa,opb)])
return _dec_from_triple(0, result.lstrip('0') or '0', 0)
def logical_xor(self, other, context=None):
Applies an 'xor' operation between self and other's digits.
if context is None:
context = getcontext()
other = _convert_other(other, raiseit=True)
if not self._islogical() or not other._islogical():
return context._raise_error(InvalidOperation)
# fill to context.prec
(opa, opb) = self._fill_logical(context, self._int, other._int)
# make the operation, and clean starting zeroes
result = .join([str(int(a)^int(b)) for a,b in zip(opa,opb)])
return _dec_from_triple(0, result.lstrip('0') or '0', 0)
What's the posture about this? Should this be fixed?
ps: Even more duplicated code is found in python 2.7.
--
messages: 147201
nosy: skreft
priority: normal
severity: normal
status: open
title: Duplicated Code
versions: Python 2.7, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13364
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13362] Many PEP 8 errors
skreft skr...@gmail.com 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 developers who modify the code, could know that the source code does not follow the coding style and probably she/he could improve the code. This tool would also help newcomers to contribute better code. Unfortunately, by the decision of rejecting this issue without even answering the full issue, I conclude that the Python team is not willing to improve its own basecode. I repeat my posture, python source code should be a model of a python project, hence if there are tools that can ensure or improve the quality of the project, they should be incorporated to the development process. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13362 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
