Changes by Eric V. Smith :
--
keywords: +needs review
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue17633>
___
___
Python-bug
Eric V. Smith added the comment:
I think the functionality is reasonable for this module.
When I originally read the bug title, I was concerned that it was actually
doing a reverse DNS lookup, which would not be appropriate. But now I realize
it's just computing the name that would be
Eric V. Smith added the comment:
I'd prefer to leave the trailing dots. It's the technically correct thing to do.
And as they say, technically correct is the best kind of correct!
--
title: Add ipaddress property to get name of reverse DNS pointer -> Add
ipaddress propert
Eric V. Smith added the comment:
The patch looks good to me, save for a versionadded tag in the docs. I've
mentioned it on Rietveld.
Not to get in to bikeshedding on the name, but I'd prefer something with PTR in
the name. I'm an old-timer, and think of these as "PTR lo
Eric V. Smith added the comment:
Or, now that I think about it some more, maybe leave the name as
reverse_pointer and just mention PTR records in the documentation.
--
___
Python tracker
<http://bugs.python.org/issue20
Eric V. Smith added the comment:
I concede the point on the trailing dot.
The reason we used to always use it is that it prevented the local resolver
from first trying to append the host's default domain name (as, for example,
defined in /etc/resolv.conf as "search"). I
Eric V. Smith added the comment:
The documentation change looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue20480>
___
___
Python-bugs-list m
Eric V. Smith added the comment:
That would be a great improvement. It's in Python/formatter_unicode.c, line
245, in parse_internal_render_format_spec().
That code knows about the format spec, but not the type being formatted. That
would be easy enough to pass in.
This fix would only
Eric V. Smith added the comment:
int, float, str, and complex are the types formatted by that code.
Notice that Decimal already has a better message:
>>> format(Decimal(42), 'tx')
Traceback (most recent call last):
...
ValueError: Invalid format specifier: tx
>>>
Eric V. Smith added the comment:
Looks good to me. Once 3.5 is open for new features, I'll commit this. (But
feel free to ping me if you think it's lingering!)
Thanks!
--
assignee: -> eric.smith
___
Python tracker
<http:/
Eric V. Smith added the comment:
re.match requires a match at the beginning of the string. From the docs: "If
zero or more characters at the beginning of string match the regular expression
pattern, ...".
If you switch to re.search, they'll all match:
>>> r
Changes by Eric V. Smith :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20810>
___
___
Python-bugs-list
Eric V. Smith added the comment:
I think you always want the leading zero. Mark (Dickinson), what do yo think?
And I also think changing it at this point would be problematic.
--
nosy: +anthonybaxter, barry, benjamin.peterson, eric.araujo, georg.brandl,
gvanrossum, lemburg, loewis
Eric V. Smith added the comment:
Oops, not sure how the nosy list got changed. Sorry about that.
--
nosy: -anthonybaxter, barry, benjamin.peterson, eric.araujo, georg.brandl,
gvanrossum, lemburg, loewis, tarek
___
Python tracker
<h
Eric V. Smith added the comment:
I still think this is a special case that we won't "fix". And even if we did,
you'd have to wait until 3.5.
But instead of your solution, it might be easier to wrap your floats in a class
that implements your version of format, based on
Eric V. Smith added the comment:
Please discuss this on the python-ideas mailing list, then if there's interest
we'll re-open this issue.
I'm -0 on the idea, but I haven't really thought about it much.
--
nosy: +eric.smith
resolution: -> rejected
stage: ->
Eric V. Smith added the comment:
There is some history for using "in" for containment. I'm porting some code
from IPy (https://pypi.python.org/pypi/IPy/), and it uses "in".
It would make my life easier if "in" worked in ipaddress, but then again it
wo
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue20899>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric V. Smith :
--
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue10379>
___
___
Python-bug
Changes by Eric V. Smith :
--
assignee: docs@python ->
keywords: +easy
stage: -> needs patch
type: -> behavior
___
Python tracker
<http://bugs.python.or
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: -> resol
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'
--
___
Py
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
<h
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
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
<http://bugs.python.org/issue28
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:
I withdraw my concern. I was thinking it would affect the caller, but of course
it won't. Apologies.
--
___
Python tracker
<http://bugs.python.org/is
Eric V. Smith added the comment:
It looks good to me, save for one tiny issue. I left a review comment.
--
___
Python tracker
<http://bugs.python.org/issue28
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
<http://bugs.python.org/is
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(
Changes by Eric V. Smith :
--
stage: -> resolved
___
Python tracker
<http://bugs.python.org/issue28975>
___
___
Python-bugs-list mailing list
Unsubscrib
Eric V. Smith added the comment:
https://github.com/python/devguide/blob/github/runtests.rst
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue29
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'
Furthermo
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-stri
Eric V. Smith added the comment:
Do you have a link to the SO question?
--
___
Python tracker
<http://bugs.python.org/issue29104>
___
___
Python-bugs-list mailin
Eric V. Smith added the comment:
Yes:
>>> f'\{2*5}'
'\\{10'
I agree '\\10' would make sense.
--
___
Python tracker
<http://bugs.python.org/issue29104>
___
_
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
<http://bugs.python.org/issue29
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue29144>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue29164>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 ord
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
___
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
<http://bugs.python.org/is
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 nam
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 sy
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, non
Changes by Eric V. Smith :
--
nosy: +eric.smith
title: Use namedtuple in Formatter.parse iterator response -> Use namedtuple in
string.Formatter.parse iterator response
___
Python tracker
<http://bugs.python.org/issu
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'
Changes by Eric V. Smith :
--
versions: +Python 3.7 -Python 3.5
___
Python tracker
<http://bugs.python.org/issue29696>
___
___
Python-bugs-list mailing list
Unsub
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&#x
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
<http
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
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
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
Changes by Eric V. Smith :
--
title: Roudning/Large Int representation error with multiplication and division
-> Rounding/Large Int representation error with multiplication and division
___
Python tracker
<http://bugs.python.org/issu
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.smi
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
___
P
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
Eric V. Smith added the comment:
I don't think such files are common: I've never seen such a file "in the wild".
I created one, by accident, while testing PEP 420.
OTOH, it was surprisingly easy to create the malform
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue17247>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
Mark is the ultimate authority here, but my recollection is (and a quick scan
of the code shows) that half to even rounding is used in all of our float to
string conversions. So that includes %f and float.__format__, among others
Eric V. Smith added the comment:
What would this give:
tm = datetime.time(13, 20)
later = tm + datetime.timedelta(hours=47, minutes=44)
datetime.time(13, 4)? Or raise an exception?
I've thought about this before, but it's always a problem when going over date
boundaries. If
Eric V. Smith added the comment:
I've just looked through the code for 2.7. It uses short float repr for both
%-formatting and for float.__format__. So they both use Gay's code, and both
should work the same as they do in 3.2+. In all cases, round-half-to-even is
used.
It's 2.
Changes by Eric V. Smith :
--
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue17280>
___
___
Pyth
Eric V. Smith added the comment:
This is a duplicate of issue 13598. I'll add you to nosy over there.
--
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyth
Changes by Eric V. Smith :
--
nosy: +binkert
___
Python tracker
<http://bugs.python.org/issue13598>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue17336>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
Evgeny: I completely agree. It's unfortunate that argparse doesn't work that
way.
However, I think it's too late to change this behavior without adding a new
parser. I don't think existing argparse can be changed to not operate the
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue17457>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
I agree with David. This is a programming error, and should result in an
exception.
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue17
Eric V. Smith added the comment:
Can you show us the code that causes the problem?
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue17
Eric V. Smith added the comment:
I was going to blame Barry, but I see he beat me to it :)
It looks like an oversight, and it shouldn't be abstract.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Eric V. Smith:
In the mail hook, there's a comment that says:
'''
To set the SMTP server to something other than localhost, add a [smtp]
section to your hgrc:
[smtp]
host = mail.python.org
port = 25
'''
This is not true. The default host
Eric V. Smith added the comment:
Barry meant that the upstream program that triggered this error has been
changed to call format_string() instead of format(). The bug still exists in
format().
My suggestion is to have format() be an alias for format_string(). Deprecating
format() is an
Eric V. Smith added the comment:
So I guess the question is: would this be a bug fix and applied to 2.7 and 3.3,
or just an enhancement for 3.4?
I think it would be a bug fix and thus should be backported. It's not like we'd
be breaking any working code, unless it was expecting the
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue17621>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
My only suggestion would be that the datetime example would be better if it
actually used a time portion, similar to the strftime example above it.
Otherwise, it looks good.
--
___
Python tracker
<h
Eric V. Smith added the comment:
That looks great. Thanks!
--
___
Python tracker
<http://bugs.python.org/issue8913>
___
___
Python-bugs-list mailing list
Unsub
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue17630>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue17633>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
Could you construct a test (that would fail without your patch)?
Thanks.
--
___
Python tracker
<http://bugs.python.org/issue17
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue17705>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric V. Smith :
--
assignee: -> eric.smith
___
Python tracker
<http://bugs.python.org/issue17705>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Eric V. Smith :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Eric V. Smith added the comment:
Indeed, this should be on python-ideas. Eric: can you start a thread over
there? Thanks.
--
nosy: +eric.smith
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
___
Python track
Eric V. Smith added the comment:
I agree it should work the same as Enum, and I agree it should be possible to
supply the module name. But wouldn't it be cleaner as:
Point = namedtuple('Point', 'x y z', module=__name__)
rather than:
Point = namedtuple(__
Changes by Eric V. Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue17959>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
But int has its own __format__ method, so this does not apply. Per the title of
this issue, this only refers to object.__format__.
For example:
This works now, and will continue working:
>>> format(2, '1')
'2'
This is currently
Eric V. Smith added the comment:
I say close it. Any "shell detection" is likely to be fragile, and any changes
are likely to break something. It's not worth the risk.
--
___
Python tracker
<http://bugs.py
Eric V. Smith added the comment:
I agree that we should not say that %-formatting will be removed from the
language. Not until Python 5000, anyway.
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue18
Eric V. Smith added the comment:
This is a duplicate of issue 1467929.
--
nosy: +eric.smith
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Eric V. Smith added the comment:
You should discuss this on the python-ideas mailing list. Then if there's
traction there, we'll re-open this issue. Please reference this issue number
when starting the discussion on python-ideas so we can find it later.
--
nosy: +eric.sm
Eric V. Smith added the comment:
hash() is not defined to be unique, so you're always going to have collisions.
The behavior of hash() for int that you're seeing is not a bug.
There's some background here:
http://stackoverflow.com/questions/10130454/why-do-1-and-2-both-hash
Eric V. Smith added the comment:
I'm not sure this should be documented. It follows from int and bool
equivalence. Plus, I consider it an anti-pattern.
We don't want to document everywhere you can pass a bool where an int is called
for. That's thousands of places.
Changes by Eric V. Smith :
--
stage: -> resolved
___
Python tracker
<http://bugs.python.org/issue23083>
___
___
Python-bugs-list mailing list
Unsubscrib
Eric V. Smith added the comment:
This works fine for me, too, using the Windows version of 3.4.2 downloaded from
python.org.
2 questions:
- where did you download Python?
- which shell are you using?
--
nosy: +eric.smith
___
Python tracker
<h
Eric V. Smith added the comment:
I'm glad you found it!
--
resolution: fixed -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pyth
Eric V. Smith added the comment:
Not that I think it's worth changing for this case, but I find code like this
better written as:
if some_test:
fl = contextlib.closing(open(sys.argv[1]))
else:
fl = sys.stdin
with fl as fl:
do_stuff(fl)
This way you don't need another
Eric V. Smith added the comment:
Good point on contextlib.closing not being needed. I usually use this pattern
on things that aren't files!
On second thought, the with statement will close sys.stdin, so this isn't a
valid pattern here. Sorry for
Eric V. Smith added the comment:
I think Michael is asking if the proposed change would ever be accepted. If the
answer is "no, not even if you write the tests and update the documentation",
then there's no sense putting the work into this. That seems like a reasonable
que
Eric V. Smith added the comment:
I don't think we want to encourage the type of coupling that arises from
subclassing, especially when when overriding an undocumented method. I'm +1 on
the change. I'll review the patch. Michael: can you write the tests, and
hopefully docs?
-
2301 - 2400 of 2699 matches
Mail list logo
