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 tracker <rep...@bugs.pyth
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 tracker <
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', 'B', 'rb', 'F',
'Br', 'R', 'U', 'br', 'fR', 'b', 'f', 'Rb', 'Rf', 'r', 'u', 'bR'])
My basic point is th
Eric V. Smith added the comment:
That's great. Thanks!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28489>
___
___
Python-bugs-
Changes by Eric V. Smith <e...@trueblade.com>:
--
stage: -> commit review
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28489>
___
_
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 them
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Eric V. Smith <e...@trueblade.com>:
--
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Eric V. Smith <e...@trueblade.com>:
--
assignee: docs@python ->
keywords: +easy
stage: -> needs patch
type: -> behavior
___
Python tracker <rep...@bugs.python.org>
<http://bu
Eric V. Smith added the comment:
I think this is documented. This is a result of supported nested expressions in
the format_spec:
>>> an_x = "X"
>>> f'{10:02{an_x}}'
'0A'
--
___
Python tracker <rep...@bugs.pyth
Eric V. Smith added the comment:
Specifically, see: https://www.python.org/dev/peps/pep-0498/#format-specifiers
str.format() also works this way:
>>> '{0:02{1}}'.format(10, an_x)
'0A'
--
___
Python tracker <rep...@bugs.pytho
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
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.
--
___
Python tr
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.
Similarly:
'foo' f'bar' 'baz'
i
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
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 <rep...@bugs.python.org>
<h
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 an actual
Changes by Eric V. Smith <e...@trueblade.com>:
--
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by Eric V. Smith <e...@trueblade.com>:
Added file: http://bugs.python.org/file45284/28128-2.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
Oops, use 28128-3.diff.
--
Added file: http://bugs.python.org/file45285/28128-3.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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.
--
___
Python
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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_warning.py&quo
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_WarnExplicitObject followed
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 doing
nothing
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 doesn
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 with -Wall or -Werror, then you won't
Eric V. Smith added the comment:
I'll work on this as soon as I can, coordinating with Ned.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
I'll work on this later today.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28128>
___
___
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
___
Python
Changes by Eric V. Smith <e...@trueblade.com>:
--
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
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 <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/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 <rep...@bugs.python.org>
<http
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 "test.py&quo
Changes by Eric V. Smith <e...@trueblade.com>:
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28424>
___
_
Changes by Eric V. Smith <e...@trueblade.com>:
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28425>
___
_
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.smith
Eric V. Smith added the comment:
Yes, it's a duplicate.
The only valid operation on the value of calling tell() from a text-mode file
is to pass it to seek(). As long as that works, there's no bug here.
--
nosy: +eric.smith
resolution: -> duplicate
stage: -> resolved
status
Eric V. Smith added the comment:
Assuming Path is pathlib.Path, this is equivalent to the difference between:
>>> list(os.walk('/tmp'))
[('/tmp',
and:
>>> list(os.walk('/tmp/'))
[('/tmp/',
Because:
>>> pathlib.Path('/tmp')
PosixPath('/tmp')
>>> p
Eric V. Smith added the comment:
Isn't the difference that you use os.walk(Path(source)) in the first example,
and os.walk(source) in the second one?
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
It looks good to me, save for one tiny issue. I left a review comment.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
I withdraw my concern. I was thinking it would affect the caller, but of course
it won't. Apologies.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
And note that there are tests that explicitly check that the colon with no port
works (via issue 20270).
Given that this behavior has been around for a while, and is explicitly
allowed, I would recommend against changing this to an error
Eric V. Smith added the comment:
Isn't this just a lot of churn for not a lot of benefit? I'm all for
consistency, but you'll break patches on the bug tracker and externally
maintained patches.
--
nosy: +eric.smith
___
Python tracker <
Eric V. Smith added the comment:
Can you please paste your code into a comment on this issue? Gist content has a
habit of vanishing. Thanks!
--
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/issue29144>
___
_
Changes by Eric V. Smith <e...@trueblade.com>:
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29164>
___
_
Eric V. Smith added the comment:
This problem was no doubt introduced after 3.6a1 when I changed the parsing to
disallow backslashes inside {}.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
Yes:
>>> f'\{2*5}'
'\\{10'
I agree '\\10' would make sense.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Eric V. Smith added the comment:
Do you have a link to the SO question?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29104>
___
__
Eric V. Smith added the comment:
I'm not sure this counts as an error. The backslash means to treat the next
character literally, which this does. And since \{ is not a valid escape
sequence, it keeps both characters, exactly like:
>>> '\c'
'\\c'
Furthermore, since unknown escape
Eric V. Smith added the comment:
But I admit that dropping the trailing } seems odd. I think this particular
usage should be an error: no bare } allowed, similar to:
>>> f'10}'
File "", line 1
SyntaxError: f-string: single
Changes by Eric V. Smith <e...@trueblade.com>:
--
stage: -> resolved
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28975>
___
__
Eric V. Smith added the comment:
https://github.com/python/devguide/blob/github/runtests.rst
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
This should be easy enough to fix, at least in IPv4Interface.__init__. It needs
to copy some of IPv4Network.__init__, dealing with address[1] and calling
_make_netmask(). Currently, it just calls int(address[1]).
I haven't looked at IPv6Interface.
Tests
Eric V. Smith added the comment:
While an IPv4Interface may be a subclass of an IPv4Address, it definitely has
more information attached to it: the netmask of the network it's on. So an
interface (like a network) needs to allow additional parameters to specify the
netmask.
It should be true
Eric V. Smith added the comment:
Thanks! Yes, we'll need tests.
I'm out of town most of the weekend, but I'll look at this as soon as I can.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
Just a guess, but it's because this code was written at a time when subclassing
was the preferred way to extend code. Now we know better :), but it's not
possible to change history, unfortunately. Lots of code depends on the current
behavior.
If you find
Eric V. Smith added the comment:
This would be an issue for pscyopg2 support, not the Python bug tracker.
You're probably using an unsupported combination of psycopg2 and postgres
libraries.
--
nosy: +eric.smith
resolution: -> not a bug
stage: -> resolved
status: open -&g
Eric V. Smith added the comment:
+1: gets the job done without complicating the API.
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
I agree this needs to be different from replace(), due to not being atomic.
That makes it an enhancement, so I'm removing 3.5.
I'm +1 on Path supporting something like shutil.move().
--
nosy: +eric.smith
type: -> enhancement
versions: -Python
Eric V. Smith added the comment:
Serhiy: I plan to find time in the next week or so to look at this. Sorry for
the delay. Plus, the new workflow isn't helping me out: I need to get up to
speed on it.
--
___
Python tracker <rep...@bugs.python.
Eric V. Smith added the comment:
I think these are reasonable improvements. Also, move the initialization of
"silent" in to __new__.
--
keywords: +easy
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Eric V. Smith added the comment:
That's consistent with the example: it's showing you how to create a list of
functions, that when called, return squares.
"This gives you a list that contains 5 lambdas that calculate x**2"
Maybe "squares" isn't the most awesome name, but
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
Eric V. Smith added the comment:
Oops, yes, __init__.
Plenty of the demos use imports. I think it would be clearer with argparse, but
I also don't feel strongly about it.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Eric V. Smith added the comment:
Short of a compelling use case, I suggest we reject this enhancement request.
len() was deliberately not added in #24454. It's not like any normal code would
be iterating over match groups.
--
nosy: +eric.smith
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>:
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30104>
___
_
Eric V. Smith added the comment:
I think the example is correct. Because baz's action is store_false, the
default is True. So if baz is omitted, it should have a True value. That's what
the example shows, and what I see when I run this code.
Can you show what you tested, what you saw
Eric V. Smith added the comment:
I agree we shouldn't do anything heroic to "fix" dtoa.c. I'd wait and see if
Gay (or other maintainers) will chose an approach if Clang keeps this behavior.
At most, I think Mark's idea to use -fno-strict-aliasing only on dtoa.c and
nowhere
Eric V. Smith added the comment:
No, we won't be adding new features to 2.7. Sorry.
--
nosy: +eric.smith
resolution: -> rejected
stage: -> resolved
type: -> enhancement
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Eric V. Smith added the comment:
The examples don't cover it, but look at the documentation for setting
arbitrary mail headers such as CC.
And look at smtplib.SMTP.sendmail() on sending a message to arbitrary
recipients (to, cc, or bcc are all the same):
https://docs.python.org/2/library
Eric V. Smith added the comment:
You need to review how SMTP works. The contents of the mail message have no
bearing on where messages are sent. That's exactly how BCC works: there's
nothing in the message telling you who is BCC'd, but the mail is still sent to
the BCC recipients, via SMTP
Eric V. Smith added the comment:
So, you want to improve the examples? I wouldn't be opposed to that. I don't
see that there's any code to change.
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
___
Python tracker &
Changes by Eric V. Smith <e...@trueblade.com>:
--
resolution: rejected ->
stage: resolved -> needs patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Eric V. Smith added the comment:
Yes, I think it can be closed. Thanks!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28739>
___
__
Changes by Eric V. Smith <e...@trueblade.com>:
--
nosy: +eric.smith
title: Use namedtuple in Formatter.parse iterator response -> Use namedtuple in
string.Formatter.parse iterator response
___
Python tracker <rep...@bugs.pytho
Eric V. Smith added the comment:
It's in string.py, so it would be easy just to add a namedtuple there:
class Formatter:
...
def parse(self, format_string):
return _string.formatter_parser(format_string)
I don't see a need to add a structseq to _string, since it's a private API
Changes by Eric V. Smith <e...@trueblade.com>:
--
versions: +Python 3.7 -Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Eric V. Smith added the comment:
--
Eric.
> On Mar 3, 2017, at 6:36 AM, Bernhard M. Wiedemann <rep...@bugs.python.org>
> wrote:
>
>
> New submission from Bernhard M. Wiedemann:
>
> See https://reproducible-builds.org/ and
> https://reproducible-b
Eric V. Smith added the comment:
We absolutely cannot change this to give an error if the second or subsequent
parameters is absolute. I have code that reads user-named config files. If the
path is relative, it's relative to a config directory, but it's allowed to be
absolute
Eric V. Smith added the comment:
I'm -0 on a backport. The new behavior is more correct, but I don't like
changing the exception type in a micro release.
--
___
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/issue30978>
___
_
Eric V. Smith added the comment:
The reason that this was done was to give us flexibility in deciding how the
backslashes should be interpreted in the future. I announced it on python-dev
here: https://mail.python.org/pipermail/python-dev/2016-August/145979.html.
That message contains a link
Eric V. Smith added the comment:
> Unfortunately, as far as I know, clang still does not support
> function-level optimization pragmas. Maybe it was implemented
> recently, but then you would still have to have a workaround>
> for older versions.
I realize the answer is probably
Changes by Eric V. Smith <e...@trueblade.com>:
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31136>
___
_
Eric V. Smith added the comment:
Thanks. There was some work on this recently: I'll try and check 3.7 later
today.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
On 3.6.1 on Windows, I get:
% python3 bpo-31140.py
File "", line 1
(a>2s)
^
SyntaxError: invalid syntax
Which is far from ideal, but at least points to (a portion of) the correct text.
I won't have access to a copy of 3.6.2 or 3.
Eric V. Smith added the comment:
I'm in favor of backporting to 3.6. It's not an intrusive change and is helpful
in porting 2.x scripts.
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
This is on my list of things to review at PyCon, when I should finally have
some free time.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric V. Smith added the comment:
I'm okay with this change.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28974>
___
___
Pyth
Eric V. Smith added the comment:
We won't do that, because then we'd have two functions that do the same thing.
There's no sense having to learn two functions, just to achieve consistency.
Sorry.
--
___
Python tracker <rep...@bugs.python.org>
Eric V. Smith added the comment:
There's no particular reason, we just weren't careful about enforcing a
consistent style, especially on older code.
But whatever the reason, it's now too late to change this.
--
nosy: +eric.smith
resolution: -> wont fix
stage: -> resolved
Changes by Eric V. Smith <e...@trueblade.com>:
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30590>
___
_
Eric V. Smith added the comment:
You'll need to be careful about fully translating to python 3, though. What do
you do with:
print >> sys.stderr, "message"
or:
print "message",
?
--
nosy: +eric.smith
___
Python track
Eric V. Smith added the comment:
Sorry, I've been busy. I'll get to this soon, though.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
701 - 800 of 2689 matches
Mail list logo
