Eric V. Smith added the comment:
Yes, that's my thinking as well. I'll have a patch soon-ish.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
Now I think it's not a refcount problem.
I'm going to switch to POP/PUSH instead of TOP/SET_TOP. I believe the problem
is that I'm not adjusting the top of stack if there's an error.
--
title: Core dump in f-string with formatting errors due
Eric V. Smith added the comment:
Thanks for the report and the debugging help.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by Eric V. Smith <e...@trueblade.com>:
--
assignee: -> eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26287>
___
_
Changes by Eric V. Smith <e...@trueblade.com>:
--
nosy: +brett.cannon, eric.smith, eric.snow, ncoghlan
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Eric V. Smith added the comment:
Do you have a pointer to the spec which requires -0 vs.
-3.333e+20, for example?
--
nosy: +eric.smith
___
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/issue26276>
___
_
Eric V. Smith added the comment:
Hi, Mark.
Yes, PEP 3101 is very much under-specified in this area. I tried to avoid the
same mistake in PEP 498, although of course that's a different problem area.
I don't recall why this particular case broke between 3.2.3 and 3.4.3. I'll try
and track
Changes by Eric V. Smith <e...@trueblade.com>:
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26241>
___
_
Eric V. Smith added the comment:
Agreed. And, since any API change would just be a 3.6+ change, this would
increase the difficulty of moving between 2.7 and 3.x. Which is not something
we want.
--
___
Python tracker <rep...@bugs.python.org>
Eric V. Smith added the comment:
Changing to just 3.6, since that's the only place we could change the behavior.
That said, I'd be -1 on making such a change. It would no doubt break some
existing code.
--
nosy: +eric.smith
type: -> enhancement
versions: -Python 2.7, Python
Eric V. Smith added the comment:
Please see https://docs.python.org/3.5/tutorial/floatingpoint.html for a
discussion of why this is not a bug.
--
nosy: +eric.smith
resolution: -> not a bug
stage: -> resolved
status: open -> closed
_
Eric V. Smith added the comment:
I believe this is a duplicate of issue 9334. There's a lot of discussion there.
--
nosy: +eric.smith
stage: -> resolved
status: open -> closed
superseder: -> argparse does not accept options taking arguments beginning
with dash (regres
Eric V. Smith added the comment:
Without lots of analysis (and disassembly), I can't speak to how valid your
tests are, but they don't seem unreasonable.
format() will always be slower, because it's more general (primarily in that it
can be extended to new types). Plus, it involves at least
Eric V. Smith added the comment:
> '''
> When no explicit alignment is given, preceding the width field by a zero
> ('0') character enables sign-aware zero-padding for numeric types. This is
> equivalent to a fill character of '0' with an alignment type of '='.
> '''
I think th
Eric V. Smith added the comment:
I agree with David here, this isn't a bug tracker level issue.
But, to the specifics of your example, it already works:
Python 3.6.0a0 (default:9095a5787a82+, Feb 5 2016, 18:24:55)
[GCC 5.2.1 20151010] on linux
Type "help", "copyright", &
Eric V. Smith added the comment:
For 3.5 and 2.7, I'd suggest:
format(value, 'x')
or:
format(value, 'X')
Although you might disagree because of the verbosity. But at least you're not
parsing a string at runtime.
And for 3.6 with PEP-498:
f'{value:x}'
There are of course options for padding
Eric V. Smith added the comment:
I agree that copy2 should not fail because chmod fails. Could you please
provide the entire traceback message when it fails (on both 2.7 and 3.4 or
3.5)? And what OS are you running on, and what filesystem?
It looks like the error happens because errno=95
Eric V. Smith added the comment:
There's a link in the PEP to the discussion on why it was rejected. There's a
lot to read in the thread (I just spent 30 minutes re-reading it!).
I'm going to close this. If you'd like to re-open the discussion with new
insights, I'd suggest posting to python
Eric V. Smith added the comment:
You'll need to convert the string to bytes first, by using .encode().
--
nosy: +eric.smith
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.pytho
New submission from Eric V. Smith:
I've separated this out from issue 26331, so as to not interfere with
discussions and code reviews for the parsing portion of the PEP.
--
assignee: eric.smith
components: Interpreter Core
messages: 266023
nosy: eric.smith
priority: normal
severity
Eric V. Smith added the comment:
I've created issue 27080 to track the formatting part of this.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
I considered doing this, and have some of it implemented. I discussed it with
Larry Hastings and Mark Shannon at PyCon Ireland, and we decided to just use
''.format() and the new FORMAT_VALUE opcode, since that was the simplest way to
fix the previous
Changes by Eric V. Smith <e...@trueblade.com>:
--
assignee: -> eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27078>
___
_
Changes by Eric V. Smith <e...@trueblade.com>:
--
nosy: +georg.brandl
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27080>
___
_
Eric V. Smith added the comment:
See the rejected PEP 351: https://www.python.org/dev/peps/pep-0351/
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
Yes, I'll read PEP 515 and work on the formatting.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
Okay. Adding back 3.5 and 2.7, in case someone wants to document the behavior
there. I'm not sure if we fix docs in 3.4 still.
--
versions: +Python 2.7, Python 3.5
___
Python tracker <rep...@bugs.python.org>
Eric V. Smith added the comment:
I think it's okay to change this as far as str.format() goes.
Interestingly enough, the motivating case to add str.format_map() in issue 6081
was exactly this kind of code. Although I notice that the example in that
issue, which it shows as failing, works
Changes by Eric V. Smith <e...@trueblade.com>:
--
nosy: +eric.smith
type: -> behavior
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Eric V. Smith added the comment:
I'm a native speaker, and it's not the greatest sentence. How about:
All of Python’s immutable built-in objects (such as numbers, strings and
tuples) are hashable. None of its mutable containers (such as lists or
dictionaries) are hashable.
--
nosy
Eric V. Smith added the comment:
I'm not sure PyObject_GetItem instead of PyDict_GetItem in 3.x completely
explains things, because the code in issue 6081 also works in 2.7.
But I don't think it's terribly important in any event, as long as we
understand the 3.x difference. Thanks
Eric V. Smith added the comment:
Doesn't namedtuple use _fields (as opposed to _fields_) for a similar purpose?
Would Enum using _order be more consistent with that?
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
Changes by Eric V. Smith <e...@trueblade.com>:
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26785>
___
_
Eric V. Smith added the comment:
Changing versions.
I left in 2.7, but I doubt we'd make any changes to 2.7 with regards to this.
--
versions: -Python 3.2, Python 3.3
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
Oops, sorry. I'm an idiot. I was running in a venv where python was python3.
Checking with my installed 2.7.10, I see the expected error.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Eric V. Smith added the comment:
I intend to review this. As this is not a new feature, it doesn't need to be
completed by beta 1. I'm focusing my energies on new features, then I'll look
at this.
--
___
Python tracker <rep...@bugs.python.
Changes by Eric V. Smith <e...@trueblade.com>:
--
title: Roudning/Large Int representation error with multiplication and division
-> Rounding/Large Int representation error with multiplication and division
___
Python tracker <rep...@bug
Eric V. Smith added the comment:
Thanks for giving an example.
You misunderstand how the "/" operator works in python 3.x: the result is
always a float. If you use "//", y
Eric V. Smith added the comment:
> And the expected performance for optimal `f'X is {x}'` code would
> be *faster* than `"'X is %s' % (x,)"` which still needs to
> interpret the string at runtime, and build a proper tuple object
> on stack.
That's not necessarily true
Eric V. Smith added the comment:
Since your result is 6.754791118045615e+200, it's definitely not stored as an
integer.
If you would show us exactly how you calculated this value, we can explain
where the conversion to floating point is taking place.
In the meantime, I'm going to close
Eric V. Smith added the comment:
Actually, Python represents large integers exactly. Can you provide a specific
example of a problem you're seeing?
--
components: +Interpreter Core -ctypes
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.
Eric V. Smith added the comment:
Thanks for the suggestion. However, I don't think it's possible or desirable
for python to implement this.
There are two problems: 1) the internals of python would have to be drastically
changed to support this, and 2) you'd need different syntax to support
Eric V. Smith added the comment:
Instead of:
__all__ = [name for name in globals() if not name.startswith('_') and name not
in {'enum', 're', 'sys', 'wantobjects'}]
Maybe this would be less fragile:
import types
__all__ = [name for name, obj in globals().items() if not name.startswith
Eric V. Smith added the comment:
Right, that's basically what _all_string_prefixes() does: it starts with the 6
unique prefixes that are case- and order- independent ('b', 'r', 'u', 'f',
'br', 'fr'), and adds the cased and ordered versions.
If you're saying that we should list those 8
Eric V. Smith added the comment:
Can you give us your platform, platform version, compiler, and compiler
version? Also, the entire output of "make install" (or whatever make command
you're running).
Thanks.
--
nosy: +eric.smith
___
Pyth
Eric V. Smith added the comment:
You should report this to the Numpy tracker. It's a third party package.
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
Since these codes don't apply to all types, you'll need some words saying what
they do apply to. For example, None being the same as "g" is true for int,
float, and Decimal; but None is "s" for strings.
And, for example, none of th
Eric V. Smith added the comment:
Unfortunately I'm not going to have time to implement this before 3.6 beta 1,
so I'm un-assigning it to myself. I'll post to python-dev and hopefully someone
else can get to it. Apologies for waiting so long.
--
assignee: eric.smith ->
versi
New submission from Eric V. Smith:
See https://mail.python.org/pipermail/python-dev/2016-August/145979.html for
details.
PEP 498 is going to be changed to disallow backslashes inside braces (the
expression portions of an f-string).
However, I can't get that change done in time for 3.6 beta 1
Changes by Eric V. Smith <e...@trueblade.com>:
--
keywords: +patch
Added file: http://bugs.python.org/file44311/27921.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Eric V. Smith <e...@trueblade.com>:
--
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27921>
___
_
Eric V. Smith added the comment:
No problem! Thanks for caring enough to open an issue and submit a patch, even
if we don't use it.
--
stage: -> resolved
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Eric V. Smith added the comment:
While they probably should be entered with escapes, there's no actual technical
requirement for that.
>From the command line, I can enter a control-A with control-V control-A (this
>might be different depending on your environment, or if you use an
New submission from Eric V. Smith:
See issue 27921.
Currently (and for 3.6 beta 1), backslashes are not allowed anywhere in
f-strings. This needs to be changed to allow them in the string parts, but not
in the expression parts.
Also, require that the start and end of an expression be literal
Eric V. Smith added the comment:
See issue 27948 for adding backslashes back in to the string parts of an
f-string.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
Of course. Never mind. LGTM.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27078>
___
___
Pyth
Eric V. Smith added the comment:
Left a review comment. I'd like to see this in before 3.6 beta 1.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
Now that I've looked at PyUnicode_New, I agree with using PyUnicode_New(0, 0).
I can't imagine we could measure the difference with optimizing it in the
opcode itself before calling PyUnicode_New.
Thanks for adding this, Serhiy. I think it's great stuff
Eric V. Smith added the comment:
> This looks a little ugly.
True. My goal is to get the simplest possible thing working now, and then
before beta 2 fix it so that backslashes again work in the text portions of an
f-string. After that, I'll fix this particular piece of code (and the oth
Changes by Eric V. Smith <e...@trueblade.com>:
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27934>
___
_
Changes by Eric V. Smith <e...@trueblade.com>:
--
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Eric V. Smith added the comment:
This patch implements the new logic. It passes all of the fstring tests (except
of course the ones that had backslashes in the expressions). I'd still like to
add some more tests, because I'm not convinced the named unicode escapes are
correct (f"\N{LEFT
Changes by Eric V. Smith <e...@trueblade.com>:
--
title: f-strings do not round trip through Tools/parser/test_unparse.py -> Some
f-strings do not round trip through Tools/parser/test_unparse.py
___
Python tracker <rep...@bugs.pytho
Eric V. Smith added the comment:
The problem with test_unparse is that:
f'''{"'"}'''
becomes:
f'{"\'"}'
when it's run through Tools/parser/unparse.py.
I'll open another issue for this.
--
___
Python tracker <rep...
Eric V. Smith added the comment:
I added a note in Misc/NEWS. Is that not what you mean?
I'll look at match_methods.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
Fixed. Thanks, Serhiy.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24454>
___
___
Pyth
Eric V. Smith added the comment:
On 9/11/2016 10:05 AM, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
> ./Modules/_sre.c:2425:14: warning: ‘match_getitem_doc’ defined but not used [-
> Wunused-variable]
Not in Visual S
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:
See also issue 27772.
The difference in the error messages is due to the first ones looking for
specific invalid combinations (in this case things the string formatter does
not understand), and the last one which is "I have no idea what you're a
Eric V. Smith added the comment:
Since Brett is working on the parsing part, I'll work on this. I might take a
stab at the documentation first, but in any event I'll commit it tonight.
--
assignee: -> eric.smith
___
Python tracker &
Eric V. Smith added the comment:
Updated patch, works against HEAD. I added a few tests and tweaked some
comments. My goal is to commit this today, before the 3.6b1 cutoff. I don't
think there's much risk to it.
I still need to update the PEP.
--
Added file: http://bugs.python.org
Changes by Eric V. Smith <e...@trueblade.com>:
--
assignee: -> eric.smith
versions: +Python 3.6 -Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Eric V. Smith added the comment:
I just noticed that the patch doesn't handle 'X' (uppercase) correctly, while
it does handle 'x' (lowercase). I'll fix that when I commit.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Eric V. Smith added the comment:
I've fixed the code and fixed/added tests. I still need to update the docs and
PEP 498. I'll create a separate issue for the docs, once I'm done with the PEP.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
Eric V. Smith added the comment:
I also fixed the code so both '_' and ',' can't be specified, and added tests.
The documentation is also updated.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tra
Eric V. Smith added the comment:
I'm done with the formatting (issue 27080), so PEP 515 can be marked as final.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
Updated patch, with docs. I'd like to get this in to 3.6. Can anyone take a
look?
--
Added file: http://bugs.python.org/file44522/issue-24454-1.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Eric V. Smith added the comment:
Yes, I think we should implement this for object.__format__. Marking as easy.
--
components: +Interpreter Core -Library (Lib)
keywords: +easy (C)
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Eric V. Smith added the comment:
Sorry for not responding earlier. It's unlikely I'll have time for this before
beta 2, although I can probably get to it after that and before beta 3. Don't
let me stop someone else from improving on the patch
Eric V. Smith added the comment:
I left a comment on Rietveld, but repeating it here because for me those
messages often go to spam:
I think you want to make this more general, by modifying the message for the
TypeError that follows. Any type that doesn't provide it's own __format__
should
Eric V. Smith added the comment:
Couldn't we create a private version of PyUnicode_DecodeUnicodeEscape, to be
called by ast.c, which passes back invalid escape info? Then have the actual
warning raised by ast.c, which knows enough about the context to generate a
better error/warning. I think
Eric V. Smith added the comment:
Here is an extremely rough patch that shows the basic concept. I named the
private function _PyUnicode_DecodeUnicodeEscape.
The problems with this patch are:
1. it always raises an error, not a warning
2. the private function isn't declared in a .h file
3
Eric V. Smith added the comment:
Also, I assume this is a problem with all such syntax warnings: you only see
this warning/error when the file is originally compiled. Once the .pyc file
exists, you'll never see a warning or error. Maybe that's okay, but it means
there's a certain class
Eric V. Smith added the comment:
I forgot: this is what Nick's example now looks like:
$ ./python -Wall escape_warning.py
Traceback (most recent call last):
File "escape_warning.py", line 1, in
import bad_escape
File "/home/eric/local/python/cpython/bad_escape.py",
Eric V. Smith added the comment:
Tim: Cool! That's way more useful than I thought it would be.
Serhiy: It's a proof of concept. Lots of design remains to be done. I'm not
sure we've agreed on the concept yet, so I don't think it's worthwhile
designing the API
New submission from Eric V. Smith:
The problem relates to how f-strings are re-created.
For the input file foo.txt containing this one line:
f'''{"'"}'''
Run:
./python Tools/parser/test_unparse.py foo.txt
Gives this output:
f'{"\'"}'
This result is not a valid f-strin
Eric V. Smith added the comment:
Issue 28002 tracks the problem with Tools/parser/unparse.py.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
Tim: I believe that's correct. I'm going to close this issue.
Guni: If you have more information or you feel this is an actual bug, please
post it here.
--
resolution: -> not a bug
stage: -> resolved
status: open -&g
Eric V. Smith added the comment:
Here's a slightly simplified version. I can reproduce this on Windows with
3.4.3 cygwin 32-bit and on Linux with 3.3.2 64-bit.
--
nosy: +eric.smith
Added file: http://bugs.python.org/file44211/27833.py
___
Python
Eric V. Smith added the comment:
One thing to be careful of here is that there's one slight difference between
how str.format() and f-strings handle indexing of values. f-strings, of course,
use normal Python semantics, but
str.format() treats indexing by things that don't look like integers
Eric V. Smith added the comment:
There isn't a direct mapping between %-formatting and __format__ format
specifiers. Off the top of my head, I can think of at least one difference:
>>> '%i' % 3
'3'
>>> '{:i}'.format(3)
Traceback (most recent call last):
File "&q
Eric V. Smith added the comment:
>> But that would require some discussion, to decide on the correct behaviour.
>What open question(s) do you think of?
You need to provide an exact specification of what you want. It's not clear,
for example, if you want to support required p
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:
Thanks, Serhiy. I updated the patch.
--
Added file: http://bugs.python.org/file45385/28633-1.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Eric V. Smith <e...@trueblade.com>:
--
assignee: -> eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28633>
___
_
Eric V. Smith added the comment:
This file is derived from my namedlist project on PyPI.
I've stripped out the namedlist stuff, and just left namedtuple. I've also
removed the Python 2 support, and I've removed support for default parameters.
After that surgery, I have not tested it very well
Eric V. Smith added the comment:
Thanks, Jason. I updated the PEP, so now I think the docs and PEP match the
implementation.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.pytho
Eric V. Smith added the comment:
Works:
>>> f'' b''
File "", line 1
SyntaxError: cannot mix bytes and nonbytes literals
Fails:
>>> b'' f''
Segmentation fault
$
Regular strings work:
>>> '' b''
File "", line 1
SyntaxError: cannot mix bytes a
Eric V. Smith added the comment:
The ones in msg280228 give correct error messages.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
601 - 700 of 2689 matches
Mail list logo
