[Python-Dev] Binary Operator for New-Style String Formatting
Hello all,
For better or for worse, I have created a patch against the py3k trunk
which introduces a binary operator '@' as an alternative syntax for
the new string formatting system introduced by PEP 3101 (Advanced
String Formatting). [1]
For common cases, this syntax should be as simple and as elegant as
its deprecated [2] predecessor ('%'), while also ensuring that more
complex use cases do not suffer needlessly.
I would just like to know whether this idea will float before
submitting the patch on Roundup and going through the formal PEP
process. This is my first foray into the internals of the Python
core, and with any luck, I did not overlook any BDFL proclamations
banning all new binary operators for string formatting. :-)
QUICK EXAMPLES
{} {} {} @ (1, 2, 3)
'1 2 3'
foo {qux} baz @ {qux: bar}
'foo bar baz'
One of the main complaints of a binary operator in PEP 3101 was the
inability to mix named and unnamed arguments:
The current practice is to use either a dictionary or a tuple as
the second argument, but as many people have commented ... this
lacks flexibility.
To address this, a convention of having the last element of a tuple
as the named arguments dictionary is introduced.
{} {qux} {} @ (1, 3, {qux: bar})
'1 bar 3'
Lastly, to print the repr() of a dictionary as an unnamed argument,
one would have to append an additional dictionary so there is no
ambiguity:
{} @ {foo: bar}
Traceback (most recent call last):
File stdin, line 1, in module
IndexError: tuple index out of range
{} @ ({foo: bar}, {})
{'foo': 'bar'}
Admittedly, these workarounds are less than clean, but the
understanding is the '@' syntax would indeed be an alternative, so one
could easily fall back to the str.format() method or the format()
function.
IMPLEMENTATION
Code-wise, the grammar was edited per PEP 306 [3], and a
function was introduced in unicodeobject.c as PyUnicode_FormatPrime
(in the mathematical sense of A and A' -- I didn't fully understand or
want to intrude upon the *_FormatAdvanced namespace).
The PyUnicode_FormatPrime function transforms the incoming arguments,
i.e. the operands of the binary '@', and makes the appropriate
do_string_format() call. Thus, I have reused as much code as
possible.
I have done my development with git by using two branches: 'master'
and 'subversion', the latter of which can be used to run 'svn update'
and merge back into master. This way my code changes and the official
ones going into the Subversion repository can stay separate, meanwhile
allowing 'svn diff' to produce an accurate patch at any given time.
The code is available at:
http://github.com/jcsalterego/py3k-atsign/
The SVN patch [4] or related commit [5] are good starting points.
References:
[1] http://www.python.org/dev/peps/pep-3101
[2] http://docs.python.org/3.0/whatsnew/3.0.html
[3] http://www.python.org/dev/peps/pep-0306/
[4] http://github.com/jcsalterego/py3k-atsign/blob/master/py3k-atsign.diff
[5]
http://github.com/jcsalterego/py3k-atsign/commit/5c8bdf72d9252cea78af2b7809613f6530e25db4
Thanks,
--
Jerry Chen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Binary Operator for New-Style String Formatting
On Sun, Jun 21, 2009 at 1:36 PM, Jerry Chenj...@3rdengine.com wrote:
QUICK EXAMPLES
{} {} {} @ (1, 2, 3)
'1 2 3'
foo {qux} baz @ {qux: bar}
'foo bar baz'
One of the main complaints of a binary operator in PEP 3101 was the
inability to mix named and unnamed arguments:
The current practice is to use either a dictionary or a tuple as
the second argument, but as many people have commented ... this
lacks flexibility.
The other reason an operator was a pain is the order of operations:
'{0}'.format(1 + 2)
'3'
'%s' % 1 + 2
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: cannot concatenate 'str' and 'int' objects
In general, I don't see any gain in introducing an operator for string
formatting. What's the point? Maybe you save a few characters of
typing, but it sure is easier to Google for Python string format
than for Python @.
A big -1 from me.
Steve
--
Where did you get the preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Binary Operator for New-Style String Formatting
Hello,
For better or for worse, I have created a patch against the py3k trunk
which introduces a binary operator '@' as an alternative syntax for
the new string formatting system introduced by PEP 3101 (Advanced
String Formatting). [1]
While many people find the new format() tedious to adapt to, I don't think
adding a third formatting syntax will help us.
Especially given this annoyance:
Lastly, to print the repr() of a dictionary as an unnamed argument,
one would have to append an additional dictionary so there is no
ambiguity:
{} @ {foo: bar}
Traceback (most recent call last):
File stdin, line 1, in module
IndexError: tuple index out of range
{} @ ({foo: bar}, {})
{'foo': 'bar'}
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Binary Operator for New-Style String Formatting
On Sun, 21 Jun 2009 at 12:36, Jerry Chen wrote: For better or for worse, I have created a patch against the py3k trunk which introduces a binary operator '@' as an alternative syntax for the new string formatting system introduced by PEP 3101 (Advanced String Formatting). [1] It seems to me that this topic is more appropriate for python-ideas. That said, I'm -1 on it. The 'keywords as last item of tuple' reeks of code-smell to my nose, and I don't think you've addressed all of the reasons for why a method was chosen over an operator. Python has a tradition of having one obvious way to do something, so introducing an alternative syntax that you admit is sub-optimal does not seem to me to have enough benefit to justify breaking that design guideline. Congratulations on your first foray into the core, though :) --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Binary Operator for New-Style String Formatting
Jerry Chen wrote:
Hello all,
For better or for worse, I have created a patch against the py3k trunk
which introduces a binary operator '@' as an alternative syntax for
the new string formatting system introduced by PEP 3101 (Advanced
String Formatting). [1]
For common cases, this syntax should be as simple and as elegant as
its deprecated [2] predecessor ('%'), while also ensuring that more
complex use cases do not suffer needlessly.
I would just like to know whether this idea will float before
The place to float trial balloons is the python-ideas list.
submitting the patch on Roundup and going through the formal PEP
process. This is my first foray into the internals of the Python
Even if this particular idea in not accepted, I hope you learned from
and enjoyed the exercise and will try other forays.
core, and with any luck, I did not overlook any BDFL proclamations
banning all new binary operators for string formatting. :-)
QUICK EXAMPLES
{} {} {} @ (1, 2, 3)
The only advantage '@' over '.format' is fewer characters.
I think it would be more useful to agitate to give 'format' a one char
synonym such as 'f'.
One disadvantage of using an actual tuple rather than an arg quasi-tuple
is that people would have to remember the trailing comma when printing
one thing. '{}' @ (1,) rather than '{}' @ (a) == '{}' @ a. [If you say,
'Oh, then accept the latter', then there is a problem when a is a tuple!]
'1 2 3'
foo {qux} baz @ {qux: bar}
'foo bar baz'
One of the main complaints of a binary operator in PEP 3101 was the
inability to mix named and unnamed arguments:
The current practice is to use either a dictionary or a tuple as
the second argument, but as many people have commented ... this
lacks flexibility.
To address this, a convention of having the last element of a tuple
as the named arguments dictionary is introduced.
{} {qux} {} @ (1, 3, {qux: bar})
'1 bar 3'
Lastly, to print the repr() of a dictionary as an unnamed argument,
one would have to append an additional dictionary so there is no
ambiguity:
{} @ {foo: bar}
Traceback (most recent call last):
File stdin, line 1, in module
IndexError: tuple index out of range
{} @ ({foo: bar}, {})
{'foo': 'bar'}
This is another disadvantage -- to me a big one.
Formatting is inherently an n-ary function who args are one format and
an indefinite number of objects to plug in. Packaging the remaining args
into an object to convert the function to binary is problematical,
especially in Python with its mix of positional and named args. Even
without that, there is possible confusion between a package as an arg in
itself and a package as a container of multiple args. The % formatting
problem with tuple puns was one of the reasons to seek a replacement.
Terry Jan Reedy
Admittedly, these workarounds are less than clean, but the
understanding is the '@' syntax would indeed be an alternative, so one
could easily fall back to the str.format() method or the format()
function.
IMPLEMENTATION
Code-wise, the grammar was edited per PEP 306 [3], and a
function was introduced in unicodeobject.c as PyUnicode_FormatPrime
(in the mathematical sense of A and A' -- I didn't fully understand or
want to intrude upon the *_FormatAdvanced namespace).
The PyUnicode_FormatPrime function transforms the incoming arguments,
i.e. the operands of the binary '@', and makes the appropriate
do_string_format() call. Thus, I have reused as much code as
possible.
I have done my development with git by using two branches: 'master'
and 'subversion', the latter of which can be used to run 'svn update'
and merge back into master. This way my code changes and the official
ones going into the Subversion repository can stay separate, meanwhile
allowing 'svn diff' to produce an accurate patch at any given time.
The code is available at:
http://github.com/jcsalterego/py3k-atsign/
The SVN patch [4] or related commit [5] are good starting points.
References:
[1] http://www.python.org/dev/peps/pep-3101
[2] http://docs.python.org/3.0/whatsnew/3.0.html
[3] http://www.python.org/dev/peps/pep-0306/
[4] http://github.com/jcsalterego/py3k-atsign/blob/master/py3k-atsign.diff
[5]
http://github.com/jcsalterego/py3k-atsign/commit/5c8bdf72d9252cea78af2b7809613f6530e25db4
Thanks,
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] run time error anlysis of python source code
To All, It appears that one possibility of investigation into the development of a safety-critical variant of the python language would be to conduct run time error analysis of the source code that is responsible for producing the python language. Therefore, I will now conduct these run time error analysis of the python source code as if the python environment itself was to be utilized as a FADEC controller within an aircraft engine. I have already conducted some analysis already and it appears to be some concern with memory management within Python. I will redouble my efforts and determine if I am correct and as a promise. I will give my findings to everyone to enjoy if they so want it. I will also give the correct source if anyone would want it for their own purposes. The source code that I will be evaluating is the one responsible for the newer variants of Python 3.0. I believe that I will name this new variant of the python language as Apocalypse Python !! I will also develop a web-page for the development and evolution of Apocalypse Python. If anyone has any questions, please let me know !!! Thank You, David Blubaugh ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Binary Operator for New-Style String Formatting
Ah, the people have spoken!
On Sun, Jun 21, 2009 at 2:12 PM, Terry Reedytjre...@udel.edu wrote:
The place to float trial balloons is the python-ideas list.
I'll put this one to rest, and as mentioned, will direct any future
suggestions to python-ideas instead of here.
Most of the arguments against my proposal state there is little gain
and much to lose (in terms of clarity or an obvious way to go about
string formatting) -- and, I agree.
The only advantage '@' over '.format' is fewer characters.
I think it would be more useful to agitate to give 'format' a one char
synonym such as 'f'.
str.f() would be a great idea.
One disadvantage of using an actual tuple rather than an arg quasi-tuple is
that people would have to remember the trailing comma when printing one
thing. '{}' @ (1,) rather than '{}' @ (a) == '{}' @ a. [If you say, 'Oh,
then accept the latter', then there is a problem when a is a tuple!]
My code transforms both '{}' @ (a) and '{}' @ a to '{}'.format(a), but
the problem you speak of is probably an edge case I haven't quite
wrapped my head around.
For what it's worth, I spent a bit of time trying to work out the
syntactical quirks, including adapting the format tests in
Lib/test/test_unicode.py to this syntax and ensuring all the tests
passed. In the end though, it seems to be an issue of usability and
clarity.
Formatting is inherently an n-ary function who args are one format and an
indefinite number of objects to plug in. Packaging the remaining args into
an object to convert the function to binary is problematical, especially in
Python with its mix of positional and named args. Even without that, there
is possible confusion between a package as an arg in itself and a package as
a container of multiple args. The % formatting problem with tuple puns was
one of the reasons to seek a replacement.
Also (from R. David Murray):
That said, I'm -1 on it. The 'keywords as last item of tuple' reeks
of code-smell to my nose, and I don't think you've addressed all of
the reasons for why a method was chosen over an operator. Python has a
tradition of having one obvious way to do something, so introducing an
alternative syntax that you admit is sub-optimal does not seem to me
to have enough benefit to justify breaking that design guideline.
Well stated (and everyone else).
Just one last note: I think my end goal here was to preserve the
visual clarity and separation between format string and format
parameters, as I much prefer:
%s %s %s % (1, 2, 3)
over
{0} {1} {2}.format(1, 2, 3)
The former is a style I've grown accustomed to, and if % is indeed
being slated for removal in Python 3.2, then I will miss it sorely
(or... just get over it).
Thanks to everyone who has provided constructive criticism and great
arguments.
Cheers,
--
Jerry Chen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Binary Operator for New-Style String Formatting
For better or for worse, I have created a patch against the py3k trunk which introduces a binary operator '@' as an alternative syntax for the new string formatting system introduced by PEP 3101 (Advanced String Formatting). [1] I'd like to join everybody else who said that this would be a change for the worse. This kind of syntax is one of the most prominent features of Perl. $...@~ly/your/s!, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] xmlrpc improvements
On Sat, Jun 20, 2009 at 6:57 PM, Martin v. Löwismar...@v.loewis.de wrote: Fredrik Lundh wrote: I think you really need to get Fredrik Lundh to comment on it. If he can't predict when he'll be able to review the changes, maybe he can accept releasing control of xmlrpclib. Pointer to the patch? http://bugs.python.org/issue6267 The xmlrpclib.py changes looks ok. I'll leave it to other reviewers to check the rest. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Binary Operator for New-Style String Formatting
I'm against syntax for this, for all the reasons stated by others.
Jerry Chen wrote:
Just one last note: I think my end goal here was to preserve the
visual clarity and separation between format string and format
parameters, as I much prefer:
%s %s %s % (1, 2, 3)
over
{0} {1} {2}.format(1, 2, 3)
If it helps, in 3.1 and 2.7 this can be written as
{} {} {}.format(1, 2, 3)
I'm not sure it helps for visual clarity, but it definitely makes the
typing easier for simple uses.
The former is a style I've grown accustomed to, and if % is indeed
being slated for removal in Python 3.2, then I will miss it sorely
(or... just get over it).
I've basically come to accept that %-formatting can never go away,
unfortunately. There are too many places where %-formatting is used, for
example in logging Formatters. %-formatting either has to exist or it
has to be emulated.
Although if anyone has any suggestions for migrating uses like that, I'm
interested.
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] xmlrpc improvements
On Sat, Jun 20, 2009 at 6:57 PM, Martin v. Löwismar...@v.loewis.de wrote: While I have your attention, please also review http://bugs.python.org/issue6233 I'm pretty sure that fix is the wrong fix - afaik, _encode is used to encode tag/attribute names, and charrefs don't work in that context. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] run time error anlysis of python source code
omega_force2...@yahoo.com wrote: It appears that one possibility of investigation into the development of a safety-critical variant of the python language would be to conduct run time error analysis of the source code that is responsible for producing the python language. Therefore, I will now conduct these run time error analysis of the python source code as if the python environment itself was to be utilized as a FADEC controller within an aircraft engine. I have already conducted some analysis already and it appears to be some concern with memory management within Python. I will redouble my efforts and determine if I am correct and as a promise. I will give my findings to everyone to enjoy if they so want it. I will also give the correct source if anyone would want it for their own purposes. The source code that I will be evaluating is the one responsible for the newer variants of Python 3.0. I hope you mean 3.1 ;-) 3.0 was basically a trial version of Py3. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] xmlrpc improvements
Fredrik Lundh wrote: On Sat, Jun 20, 2009 at 6:57 PM, Martin v. Löwismar...@v.loewis.de wrote: Fredrik Lundh wrote: I think you really need to get Fredrik Lundh to comment on it. If he can't predict when he'll be able to review the changes, maybe he can accept releasing control of xmlrpclib. Pointer to the patch? http://bugs.python.org/issue6267 The xmlrpclib.py changes looks ok. I'll leave it to other reviewers to check the rest. Comment cc'ed to tracker ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] run time error anlysis of python source code
Hi David, omega_force2...@yahoo.com wrote: It appears that one possibility of investigation into the development of a safety-critical variant of the python language There is some interesting work related to a safety-critical variant of Python. would be to conduct run time error analysis of the source code that is responsible for producing the python language. There's been some effort into this too, and the Coverity and Klocwork based fixes could also be of interest to you. Therefore, I will now conduct these run time error analysis of the python source code as if the python environment itself was to be utilized as a FADEC controller within an aircraft engine. Nice, what tools do you have available for this? Any papers that would be a good start on the topic? I have already conducted some analysis already and it appears to be some concern with memory management within Python. I will redouble my efforts and determine if I am correct and as a promise. I will give my findings to everyone to enjoy if they so want it. I will also give the correct source if anyone would want it for their own purposes. The source code that I will be evaluating is the one responsible for the newer variants of Python 3.0. You want the py3k branch. BTW, take a look at Brett Cannon's work on Python security, as well as tav's. I believe that I will name this new variant of the python language as Apocalypse Python !! Oh. Apocalypse Python !!, you say? Maybe something that conveys a security message or anything that doesn't relate to the end of the world could work better. I will also develop a web-page for the development and evolution of Apocalypse Python. Ah. Hm. David? Don't. I mean, read the mailing lists, take a look at open bug reports, read the community blogs. You'll get to know how things flow, you'll figure a nice way to relate your ideas to what people are discussing and past experiences. Make small contributions that bring us closer to... Apocalypse Python !!, then you'll have an easier time to push the idea of going the whole way towards it. Or just do it, dunno, if it makes you feel better go for it, we all have our own issues. That's why we have an issue tracker, it's s nice, wanna see it??? If anyone has any questions, please let me know !!! OK, I promise. Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] run time error anlysis of python source code
On Sun, Jun 21, 2009 at 5:05 PM, Daniel Dinizaja...@gmail.com wrote: Hi David, omega_force2...@yahoo.com wrote: It appears that one possibility of investigation into the development of a safety-critical variant of the python language There is some interesting work related to a safety-critical variant of Python. would be to conduct run time error analysis of the source code that is responsible for producing the python language. There's been some effort into this too, and the Coverity and Klocwork based fixes could also be of interest to you. Therefore, I will now conduct these run time error analysis of the python source code as if the python environment itself was to be utilized as a FADEC controller within an aircraft engine. Nice, what tools do you have available for this? Any papers that would be a good start on the topic? I have already conducted some analysis already and it appears to be some concern with memory management within Python. I will redouble my efforts and determine if I am correct and as a promise. I will give my findings to everyone to enjoy if they so want it. I will also give the correct source if anyone would want it for their own purposes. The source code that I will be evaluating is the one responsible for the newer variants of Python 3.0. You want the py3k branch. BTW, take a look at Brett Cannon's work on Python security, as well as tav's. Is py3k branch even passing all tests on all buildbots all the time? I don't think svn head is the right thing to look at. Also, it's worth noting that most big libraries are 2.x compatible only. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] run time error anlysis of python source code
Maciej Fijalkowski fijall at gmail.com writes: Is py3k branch even passing all tests on all buildbots all the time? As much as other branches do (that is, not much, due to the flakiness of some of the tests and the lack of buildbot maintenance). I don't think svn head is the right thing to look at. Also, it's worth noting that most big libraries are 2.x compatible only. For projects difficult enough that they won't be finished before a couple of years, I think it makes sense to target 3.x. Big libraries will hopefully migrate gradually. SQLAlchemy recently announced that their current development version is 100% py3k-compatible (http://www.sqlalchemy.org/news.html#item_1). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] run time error anlysis of python source code
Daniel Diniz wrote: Apocalypse Python !!, you say? Maybe something that conveys a security message or anything that doesn't relate to the end of the world could work better. I guess the idea is meant to be that it's safe enough to use for something that would result in the end of the world if it failed !! Although personally, if something might cause the end of the world if it failed, I'd prefer not to attempt it in the first place !! -- Apocalypse Python !! - If you ever need to use it, you're in deep trouble... !! Greg !! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
