Changes by Benjamin Peterson benja...@python.org:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
Benjamin Peterson added the comment:
Should be generally patched up in 3.4. Try it out.
--
nosy: +benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
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
Nick Coghlan added the comment:
This actually came up on the core-mentorship list (someone was trying to
translate old mod-formatting code that used a colon in the lookup names and
discovered this odd behaviour)
My own preference is to let this quote from PEP 3101 dominate the behaviour:
The
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
___
Python-bugs-list mailing
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
nosy: +belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
___
Éric Araujo added the comment:
You can bring this up to python-dev to get other developers’ opinion.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
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
Changes by Florent Xicluna florent.xicl...@gmail.com:
--
nosy: +flox
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
___
Python-bugs-list
Petri Lehtinen pe...@digip.org added the comment:
I added some comments on rietveld. These are only nit-picking about style and
mostly reflect my personal taste, not show stoppers in any case.
--
___
Python tracker rep...@bugs.python.org
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
Petri Lehtinen pe...@digip.org added the comment:
Ben Wolfson wrote:
Maybe, but the last time it went to python-dev (in December) there
was little discussion at all, and the patches that exist now worked
on the codebase as it existed then.
Maybe it's pointless to bring it up on python-dev
Petri Lehtinen pe...@digip.org added the comment:
Ben,
As I've said, I think that we should go for the documented behavior with the
addition of not allowing braces inside the format string (with the exception of
format_spec).
So AFAICS, index_string would become
index_string ::= any
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
Eric V. Smith e...@trueblade.com added the comment:
I'll look at it when I'm done with PEP 420.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
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
Changes by Eric V. Smith e...@trueblade.com:
--
assignee: - eric.smith
___
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.)
--
Petri Lehtinen pe...@digip.org 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.
All three patches look different to me.
Anyway, as far as I can tell the patches would have to be reworked
in the
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:
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 for
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 in
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
Please stick with integer instead of decimalinteger. In an effort to make
the docs more precise, there is an unintended effect of making them harder to
understand.
--
nosy: +rhettinger
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
___
Petri Lehtinen pe...@digip.org 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,
R. David Murray rdmur...@bitdance.com added the comment:
The documentation is, in principle, wrong. The actual authority for the
correct implementation is PEP3101, which says the following:
The str.format() function will have
a minimalist parser which only attempts to figure out when
R. David Murray rdmur...@bitdance.com added the comment:
Note that the PEP also explicitly addresses your concern about getattr, as well
(validation of the name is delegated to the object's __getattr__).
--
___
Python tracker rep...@bugs.python.org
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 is at
R. David Murray rdmur...@bitdance.com added the comment:
I agree that the current situation is a bit murky and ought to be clarified,
but I'm going to leave it to Eric to point they way forward, as he is far more
knowledgeable about this area than I.
--
Petri Lehtinen pe...@digip.org added the comment:
I've played around with the str.format() code for a few weeks now, to
investigate its poor performance compared to the % operator.
Having written a few parsers before, I would change it to parse each
part separately:
1. field_name
2a. if
Eric V. Smith e...@trueblade.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,
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
Eric V. Smith e...@trueblade.com added the comment:
The intermingling of character data and markup is far from irrelevant: that's
exactly what str.format() does! I don't see how it can be irrelevant to a
discussion of how the string is parsed.
Note that there are no restrictions, in general,
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 it
Eric V. Smith e...@trueblade.com added the comment:
From the PEP: Format strings consist of intermingled character data and
markup.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
Eric V. Smith e...@trueblade.com added the comment:
d = {{0}: spam}
# a matched pair of braces. What's inside is considered markup.
...
{0}.format(d)
{'{0}': 'spam'}
# a matched pair of braces. Inside is a matched pair of braces, and what's
inside of that is not considered markup.
I'm
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
Eric V. Smith e...@trueblade.com added the comment:
We're going to have to agree to disagree. I believe that {0[}]} is the markup
{0[} followed by the character data ]}.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
Changes by Petri Lehtinen pe...@digip.org:
--
nosy: +petri.lehtinen
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
___
Python-bugs-list
Changes by Éric Araujo mer...@netwok.org:
--
keywords: +needs review
stage: - patch review
versions: -Python 2.6, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
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
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +eric.smith, mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
___
Eric V. Smith e...@trueblade.com added the comment:
I haven't had time to completely review this, I will do so later today.
But let me just say that the string is first parsed for replacement strings
inside curly braces. There's no issue with that, here.
Next, the string is parsed for
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
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
Eric V. Smith e...@trueblade.com added the comment:
but makes me think that treating ! and : in the index field separately is
definitely wrong.
But it doesn't know they're in an index field when it's doing the parsing for
':' or '!'.
It might be possible to change this so that the field
Eric V. Smith e...@trueblade.com added the comment:
Note also that the nested expansion is only allowed in the format_spec part,
per the documentation. Your last examples are attempting to do it in the
field_name, which leads to the errors you see. Your very last example doesn't
look right to
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 in
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 of
Changes by Ben Wolfson wolf...@gmail.com:
--
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12014
___
___
Python-bugs-list
58 matches
Mail list logo
