Changes by Ben Wolfson wolf...@gmail.com:
--
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
___
Python-bugs-list
Ben Wolfson added the comment:
Ping.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
___
Python-bugs-list mailing list
Unsubscribe
Ben Wolfson added the comment:
My own preference is to let this quote from PEP 3101 dominate the behaviour:
The rules for parsing an item key are very simple. If it starts with a digit,
then it is treated as a number, otherwise it is used as a string.
That means Petri's suggested solution
Ben Wolfson wolf...@gmail.com added the comment:
Ping!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
___
Python-bugs-list mailing
Ben Wolfson wolf...@gmail.com added the comment:
I can certainly address those issues---I'll hold off on doing so, though, until
it's clearer whether more substantive things come up, so I can just do it in a
swoop.
--
___
Python tracker rep
Ben Wolfson wolf...@gmail.com added the comment:
Here's a patch that works against the current unicode_format.h and implements
what Petri suggested.
--
Added file: http://bugs.python.org/file25699/strformat-no-braces.diff
___
Python tracker rep
Ben Wolfson wolf...@gmail.com added the comment:
Are you still willing to rework the patches?
Sure. Now that I've actually looked at unicode_format.h it looks like the
biggest (relevant) difference might just be that the file isn't named
string_format.h, so I suspect it will be pretty
Ben Wolfson wolf...@gmail.com added the comment:
Ping!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
___
Python-bugs-list mailing
Ben Wolfson wolf...@gmail.com added the comment:
just curious if there are any developments here since the first 3.3 alpha has
been released.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
Ben Wolfson wolf...@gmail.com added the comment:
All three patches look different to me.
Yeah, I verified that later; I'm not sure what made me think otherwise except
that I eyeballed them sloppily. (It's still true that they'd need to target a
different file for 3.3 now
Ben Wolfson wolf...@gmail.com added the comment:
I just noticed that the patch labelled strformat-as-document is actually the
same as the other one, owing to my incompetence. Anyway, as far as I can tell
the patches would have to be reworked in the light of recent changes anyway. I
am willing
Ben Wolfson wolf...@gmail.com added the comment:
The guys at #python-dev confirmed the same happens on 2.7 but not on 3.x.
Really? This is on gentoo, not debian, admittedly:
coelacanth ~ 11:12:36 $ python3
Python 3.1.3 (r313:86834, May 1 2011, 09:41:48)
[GCC 4.4.4] on linux2
Type help
Ben Wolfson wolf...@gmail.com added the comment:
This patch differs from the previous one; its goal is to bring the actual
behavior of the interpreter into line with the documentation (with the
exception of using only decimal integers, rather than any integers, wherever
the documentation
Ben Wolfson wolf...@gmail.com added the comment:
And here is a patch for Greg Ewing's proposal:
http://mail.python.org/pipermail/python-dev/2011-June/111934.html
Again, decimal integers rather than any kind of integers are used.
Both patches alter the exceptions expected in various places
Ben Wolfson wolf...@gmail.com added the comment:
undo integer - decimalinteger in docs
--
Added file: http://bugs.python.org/file22601/strformat-as-documented.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
Changes by Ben Wolfson wolf...@gmail.com:
Removed file: http://bugs.python.org/file22598/strformat-as-documented.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
Ben Wolfson wolf...@gmail.com added the comment:
(same as previous)
--
Added file:
http://bugs.python.org/file22602/strformat-just-identifiers-please.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
Changes by Ben Wolfson wolf...@gmail.com:
Removed file:
http://bugs.python.org/file22599/strformat-just-identifiers-please.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
Ben Wolfson wolf...@gmail.com added the comment:
Hm. As I interpret this:
The str.format() function will have
a minimalist parser which only attempts to figure out when it is
done with an identifier (by finding a '.' or a ']', or '}',
etc.).
The present implementation
Ben Wolfson wolf...@gmail.com added the comment:
PEP 3101 defines format strings as intermingled character data and markup.
Markup defines replacement fields and is delimited by braces. Only after markup
is extracted does the PEP talk about interpreting the contents of the markup.
So, given
Ben Wolfson wolf...@gmail.com added the comment:
str.format doesn't intermingle character data and markup. The PEP is quite
clear about the terms in this case, at least: the *argument* to str.format
consists of character data (passed through unchanged) and markup (processed).
That's what
Ben Wolfson wolf...@gmail.com added the comment:
From the PEP: Format strings consist of intermingled character data and
markup.
I know. Here is an example of a format string:
hello, {0}
Here is the character data from that format string:
hello,
Here is the markup:
{0}
This follows
Ben Wolfson wolf...@gmail.com added the comment:
Actually, that's the wrong place in MarkupIterator_next to include that loop.
The attached diff has it in the right place. The results of make test here
are:
328 tests OK.
1 test failed:
test_unicode
25 tests skipped:
test_codecmaps_cn
Ben Wolfson wolf...@gmail.com added the comment:
The semantics the docs suggest for index fields (namely that whatever is in the
index field is just passed to getitem) do seem to be right, no other processing
is done here, for instance:
d = {{0}:hi}
{0[{0}]}.format(d)
'hi'
import string
Ben Wolfson wolf...@gmail.com added the comment:
My last examples were actually just attempting to figure out what triggered the
unexpected behavior. I don't want to do expansion inside the field_name part!
(I'll have a reply to your previous comment about use-cases shortly
Ben Wolfson wolf...@gmail.com added the comment:
Here's my use case.
I'm writing a python version of the ruby library HighLine for CLI interaction,
to be called, uncreatively, PyLine. One of the moderately neat things about the
library is that it allows for color information to be embedded
New submission from Ben Wolfson wolf...@gmail.com:
As near as I can make out from
http://docs.python.org/library/string.html#formatstrings, the following
should return the string hi:
{0[!]}.format({!:hi})
We have a {, followed by a field name, followed by a }, the field name
consisting
Changes by Ben Wolfson wolf...@gmail.com:
--
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
___
Python-bugs-list
28 matches
Mail list logo
