Eric Smith added the comment:
Also note that this patch causes a few tests to fail, since they're
trying to ensure that '{}'.format will fail. If we go forward I'll
address that too, of course.
--
message_count: 15.0 -> 16.0
___
Changes by Eric Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue5481>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Smith added the comment:
I'm thinking of allowing you to mix keywords and auto-numbering, but not
manual numbering and auto-numbering. This would be so we could do:
>>> '{:{fmt}} {:{fmt}}'.format(3.1415, 2.71828, fmt='1.4f')
'pi=3.1415 e=2.7183'
Eric Smith added the comment:
Copy and paste error. That should be:
>>> 'pi={:{fmt}} e={:{fmt}}'.format(3.1415, 2.71828, fmt='1.4f')
'pi=3.1415 e=2.7183'
--
___
Python tra
Eric Smith added the comment:
Should string.Format also support auto-numbering?
It seems like it should, but I'm not convinced it's possible without
modifying the signatures to the public methods, in particular
get_field(). The design of string.Format doesn't support state tha
Eric Smith added the comment:
I believe this patch is complete. I need to add tests and documentation,
but the code itself should be finished.
Here's the normal case:
>>> '{} {}'.format('test', 0)
'test 0'
It also handles error checking:
>>&
Eric Smith added the comment:
About '{:{fmt}}' and other wacky combinations, like '{.__doc__}':
It's much easier and cleaner in the code to allow these cases than it
would be to disallow them. And I rather like the '{:{fmt}}' example!
I suggest leaving th
Changes by Eric Smith :
Removed file: http://bugs.python.org/file13283/half-baked-not-for-real-use.patch
___
Python tracker
<http://bugs.python.org/issue5237>
___
___
Eric Smith added the comment:
Committed:
r70364 (trunk)
r70366 (py3k)
The docs still need updating. If anyone with more knowledge of the
documentation system than I have would like to tackle those, please feel
free!
--
priority: -> high
resolution: -> ac
Eric Smith added the comment:
I implemented this one:
field_name::= (identifier | integer | ) ("." attribute_name |
"[" element_index "]")*
Which I would have written as:
field_name::= (identifier | integer)? ("." attribute_name |
&quo
Eric Smith added the comment:
Antoine Pitrou wrote:
> The problem seems to be that the thousands separator on the Solaris
> variant of en_US is an empty string (rather than a comma) (*), and
> apparently it hits a bug in the padding mechanism (which perhaps assumes
> that t
New submission from Eric Smith :
I think the way leading zero padding is handled for int and float by
format's 'n' code is a bug.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en_US.UTF8')
'en_US.UTF8'
>>> format(1
Eric Smith added the comment:
C# doesn't seem to have the issue because they don't allow any modifies
when specifying locale-aware formatting. Specifying a picture seems to
be the only way to get leading zeros added.
Similarly, Java looks to be pic
Eric Smith added the comment:
Oops, assigning it to you was an error. I was just trying to figure out
what your userid is so I could add you to Nosy, and I was using
"Assigned To" to find it. I've fixed that.
The current behavior is an accident of the implementation. The
imple
Eric McRae added the comment:
Had forgotten about this. Just re-ran my test and it works fine now.
My current versions are Python 2.5.1 and Tk 8.4
So long and thanks for all the fish...
--
status: open -> closed
versions: +Python 2.5 -Python
Eric Smith added the comment:
> I also not fan on functions having different result type
> (format->bytes or str, it depends...).
In 3.x, str.format() and bytes.format() would be two different methods
on two different objects. I don't think there's any expectation that
New submission from Eric Smith :
If no format specifier is supplied to a float, it's supposed to work
like 'g', but with at least one digit after the decimal. This works for
non-exponential notation:
>>> format(1., '')
'1.0'
>>> format(1.
Changes by Eric Smith :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue5686>
___
___
Python-bugs-list mailing list
Unsubscri
Eric Smith added the comment:
The documentation doesn't agree with the PEP. The docs at
http://docs.python.org/library/string.html#formatstrings just say '' is
the same as 'g'. It does not draw a distinction between exponential and
fixed output.
The PEP has the &quo
Changes by Eric Smith :
--
assignee: -> eric.smith
___
Python tracker
<http://bugs.python.org/issue5690>
___
___
Python-bugs-list mailing list
Unsubscri
Eric Smith added the comment:
Problem was a debug #ifdef in the wrong place. Sorry for not testing in
non-debug mode.
Fixed in r71184.
--
priority: release blocker -> normal
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open
Eric Smith added the comment:
This isn't testing what I thought it was testing. I'd forgotten that
format(x, '') is exactly equivalent to str(x).
The better test is using a format string of '<':
>>> 1e200.__format__('<')
'1.0
Eric Smith added the comment:
My changes on the py3k-short-float-repr branch include:
- Create a new function PyOS_double_to_string. This will replace
PyOS_ascii_formatd. All existing internal uses of PyOS_ascii_formatd
follow this pattern: printf into a buffer to build up the format string
Eric Smith added the comment:
I believe this is a duplicate of issue 4482. I'm closing this and will
add everyone who is nosy on this to be nosy on 4482.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://b
Eric Smith added the comment:
This is a duplicate of 4799, which I've closed.
I've resisted fixing this because differences in various platform
sprintf's have made it difficult. Now that Mark Dickinson and I are
close to removing the use of sprintf for float formatting, I'
Eric Smith added the comment:
Actually this isn't quite a duplicate of 4799, but it's close. Any fix
to this issue will also address 4799's original report:
> On windows, with python 2.6, s = '%s' % float('inf') is 'inf',
Eric Smith added the comment:
This won't get fixed in 3.0 or 2.6. Still not sure about 2.7, but I'm
considering how to fix it there.
--
versions: -Python 2.6, Python 3.0
___
Python tracker
<http://bugs.python.
Changes by Eric Smith :
--
nosy: +marketdickinson
___
Python tracker
<http://bugs.python.org/issue3382>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Smith added the comment:
Agreed. That might be the strategy for 2.7.
But it depends on how much of the other float and int formatting code I
can re-use from 3.1. If I can hide the 2.7/3.1 differences in
PyOS_double_to_string, then the 2.7 and 3.1 code should be identical,
and the fix will
New submission from Eric Blond :
Here's the traceback I got:
===
>>> s.serve_forever()
Exception happened during processing of request from ('127.0.0.1',
54611)
Traceback (most recent call last):
File "C:\Python30\lib\s
Eric Blond added the comment:
That's it actually.
I forgot to call base class' setup() method when I redefined it in my
subclass. When I properly call StreamRequestHandler.setup() on my
derived class' setup(), everything works fine.
I'm not a socketserver speciali
Changes by Eric Blond :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue5746>
___
___
Python-bugs-list mailing list
Unsubscri
New submission from Eric Smith :
All of the macros it defines around line 565 should either already be in
stringdefs.h, or they should be added there.
The same issue exists in Objects/bytearrayobject.c. I haven't looked in
2.7, but I assume the same problem exists there.
--
ass
New submission from Eric Smith :
The point of the empty type code is to make sure a number looks like a
float (so as to avoid formatting 2.0 as "2"). But if we have an
exponent, the result already looks like a float, so there's no need to
modify the number further.
Eric Smith added the comment:
For a more detailed discussion, scroll to the bottom of
http://mail.python.org/pipermail/python-dev/2009-April/088417.html
--
___
Python tracker
<http://bugs.python.org/issue5
Eric Smith added the comment:
Fixed in trunk (will be 3.1) in r71665.
--
___
Python tracker
<http://bugs.python.org/issue5515>
___
___
Python-bugs-list mailin
Changes by Eric Smith :
--
___
Python tracker
<http://bugs.python.org/issue5515>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/m
Eric Smith added the comment:
Fixed in py3k (will be 3.1) in r71665.
--
___
Python tracker
<http://bugs.python.org/issue5515>
___
___
Python-bugs-list mailin
Eric Smith added the comment:
Fixed in py3k (which will become 3.1) in r71665.
--
___
Python tracker
<http://bugs.python.org/issue5772>
___
___
Python-bugs-list m
Eric Smith added the comment:
Terry, are you still interested in documenting this (please say yes!)?
I'm hoping it can be done by the beta release.
Thanks.
Eric.
--
___
Python tracker
<http://bugs.python.org/i
Eric Smith added the comment:
Terry J. Reedy wrote:
> Terry J. Reedy added the comment:
>
> Yes, added to 'do in next few days' list.
Thanks so much.
--
___
Python tracker
<http://bug
New submission from Eric Smith :
With the changes in r71665, w_object() in marshal.c needs to be checked
for out of memory errors when converting floats to strings. I'm not
convinced the existing error checking was correct, but I haven't spent a
lot of time looking at it.
The fact tha
Eric Smith added the comment:
Also, remove_trailing_zeros should go inside the #ifdef so it's not
included if Gay's code is being used.
--
___
Python tracker
<http://bugs.python.
Eric Smith added the comment:
I agree that there should be 2 behaviors, not 3.
This patch looks okay to me, and tests pass both with and without
defining PY_NO_SHORT_FLOAT_REPR.
One nit: You don't need to use Py_CHARMASK when using the ISDIGIT macro
locally defined in pystrtod.c. On the
Eric Smith added the comment:
I definitely think that if you go with isdigit, you need the macro. I've
been bitten by this in 3.0.
My actual suggestion is to go with isdigit and the macro everywhere in
this file and all files.
But for just this checkin, ISDIGIT is probably
New submission from Eric Smith :
PEP 378 says that the ',' format option applies to types 'd', 'e', 'f',
'g', 'E', 'G', '%' and 'F'. I think this should also be extended to
include the empty type '&#x
Eric Smith added the comment:
I updated the PEP in r71686. I'll fix the code and add a test after I
backport the entire thing to 2.7.
--
___
Python tracker
<http://bugs.python.org/i
Eric Smith added the comment:
I concur. I've also been bitten by forgetting Py_CHARMASK, so a single
version that took this into account (and was locale-unaware) would be
welcome.
In private mail I'd mentioned that if these are functions, they should
take int. But I now think that&#
Eric Smith added the comment:
Fixed in r71783.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue5775>
___
___
Eric Smith added the comment:
Thanks, Terry. Your changes look reasonable to me. Can you commit them,
or at least convert it to a patch against the existing docs?
--
___
Python tracker
<http://bugs.python.org/issue5
Eric Smith added the comment:
Thanks, Terry.
I think the only changes I'll make are:
arg_name: (`identifier` | `integer`)*
should be:
arg_name: (`identifier` | `integer`)?
And leave:
conversion: "r" | "s"
instead of:
conversion: "r" | "
Eric Smith added the comment:
Documentation changes checked into trunk in r71788 and py3k in r71790.
Issue closed.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Eric Smith added the comment:
Also, see _toupper/_tolower in Objects/stringlib/stringdef.h and
Objects/stringobject.c. Those should be rationalized as well.
--
___
Python tracker
<http://bugs.python.org/issue5
Eric Smith added the comment:
Fixed in trunk as part of r71796. Closing the issue.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Eric Smith added the comment:
Fixed in trunk as part of r71796. Closing the issue.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Eric Smith added the comment:
Checked in to trunk in r71802 and py3k in r71804.
--
resolution: -> fixed
status: open -> closed
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/
Eric Smith added the comment:
I agree on the alignment issue. Maybe if you explicitly ask for the
"sign" of a NaN, it should always be a space.
And when requesting leading zeros, you also get leading spaces instead?
--
___
Python trac
Eric Smith added the comment:
Wow, that does greatly simplify printing. One nit: the variable named
'im' isn't needed any more, you could just use 'pim'. Not sure if the
asymmetry with 're' and 'pre' is worthwhile, though.
Mark Dickinson wrote:
&
Eric Smith added the comment:
The fallback code, around line 633 in the patched version of pystrtod.c,
probably also needs to be modified. It's this code that would need
backporting to 2.7.
--
___
Python tracker
<http://bugs.python.org/i
Changes by Eric Devolder :
--
nosy: +keldonin
___
Python tracker
<http://bugs.python.org/issue5831>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Eric Smith :
PyOS_ascii_formatd is no longer needed, now that we have
PyOS_double_to_string. PyOS_ascii_formatd has a horrible interface,
requiring a format string to be composed and then parsed. The format
string is a very limited printf-like format string.
In 2.7 and 3.1
Eric Smith added the comment:
It makes most sense to name the new 2.7 replacement function to be
_PyOS_double_to_string (with a leading underscore). It will be the same
as PyOS_double_to_string, except that instead of allocating a buffer and
returning it, you will supply it a buffer and a
Eric Smith added the comment:
Committed in trunk as r71938. I'll use a slightly different strategy in
py3k.
--
___
Python tracker
<http://bugs.python.org/i
Eric Smith added the comment:
I agree this is a feature request. It comes down to:
What should the format specifier mini-language for complex numbers look
like?
Should it look like the existing mini-language for floats, but have the
format specified twice, with some sort of delimiter? Or just
Eric Smith added the comment:
Mark Dickinson wrote:
>> What should the format specifier mini-language for complex numbers look
>> like?
>> Should it look like the existing mini-language for floats, but have
>> the format specified twice, with some sort of delimiter?
&g
Eric Smith added the comment:
Checked in for trunk (r71938) and py3k (r71989).
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Changes by Eric Smith :
--
assignee: -> eric.smith
___
Python tracker
<http://bugs.python.org/issue1588>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Eric Smith :
--
assignee: jafo -> eric.smith
versions: +Python 2.7 -Python 2.6
___
Python tracker
<http://bugs.python.org/issue1467929>
___
___
Py
Eric Smith added the comment:
I'll implement this by adding a pyctype.h and pyctype.c, mimicking
. I'll essentially copy and rename the methods in
bytes_methods.[ch], then change bytes_methods.h to refer to the new
versions, for backward compatibility.
--
assignee: -&g
Eric Smith added the comment:
The patch incorrectly raises an exception for:
'%(a)s %%' % {'a':'xyz'}
I'll look into fixing it.
--
___
Python tracker
&
Eric Smith added the comment:
> I don't see any problem with dealing with width, alignment
> and padding with a user-specified fill character; I think we
> should keep these if possible. It's just zero padding where
> it's not clear what should happen.
You're
Eric Smith added the comment:
> This sounds good to me. I assume a '+' would still affect
> the sign of the real part?
Forgot to reply to this part.
Yes, a '+', '-', or ' ' would still affect the real
Eric Smith added the comment:
> More specifically, how about allowing widths, and the
> '<', '>' and '^' alignment specifiers, but not '=', or
> '0' for zero-padding.
That sounds correct.
> I suppose that thousands separato
Eric Smith added the comment:
Checked in to trunk (rr72040) and py3k (r72044).
Windows buildbots look okay, closing.
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Eric Smith added the comment:
Mark Dickinson wrote:
> (1) What about parentheses? The current complex repr and str have
> parentheses in them, for reasons that I still don't really understand.
>
> I'd suggest leaving them out altogether; except that I have
> the im
Eric Smith added the comment:
See the attached patch. Comments welcome.
I'm not sure I'm doing the right thing with 'g' and appending zeros:
>>> format(3+4j, '.2')
'(3+4j)'
>>> format(3+4j, '.2g')
'3.0+4.0j'
>>
Eric Smith added the comment:
Mark Dickinson wrote:
> The trailing zeros thing is heavily bound up with issue 5858, of course;
> I think we need a decision on that, one way or the other. One problem
> is that I'm only proposing the issue 5858 change for py3k, not trunk.
I don&#x
Eric Smith added the comment:
Here's a patch against py3k, with one slight change with non-empty
presentation types.
--
Added file: http://bugs.python.org/file13802/issue-1588-1-py3k.patch
___
Python tracker
<http://bugs.python.org/i
Eric Smith added the comment:
Mark Dickinson wrote:
>> Although I guess if we wanted to, we could say that the empty
>> presentation type is equivalent to 'g', but gives you parens.
>
> This works for me.
Me, too.
> [about suppressing real zeros...]
>&g
Eric Smith added the comment:
I'm also going to disallow the '%' format code. I don't think it makes
any sense to convert a complex number to a percentage.
--
___
Python tracker
<http://bu
Eric Smith added the comment:
...
> Is this intentional? I was expecting to get strings of length 20,
> with the substring '(123+4j)' positioned either in the middle
> or on the left or right.
No, not intentional. I'll fix it an
Eric Smith added the comment:
I agree this should be changed.
This:
>>> format(1234.56, '.4')
'1235.0'
is definitely a problem.
--
___
Python tracker
<
Eric Smith added the comment:
This is a patch against py3k, including tests in test_complex.py. It
should deal with the padding, but let me know.
--
stage: test needed -> patch review
Added file: http://bugs.python.org/file13805/issue-1588-2-py3k.pa
Eric Smith added the comment:
I also propose to disallow the '=' alignment flag. It means put the
padding between the sign and the digits, and since there are 2 signs,
it's not clear what this would mean.
Remember, by using .real and .imag, you can achieve this level of
Eric Smith added the comment:
I think these patches are complete. One for py3k, one for trunk. If no
complaints, I'll apply them before this weekend's py3k beta.
--
Added file: http://bugs.python.org/file13807/issue-1588-trunk.patch
Changes by Eric Smith :
Added file: http://bugs.python.org/file13808/issue-1588-py3k.patch
___
Python tracker
<http://bugs.python.org/issue1588>
___
___
Python-bugs-list m
Changes by Eric Smith :
Removed file: http://bugs.python.org/file13801/issue-1588-0.patch
___
Python tracker
<http://bugs.python.org/issue1588>
___
___
Python-bugs-list m
Changes by Eric Smith :
Removed file: http://bugs.python.org/file13802/issue-1588-1-py3k.patch
___
Python tracker
<http://bugs.python.org/issue1588>
___
___
Python-bug
Changes by Eric Smith :
Removed file: http://bugs.python.org/file13805/issue-1588-2-py3k.patch
___
Python tracker
<http://bugs.python.org/issue1588>
___
___
Python-bug
Changes by Eric Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue5872>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Smith added the comment:
I'm getting an undefined _remove_trailing_zeros using a normal build
(not using the fallback code). I think it's now always called.
--
stage: patch review -> needs patch
___
Python tracker
<http:/
Eric Smith added the comment:
I think this is great stuff, Larry. It's a definite improvement.
Unfortunately with my workload of other Python issues, I'm not going to
be able to review this before the 3.1 beta. I don't use many
PyTypeObject's, so my review would be mostly
Eric Smith added the comment:
Using the _v2 patch, I tested both with the fallback code and with Gay's
code, and both work.
It's sort of shocking just how much effort you had to go through! But I
can't see a simpler way to do it.
It looks good to me.
--
stage: needs
Eric Smith added the comment:
Thanks, Mark.
I'm not so worried about the code, but more so the tests. As far as the
code goes, it's really a combination of float and string formatting. I
copied the float formatting and refactored the string formatting so I
could reuse it.
But
Eric Smith added the comment:
If http://bugs.python.org/issue5859 is implemented, then this issue
really just becomes making sure NAN and INF are uppercase.
--
___
Python tracker
<http://bugs.python.org/issue3
Eric Smith added the comment:
The doc patch doesn't apply cleanly for me.
There are a number of code cleanups in the patch, like 0->False,
1->True, the improvement of the params to path(), improvement in
isabs(), etc. I think these cleanups should be made in a separate patch,
s
Eric Smith added the comment:
The patch looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue5859>
___
___
Python-bugs-list mailing list
Unsub
Eric Smith added the comment:
Is this suggestion for all types, or just complex? Because float has the
same issue.
>>> format(pi, '')
'3.14159265359'
[38243 refs]
>>> format(pi, '>')
'3.14159'
--
__
Eric Smith added the comment:
> Hmm. That also seems wrong to me. So I guess it's a suggestion
> for float as well, which means it's not specific to this issue.
> Should I open a separate feature request?
Yes, this is a separate issue. It comes from PEP 3101's specifi
Eric Smith added the comment:
This looks okay to me (although since it's not hooked up I haven't
tested it). I particularly like that it doesn't allow leading
whitespace, and that the caller no longer has to remember errno
(forgetting to set and/or test it have both caused me
3101 - 3200 of 6620 matches
Mail list logo
