Eric V. Smith added the comment:
You should read: https://docs.python.org/3/tutorial/floatingpoint.html
--
components: -Build
nosy: +eric.smith
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tra
Changes by Eric V. Smith <e...@trueblade.com>:
--
keywords: -patch
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Eric V. Smith added the comment:
I've fixed this particular problem, but the tokenize module definitely has some
other issues. It recompiles regexes very often when it doesn't need to, it
treats single- and triple-quoted strings differently (leading to some code
bloat), etc. I may open
Eric V. Smith added the comment:
This patch addresses Larry's review, plus bumps the bytecode magic number.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
Oops. Forgot to include the diff with that last message. But it turns out it
doesn't work, anyway, because I put the #define's in opcode.h, which is
generated (so my code got deleted!).
I'll try to find some reasonable .h file to use and submit a new patch
Eric V. Smith added the comment:
Brett: I'll take a look.
Serhiy: I'm looking for a place to put some #defines related to the bit masks
and bit values that my FORMAT_VALUE opcode is using for opargs. One option is
to just put them in Tools/scripts/generate_opcode_h.py, so that they end up
Eric V. Smith added the comment:
Thanks, Serihy. I looked at those, and neither one is a great fit. But not
having a better option, I went with ceval.h. Here's the patch.
--
Added file: http://bugs.python.org/file40880/format-opcode-2.diff
New submission from Eric V. Smith:
Currently, the f-string f'a{3!r:10}' evaluates to bytecode that does the same
thing as:
''.join(['a', format(repr(3), '10')])
That is, it literally calls the functions format() and repr(). The same holds
true for str() and ascii() with !s
Eric V. Smith added the comment:
In what way does the OS crash? Are there any kernel messages? Or is this the
python executable crashing? Again, if so, what messages are printed?
In any event, if this really is an OS crash, then it's a Linux bug and should
be reported to them
Eric V. Smith added the comment:
Small cleanups. Fixed a bug in PyCompile_OpcodeStackEffect.
--
Added file: http://bugs.python.org/file40864/format-opcode-1.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
Assuming David means "it wouldn't be unreasonable to insert a disclaimer", I
agree.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Eric V. Smith added the comment:
D'oh! I read your original comment as "it would be unreasonable to insert a
disclaimer", and then I wondered why you'd used such a convoluted sentence and
reversed your meaning. It's all my fault. Fortunately, I don't think Mrs.
McKinley from
Eric V. Smith added the comment:
Right, they're the same because it's a single bit. You 'and' with a mask to get
the bits you want, and you 'or' together the values. It's an old habit left
over from my bit-twiddling days.
I guess the test could really be:
have_fmt_spec = (oparg & FVS_
Eric V. Smith added the comment:
Some formatting improvements.
I removed one of the optimizations I was doing, because it's also done in
PyObject_Format(). I plan on moving other optimizations into PyObject_Format(),
but I'll open a separate issue for that.
I swapped the order
Eric V. Smith added the comment:
Brett: https://docs.python.org/devguide/compiler.html#introducing-new-bytecode
looks correct (and reminded me to update dis.rst!).
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
Eric V. Smith added the comment:
It does not currently work, because the docstring logic looks for a string, not
an expression. And an f-string is an expression.
It would require changing the compiler to evaluate the f-string expression
Eric V. Smith added the comment:
Since f-strings are not constant strings, they cannot be used as docstrings
without some modifications to the compiler.
I'm not sure it's worth evaluating a docstring f-string at compile time to make
them become docstrings: I can't think of a use case where
Eric V. Smith added the comment:
Oops, wrong issue. Ignore my last comment. I shouldn't do two things at once.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
I think the error here is that tokenize returns type=ASYNC for 'async', instead
of type=NAME.
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
I agree that there's no bug here: the timers are working as expected.
ivb: if you disagree, please explain what behavior you expected, versus what
you see.
--
nosy: +eric.smith
resolution: -> not a bug
stage: -> resolved
status: open -&g
Eric V. Smith added the comment:
That's an unfortunate implementation choice. I agree we probably can't break
locale.atof, but how about adding another function with a better
implementation, that's strictly locale-aware?
--
nosy: +eric.smith
Eric V. Smith added the comment:
That's a great test, thanks.
If we were designing this from scratch, I agree that raising an exception is
the right thing to do. But the questions is: can we change the behavior now?
I think it's unlikely that anyone is relying on these functions returning
[W
Eric V. Smith added the comment:
Yes, both 'fr' and 'rf' need to be supported (and all upper/lower variants).
And in the future, maybe 'fb' (and 'rfb', 'bfr', ...).
Unfortunately, the regex doesn't scale well for all of the combinations
Eric V. Smith added the comment:
This patch cleans up string matching in tokenize.py, and adds f-string support.
--
Added file: http://bugs.python.org/file40821/issue25311-1.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Eric V. Smith added the comment:
Avoid truncating the expected results when the tokens are long.
--
Added file: http://bugs.python.org/file40799/issue-25422-1.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
Removed the truncation of tokens. There's really no point to it, and it could
be hiding bugs.
Also removed the truncation of token names, although none were ever truncated.
--
Added file: http://bugs.python.org/file40800/issue-25422-2.diff
Changes by Eric V. Smith <e...@trueblade.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Eric V. Smith added the comment:
Multi-line string tests were added in changeset 91c44dc35dfd. That will make
changes for this issue safer. Updated patch to come.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Eric V. Smith <e...@trueblade.com>:
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file40798/issue-25422.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by Eric V. Smith <e...@trueblade.com>:
--
title: tokenize: add test for multi-line strings -> tokenize: add tests for
multi-line strings
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
New submission from Eric V. Smith:
As part of fixing issue 25311, I'm going to change how the string pattern
recognition works. I want to make sure I don't break anything that currently
works, but there are no tests for multi-line strings. I'll add those first,
under this issue.
I'm
Changes by Eric V. Smith <e...@trueblade.com>:
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Changes by Eric V. Smith <e...@trueblade.com>:
--
title: Use with instead of try finally -> In threading module, use with instead
of try finally
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Eric V. Smith added the comment:
This is not a bug. See: https://docs.python.org/3.5/tutorial/floatingpoint.html
--
nosy: +eric.smith
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bug
Eric V. Smith added the comment:
Although the function names have changed (I think due to Argument Clinic), the
reported issue still applies to the current code:
https://hg.python.org/cpython/file/tip/PC/msvcrtmodule.c#l309
I'll let other decide if the change is actually desirable. It would
Eric V. Smith added the comment:
Oops, make that 80 combinations (I forgot the various 'fb' ones):
['B', 'BF', 'BFR', 'BFr', 'BR', 'BRF', 'BRf', 'Bf', 'BfR', 'Bfr', 'Br', 'BrF',
'Brf', 'F', 'FB', 'FBR', 'FBr', 'FR', 'FRB', 'FRb', 'Fb', 'FbR', 'Fbr', 'Fr',
'FrB', 'Frb', 'R', 'RB', 'RBF', 'RBf
Eric V. Smith added the comment:
I think the best way to approach this is to generate (in code) all of the
places where string prefixes appear. There's StringPrefix, endpats,
triple_quotes, and single_quoted.
With the currently valid combinations of f, b, r, and u, I count 24
combinations
Eric V. Smith added the comment:
My first attempt. Many more tests are needed.
I'm going to need to spend some time trying to figure out how parts of
tokenize.py actually works. I'm not sure, for example, that endpats is
initialized correctly. There definitely aren't enough tests, since if I
Eric V. Smith added the comment:
Actually, int.__format__, etc. are not in this file. So that's good.
The things that are in this file but are unrelated to unicodeobject.c are the
support routines for implementing string.Formatter. I think I'll move those
elsewhere, as a first step
New submission from Eric V. Smith:
See PEP 498.
f'New for Python {sys.version.split()[0]}'
'New for Python 3.6.0a0'
--
assignee: eric.smith
components: Interpreter Core
files: pep-498.diff
keywords: patch
messages: 249362
nosy: eric.smith
priority: normal
severity: normal
status: open
Eric V. Smith added the comment:
One thing I've done in this implementation is to build up a string to pass to
str.format(), instead of using the original string. This new string uses
positional parameters instead of named parameters.
I had originally proposed to add a string.interpolate
Eric V. Smith added the comment:
Fixed validate_exprs bug.
--
Added file: http://bugs.python.org/file40316/pep-498-1.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Eric V. Smith <e...@trueblade.com>:
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25008>
___
_
Eric V. Smith added the comment:
Make sure f-strings are identified as literals in error messages.
--
Added file: http://bugs.python.org/file40317/pep-498-2.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
I use smtpd.py for testing my code. But it's not such a big deal that I
couldn't live without it. If I have some time to burn, I might convert it to
asyncio so I can continue to use it.
--
nosy: +eric.smith
Eric V. Smith added the comment:
Isn't Python-ast.c a generated file?
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
With both python 2 and 3, what does "ps -efww | fgrep soffice" produce?
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Eric V. Smith added the comment:
I discussed it with Guido and added 'F' to the PEP.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
+1 on the "by default" change.
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Eric V. Smith added the comment:
I'll probably ensure that all of the parsing errors contain "format string" or
"f-string" or similar. That way the regex check is easier, and the user can
search for it more easily.
It remains to be seen how these are referenced in the docu
Eric V. Smith added the comment:
After discussing it with Guido, I've removed the ability to combine 'f' with
'u'.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
This patch fixes triple-quoted strings, plus a few bugs. I'm going to commit it
tomorrow, barring any unforeseen issues.
--
Added file: http://bugs.python.org/file40447/pep-498-5.diff
___
Python tracker <
Eric V. Smith added the comment:
Yes, Jelle, you are correct in all 3 cases. Remember that the steps are to
extract the string from the source code, decode backslash escapes, and only
then treat it as an f-string.
For the first case, without the 'f' prefix:
'{ {1: 2\N{RIGHT CURLY BRACKET}[1
Eric V. Smith added the comment:
Agreed on checking the error messages better. Especially since even the
simplest of errors (like leaving out a quote) results in a syntax error in
parsing the string, not parsing inside the f-string.
I'll look at it eventually
Eric V. Smith added the comment:
This one has been fixed:
>>> f"{'a\\'b'}"
"a'b"
This one was a bug that I previously fixed, that Martin pointed out:
>>> f"{x!s!s}"
File "", line 1
SyntaxError: invalid character following conversion c
Eric V. Smith added the comment:
Both of those are known (to me!) byproducts of the current implementation. If
my crazy idea of adding opcodes to speed up f-strings flies, then this issue
will go away. I consider this a corner case that doesn't need to be addressed
before committing this code
Eric V. Smith added the comment:
I rewrote the format_spec parser to recursively call the f-string parser, so
any oddness in what's allowed in a format_spec is gone.
It took way longer than I thought, but the code is better for it.
--
Added file: http://bugs.python.org/file40480/pep
Eric V. Smith added the comment:
Simplified error handling, fixed 2 memory leaks.
All tests now pass with no leaks.
This should be the final version.
--
Added file: http://bugs.python.org/file40484/pep-498-7.diff
___
Python tracker <
Eric V. Smith added the comment:
Thanks again, Martin. I've found 4 bugs so far, based on your suggested tests.
The ones I haven't fixed are: 'fur' strings don't work (something in the
lexer), and triple quoted strings don't work correctly. I'm working on both of
those, and should have
Eric V. Smith added the comment:
It turns out 'fur' strings aren't a thing, because 'ur' strings aren't.
>From tokenizer.c:
/* ur"" and ru"" are not supported */
And the PEP:
https://www.python.org/dev/peps/pep-0414/#exclusion-of-raw-unicode-literals
I'll add a test
Eric V. Smith added the comment:
Hopefully the last version.
--
Added file: http://bugs.python.org/file40495/pep-498-8.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
> Martin Panter added the comment:
>
> Another strange error message (though maybe the new test changes you
> mentioned caught this):
>
>>>> f'{3:{10}' # Actually missing a closing bracket '}'
> File "", line 1
>
Changes by Eric V. Smith <e...@trueblade.com>:
Removed file: http://bugs.python.org/file40302/pep-498.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Eric V. Smith <e...@trueblade.com>:
Removed file: http://bugs.python.org/file40316/pep-498-1.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Eric V. Smith <e...@trueblade.com>:
Removed file: http://bugs.python.org/file40317/pep-498-2.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Eric V. Smith added the comment:
This implements the accepted PEP 498. The only other real change I plan on
making is to do dynamic memory allocation when building the expressions that
make up a JoinedStr AST node. The code has all of the places to do that already
laid out, it's just a matter
Eric V. Smith added the comment:
Thanks, Martin. I've posted my replies. I'll add some more tests, and work on
the triple quoted string bug.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
This version does dynamic allocation for the expression list, and fixes some
memory leaks and early decrefs.
I think it's complete, but I'll take some more passes through it checking for
leaks.
--
___
Python
Changes by Eric V. Smith <e...@trueblade.com>:
Added file: http://bugs.python.org/file40430/pep-498-4.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Eric V. Smith added the comment:
The good news is that the performance is pretty good, and finally I have a case
where I can beat %-formatting:
$ ./python.bat -mtimeit -s 'a=2' "'%s' % a"
100 loops, best of 3: 0.883 usec per loop
$ ./python.bat -mtimeit -s 'a=2' '"{}"
Eric V. Smith added the comment:
I'm closing this as unneeded.
--
resolution: -> rejected
stage: -> resolved
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Eric V. Smith added the comment:
Fixed in 3.4, 3.5, and 3.6. Thanks for the bug report and patch! I added you to
the Misc/ACKS file.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
versions: +Python 3.6
___
Python tra
Eric V. Smith added the comment:
>From the info in issue 25279, I'd say it's an error in your code.
But to make sure it's not an error in the stdlib, can you show us your code?
Without that, it's not possible to diagnose this any further.
--
nosy: +eric.smith
status: pending ->
Changes by Eric V. Smith <e...@trueblade.com>:
--
status: open -> pending
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25278>
___
_
Eric V. Smith added the comment:
Thanks for noticing tokenize.py. And thanks for the kind note!
--
assignee: -> eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Eric V. Smith added the comment:
You'll need to reproduce this in a smaller piece of code that demonstrates the
problem. The code you've included is very large, and imports libraries we don't
have access to.
Otherwise, we can't reproduce it and we can't help
New submission from Eric V. Smith:
A group of us (all added as nosy) spent part of the day working on issue 25008
(write an smtpd with asyncio).
We came across some code that contained a copy of StreamReader.readline, but it
used b'\r\n' instead of b'\n' for a line ending character
Eric V. Smith added the comment:
Good point. I quick test of our sample code shows that calling regular readline
to read up to '\n' does in fact work correctly. Let me do some more testing,
then I'll likely close this.
Thanks!
--
___
Python
Eric V. Smith added the comment:
That's awesome, thanks! Definitely simpler than where I was going.
I'm not in front of my dev machine right now, so I can't run it. But if it
works, it works.
I suggest adding the test cases to test_unparse.py's UnparseTestCase. That way,
any problems
New submission from Eric V. Smith:
Issue 24965 add f-strings (see PEP 498). They need to be documented.
--
assignee: docs@python
components: Documentation
messages: 251101
nosy: docs@python, eric.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: PEP 498 f
Eric V. Smith added the comment:
And it always fails with "-u cpu", which the buildbots use.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Eric V. Smith added the comment:
Documentation task added as issue #25179.
Thanks to Martin for the great code reviews.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Eric V. Smith:
test_unparse.py occasionally fails if it picks a module that uses f-strings.
--
assignee: eric.smith
keywords: easy
messages: 251106
nosy: eric.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Tools/parser/unparse.py needs
Changes by Eric V. Smith <e...@trueblade.com>:
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25092>
___
_
Changes by Eric V. Smith <e...@trueblade.com>:
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Eric V. Smith added the comment:
Thanks for the feedback.
On the
f"{expr3!s}" → format(str(expr3))
issue, I'm trying to show the 1 argument version of format (which is what the
code generator actually calls). Although I realize that's not a great example,
since the string
Eric V. Smith added the comment:
Cleaned up the error handling in fstring_expression_compile so it's easier to
verify and more robust in the face of future changes.
Added a test for an un-doubled '}', which is an error in a top-level literal
(and ends a nested expression). Modified existing
Eric V. Smith added the comment:
I changed the generated code to call:
format(x [, spec])
instead of:
x.__format__(spec)
The reason is that the correct way to call __format__ is actually:
type(x).__format__(x, spec)
That is, the __format__ lookup is done on the type, not the instance. From
Changes by Eric V. Smith <e...@trueblade.com>:
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Eric V. Smith added the comment:
This task is actually pretty difficult, and is going to require some major
surgery to unparse.py.
Unfortunately, until it's fixed, you can't use f-strings in the stdlib or in
stdlib tests.
Particularly challenging are nested f-strings like:
f'{f"{
Changes by Eric V. Smith <e...@trueblade.com>:
--
resolution: -> fixed
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Eric V. Smith added the comment:
The problem is definitely that:
format = PyUnicode_EncodeLocale(format_arg, "surrogateescape");
fails on Windows.
Windows is using strftime, not wcsftime. It's not using wcsftime because of
issue 10653.
If I force Windows to use wcsftime, this
Eric V. Smith added the comment:
+1
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25317>
___
___
Python-bugs-
Eric V. Smith added the comment:
Here's the patch.
I added some more tests, including tests for ''.format_map(). I think the
format_map() tests convince me that keeping None for non-matched groups makes
sense.
--
assignee: -> eric.smith
keywords: +easy, needs review, patch
st
Eric V. Smith added the comment:
I've been playing around with this. My implementation is basically the naive:
def __getitem__(self, value):
return self.group(value)
I have the following tests passing:
def test_match_getitem(self):
pat = re.compile('(?:(?Pa)|(?Pb))(?Pc
Eric V. Smith added the comment:
I agree that the proposed change would require a PEP, and this should be
discussed on python-ideas.
I also think there's very little chance such a change would be accepted, but
that doesn't mean it's impossible.
I think using a external library is your best
Eric V. Smith added the comment:
I see a small difference, but I think it's related to the fact that in the
first example you're concatenating 2 strings (',' and the result of {0}), and
in the 2nd example it's 3 strings ("'", {0}, "',"):
$ echo '",{0}".format(x)
Eric V. Smith added the comment:
Please show us how you're measuring the performance. Also, please show the
output of "python -V".
--
components: +Interpreter Core -Windows
nosy: +eric.smith -paul.moore, steve.dower, tim.golden, zach.ware
Eric V. Smith added the comment:
I agree that the "to xxx" changes look good. And the handful of other
corrections look good, too.
I left a review comment with one typo I found.
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.pyth
Eric V. Smith added the comment:
The problem has to do with refcounting when an error occurs. Adjusting the
title accordingly.
I'm not sure yet if the problem is in PyObject_Format(), or in handling errors
in the eval loop when processing FORMAT_VALUE opcodes. I'm slowly tracking it
down
501 - 600 of 2689 matches
Mail list logo
