Changes by Eric V. Smith e...@trueblade.com:
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
___
Python-bugs-list
Eric V. Smith added the comment:
What is '{:}' supposed to mean?
It should be the same as '{}'. That is, an empty format string.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
Eric V. Smith added the comment:
I think:
'{:}'.format(AF.IPv4)
'AF.IPv4'
is correct, assuming str(AF.IPv4) is 'AF.IPv4'. I'm not sure what:
'{:10}'.format(AF.IPv4)
should produce. There's a special case for an empty format string calling str().
I think that specifying __format__() would
Eric V. Smith added the comment:
I think that specifying __format__() would be best, except then you need to
decide what sort of format specification language you want to support, and
deal with all of the implementation details. Or, maybe just have Enum's
__format__ be:
def
Eric V. Smith added the comment:
For format, I think the question is should an IntEnum format like an int, with
the wacky exception of a specifier of '', or should it always format like a
str?
I assumed we'd want it to look like the str() version of itself, always. But
it's debatable.
I
Eric V. Smith added the comment:
I think IntEnum should act like a str for format() purposes. After all, having
a useful string representation is a prime reason it exists. If you want it to
act like a str() sometimes, and an int() at others, you're going to have to
parse the format specifier
Eric V. Smith added the comment:
If IntEnum.__format__ is going to parse the format string, it's a little
fragile. For example, say we modify int.__format__ to understand a Z
presentation type. Who's going to remember to update IntEnum.__format__?
For reference, the existing integer formats
Eric V. Smith added the comment:
I don't think it's possible for int (PyLong) to handle a decision to format
itself as a string. Personally, I'd like this:
format(3, 's')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: Unknown format code 's' for object of type
Changes by Eric V. Smith e...@trueblade.com:
--
assignee: - ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
___
Python-bugs
Eric V. Smith added the comment:
The value of int is always used, except when the format string is empty. PEP
3101 explicitly requires this behavior. For all built-in types, an empty
format specification will produce the equivalent of str(value). The built-in
type here refers to int, since
Eric V. Smith added the comment:
So what you're saying is that '{:}' is empty, but '{:10}' is not?
Yes, exactly. The part before the colon says which argument to .format() to
use. The empty string there means use the next one. The part after the colon
is the format specifier. In the first
Eric V. Smith added the comment:
It's not whether a field width is specified that makes it empty or not, it's
where there's anything in the format specifier at all. I'm trying to simplify
the conversation by using format() instead of str.format(), but I'm not
succeeding!
Going back
Eric V. Smith added the comment:
In order to avoid that logic, and cause more format specifiers to result in
str-like behavior, we'll need to implement an __format__ somewhere (IntEnum,
I guess) that makes the int or str decision.
If this is the way format is supposed to work, then I'll
Eric V. Smith added the comment:
On 8/15/2013 5:46 PM, Eli Bendersky wrote:
The whole point of IntEnum and replacing stdlib constants with it was
friendly str repr out of the box. This means that just printing out an
enum member should have a nice string representation. And just printing
Eric V. Smith added the comment:
On 8/15/2013 7:09 PM, Ethan Furman wrote:
Ethan Furman added the comment:
Eric V. Smith added the comment:
I think the answers should be:
- Formats as int if the length of the format spec is = 1 and it ends in
one of bdoxX (the int presentation types
Eric V. Smith added the comment:
On 8/15/2013 8:20 PM, Ethan Furman wrote:
The characters I list are the justification chars and the digits that would
be used to specify the field width. If
those are the only characters given then treat the MixedEnum member as the
member string
Eric V. Smith added the comment:
Objects/unicodeobject.c has this, at line 14316:
if (PyMapping_Check(args) !PyTuple_Check(args) !PyUnicode_Check(args))
ctx.dict = args;
else
ctx.dict = NULL;
and later at line 14348:
if (ctx.argidx ctx.arglen !ctx.dict
Changes by Eric V. Smith e...@trueblade.com:
--
title: '' % [1] doens't fail - '' % [1] doesn't fail
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18750
Eric V. Smith added the comment:
On 8/16/2013 12:24 AM, Ethan Furman wrote:
Ethan Furman added the comment:
Eric V. Smith added the comment:
But a datetime format string can end in 0, for example.
format(datetime.datetime.now(), '%H:%M:%S.00')
'20:25:27.00'
Not a problem, because
Eric V. Smith added the comment:
The code looks basically the same in 2.7, and there PyMapping_Check looks for
__getitem__, so maybe issue 5945 is just incorrect in its analysis.
In any event, I'm not sure this is worth fixing. There are lots of little
corner cases that could be broken
Eric V. Smith added the comment:
Oh, I don't feel my time has been wasted. Where else can I have a discussion of
__format__?
With this patch, given this:
class UpperString(str):
def __format__(self, fmt):
return str.__format__(self, fmt).upper()
class UpperEnum(UpperString, Enum
Eric V. Smith added the comment:
On 8/20/2013 9:26 PM, Ethan Furman wrote:
Sounds like the way forward is to specify in the docs how the default
Enum __format__ behaves (basically honors width and justification
settings to yield the name, anything else passes through to the Enum
member
Eric V. Smith added the comment:
I agree splitting this makes sense, so as to not delay the %-formatting fix.
While similar in principle, the fixes are unrelated. We may as well keep this
issue the __format__ part, since it's been most discussed here
Eric V. Smith added the comment:
I haven't had time to review this yet, but at least several of these, if true,
are definitely bugs that should be backported. 254.192.128.0 as a netmask?
Descending octets as the condition? Yikes.
--
nosy: +eric.smith
stage: - patch review
Eric V. Smith added the comment:
Looks good to me, too. Thanks for considering all of the feedback!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
Eric V. Smith added the comment:
It would be nice to combine the behaviors that defaultdict and the
case-insensitive comparisons.
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18986
Eric V. Smith added the comment:
Just today I was using a defaultdict where the keys are stock symbols. They're
case insensitive (at least for this particular application).
In this case I just str.upper everything, but it would be a nice feature to
case-preserve the keys that I pre-populate
Eric V. Smith added the comment:
True enough!
I was trying to distinguish keys that I populate with initial values (mostly
stock indexes) versus those where I just read values from a user-supplied file.
When I populate the index values, I'd like to preserve the case I initially
used. When I
Eric V. Smith added the comment:
On 09/17/2013 09:34 AM, R. David Murray wrote:
R. David Murray added the comment:
Because most often the time at which you want the original key is the point
at which you are about to re-serialize the data...so you need the value too.
I can't think
Eric V. Smith added the comment:
On 09/17/2013 10:12 AM, Eric V. Smith wrote:
On the other hand, I don't have a use case for the original key, anyway.
So I don't have a strong feeling about this, other than it feels odd
that the answer to the original question (I think on python-dev) how do
Eric V. Smith added the comment:
Can you print out sys.executable and sys.path in both cases, and post the
results here?
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19056
Eric V. Smith added the comment:
Glad to see it's working.
--
resolution: fixed - invalid
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19056
Eric V. Smith added the comment:
The Windows (and before it MS-DOS) EOF character is Ctrl-Z. Try that.
Depending on the toolset you use, it might use Ctrl-D as EOF. Cygwin's python
uses Ctrl-D.
--
nosy: +eric.smith
___
Python tracker rep
Eric V. Smith added the comment:
It's trying to be consistent on whatever platform it's on. I'd rather
python.exe match all other text-based .exe's on Windows. We can't have it both
ways.
But I agree it's a hassle. Cross-platform is a problem that Cygwin is trying to
solve, so I suggest you
Eric V. Smith added the comment:
Closing as rejected.
--
resolution: - rejected
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19089
Eric V. Smith added the comment:
If you could write up a concrete proposal, including which format specifiers
would be supported, that would be helpful.
Would it be extensible with something like __bformat__?
There's really quite a bit of work to be done to specify how this would work
Eric V. Smith added the comment:
Also, with the PEP 393 changes, the implementation will be much more difficult.
Sharing code with str (unicode) will likely be impossible, or require much
refactoring of the existing code.
--
___
Python tracker rep
Eric V. Smith added the comment:
I've lost track what we were talking about. I thought we were trying to support
b'something'.format() in 3.4, for a restricted set of arguments.
I don't see how a third-party package is going to help, if the goal is to allow
3.4 to be source compatible
Eric V. Smith added the comment:
Can you provide some code which demonstrates this?
It's easier to address this if we have known working (or non-working) examples.
Thanks.
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http
Eric V. Smith added the comment:
This isn't strictly related to printing a tuple. It's the difference between
str() and repr():
print (uäöü) # uses str
äöü
print repr(uäöü)
u'\xe4\xf6\xfc'
When the tuple is printed, it uses the repr of its constituent parts
Eric V. Smith added the comment:
As Martin points out, your first example is printing a string, not a tuple. The
parens here are not building a tuple, they are just used for grouping in the
expression, and are not doing anything in this example.
So my explanation still holds: everything
Eric V. Smith added the comment:
Remember that one reason for importing the C version at the bottom of the
python version is so that alternate implementations (PyPy, IronPython, Jython)
could provide partial versions of the C (or equivalent) versions. By importing
after the Python version
New submission from Eric V. Smith:
In
http://docs.python.org/library/string.html#format-specification-mini-language,
it says The fill character can be any character other than ‘{‘ or ‘}’.
But that's not actually true. It's only true when using str.format, as it does
the parsing
Eric V. Smith added the comment:
See also issue 19238.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19289
___
___
Python-bugs-list mailing
Eric V. Smith added the comment:
See also issue 19289.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19238
___
___
Python-bugs-list mailing
Eric V. Smith added the comment:
Looks good to me. Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19238
___
___
Python-bugs-list mailing
Eric V. Smith added the comment:
I suggest you get consensus on this idea on the python-ideas mailing list first.
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19427
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 rep...@bugs.python.org
http://bugs.python.org/issue17556
Eric V. Smith added the comment:
Can you show us the code that causes the problem?
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17608
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 rep...@bugs.python.org
http://bugs.python.org/issue17566
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 is '', which tells smtplib.SMTP
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
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 exception
Changes by Eric V. Smith e...@trueblade.com:
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17621
___
___
Python-bugs-list
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 rep
Eric V. Smith added the comment:
That looks great. Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8913
___
___
Python-bugs-list mailing
Changes by Eric V. Smith e...@trueblade.com:
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17630
___
___
Python-bugs-list
Changes by Eric V. Smith e...@trueblade.com:
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17633
___
___
Python-bugs-list
Eric V. Smith added the comment:
Could you construct a test (that would fail without your patch)?
Thanks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17633
Changes by Eric V. Smith e...@trueblade.com:
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17705
___
___
Python-bugs-list
Changes by Eric V. Smith e...@trueblade.com:
--
assignee: - eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17705
___
___
Python-bugs
Changes by Eric V. Smith e...@trueblade.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17728
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 tracker rep
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(__name__ + '.Point', 'x y z
Changes by Eric V. Smith e...@trueblade.com:
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17959
___
___
Python-bugs-list
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 an error, and will remain an error
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 rep...@bugs.python.org
http://bugs.python.org/issue6208
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 rep...@bugs.python.org
http://bugs.python.org/issue18031
Eric V. Smith added the comment:
I think it's just an oversight.
--
assignee: barry - brett.cannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18058
Eric V. Smith added the comment:
No reason I can think of, other than it never occurred to me to do it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18056
Eric V. Smith added the comment:
I don't think anyone would (or should!) write code that cares, so I think your
proposed change is a good one.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18070
Eric V. Smith added the comment:
See also issue18107, in particular
http://mail.python.org/pipermail/pypy-dev/2013-May/011433.html.
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3451
Eric V. Smith added the comment:
It's by design. Search for mutable default arguments, for example
http://docs.python-guide.org/en/latest/writing/gotchas.html#mutable-default-arguments
--
nosy: +eric.smith
resolution: - invalid
stage: - committed/rejected
status: open - closed
New submission from Eric V. Smith:
See:
http://mail.python.org/pipermail/python-dev/2013-June/127068.html
The find command:
find $(srcdir) '(' -name '*.fdc' -o -name '*~' \
-o -name '[@,#]*' -o -name '*.old' \
-o -name '*.orig' -o
Eric V. Smith added the comment:
My plan is to just fix this issue, right now, by changing the find command to
be:
find $(srcdir)/[a-zA-Z]* ...
That fixes this bug and keeps the current functionality.
If someone wants to open another issue about changing what distclean does, I
think
Eric V. Smith added the comment:
I'm not sure what you're saying. Given the function definition, the way you're
calling it is incorrect, and the error messages explain why.
Are you saying that these ways to call repeatfunc() are documented somewhere
that needs fixing? I couldn't find
Changes by Eric V. Smith e...@trueblade.com:
--
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18313
___
___
Python-bugs
Eric V. Smith added the comment:
I see. You can't call repeatfunc() and specify times with a named argument
because of *args. Interesting. I'll let Raymond weigh in.
--
status: pending - open
___
Python tracker rep...@bugs.python.org
http
Changes by Eric V. Smith e...@trueblade.com:
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18340
___
___
Python-bugs-list
Eric V. Smith added the comment:
Could you provide an entire example, showing the class num and how you assign
__div__?
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18474
Eric V. Smith added the comment:
While the classmethod version has some appeal, it doesn't extend well to
handling multiple exception types.
I'm -0 on this, in any event. I think the original code is more clear. Why
force people to learn (or recognize) a second idiom for something so simple
Eric V. Smith added the comment:
I agree with Bryan. Further, if the string is being interpreted as Tcl, then
this strikes me as a possible injection attack vector (although I'll admit to
not having looked at the code to see how the Tcl code is being used and/or
interpreted).
--
nosy
Eric V. Smith added the comment:
The case with 1.__format__ is confusing the parser. It sees:
floating point number 1. __format__
which is indeed a syntax error.
Try:
1 .__format__(u'n')
'1'
or:
(1).__format__(u'n')
'1
Eric V. Smith added the comment:
I believe the conversion is happening in Objects/abstract.c in PyObject_Format,
around line 864, near this comment:
/* Convert to unicode, if needed. Required if spec is unicode
and result is str */
I think changing the docs will result in more
Changes by Eric V. Smith e...@trueblade.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15039
Eric V. Smith added the comment:
I was just logging in to make this point, but Serhiy beat me to it. When I
wrote several years ago that this was easy, it was before the (awesome) PEP
393 work. I suspect, but have not verified, that having a bytes version of this
code would now require
Eric V. Smith added the comment:
The implementation may be difficult, therefore no one should attempt it?
The development cost and maintenance cost is surely part of the evaluation when
deciding whether to implement a feature, no?
--
___
Python
Changes by Eric V. Smith e...@trueblade.com:
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16131
___
___
Python-bugs-list
Eric V. Smith added the comment:
As this is a feature request, it can only be applied to 3.4. I've modified the
versions.
--
components: +Library (Lib)
nosy: +eric.smith
versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python
3.5
Eric V. Smith added the comment:
To Heikki Partanen excellent point in the review about date __format__ strings
allowing you to combine date formatting with other types of formatting:
This is a great point. It's the lack of this that (for example) requires the
logging module to have
Eric V. Smith added the comment:
It might be more motivating if you (Xavier de Gaye) could let us know of a
real-world problem caused by this behavior.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16489
Eric V. Smith added the comment:
I agree it's a bug. And the fix looks good to me.
Having said that: I haven't looked at the import.c version to verify what is
happening. Does the test pass under 3.2?
--
___
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/issue16612
___
___
Python-bugs-list
New submission from Eric V. Smith:
The python source code usually uses customiz* (341 instances) over
customis* (19 instance, 8 of which are in logging).
I realize foolish consistency, and all that, but I think the documentation
should all use the same conventions. I'd be happy to change
Eric V. Smith added the comment:
It looks like you need to use double-backslashes everywhere in your path, or
use single backslashes and raw strings (r).
--
nosy: +eric.smith
resolution: - invalid
status: open - closed
___
Python tracker rep
Eric V. Smith added the comment:
Apologies for reading too quickly. I've reopened this.
--
resolution: invalid -
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19528
Eric V. Smith added the comment:
Can you provide a small, stand-alone program that demonstrates the problem? In
particular, I want to see how this filename is provided to logging.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Eric V. Smith e...@trueblade.com:
--
resolution: invalid -
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19528
Eric V. Smith added the comment:
Thanks, Peter.
--
resolution: - invalid
stage: - committed/rejected
status: open - closed
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19528
Eric V. Smith added the comment:
Agreed with Nick. I think it's clear than any change to the behavior will have
to take place inside os.path. I just don't know what that change would be.
--
___
Python tracker rep...@bugs.python.org
http
201 - 300 of 2689 matches
Mail list logo
