[issue42109] Use hypothesis for testing the standard library, falling back to stubs
Change by Aaron Meurer : -- nosy: +asmeurer ___ Python tracker <https://bugs.python.org/issue42109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()
Aaron Meurer added the comment:
When talking about making exit only work when typed at the interpreter,
something to consider is the confusion that it can cause when there is a
mismatch between the interactive interpreter and noninteractive execution,
especially for novice users. I've seen beginner users add exit() to the bottom
of Python scripts, presumably because the interpreter "taught" them that you
have to end with that.
Now imagine someone trying to use exit as part of control flow
if input("exit now? ") == "yes":
exit
Unless exit is a full blown keyword, that won't work. And the result is yet
another instance in the language where users become confused if they run across
it, because it isn't actually consistent in the language model.
There are already pseudo-keywords in the language, in particular, super(), but
that's used to implement something which would be impossible otherwise. Exiting
is not impossible otherwise, it just requires typing (). But that's how
everything in the language works. I would argue it's a good thing to reinforce
the idea that typing a variable by itself with no other surrounding syntax does
nothing. This helps new users create the correct model of the language in their
heads.
--
nosy: +asmeurer
___
Python tracker
<https://bugs.python.org/issue44603>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16959] rlcompleter doesn't work if __main__ can't be imported
Aaron Meurer added the comment: A quick glance at the source shows that it still imports __main__ at the top-level. I have no idea how legitimate it is that the App Engine (used to?) makes it so that __main__ can't be imported. -- nosy: +asmeurer ___ Python tracker <https://bugs.python.org/issue16959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44455] compileall should exit nonzero for nonexistent directories
New submission from Aaron Meurer : $ ./python.exe -m compileall doesntexist Listing 'doesntexist'... Can't list 'doesntexist' $ echo $? 0 It's standard for a command line tool that processes files to exit nonzero when given a directory that doesn't exist. -- messages: 396087 nosy: asmeurer priority: normal severity: normal status: open title: compileall should exit nonzero for nonexistent directories ___ Python tracker <https://bugs.python.org/issue44455> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43420] Optimize rational arithmetics
Aaron Meurer added the comment: I'm surprised to hear that the "typical use-case" of Fraction is fractions converted from floats. Do you have evidence in the wild to support that? I would expect any application that uses fractions "generically" to run into the same sorts of problems SymPy does. The issue is that the sum or product of two unrelated fractions has a denominator that is ~ the product of the denominators of each term. So they tend to grow large, unless there is some structure in the terms that results in lots of cancellation. That's why real world numeric typically doesn't use exact arithmetic, but there are legitimate use-cases for it (computer algebra being one). This actually also applies even if the denominators are powers of 2. That's why arbitrary precision floating point numbers like Decimal or mpmath.mpf limit the precision, or effectively, the power of 2 in the denominator. By the way, the "algorithm" here really isn't that complicated. I didn't even realize it had a name. The idea is that for a/b * c/d, if a/b and c/d are already in lowest terms, then the only cancellation that can happen is from a/d or from c/b. So instead of computing gcd(a*c, b*d), we only compute gcd(a, d) and gcd(c, b) and cancel them off the corresponding terms. It turns out to be faster to take two gcds of smaller numbers than one gcd of big ones. The algorithm for addition is a bit more complicated, at least to see that it is correct, but is still not that bad (the paper linked in the OP explains it clearly in one paragraph). It's far less complicated than, for example, Lehmer's gcd algorithm (which is implemented in math.gcd). -- ___ Python tracker <https://bugs.python.org/issue43420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43420] Optimize rational arithmetics
Change by Aaron Meurer : -- nosy: +asmeurer ___ Python tracker <https://bugs.python.org/issue43420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39820] Bracketed paste mode for REPL: don't execute pasted command before ENTER is pressed explicitly
Aaron Meurer added the comment:
To reiterate some points I made in the closed issues
https://bugs.python.org/issue42819 and https://bugs.python.org/issue32019.
A simple "fix" would be to emulate the non-bracketed paste buffering. That is,
accept the input using bracketed paste, but split it line by line and send that
to the REPL. That would achieve some of the benefits of bracketed paste (faster
pasting), without having to change how the REPL works.
For actually allowing multiline input in the REPL, one issue I see is that the
so-called "single" compile mode is fundamentally designed around single line
evaluation. To support proper multiline evaluation, it would need to break from
this model (which in my opinion is over engineered).
In one of my personal projects, I use a function along the lines of
import ast
def eval_exec(code, g=None, l=None, *, filename="", noresult=None):
if g is None:
g = globals()
if l is None:
l = g
p = ast.parse(code)
expr = None
res = noresult
if p.body and isinstance(p.body[-1], ast.Expr):
expr = p.body.pop()
code = compile(p, filename, 'exec')
exec(code, g, l)
if expr:
code = compile(ast.Expression(expr.value), filename, 'eval')
res = eval(code, g, l)
return res
This function automatically execs the code, but if the last part of it is an
expression, it returns it (note that this is much more useful than simply
printing it). Otherwise it returns a noresult marker (None by default).
I think this sort of functionality in general would be useful in the standard
library (much more useful than compile('single')), but even ignoring whether it
should be a public function, this is the sort of thing that is needed for
"proper" multiline execution in a REPL. Terry mentioned that idle supports
multiline already. But I tried pasting
a = 1
a
into idle (Python 3.9), and I get the same "SyntaxError: multiple statements
found while compiling a single statement" error, suggesting it still has the
same fundamental limitation.
Also, if it wasn't clear, I should note that this is independent of pasting.
You can already write
def func():
return 1
func()
manually in the interpreter or IDLE and it will give a syntax error.
--
___
Python tracker
<https://bugs.python.org/issue39820>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42819] readline 8.1 enables the bracketed paste mode by default
Aaron Meurer added the comment: Instead of enabling it by default, why not just keep it but emulate the old behavior by splitting and buffering the input lines? That way you still get some of the benefits of bracketed paste, i.e., faster pasting, but without the hard work of fixing the REPL to actually support native multiline editing + execing multiline statements (the broken "simple" design). -- nosy: +asmeurer ___ Python tracker <https://bugs.python.org/issue42819> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21821] The function cygwinccompiler.is_cygwingcc leads to FileNotFoundError under Windows 7
Aaron Meurer added the comment: Is find_executable() going to be extracted from distutils to somewhere else? It's one of those functions that is useful outside of packaging, and indeed, I've seen it imported in quite a few codes that aren't related to packaging. If so, the patch I mentioned could still be relevant for it (if it hasn't been fixed already). -- nosy: +asmeurer ___ Python tracker <https://bugs.python.org/issue21821> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30384] traceback.TracebackException.format shouldn't format_exc_only() when __traceback__ is None
Aaron Meurer added the comment: Neither of those things preclude the possibility of the traceback module doing a better job of printing tracebacks for exceptions where __traceback__ = None. -- ___ Python tracker <https://bugs.python.org/issue30384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30384] traceback.TracebackException.format shouldn't format_exc_only() when __traceback__ is None
Aaron Meurer added the comment: I don't think it's helpful to make such a literalistic interpretation. Just because the variable is called "traceback" doesn't mean it should apply only to the things that are *technically* a traceback (and I don't agree anyway that the line containing the exception isn't part of the "traceback"). > I guess you're saying that the __context__ exception of the TypeError in your > example has an empty traceback, which means it was never raised Does it mean that? Again, __traceback__ isn't documented anywhere, so I don't know what it being None really means. All I know is that it apparently disables the printing of tracebacks in the traceback module, but fails to omit the exception line itself, leading to an unreadable traceback in my example. -- ___ Python tracker <https://bugs.python.org/issue30384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30384] traceback.TracebackException.format shouldn't format_exc_only() when __traceback__ is None
Aaron Meurer added the comment: I think I found another way to achieve what I was trying to do, which is why I never pursued this. But I still think it's a bug. __traceback__ = None isn't documented anywhere that I could find, so I was only able to deduce how it should work from reading the source code. If it is documented somewhere let me know. I admit my initial report is a bit unclear. If you play with the test.py you can see what is going on import traceback try: raise ValueError except Exception as e: e.__traceback__ = None try: raise TypeError except: traceback.print_exc() produces this output: ValueError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "test.py", line 8, in raise TypeError TypeError My goal is to completely hide the caught exception in the traceback printed from the traceback module. It seems odd that it hides everything except for the actual ValueError. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue30384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30384] traceback.TracebackException.format shouldn't format_exc_only() when __traceback__ is None
Aaron Meurer added the comment: > It's not entirely clear to me what you are trying to do (what is the output > you are hoping to get?) but this looks more like a question than a bug > report, so I am closing this issue. If this is still relevant, I'd suggest > you ask on the python users list or StackOverflow - you are more likely to > receive a prompt response there. If you don't understand an issue, the correct response isn't to close it because you don't understand it. If an issue is unclear, you should ask for clarification, not insult the person who opened it. What you described *is* the bug report. If you read even the title you would see that the report is that setting __traceback__ to None doesn't affect the printing of the exception. -- nosy: +asmeurer ___ Python tracker <https://bugs.python.org/issue30384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35212] Expressions with format specifiers in f-strings give wrong code position in AST
Aaron Meurer added the comment:
The same thing occurs with specifiers like {a!r}.
--
nosy: +asmeurer
___
Python tracker
<https://bugs.python.org/issue35212>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41506] Inclusion or documentation of extended with syntax in 3.9
New submission from Aaron Meurer :
This discussion started at https://github.com/python/cpython/pull/19503
(actually on Twitter https://twitter.com/asmeurer/status/1289304407696261120),
but Guido asked me to move it bpo.
Alongside the implementation of Python 3.9's new PEG parser, a new syntax
feature has been added, which is the ability to use parentheses in with
statements, like
with (open('a') as f1,
open('b') as f2):
...
This is an error in lower versions of Python (or an error about tuple not
having __enter__ if the "as" parts are omitted).
This new feature is not documented in the "What's new in Python 3.9" document
https://docs.python.org/3.9/whatsnew/3.9.html.
It also apparently goes against PEP 627
https://www.python.org/dev/peps/pep-0617/, which says (in bold), "no new Python
Grammar addition will be added that requires the PEG parser".
Note that this feature does indeed rely on the PEG parser, and it stops working
if you use python -X oldparser or PYTHONOLDPARSER=1.
I think this feature should either
1. be removed from 3.9 and held until 3.10, or
2. be documented properly, including in the document for the "with" statement
and the "what's new" document. Also the PEP should be updated if this option is
chosen.
Others have stated opinions about this on the issue or on Twitter, but I'll let
them repeat them here rather than trying to summarize.
--
messages: 375029
nosy: asmeurer
priority: normal
pull_requests: 20921
severity: normal
status: open
title: Inclusion or documentation of extended with syntax in 3.9
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue41506>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39820] Bracketed paste mode for REPL
Aaron Meurer added the comment: Related issue https://bugs.python.org/issue32019 -- nosy: +asmeurer ___ Python tracker <https://bugs.python.org/issue39820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39854] f-strings with format specifiers have wrong col_offset
New submission from Aaron Meurer :
This is tested in CPython master. The issue also occurs in older versions of
Python.
>>> ast.dump(ast.parse('f"{x}"'))
"Module(body=[Expr(value=JoinedStr(values=[FormattedValue(value=Name(id='x',
ctx=Load()), conversion=-1, format_spec=None)]))], type_ignores=[])"
>>> ast.dump(ast.parse('f"{x!r}"'))
"Module(body=[Expr(value=JoinedStr(values=[FormattedValue(value=Name(id='x',
ctx=Load()), conversion=114, format_spec=None)]))], type_ignores=[])"
>>> ast.parse('f"{x}"').body[0].value.values[0].value.col_offset
3
>>> ast.parse('f"{x!r}"').body[0].value.values[0].value.col_offset
1
The col_offset for the variable x should be 3 in both instances.
--
messages: 363375
nosy: asmeurer
priority: normal
severity: normal
status: open
title: f-strings with format specifiers have wrong col_offset
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue39854>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32912] Raise non-silent warning for invalid escape sequences
Aaron Meurer added the comment: Are there issues tracking the things I mentioned, which should IMO happen before this becomes a hard error (making the warnings reproduce even if the file has already been compiled, and making warning message point to the correct line in multiline strings)? And is it too late to potentially get some of those things in 3.8? -- ___ Python tracker <https://bugs.python.org/issue32912> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37433] syntax error in multiline f-string produces ~40k spaces output
Aaron Meurer added the comment:
This seems related. It's also possible I'm misunderstanding what is supposed to
happen here.
If you create test.py with just the 2 lines:
"""
a
and run python test.py from CPython master, you get
$./python.exe test.py
File "/Users/aaronmeurer/Documents/cpython/test.py", line 4
a
^
SyntaxError: EOF while scanning triple-quoted string literal
Notice that it reports line 4 even though the file only has 2 lines.
The offset in the syntax error is 6 columns (line numbers and column offsets
in SyntaxErrors count from 1)
>>> try:
... compile('"""\na', '', 'exec')
... except SyntaxError as e:
... print(repr(e))
...
SyntaxError('EOF while scanning triple-quoted string literal', ('', 2, 6,
'"""\na\n'))
--
___
Python tracker
<https://bugs.python.org/issue37433>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32912] Raise non-silent warning for invalid escape sequences
Aaron Meurer added the comment: Well paradoxically, the bugs that this prevents are the ones it doesn't warn about. If someone writes '\tan(x)' thinking it is a string representing a LaTeX formula for the tangent of x, they won't realize that they actually created a string with a tab plus "an(x)". So actually I would argue that the end goal *is* to make people aware of which escape characters exist, or at the very least, always make strings raw if there's even the remotest chance they will contain a backslash character. Is it the best way to go about this? I don't know. The whole thing sort of makes me think raw strings should have been the default, but it's obviously too late to change that. I personally don't feel strongly about the warnings being enabled by default or not. My big gripe is that if you actually want the warnings they are difficult to get in a reproducible way. I'm actually surprised they are so annoying for you. Once a py file is compiled into a pyc file the warnings completely disappear, even if you want them! The fact that you can't use a real escape sequence in a raw string is annoying but not the end of the world given that it's trivial to concatenate strings. -- ___ Python tracker <https://bugs.python.org/issue32912> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32912] Raise non-silent warning for invalid escape sequences
Aaron Meurer added the comment: Raymond, are you in agreement that these warnings should at some point eventually become syntax errors? -- ___ Python tracker <https://bugs.python.org/issue32912> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37433] syntax error in f-string in multiline string produces ~40k spaces of output
Aaron Meurer added the comment: This looks like the same issue I mentioned here https://bugs.python.org/msg344764 -- nosy: +asmeurer ___ Python tracker <https://bugs.python.org/issue37433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32912] Raise non-silent warning for invalid escape sequences
Aaron Meurer added the comment: I agree. Please someone else do that. I don't know what already has issues and I unfortunately don't have time right now to help out with any of this. I simply mentioned all these things as arguments why Python should not (yet) make these warnings errors, which is the point of this issue. Also, for the pyparsing example, you would have gotten lucky because it also contained \w, which is not a valid escape. If it didn't, you wouldn't be warned. So clearly this will help things, but it will also be good to have linting tools that, for example, warn about any escape sequences inside docstrings. -- ___ Python tracker <https://bugs.python.org/issue32912> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32912] Raise non-silent warning for invalid escape sequences
Aaron Meurer added the comment: I agree with Raymond that third party libraries are not ready for this. My biggest issue is that the way Python warns about this makes it very difficult for library authors to fix this. Most won't even notice. The problem is the warnings are only shown once, when the file is compiled. So if you run the code in any way that causes Python to compile it, a further run of 'python -Wd' will show nothing. I don't know if it's reasonable, but it would be nice if Python recompiled when given -Wd, or somehow saved the warning so it could be shown if that flag is given later. As an anecdote, for SymPy's CI, we went through five (if I am counting correctly) iterations of trying to test this. Each of the first four were subtly incorrect, until we finally managed to find the correct one (for reference, 'python -We:invalid -m compileall -f -q module/'). So most library authors who will attempt to add tests against this will get it wrong. Simply adding -Wd as you would expect is wrong. If the code is already compiled (which it probably is, e.g., if you ran setup.py), it won't show the warnings. At the very least the "correct" way to test this should be documented. Things would probably be improved if the warnings were always shown, as at least then devs will see the error once (although most will probably be confused when the warning doesn't repeat). Another problem is the information in the warnings. It seems the line number of the string is now shown, which is an improvement (https://bugs.python.org/issue28128). It would be nice if it showed the actual line and column number in the file of the invalid escape. This is especially annoying when an escape appears in a docstring. It just shows """ as the offending line. We have a lot of LaTeX in our docstrings in SymPy, so we had quite a few of these to fix. SymPy doesn't have invalid escapes anymore because I was proactive about it, but from what I've seen, most library authors haven't been. By the way, this looks like a bug (python 3.8b1): $ cat test.py """ a \p """
[issue36370] "Fatal Python error: Cannot recover from stack overflow" from SymPy tests
New submission from Aaron Meurer :
I am getting a Fatal Python error: Cannot recover from stack overflow. running
the SymPy tests on a branch of mine where the tests fail. I have reproduced
this in Python 3.6.7, as well as CPython master
(fc96e5474a7bda1c5dec66420e4467fc9f7ca968).
Here are the repro steps:
1. Check out my git branch https://github.com/asmeurer/sympy/tree/python-crash
2. Install or point PYTHONPATH to mpmath
3. Run python and type
from sympy import test
test('sets', subprocess=False)
The tests will run (with failures) until they reach a point where Python
crashes with
Fatal Python error: Cannot recover from stack overflow.
Current thread 0x7fffa8e623c0 (most recent call first):
File
"/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/core/relational.py",
line 385 in __new__
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1594 in _contains
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 286 in contains
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1257 in
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/core/logic.py",
line 139 in fuzzy_and
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1257 in _handle_finite_sets
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1900 in simplify_intersection
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1200 in __new__
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 109 in intersect
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 309 in is_subset
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1348 in reduce
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1338 in __new__
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 551 in __sub__
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1269 in _handle_finite_sets
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1900 in simplify_intersection
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1200 in __new__
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 109 in intersect
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 309 in is_subset
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1348 in reduce
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1338 in __new__
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 551 in __sub__
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1269 in _handle_finite_sets
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1900 in simplify_intersection
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1200 in __new__
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 109 in intersect
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 309 in is_subset
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1348 in reduce
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1338 in __new__
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 551 in __sub__
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1269 in _handle_finite_sets
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1900 in simplify_intersection
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1200 in __new__
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 109 in intersect
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 309 in is_subset
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1348 in reduce
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1338 in __new__
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 551 in __sub__
File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py",
line 1269 in _handle_finite_sets
File "/
[issue16482] pdb.set_trace() clobbering traceback on error
Aaron Meurer added the comment: You can download the branch for a pull request even if the repo is deleted using this https://stackoverflow.com/a/28622034/161801. That will let you keep the original commits intact. -- nosy: +asmeurer ___ Python tracker <https://bugs.python.org/issue16482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33899] Tokenize module does not mirror "end-of-input" is newline behavior
Aaron Meurer added the comment: Is it expected behavior that comments produce NEWLINE if they don't have a newline and don't produce NEWLINE if they do (that is, '# comment' produces NEWLINE but '# comment\n' does not)? -- nosy: +asmeurer ___ Python tracker <https://bugs.python.org/issue33899> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14102] argparse: add ability to create a man page
Aaron Meurer added the comment: I see. I haven't dug much into the argoarse source, so I don't have a good feel for how feasible such a tool would be to write. Such refactoring would also be useful for generating HTML or RST for the help. I've previously used help2man and man2html to generate html help, but both tools are very limited in what they can do. -- ___ Python tracker <https://bugs.python.org/issue14102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14102] argparse: add ability to create a man page
Aaron Meurer added the comment: Couldn't such a tool exist outside the standard library. I'm thinking a function that you would import and wrap the parser object, similar to how argcomplete works (https://argcomplete.readthedocs.io/en/latest/index.html). The downside is that developers would have to opt-in for it to work (much like they currently have to opt-in to bash completion with things like argcomplete). But it would allow much more flexibility being outside the standard library. I completely agree that it should be done in Python either way. help2man is very limited in its flexibility (it doesn't help that it's written in Perl), and there are fundamental limits to what you can do from parsing the --help output, vs. just generating correct troff from the source. Installing the manpage is a separate concern. That would need to go in setuptools or distutils, if anywhere. But before you can worry about how to install it you need to be able to generate it in the first place. -- nosy: +asmeurer ___ Python tracker <https://bugs.python.org/issue14102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24622] tokenize.py: missing EXACT_TOKEN_TYPES
Aaron Meurer added the comment: I would suggest adding this to the what's new document https://docs.python.org/3.7/whatsnew/3.7.html. The change affects user-facing code (the exact_type attribute of TokenInfo is OP for ... and -> tokens prior to this patch). I would also point out that this directly contradicts the documentation (from https://docs.python.org/3/library/tokenize.html, "To simplify token stream handling, all operator and delimiter tokens and Ellipsis are returned using the generic OP token type. The exact type can be determined by checking the exact_type property on the named tuple returned from tokenize.tokenize()."), so I don't see why it can't be backported. -- nosy: +Aaron.Meurer ___ Python tracker <https://bugs.python.org/issue24622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32300] print(os.environ.keys()) should only print the keys
Aaron Meurer <asmeu...@gmail.com> added the comment: Can't third party code write their own proxies? Why do we have to do that? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32300] print(os.environ.keys()) should only print the keys
Aaron Meurer <asmeu...@gmail.com> added the comment: Serhiy, isn't option 4? 4. Make KeysView.__repr__ show list(self). Add a custom wrapper for Shelf's KeysView so that it doesn't do this. This seems to be what Victor is suggesting. It makes the most sense to me for the common (i.e., default) case to be to show the keys (and just the keys), and for use cases that want otherwise to subclass and modify. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32313] Wrong inspect.getsource for datetime
New submission from Aaron Meurer <asmeu...@gmail.com>: inspect.getsource(datetime) shows the Python source code for datetime, even when it is the C extension. This is very confusing. I believe it's because _datetime is used to override everything in datetime at the end of the file (here https://github.com/python/cpython/blob/11a247df88f15b51feff8a3c46005676bb29b96e/Lib/datetime.py#L2285), but __file__ is not imported. -- messages: 308255 nosy: Aaron.Meurer priority: normal severity: normal status: open title: Wrong inspect.getsource for datetime ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32313> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32300] print(os.environ.keys()) should only print the keys
Aaron Meurer <asmeu...@gmail.com> added the comment: So the best fix is to just override keys() in the _Environ class, so that it returns an EnvironKeysView class that overrides __repr__? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32300] print(os.environ.keys()) should only print the keys
New submission from Aaron Meurer <asmeu...@gmail.com>:
Take the following scenario which happened to me recently. I am trying to debug
an issue on Travis CI involving environment variables. Basically, I am not sure
if an environment variable is being set correctly. So in my code, I put
print(os.environ.keys())
The reason I put keys() was 1, I didn't care about the values, and 2, I have
secure environment variables set on Travis.
To my surprise, in the Travis logs, I found something like this
KeysView(environ({'TRAVIS_STACK_FEATURES': 'basic cassandra chromium couchdb
disabled-ipv6 docker docker-compose elasticsearch firefox go-toolchain
google-chrome jdk memcached mongodb mysql neo4j nodejs_interpreter
perl_interpreter perlbrew phantomjs postgresql python_interpreter rabbitmq
redis riak ruby_interpreter sqlite xserver', 'CI': 'true', ..., 'MANPATH':
'/home/travis/.nvm/versions/node/v7.4.0/share/man:/home/travis/.kiex/elixirs/elixir-1.4.5/man:/home/travis/.rvm/rubies/ruby-2.4.1/share/man:/usr/local/man:/usr/local/clang-3.9.0/share/man:/usr/local/share/man:/usr/share/man:/home/travis/.rvm/man'}))
So instead of just printing the keys like I asked for, it printed the whole
environment, plus "KeysView(environ(". Included here was my secure environment
variable.
Now, fortunately, Travis hides the contents of secure environment variables in
the logs, but it didn't used to
(https://blog.travis-ci.com/2017-05-08-security-advisory).
Aside from being a potential security issue, it's just annoying that it prints
the whole environment. The values are much larger than the keys. With a normal
dictionary, print(d.keys()) just prints the keys:
>>> print(dict(a=1, b=2).keys())
dict_keys(['a', 'b'])
--
messages: 308190
nosy: Aaron.Meurer
priority: normal
severity: normal
status: open
title: print(os.environ.keys()) should only print the keys
versions: Python 3.7
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32300>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24294] DeprecationWarnings should be visible by default in the interactive REPL
Aaron Meurer <asmeu...@gmail.com> added the comment: If it's of any interest to this discussion, for SymPy (for some time) we have used a custom subclass of DeprecationWarning that we enable by default https://github.com/sympy/sympy/blob/master/sympy/utilities/exceptions.py. I don't know if there are major libraries that do something similar. Our reasoning is that we really do want everybody to see the warnings. Obviously direct users of SymPy (both interactive users and library developers) need to see them so they can fix their code. But also if library X uses a deprecated behavior and a user of library X sees a deprecation warning for SymPy inside of library X, that incentivises them to bug the library X developers to fix the behavior (or PR it). The whole point of warnings as we see it is to be as loud as possible while still keeping things working, to avoid the situation where things stop working (when the deprecated behavior is removed). And + to Nathaniel's point that DeprecationWarnings are about more than just the standard library. Tons of libraries use the built in warnings, and the default warnings behavior makes no distinction between warnings coming from the standard library and warnings coming from other places. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue24294> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32019] Interactive shell doesn't work with readline bracketed paste
New submission from Aaron Meurer <asmeu...@gmail.com>:
Here are the steps to reproduce this:
- Compile and link Python against readline version 7.0 or higher.
- Add
set enable-bracketed-paste on
to your ~/.inputrc
- Start python and paste the following two lines. Make sure to use a terminal
emulator that supports bracketed paste (most modern ones do). You'll need to
type enter after pasting the lines.
a = 1
a
You get something like
>>> a = 1
a
File "", line 1
a
^
SyntaxError: multiple statements found while compiling a single statement
It does work, however, if you paste something that has a newline but is a
single statement, like
(1,
2)
Fixing this in the right way might not be so easy, due to the way that
compile('single') is over-engineered. A simple fix would be to disable
bracketed paste in the Python shell.
I tested this with Python 3.6.3. I was not able to get the git master to
compile, so I couldn't test it there.
--
messages: 306176
nosy: Aaron.Meurer
priority: normal
severity: normal
status: open
title: Interactive shell doesn't work with readline bracketed paste
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32019>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31684] Scientific formatting of decimal 0 different from float 0
Aaron Meurer <asmeu...@gmail.com> added the comment:
I meant that format() destroys information in a decimal in general. Obviously
if you have n digits of precision and format with m < n, then you lose
information.
I also can't help but feel that we're mixing up "trailing zeros" (i.e.,
precision), and "exponent" (magnitude), which should be orthogonal. I'm
assuming that a decimal is represented internally as base*10**exponent. I'm
also assuming that Decimal(0) sets both base and exponent to 0. It doesn't make
sense to me that a string formatting operation that requests a certain number
of digits of precision should change the exponent.
I get that 0.0 is different from 0.0, but in that case, they should print
differently: as '0.0' and '0.0'. It seems sly to try to maintain that
through a format operation via the exponent, especially when format *in
general* loses precision information for a decimal anyway (by "format" I mean
format with a set number of digits requested). Especially since that "trick"
only works for exactly one number, zero. If you do
'{:+.30e}'.format(Decimal('1.000')) or
'{:+.10e}'.format(Decimal('1.000')), no such trick is used,
because no such trick can be used. You just lose information.
I'm sure my mental model is off here. I'm used to sympy.Float/mpmath.mpf where
values like 0*2**i are normalized to i = 0 (e.g. mpmath.mpf((0, 0, 20,
0))._mpf_ gives (0, 0, 0, 0)), so this problem never comes up in the code that
I'm used to.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31684>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31684] Scientific formatting of decimal 0 different from float 0
Aaron Meurer <asmeu...@gmail.com> added the comment: I guess I would expect that to be captured by the number of zeros printed (and obviously doing a string format operation with a set number of digits destroys that information). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31684] Scientific formatting of decimal 0 different from float 0
New submission from Aaron Meurer <asmeu...@gmail.com>:
>>> '{:+.19e}'.format(0.)
'+0.000e+00'
>>> import decimal
>>> '{:+.19e}'.format(decimal.Decimal(0))
'+0.000e+19'
Note the decimal uses e+19 instead of e+00. Obviously it's still mathematically
correct, but it's annoying to have anything other than e+00 for a 0 value.
--
messages: 303653
nosy: Aaron.Meurer
priority: normal
severity: normal
status: open
title: Scientific formatting of decimal 0 different from float 0
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31684>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30384] traceback.TracebackException.format shouldn't format_exc_only() when __traceback__ is None
New submission from Aaron Meurer: I'm trying to completely hide an exception from the traceback module. From reading the source, it looks like the only way to do this is to set __traceback__ to None (I can also set __suppress_context__ to True, but that only works if I have another exception higher up in the context chain). However, this still prints the traceback itself, and the line for SyntaxErrors. Consider the attached test.py. It outputs ValueError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "test.py", line 8, in raise TypeError TypeError File "", line 1 a b ^ SyntaxError: unexpected EOF while parsing During handling of the above exception, another exception occurred: Traceback (most recent call last): File "test.py", line 19, in raise TypeError TypeError I suppose it should also not print the "During handling of the above exception, another exception occurred:" part. -- components: Library (Lib) files: test.py messages: 293837 nosy: Aaron.Meurer priority: normal severity: normal status: open title: traceback.TracebackException.format shouldn't format_exc_only() when __traceback__ is None Added file: http://bugs.python.org/file46867/test.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6028] Interpreter aborts when chaining an infinite number of exceptions
Changes by Aaron Meurer <asmeu...@gmail.com>: -- nosy: +Aaron.Meurer ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12345] Add math.tau
Aaron Meurer added the comment: Emanuel Barry, that is both untrue and irrelevant (sorry to be blunt, but that's a total straw man on my and I believe other's argument). The fact that the only mathematical constants in math are pi and e (nan and inf aren't really "mathematical" constants) *does* indicate to me that only the really important ones are included. GvR, are you also in favor of adding more math constants/functions to the math module? I do see the value of Easter eggs in the language, but two real constants and one Easter egg constant seems weirder than ten real constants and one Easter egg constant. I'm +1/(2*pi) (because I still think tau in general is stupid) to add it if it also means the math module can be expanded. And before you ask, yes, I'll be happy to contribute once things move to GitHub. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12345] Add math.tau
Aaron Meurer added the comment: I also wonder, if math will be gaining constants that no one uses like tau, if it will also gain constants that people actually do use (currently math just has pi, e, inf, and nan). [i for i in dir(numpy) if isinstance(getattr(numpy, i), float)] reveals euler_gamma as one example. https://docs.scipy.org/doc/scipy/reference/constants.html lists a bunch more. And if we're adding derived constants, why not loge2, another derived constants, used way more often than tau? In case you can't tell, I'm opposed to adding tau, although fwiw I do think it would be nice to add some of the other constants I mentioned above like euler_gamma to math, and in general, I support adding more stuff to math (but only generally useful stuff, obviously; there's no need to port all of scipy.special, for instance). As an aside, a technical note on the patch: for consistency, it should also be added to the cmath library (pardon me if I misread the patch and that's already happening). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12345] Add math.tau
Aaron Meurer added the comment: If this is implemented, it would be (as far as I can tell) the only thing in the math module that isn't also implemented in any of the standard external math libraries. None of numpy, scipy, sympy, or mpmath implement tau (if I'm missing one that others think is equally important to the ecosystem, let me know). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12345] Add math.tau
Changes by Aaron Meurer <asmeu...@gmail.com>: -- nosy: +Aaron.Meurer ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24294] DeprecationWarnings should be visible by default in the interactive REPL
Changes by Aaron Meurer <asmeu...@gmail.com>: -- nosy: +Aaron.Meurer ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24294> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25453] Arithmetics with complex infinities is inconsistent with C/C++
Changes by Aaron Meurer <asmeu...@gmail.com>: -- nosy: +Aaron.Meurer ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22515] Implement partial order on Counter
Aaron Meurer added the comment:
I can't believe this issue was closed. Why can't Counter.__lt__(self, other)
just be all(self[i] < other[i] for i in self)?
Just because Counter supports weird stuff shouldn't bill it out. To follow that
logic, we should also remove Counter.subtract
>>> Counter(a='b') - Counter(a='c')
Traceback (most recent call last):
File "", line 1, in
Counter(a='b') - Counter(a='c')
File "/Users/aaronmeurer/anaconda/lib/python3.5/collections/__init__.py",
line 709, in __sub__
newcount = count - other[elem]
TypeError: unsupported operand type(s) for -: 'str' and 'str'
It's super annoying that Counter supports all the basic set operations *except*
subset. A reminder that this *does* work:
>>> Counter(a=2) | Counter(a=1)
Counter({'a': 2})
And also fails on weird values:
>>> Counter(a='b') | Counter(a='c')
Traceback (most recent call last):
File "", line 1, in
Counter(a='b') | Counter(a='c')
File "/Users/aaronmeurer/anaconda/lib/python3.5/collections/__init__.py",
line 730, in __or__
if newcount > 0:
TypeError: unorderable types: str() > int()
--
nosy: +Aaron.Meurer
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22515>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25295] functools.lru_cache raises KeyError
Aaron Meurer added the comment: Does this mean that some SymPy object is giving different hash values on successive calls to hash()? We definitely need to look into this on the SymPy side. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25117] Windows installer: precompiling stdlib fails with missing DLL errors
Changes by Aaron Meurer <asmeu...@gmail.com>: -- nosy: +Aaron.Meurer ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19918] PureWindowsPath.relative_to() is not case insensitive
Changes by Aaron Meurer aaron.meu...@continuum.io: -- nosy: +Aaron Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19918 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24418] make install will not install pip if already present in user site-packages
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24418 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17697] Incorrect stacktrace from pdb
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17697 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16482] pdb.set_trace() clobbering traceback on error
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16482 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18199] Windows: support path longer than 260 bytes using \\?\ prefix
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18199 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23476] SSL cert verify fail for www.verisign.com
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23476 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14102] argparse: add ability to create a man page
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14102 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14537] Fatal Python error: Cannot recover from stack overflow. with SymPy test suite
Aaron Meurer added the comment: The OP describes how to get the original code. Anyway, the issue was definitely fixed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14537 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14537] Fatal Python error: Cannot recover from stack overflow. with SymPy test suite
Aaron Meurer added the comment: Or do you mean the code in CPython doesn't exist any more? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14537 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21821] The function cygwinccompiler.is_cygwingcc leads to FileNotFoundError under Windows 7
Aaron Meurer added the comment: The issue is that that the Anaconda gcc on Windows is a bat file, so it can't find it. Another fix would be to use find_executable. This is because Anaconda has patched find_executalbe (which it also would be good to get backported) diff --git Lib/distutils/spawn.py Lib/distutils/spawn.py index b1c5a44..4703f00 100644 --- Lib/distutils/spawn.py +++ Lib/distutils/spawn.py @@ -156,17 +156,16 @@ def find_executable(executable, path=None): path = os.environ['PATH'] paths = path.split(os.pathsep) -base, ext = os.path.splitext(executable) - -if (sys.platform == 'win32') and (ext != '.exe'): -executable = executable + '.exe' - -if not os.path.isfile(executable): -for p in paths: -f = os.path.join(p, executable) -if os.path.isfile(f): -# the file exists, we have a shot at spawn working -return f -return None -else: -return executable + +for ext in '.exe', '.bat', '': +newexe = executable + ext + +if os.path.isfile(newexe): +return newexe +else: +for p in paths: +f = os.path.join(p, newexe) +if os.path.isfile(f): +# the file exists, we have a shot at spawn working +return f +return None -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21821 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22200] Remove distutils checks for Python version
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22200 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14373] C implementation of functools.lru_cache
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14373 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21821] The function cygwinccompiler.is_cygwingcc leads to FileNotFoundError under Windows 7
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21821 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20010] time.strftime('%z') didn't make +HHMM return in windows xp
Aaron Meurer added the comment: Nowhere at https://docs.python.org/3.5/library/time.html#time.strftime is it indicated that %z behaves differently on different platforms. What it *does* say is %z Time zone offset indicating a positive or negative time difference from UTC/GMT of the form +HHMM or -HHMM, where H represents decimal hour digits and M represents decimal minute digits [-23:59, +23:59]. I see now that this is mentioned in the footnote at the bottom of the page. I would split that footnote into two notes. It's really about two things, %Z/%z compatibility, and the RFC. The RFC note should stay as it is in the footnote, but I would move the bits about %Z/%z compatibility much close to their entries in the table, as that is where people are going to look (I personally wouldn't even hide the information in a footnote, but that can be debated). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20010 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20010] time.strftime('%z') didn't make +HHMM return in windows xp
Aaron Meurer added the comment: I also just noticed that the %z entry in the table wasn't added until the Python 3.3 docs, although it apparently works at least in OS X in Python 2.7 (I can't test Windows right now). Was it supposed to be one of the additional directives supported on certain platforms? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20010 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20010] time.strftime('%z') didn't make +HHMM return in windows xp
Aaron Meurer added the comment: The docs could be much more clear about this in my opinion. -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20010 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20970] contradictory documentation for prog option of argparse
New submission from Aaron Meurer: I hope it's OK to report documentation issues on this tracker. Reading http://docs.python.org/3.4/library/argparse.html#prog I had to do a double take. The documentation states, By default, ArgumentParser objects uses sys.argv[0] to determine how to display the name of the program in help messages. The example then goes on to show it *not* using sys.argv[0] (sys.argv[0] in the second example would be 'subdir\myprogram.py'). Furthermore, even though the commands are apparently POSIX style, with a $ prompt and using cd, they use a backslash to access a subdirectory. -- assignee: docs@python components: Documentation messages: 213988 nosy: Aaron.Meurer, docs@python priority: normal severity: normal status: open title: contradictory documentation for prog option of argparse ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20970] contradictory documentation for prog option of argparse
Aaron Meurer added the comment: The next sentence further confuses things, This default is almost always desirable because it will make the help messages match how the program was invoked on the command line. It makes it sound like it really did intend to use sys.argv[0] literally. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12944] Accept arbitrary files for packaging's upload command
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12944 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13340] list.index does not accept None as start or stop
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13340 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18005] faster modular exponentiation in some cases
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18005 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17413] format_exception() breaks on exception tuples from trace function
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17413 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16959] rlcompleter doesn't work if __main__ can't be imported
New submission from Aaron Meurer: The rlcompleter module does not work if __main__ cannot be imported, even though it can be used without it. For example, on the App Engine, __main__ is not usable. If one creates the example app described at https://developers.google.com/appengine/docs/python/gettingstartedpython27/helloworld, and adds import rlcompleter to the top of helloworld.py, you get the following error in the AppEngine Traceback (most recent call last): File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/runtime/wsgi.py, line 196, in Handle handler = _config_handle.add_wsgi_middleware(self._LoadHandler()) File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/runtime/wsgi.py, line 255, in _LoadHandler handler = __import__(path[0]) File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py, line 692, in Decorate return func(self, *args, **kwargs) File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py, line 1766, in load_module return self.FindAndLoadModule(submodule, fullname, search_path) File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py, line 692, in Decorate return func(self, *args, **kwargs) File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py, line 1630, in FindAndLoadModule description) File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py, line 692, in Decorate return func(self, *args, **kwargs) File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py, line 1577, in LoadModuleRestricted description) File /Users/aaronmeurer/Desktop/helloworld/helloworld.py, line 2, in module import rlcompleter File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py, line 692, in Decorate return func(self, *args, **kwargs) File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py, line 1766, in load_module return self.FindAndLoadModule(submodule, fullname, search_path) File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py, line 692, in Decorate return func(self, *args, **kwargs) File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py, line 1630, in FindAndLoadModule description) File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py, line 692, in Decorate return func(self, *args, **kwargs) File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py, line 1577, in LoadModuleRestricted description) File /sw/lib/python2.7/rlcompleter.py, line 43, in module import __main__ File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py, line 692, in Decorate return func(self, *args, **kwargs) File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py, line 1766, in load_module return self.FindAndLoadModule(submodule, fullname, search_path) File /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py, line 692, in Decorate return func(self, *args, **kwargs) File /Applications
[issue16959] rlcompleter doesn't work if __main__ can't be imported
Aaron Meurer added the comment: For completion, here's the corresponding App Engine issue I opened: http://code.google.com/p/googleappengine/issues/detail?id=8665. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14938] 'import my_pkg.__init__' creates duplicate modules
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14938 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14537] Fatal Python error: Cannot recover from stack overflow. with SymPy test suite
New submission from Aaron Meurer asmeu...@gmail.com: Recently, after a small seemingly unrelated refactoring, the SymPy test suite in Python 3 started dying with Fatal Python error: Cannot recover from stack overflow. Here's how to reproduce the error git clone git://github.com/sympy/sympy.git # Clone the development version of SymPy cd sympy git checkout 0856119bd7399a416c21e1692855a1077164f21c # This is the first commit to exhibit the problem. Do this in case we make an unrelated change that removes the problem. ./bin/use2to3 # Convert the codebase to Python 3 python3 py3k-sympy/setup.py test # Run the tests The issue is described in more detail at http://groups.google.com/group/sympy/browse_thread/thread/f664fe88e6b4f29d/3a44691c945695db#3a44691c945695db. Some key points: - The test that triggers the error is an XFAIL test (test that is expected to fail) that raises RuntimeError: maximum recursion depth exceeded. - The change that caused the error, 0856119bd7399a416c21e1692855a1077164f21c (see https://github.com/sympy/sympy/commit/0856119bd7399a416c21e1692855a1077164f21c), is seemingly unrelated. The only thing that I can think of is that it has added another call to the stack. - This kills Python with Abort Trap: 6 in Mac OS X, which generates a problem report to be sent to Apple. I have included a copy of it here: https://gist.github.com/2317869. - Others have reproduced this error as well, as can be seen by our test reporter tool. See the mailing list thread for more info. - I tested this in 3.2.3r2, and the error still occurred. I tried testing in the 3.3 alpha, but I could not get it to compile. -- messages: 157876 nosy: Aaron.Meurer priority: normal severity: normal status: open title: Fatal Python error: Cannot recover from stack overflow. with SymPy test suite type: crash versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14537 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14537] Fatal Python error: Cannot recover from stack overflow. with SymPy test suite
Aaron Meurer asmeu...@gmail.com added the comment: We do have a stack overflow, but this should be raising a RuntimeError, not killing Python. The way it is now, Python dies completely with abort trap 6 (hence the Mac OS X problem report). Sorry if I didn't make this clear in the OP. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14537 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14537] Fatal Python error: Cannot recover from stack overflow. with SymPy test suite
Aaron Meurer asmeu...@gmail.com added the comment: No it does not. SymPy is a pure Python library. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14537 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13332] execfile fixer produces code that does not close the file
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13332 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12942] Shebang line fixer for 2to3
New submission from Aaron Meurer asmeu...@gmail.com: As suggested in this thread in the Python porting list (http://mail.python.org/pipermail/python-porting/2011-September/000231.html), it would be nice if 2to3 had a fixer that translated shebang lines from #! /usr/bin/env python to #! /usr/bin/env python3 Also relevant here is the draft PEP 394 (http://www.python.org/dev/peps/pep-0394/), which apparently is likely to be accepted. -- components: 2to3 (2.x to 3.0 conversion tool) messages: 143749 nosy: Aaron.Meurer priority: normal severity: normal status: open title: Shebang line fixer for 2to3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12611] 2to3 crashes when converting doctest using reduce()
Aaron Meurer asmeu...@gmail.com added the comment: Vladimir will need to confirm how to reproduce this exactly, but here is corresponding SymPy issue: http://code.google.com/p/sympy/issues/detail?id=2605. The problem is with the sympy/ntheory/factor_.py file at https://github.com/sympy/sympy/blob/sympy-0.7.1.rc1/sympy/ntheory/factor_.py#L453 (linking to the file from our release candidate, as a workaround is likely to be pushed to master soon). Vladimir, can you confirm that this particular version of the file reproduces the problem? -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12611] 2to3 crashes when converting doctest using reduce()
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12613] itertools fixer fails
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12613 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12616] zip fixer fails on zip()[:-1]
Changes by Aaron Meurer asmeu...@gmail.com: -- nosy: +Aaron.Meurer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12616 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7972] Have sequence multiplication call int() or return NotImplemented so that it can be overridden with __rmul__
New submission from Aaron Meurer asmeu...@gmail.com:
This works in Python 2.5 but not in Python 2.6.
If you do [0]*5, it gives you [0, 0, 0, 0, 0]. I tried getting this to work
with SymPy's Integer class, so that [0]*Integer(5) would return the same, but
unfortunately, the sequence multiplication doesn't seem to return
NotImplemented properly allowing it to be overridden in __rmul__. Overridding
in regular __mul__ of course works fine. From sympy/core/basic.py (modified):
# This works fine
@_sympifyit('other', NotImplemented)
def __mul__(self, other):
if type(other) in (tuple, list) and self.is_Integer:
return int(self)*other
return Mul(self, other)
# This has no affect.
@_sympifyit('other', NotImplemented)
def __rmul__(self, other):
if type(other) in (tuple, list, str) and self.is_Integer:
return other*int(self)
return Mul(other, self)
In other words, with the above, Integer(5)*[0] works, but [0]*Integer(5) raises
TypeError: can't multiply sequence by non-int of type 'Integer' just as it does
without any changes. See also my branch at github with these changes
http://github.com/asmeurer/sympy/tree/list-int-mul.
Another option might be to just have the list.__mul__(self, other) try calling
int(other).
SymPy has not yet been ported to Python 3, so I am sorry that I cannot test if
it works there.
--
messages: 99629
nosy: Aaron.Meurer
severity: normal
status: open
title: Have sequence multiplication call int() or return NotImplemented so that
it can be overridden with __rmul__
type: behavior
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7972
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
