Eric V. Smith added the comment:
This is the expected behavior:
https://docs.python.org/2/faq/programming.html#why-does-22-10-return-3
--
nosy: +eric.smith
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Pytho
Eric V. Smith added the comment:
I think removing the word "way" would be a better improvement.
--
nosy: +eric.smith
versions: -Python 3.2, Python 3.3, Python 3.6
___
Python tracker
<http://bugs.python.o
Changes by Eric V. Smith :
--
keywords: +easy
___
Python tracker
<http://bugs.python.org/issue23929>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
Updated patch with a few minor doc tweaks.
The one substantive change I did make was to add numeric_owner to the call to
self.chown() when setting directory owners. I believe this is correct, but I
need to convince myself and to write a test.
--
Added
Eric V. Smith added the comment:
Note that this change will break code that subclasses TarFile and overrides
chown(), as suggested in msg233915. I'm not too concerned about that, since
chown() is not documented. Ideally it would be renamed to _chown(), but that's
probably a sepa
Eric V. Smith added the comment:
I added numeric_owner to the self.chown() call when adding directories. I'm
reasonably sure this is correct.
I added tests for dirs, although they need some cleaning up to be simpler and
cleaner. I'll do that cleanup shortly, but I want to check this
Eric V. Smith added the comment:
Other than Misc/NEWS, I think this is the final version of this patch.
--
Added file:
http://bugs.python.org/file38981/tarfile-numeric-owner-with-tests-3.diff
___
Python tracker
<http://bugs.python.org/issue23
Eric V. Smith added the comment:
Thanks for your review, Berker. I've updated the code with most of your
suggestions, although some of them were mooted by some restructuring I did.
A couple of questions/issues:
- I'm not sure where we stand on keyword-only arguments. I certainly
Eric V. Smith added the comment:
Thanks everyone for their help, especially Michael for the original patch.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Eric V. Smith added the comment:
As this is an enhancement request, I've changed the versions.
I'm opposed to this change. If I pass an encoding along with a type for which
it makes no sense, I'd prefer an error instead of silently ignoring the
encoding.
I think your helper
Eric V. Smith added the comment:
I agree with deprecating (in the documentation) but never removing the encoding
argument to str() in Python 3. .decode() is the better way to convert a
bytes-like object to a str.
Every change proposed here would be an enhancement in 2.7, and we are not
Eric V. Smith added the comment:
I think David meant the "else" clause on a "for" statement:
https://docs.python.org/2/reference/compound_stmts.html#the-for-statement
--
nosy: +eric.smith
___
Python tracker
<http://bug
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue24192>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
Just to clarify:
If not specified, the default "presentation type" for floats is "g". Since you
didn't specify "f" in your example, it's using "g". For presentation type "g",
the precision (3 in you
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 b
Changes by Eric V. Smith :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue27921>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Eric V. Smith :
--
keywords: +patch
Added file: http://bugs.python.org/file44311/27921.patch
___
Python tracker
<http://bugs.python.org/issue27
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 th
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue27934>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.python.org/issue27
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 us
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
<http://bugs.python.org
Eric V. Smith added the comment:
Left a review comment. I'd like to see this in before 3.6 beta 1.
--
___
Python tracker
<http://bugs.python.org/is
Eric V. Smith added the comment:
Of course. Never mind. LGTM.
--
___
Python tracker
<http://bugs.python.org/issue27078>
___
___
Python-bugs-list mailing list
Unsub
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 g
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&quo
Changes by Eric V. Smith :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue27948>
___
___
Python-bugs-list mailing list
Un
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.
--
__
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'{"\'&
Eric V. Smith added the comment:
Issue 28002 tracks the problem with Tools/parser/unparse.py.
--
___
Python tracker
<http://bugs.python.org/issue27921>
___
___
Changes by Eric V. Smith :
--
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
<http://bugs.python.org/issu
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.
Changes by Eric V. Smith :
--
assignee: -> eric.smith
versions: +Python 3.6 -Python 3.5
___
Python tracker
<http://bugs.python.org/issue21879>
___
___
Python-
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 t
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
s
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
<
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
___
Eric V. Smith added the comment:
I'm done with the formatting (issue 27080), so PEP 515 can be marked as final.
--
___
Python tracker
<http://bugs.python.org/is
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
<http://bugs.python.org/is
Changes by Eric V. Smith :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
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
<http://bugs.python.org/is
Eric V. Smith added the comment:
Fixed. Thanks, Serhiy.
--
___
Python tracker
<http://bugs.python.org/issue24454>
___
___
Python-bugs-list mailing list
Unsub
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
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:
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
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:
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&qu
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 c
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
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 requi
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 lik
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
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
<http://bugs.python.org/issue28
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 improvi
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
Eric V. Smith added the comment:
I'm sure this has been discussed before and rejected. I suggest you search the
python-ideas mailing list archives, and if you do not find something in the
archives, raise the issue on python-ideas.
--
nosy: +eric.
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue28425>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue28424>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
LGTM, although I'm not so sure about your #3. Maybe it should be a separate
issue and raised on python-dev? But I don't feel strongly enough about it to
argue the point.
Thanks!
--
___
Python trac
Eric V. Smith added the comment:
I'd actually change this to be something like:
Process b"", r"", u"", and the various legal combinations.
There are 24 total combinations when you add upper case. I actually wrote a
script in Lib/tokenize.py to generate
Eric V. Smith added the comment:
FWIW, in Lib/tokenize.py, it's _all_string_prefixes():
>>> _all_string_prefixes()
set(['', 'FR', 'rB', 'rF', 'BR', 'Fr', 'RF', 'rf', 'RB', 'fr', &#x
Eric V. Smith added the comment:
That's great. Thanks!
--
___
Python tracker
<http://bugs.python.org/issue28489>
___
___
Python-bugs-list mailing list
Changes by Eric V. Smith :
--
stage: -> commit review
___
Python tracker
<http://bugs.python.org/issue28489>
___
___
Python-bugs-list mailing list
Unsubscrib
Eric V. Smith added the comment:
I'll work on this later today.
--
___
Python tracker
<http://bugs.python.org/issue28128>
___
___
Python-bugs-list m
Changes by Eric V. Smith :
--
assignee: -> eric.smith
___
Python tracker
<http://bugs.python.org/issue28128>
___
___
Python-bugs-list mailing list
Unsubscrib
Eric V. Smith added the comment:
Here's an updated patch, that fixes some problems with the earlier patch, and
adds equivalent support for bytes.
HOWEVER, I can't get the warnings machinery to raise a DeprecationWarning that
would have all of the equivalent information that
Changes by Eric V. Smith :
Added file: http://bugs.python.org/file45284/28128-2.diff
___
Python tracker
<http://bugs.python.org/issue28128>
___
___
Python-bugs-list mailin
Changes by Eric V. Smith :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue28128>
___
___
Python-bugs-list mailing list
Un
Eric V. Smith added the comment:
I would change the f-string tests. I realize it's a fragile test, but it's the
only way to test the strings in the exception.
--
___
Python tracker
<http://bugs.python.o
Eric V. Smith added the comment:
Oops, use 28128-3.diff.
--
Added file: http://bugs.python.org/file45285/28128-3.diff
___
Python tracker
<http://bugs.python.org/issue28
Eric V. Smith added the comment:
I'll take a look at it, Emanuel. But I can't promise how much progress I'll be
able to make today. I also think that at that point it becomes so complex that
it fails Ned's test for inclusion in 3.6.
--
__
Eric V. Smith added the comment:
Serihy:
I had tried this approach earlier, but it doesn't work. With your -5.diff
patch, the output is (using Nick's test case):
$ rm -rf __pycache__/ ; ./python -Werror escape_warning.py
Traceback (most recent call last):
File "escape_warn
Eric V. Smith added the comment:
Also, you'll note that with or without your patch, you get the same behavior.
The code in hg already raises DeprecationWarning, just in a different place. So
unless we can improve the DeprecationWarning output, we're better off doin
Eric V. Smith added the comment:
I'm not in front of a computer at the moment, but the output looks good. Also,
my very quick glance at -7.diff's warn_invalid_escape_sequence looks
reasonable, although I can't say for sure whether raising the error in
PyErr_WarnExplicitObj
Eric V. Smith added the comment:
TypeError is documented as "Raised when an operation or function is applied to
an object of inappropriate type". I think that fits this case: you're applying
some format code to a type that doe
Eric V. Smith added the comment:
I've pushed this to the default branch. I'll watch the buildbots.
Then Ned can decide if this goes in to 3.6.
--
___
Python tracker
<http://bugs.python.o
Eric V. Smith added the comment:
I agree it would be nice to get this in to 3.6. I'm not sure I'd go so far as
to say it's a must and can't wait for 3.6.1. It's a non-trivial change, and
it's up to Ned to say if it can go in to 3.6.
If you don't run wi
Eric V. Smith added the comment:
I'll work on this as soon as I can, coordinating with Ned.
--
___
Python tracker
<http://bugs.python.org/issue28128>
___
___
Eric V. Smith added the comment:
Chi Hsuan Yen:
I'll investigate, and open another issue as needed.
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pyth
Eric V. Smith added the comment:
I don't have a strong feeling one way or the other. I'd be surprised if anyone
is catching these errors.
--
___
Python tracker
<http://bugs.python.o
New submission from Eric V. Smith:
See msg279799 from issue28128, repeated here:
Seems the ^ pointer is not always correct. For example, in the function scope
it's correct:
$ cat test.py
def foo():
s = 'C:\Program Files\Microsoft'
$ python3.7 -W error test.py
File &q
Changes by Eric V. Smith :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue28582>
___
___
Python-bugs-list
Eric V. Smith added the comment:
I'm currently working on an update to PEP-498 to address this. I hope to have
it completed after a sprint this weekend.
--
___
Python tracker
<http://bugs.python.org/is
Eric V. Smith added the comment:
This is a duplicate of issue 28590.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> fstring's '{' from escape sequences does not start an expression
__
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
<http://bugs.python.or
Changes by Eric V. Smith :
--
assignee: -> eric.smith
___
Python tracker
<http://bugs.python.org/issue28633>
___
___
Python-bugs-list mailing list
Unsubscrib
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''
Eric V. Smith added the comment:
The ones in msg280228 give correct error messages.
--
___
Python tracker
<http://bugs.python.org/issue28633>
___
___
Python-bug
Eric V. Smith added the comment:
It's a decref of a NULL pointer. Patch with test is attached.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45383/28633-0.diff
___
Python tracke
Eric V. Smith added the comment:
Thanks, Serhiy. I updated the patch.
--
Added file: http://bugs.python.org/file45385/28633-1.diff
___
Python tracker
<http://bugs.python.org/issue28
Changes by Eric V. Smith :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
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 test
Eric V. Smith added the comment:
Can you provide a short sample that causes this error? Without a way to
reproduce it, there's not a lot we can do.
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/is
Eric V. Smith added the comment:
As you've seen, the answer is "no"!
We'd need to add logic to evaluate them at function definition time. That would
be a slight noticeable change, if the expressions had side effects.
--
___
P
Eric V. Smith added the comment:
It's Ned's call, but I wouldn't recommend changing this in 3.6, at least not
3.6.0.
As Martin points out, the reason f'foo' is a "normal" string has to do with how
strings and f-strings are assembled and concatenated.
Simila
Changes by Eric V. Smith :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue28745>
___
___
Eric V. Smith added the comment:
Thanks. Fixed in the pep repo in 4e86033.
--
assignee: docs@python -> eric.smith
resolution: -> fixed
status: open -> closed
type: -> enhancement
___
Python tracker
<http://bugs.python
Eric V. Smith added the comment:
Thanks for the bug report. However, 3.2 is no longer supported. If you can
reproduce this with 3.5 or 3.6, then please list the exact steps, including:
OS version
where you got the file you downloaded
what steps you took to install it
I'm closing this
2601 - 2699 of 2699 matches
Mail list logo
