Re: New Python 3.0 string formatting - really necessary?
For R, and others who haven't read the PEP or worked a lot with the
web, here are some really strong advantages of the new string
formatting over the old.
Note: I'm not saying that you have to use one or the other. I'm just
pointing out some of the things that the new format gives us - things
which allow the next generation of application simplification
(especially web apps).
When working on resource-oriented, generalized display applications
(eg, most any modern website), you commonly run into the problem of
wanting to display a bunch of different things in a bunch of different
ways - and on the web, display means convert to a string for the
browser. However, the mapping is not a complete graph. Rather, there
are usually some rules. For example:
* I want to show the same thing to different people in different
ways, depending on permissions.
* Sometimes I want to show a thing as a full display, and sometimes
as a link to go get more. Usually, the template (context) knows how I
want to show something, but the thing knows how to show itself.
I can solve this using the new string formatting. In particular, by
using the {0.property}, {variable[index]}, and similar
substitutions (none of which can be done in the old syntax). As a
result, I end up with an entire website, of an arbitrary number of
pages, being supported with one, 5-line generate the view method.
There is 0 code per page.
Here are some of the simpler examples. First, there might be a link to
a user's page:
a href='{0.url}{0.display_name}/a
And a link to a blog entry:
a href='{0.url}{0.display_name}/a
Wait...isn't that the same? Yup. There's the first widget: a link. Any
resource that knows its own name and URL (and that's all of them) can
be shown as a link. Similar widget extraction hugely reduces the other
combinations I have to support - eliminating a lot of redundancy, and
many LoC.
However, display_name doesn't show up the same for all users.
Administrators often get additional data (such as the username),
everywhere they see a user's name. Friends of a user see little
rollovers that tell them more about that user - such as a photo.
Fortunately, I defined my user class like:
class User:
@property
def display_name(self):
# viewer-dependent context stuff here.
And the new string formatting calls my arbitrary code, without anyone
having to think about it. But display_name doesn't need to know how to
display a name - it just needs to choose which style to use. I can
also extract that out to a template, and then have img
src='{0.photo.url}' /{0.first} for friends and {0.first} {0.last}
({0.username}) for admins, and so on. My display_name code just needs
to choose which representation to use - it doesn't define that format.
It just returns one of several opaque string constants / widgets,
making refactoring trivial.
Similarly, I can use {resource.full_display_for_viewer} or
{resource.link_display} to tell the resource how I want it to
display itself.
Hm. Doesn't that make widget sets (a la ToscaWidgets / TuboGears) and
template languages (such as Cheetah / Kid / Mako) a little obsolete?
Well, sorta. After all when displaying my user class, I can do this
too: {self.blog_entries.recent.as_ordered_list.using.link_display}.
Is that pathological? Probably (unless you have a functional
programming background or like domain-specific languages). Looping is,
after all, one of the things a real templating system gives you.
However, now you don't need to use it for common (and simple) things.
Eventually, you do run into stuff for which you want a full templating
language. And I use them. For example, they define the base page
layouts. The point, however, is that a lot of the lower-level things
can be done without using the templating language. And this reduces
the number of Mako templates you have lying around, while still
allowing great decomposability.
Most of these things could be done by having the object override
__format__(self). However, that jams my display code in with the rest
of my resource class. This way, I can have templates pull out what
they want from my resources. And I can compute the template to use and
the resources to use it on independently, then just pass it to my
displayer method.
These are capabilities that %s has no chance to every approach. The
ability to use new-style format strings reducees my LoC by a half-ton,
and they make what they leave behind a lot easier to read. Being
higher-level constructs, they allow me to eliminate redundancy, and
that's the real purpose of a programmer.
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
You know, it is so much easier to find my posts now that someone has been thoughtful enough to mark them for me. Thank you kind chaps, i shall leave a shiny new nickel for you, just send me your name, address, and phone numbers. I'll get them in the mail right away. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 21, 12:28 pm, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: I can see where the new formatting might be helpful in some cases. But, I am not sure it's worth the cost. Err... _Which_ cost exactly ? Loss of backward compatibility, mainly. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On 19 dic, 13:01, walterbyrd walterb...@iname.com wrote:
I have not worked with Python enough to really know. But, it seems to
me that more I look at python 3.0, the more I wonder if it isn't a
step backwards.
To me, it seems that this:
print %s=%d % ('this',99)
Is much easier, and faster, to type, and is also easier to read and
understand. It also allows people to leverage their knowledge of C.
This (if it's right) is much longer, and requires more special
characters.
print( {0}={1}.format('this',99))
Maybe it's worth all the extra trouble, and breaking backward
compatibilty, and all. But, I never had the idea that the old way was
all that big a problem. Of course, I could be wrong. Was the old way
all that big of a problem?
Well, I was playing with python 3k a little bit and, as usual, after a
few minutes everything felt natural.
The new string formating is perhaps a little more typing, much is much
more clear and readable.
I know where it came from. Long ago, Guido took a look at Boo, which
is a python-like .NET language, and he posted a comment saying how
much he liked the string formating, which is identical to the new one
in python.
I still can't get used to add the parenthesis to print, and this is
the only thing I don't like, but I'm sure there's a good reason for
this change...
Luis
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 29, 7:37 pm, Luis M. González luis...@gmail.com wrote:
I still can't get used to add the parenthesis to print, and this is
the only thing I don't like, but I'm sure there's a good reason for
this change...
I should know better than to post such an awful hack:
__past__.py:
from sys import excepthook as sys_excepthook
from sys import modules
---
def printhook(exctype, value, traceback):
skip = True
if isinstance(value, SyntaxError):
if 'print ' in value.text:
printable = value.text.replace('print ', '')[:-1]
skip = False
toprint = 'print(' + printable +')'
print('Trying to convert your mess into', toprint)
try:
exec(toprint)
except NameError as ne:
name = str(ne).replace(name ', '').replace(' is not
defined, '')
try:
var = str(getattr(modules['__main__'], name))
exec('print(' + printable.replace(name, var) +
')')
except AttributeError as ae:
sys_excepthook(NameError, ne, traceback)
except SyntaxError as se:
print('NameError workaround replaced something
bad')
skip = True
except NameError as ne2:
print('Too many names to map to objects :P')
skip = True
except:
print('Sorry, something went wrong and I am too
lazy to find out what')
skip = True
except:
raise
skip = True
if skip:
sys_excepthook(exctype, value, traceback)
---
Then, as I'd check some stuff in parallel on 2.5 and 3.0, I do this on
the 3.0 prompt:
---
import sys
exchook = sys.excepthook
from __past__ import printhook
sys.excepthook = printhook
---
As soon as I wrote that mess^H^H^H^H helper, remembering to use print
() became easier (I think the trauma helped) and I haven't imported
much from __past__ since.
Should I hit 'send'?
Daniel
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Mon, 29 Dec 2008 09:50:14 -0800, walterbyrd wrote: On Dec 21, 12:28 pm, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: I can see where the new formatting might be helpful in some cases. But, I am not sure it's worth the cost. Err... _Which_ cost exactly ? Loss of backward compatibility, mainly. How do you lose backward compatibility by *adding* new functionality? The old functionality will continue to work as normal. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 29, 9:44 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: How do you lose backward compatibility by *adding* new functionality? The old functionality will continue to work as normal. -- Steven AFAIK it still works the old way, but it will be deprecated soon. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Bruno Desthuilliers wrote: ... Now improvements are always welcomes, and if you compare 1.5.2 with 2.5.1, you'll find out that the core developpers did improve Python's perfs. Cool, palindromic inverses as compatible versions! -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 22, 7:26 pm, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Mon, 22 Dec 2008 06:58:06 -0800, walterbyrd wrote: On Dec 21, 12:28 pm, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: Strange enough, no one seems to complain about PHP or Ruby's performances... A few years back, there was a certain amount of chest thumping, when python/django easily beat ror in a benchmark test. Now that ruby is faster, I guess speed is no big issue. Who was doing this chest-thumping? Fanboys like r? Why should you tar all of us with their immaturity? Walter, Steven would rather live in a bland Utopian society and could care less for the greatness of competition and he has little respect for loyalty. He would like to have little league games where there is no losers, so nobody's feelings get hurt(oh NO!). And EOE so that god forbid weather or not someone is qualified they must be hired just to keep a equal balance in the workplace. Hey Steven, we should outlaw individualism too, God forbid someone think outside the box!(damn heretics!) But as they say ignorance is bliss ey Stevie? -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 21, 8:42 pm, MRAB goo...@mrabarnett.plus.com wrote:
Aaron Brady wrote:
On Dec 21, 6:14 pm, MRAB goo...@mrabarnett.plus.com wrote:
snip
Yes, I suggested that earlier, but it isn't needed because you can
create a format object with Format(string). However, most of the time
you won't bother to create a format object explicitly because of:
class str(object):
def __mod__(self, value):
return Format(self) % value
f = f%r %i
type(f)
type 'Format'
# Explicitly
f = Format(%r %i)
f
Format '%r %i'
f % (2, 3, 4)
Format '(2, 3, 4) %i'
# Implicitly, relying on the __mod__ method of str
f = %r %i
f
'%r %i'
f % (2, 3, 4)
Format '(2, 3, 4) %i'
I'd also like to add that there's nothing to prevent format objects from
having other methods where multiple placeholders can be filled in one call:
# By position
f = Format(%r %i)
f
Format '%r %i'
f.fill([(2, 3, 4), 1])
'(2, 3, 4) 1'
# By name
f = Format(%{tuple}r %{int}i)
f
Format '%{tuple}r %{int}i'
f.fill({tuple: (2, 3, 4), int: 1})
'(2, 3, 4) 1'
You're choosing to favor the '.chain()' method over the '.fill()'
method for the behavior of '%'. I don't think you've justified it
though.
Format( %r %i ).chain( ( 2, 3, 4 ) ).chain( 0 )
'(2, 3, 4) 0'
Format( %r %i ).fill( ( 2, 3, 4 ), 0 )
'(2, 3, 4) 0'
Plus, I almost think we've almost attained defeating the purpose.
The disadvantage of the chaining method is that it's positional,
left-to-right. For the purposes of i18n you want tagged placeholders,
whether they be integers or names. I think... OK, if the placeholders
include a positional tag, eg %(0)s %(1)s, then they could be filled in
according to _that_ order. Not sure about named placeholders, though.
Perhaps, like at present, if a dict is given to a format with named
placeholders then several placeholders could be filled, the problem
being how to fill a _single_ named placeholder with a dict.
Just pass a keyword argument to chain.
Format( %(tup)r %(int_)i ).chain( tup= ( 2, 3, 4 ) ).chain( int_= 0 )
'(2, 3, 4) 0'
You might want to call it 'fchain' or 'chainf'.
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 21, 12:28 pm, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: Strange enough, no one seems to complain about PHP or Ruby's performances... A few years back, there was a certain amount of chest thumping, when python/django easily beat ror in a benchmark test. Now that ruby is faster, I guess speed is no big issue. By the same reasoning, python advocates used to sneer at php because php constantly broke backward compatibility. Now that python does it, breaking backward compatibility is no big deal. I guess unicode support was not that important, until python caught up to perl. I guess, the way it works is: you first assume that python is superior, then you figure out why. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
r wrote: Steven, Would you like to elaborate on -why- escaped backslashes are needed in strings... i waiting??? Some character was needed. It just happens that backslashes have been used in this manner for composing nonprintable sequences, codes, etc. It's only in use because someone arbitrarily picked it about 40 years ago. Any character could have been used; any such character would still be have to escaped. Kind of funny that you are complaining about Python in particular when this behavior is in almost all languages today, including Perl, Ruby, Don't blame python for a mistake that Microsoft made, that of choosing a commonly-accepted escape character (long before Python was even though of!) as their path delimiter. Fortunately sane operating systems use a standard slash. Even Windows APIs accept forward slashes as path delimiters. So really your complaint about the backslash is a bit silly. Are you going to campaign that C# and Java also fix this problem by choosing another character? -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
walterbyrd wrote: On Dec 21, 12:28 pm, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: Strange enough, no one seems to complain about PHP or Ruby's performances... A few years back, there was a certain amount of chest thumping, when python/django easily beat ror in a benchmark test. Now that ruby is faster, I guess speed is no big issue. A fairly limited amount of chest-thumping, as I remember it. By the same reasoning, python advocates used to sneer at php because php constantly broke backward compatibility. Now that python does it, breaking backward compatibility is no big deal. I guess unicode support was not that important, until python caught up to perl. Python advocates shouldn't sneer at other languages. There's no need. If you like Python, use it because of its merits, not because it's better than something else. Having said which, I must say that Python's breaking backward incompatibility is of a somewhat different nature than (say) Visual Basic's. It was known about for *several years* in advance, even before Guido went to work for Google and finally had time to get the work underway. Also it's defined to be a singular event, not a continuous set of creeping changes. Python 3's updated syntax now constrains the developers in the same way that Python 2's used to. I wouldn't say that could remotely be described as constantly breaking backward compatibility. I guess, the way it works is: you first assume that python is superior, then you figure out why. That's the way some people operate, but by no means all. Is it the language or the people that are pissing you off. You sound a little discontented for a c.l.py reader. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
r wrote: Thanks MRAB, except the float is not 2 decimal places, but its there Come on... They did this for the interpreter not us. It's easer to parse this string with positional arguments and a dict of format descriptions. Come on pydev, at least be honest about it! No. They did this for the *language*. Come on, R. Read the PEP on the new string formatter. The rationale is very clear. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Michael Torrie wrote: r wrote: Steven, Would you like to elaborate on -why- escaped backslashes are needed in strings... i waiting??? Some character was needed. It just happens that backslashes have been used in this manner for composing nonprintable sequences, codes, etc. It's only in use because someone arbitrarily picked it about 40 years ago. Any character could have been used; any such character would still be have to escaped. BCPL used '*', but C, which was developed from BCPL, uses '\'. Kind of funny that you are complaining about Python in particular when this behavior is in almost all languages today, including Perl, Ruby, Don't blame python for a mistake that Microsoft made, that of choosing a commonly-accepted escape character (long before Python was even though of!) as their path delimiter. Fortunately sane operating systems use a standard slash. Even Windows APIs accept forward slashes as path delimiters. So really your complaint about the backslash is a bit silly. Are you going to campaign that C# and Java also fix this problem by choosing another character? -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 22, 8:58 am, walterbyrd walterb...@iname.com wrote: On Dec 21, 12:28 pm, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: Strange enough, no one seems to complain about PHP or Ruby's performances... A few years back, there was a certain amount of chest thumping, when python/django easily beat ror in a benchmark test. Now that ruby is faster, I guess speed is no big issue. By the same reasoning, python advocates used to sneer at php because php constantly broke backward compatibility. Now that python does it, breaking backward compatibility is no big deal. I guess unicode support was not that important, until python caught up to perl. I guess, the way it works is: you first assume that python is superior, then you figure out why. I think what walter is saying is the loyalty is gone. community: If python makes great, if it doesn't, why should i care if it goes down the toilet? i just move to ruby Were is your loyalty pyfans?, Has the fight left you??? -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
walterbyrd a écrit : On Dec 21, 12:28 pm, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: Strange enough, no one seems to complain about PHP or Ruby's performances... A few years back, there was a certain amount of chest thumping, when python/django easily beat ror in a benchmark test. I don't remember it, and honestly, I just don't give a damn. Now that ruby is faster, faster than what ? Than Python ? or than it's previous version ? I guess speed is no big issue. Please use your google-fu (if you have any). As far as I'm concerned, my position didn't change these 7+ past years: Python is (and has always been) fast enough for most of what I use it for (and when it isn't, neither PHP nor Ruby are going to be solution anyway). Now improvements are always welcomes, and if you compare 1.5.2 with 2.5.1, you'll find out that the core developpers did improve Python's perfs. Now do you have any serious argument, or are you just trolling ? By the same reasoning, python advocates used to sneer at php because php constantly broke backward compatibility. Now that python does it, breaking backward compatibility is no big deal. There's a lot 1.5.2 days code still running *unmodified* on 2.6.x. You'll have hard time finding (non-trivial, and even then) PHP3 code running unmodified on PHP5. I guess unicode support was not that important, until python caught up to perl. I guess, the way it works is: you first assume that python is superior, then you figure out why. Whoever said Python was superior (except your good friend 'r') ? As far as I'm concerned, I don't think Python is superior (OMG), I think it's a good language that happens to fit my brain *and* solve more than 80% of my programmer's needs. If you're not happy with Python's perfs, please contribute, you are welcome. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 22, 12:36 pm, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: As far as I'm concerned, I don't think Python is superior (OMG), I think it's a good language that happens to fit my brain *and* solve more than 80% of my programmer's needs. If you're not happy with Python's perfs, please contribute, you are welcome. He is contributing, by bringing up the subject for debate. Volunteers exist on all levels, not just the people who write code for CPython. Every OOS project needs diversity. There is base code, maintenance code, tutorials, essays, promotion(even if you consider it fanboyism),etc, etc. Every spoke on a wheel is just as important as all the rest, Bruno. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
Instead of just whinging, how about making a suggestion to fix it? Go on,
sit down for an hour or ten and try to work out how a BINARY OPERATOR
like % (that means it can only take TWO arguments) can deal with an
arbitrary number of arguments, *without* having any special cases.
Go on. Take your time. I'll be waiting.
Well that's easy. I see 'r' didn't answer so I will: only accept tuples
on the right hand side of the %, so all arguments have to be put inside
a tuple.
%s % 42
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: unsupported operand type(s) for %: 'str' and 'int'
%s % (42,)
'42'
Of course there would still be the possibility of uncaught bugs when
people forget to put the argument in a tuple if the argument itself is a
tuple of length 1.
def foo(x):
... print foo(%s) % x
... # should be % (x,)
...
foo('a')
TypeError: unsupported operand type(s) for %: 'str' and 'str'
# But if x is a tuple of length 1 the error is not reported
foo((1,))
foo(1)
That's why .format() is a better option IMHO.
--
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 22, 11:40 am, r rt8...@gmail.com wrote: On Dec 22, 8:58 am, walterbyrd walterb...@iname.com wrote: On Dec 21, 12:28 pm, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: Strange enough, no one seems to complain about PHP or Ruby's performances... A few years back, there was a certain amount of chest thumping, when python/django easily beat ror in a benchmark test. Now that ruby is faster, I guess speed is no big issue. By the same reasoning, python advocates used to sneer at php because php constantly broke backward compatibility. Now that python does it, breaking backward compatibility is no big deal. I guess unicode support was not that important, until python caught up to perl. I guess, the way it works is: you first assume that python is superior, then you figure out why. I think what walter is saying is the loyalty is gone. community: If python makes great, if it doesn't, why should i care if it goes down the toilet? i just move to ruby Were is your loyalty pyfans?, Has the fight left you??? Point: It is not rational for the crew to go down with the ship, only the captain. Case: Loyalty is a complex emotion, and it's not clear that it's our highest priority, or that it's anyone's. I want to use a good language. If Python stops being good (that is, a good version of Python stops being maintained and supported), then I'll stop using it, and that's the rational thing to do. Just to be fair, though, it's (contraction) not obviously irrational for a captain to go down with the ship. The mentality, commitments, and principles that it lets him keep and make may be better on the whole in the long run for captains, crews, and ships, only if they have that consequence. That is, captains that will go down with the ship are better captains of ships, and captains that have the capacity to betray, forge, or abandon principles make worse captains; therefore a good captain will go down, and can't change his mind. However, as critics and fans of Python, our actions don't really have the same consequences as the captains. That is, it is not rational for the crew to go down with the ship, only the captain. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 22, 5:53 pm, Aaron Brady castiro...@gmail.com wrote: On Dec 22, 11:40 am, r rt8...@gmail.com wrote: On Dec 22, 8:58 am, walterbyrd walterb...@iname.com wrote: On Dec 21, 12:28 pm, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: Strange enough, no one seems to complain about PHP or Ruby's performances... A few years back, there was a certain amount of chest thumping, when python/django easily beat ror in a benchmark test. Now that ruby is faster, I guess speed is no big issue. By the same reasoning, python advocates used to sneer at php because php constantly broke backward compatibility. Now that python does it, breaking backward compatibility is no big deal. I guess unicode support was not that important, until python caught up to perl. I guess, the way it works is: you first assume that python is superior, then you figure out why. I think what walter is saying is the loyalty is gone. community: If python makes great, if it doesn't, why should i care if it goes down the toilet? i just move to ruby Were is your loyalty pyfans?, Has the fight left you??? Point: It is not rational for the crew to go down with the ship, only the captain. Case: Loyalty is a complex emotion, and it's not clear that it's our highest priority, or that it's anyone's. I want to use a good language. If Python stops being good (that is, a good version of Python stops being maintained and supported), then I'll stop using it, and that's the rational thing to do. Just to be fair, though, it's (contraction) not obviously irrational for a captain to go down with the ship. The mentality, commitments, and principles that it lets him keep and make may be better on the whole in the long run for captains, crews, and ships, only if they have that consequence. That is, captains that will go down with the ship are better captains of ships, and captains that have the capacity to betray, forge, or abandon principles make worse captains; therefore a good captain will go down, and can't change his mind. However, as critics and fans of Python, our actions don't really have the same consequences as the captains. That is, it is not rational for the crew to go down with the ship, only the captain. What if the crew sabotage the ship, should the captain still go down with it, even though sabatuers are to blame? All ships need a good captain, all captains need a good crew, and all crews need a good ship.(also True in reverse()). Without loyalty python will fail, so will Ruby, so will C. Sometimes even when loyalty is scarce, a language will survive solely because it is the only ship available. You do not have to fight for python as I do to use it and benefit from it, that's OK. I don't care either way. But don't piss on me for trying to keep her a-float, Mate!. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Mon, 22 Dec 2008 06:58:06 -0800, walterbyrd wrote: On Dec 21, 12:28 pm, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: Strange enough, no one seems to complain about PHP or Ruby's performances... A few years back, there was a certain amount of chest thumping, when python/django easily beat ror in a benchmark test. Now that ruby is faster, I guess speed is no big issue. Who was doing this chest-thumping? Fanboys like r? Why should you tar all of us with their immaturity? By the same reasoning, python advocates used to sneer at php because php constantly broke backward compatibility. Now that python does it, breaking backward compatibility is no big deal. No, breaking backward compatibility IS a big deal. That's why Python is doing it slowly and carefully: the minimum amount of breakage necessary, and with the Python 2.x series kept going in parallel for at least two additional versions. I guess unicode support was not that important, until python caught up to perl. Python has had unicode support for a long time. You just needed to write u'' instead of ''. I guess, the way it works is: you first assume that python is superior, then you figure out why. Just keep on trollin'. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, Dec 20, 2008 at 10:15 PM, r rt8...@gmail.com wrote: On Dec 20, 11:11 pm, walterbyrd walterb...@iname.com wrote: On Dec 20, 5:05 pm, Roy Smith r...@panix.com He got really hung up on the % syntax. I guess it's good to know that there is, at least, one person in the world doesn't like the % formatting. As least the move was not entirely pointless. But, you must admit, of all the things people complain about with Python, the % formatting is probably one of the least common complaints. Complaints about Python's speed seem much more common. Yet, 3.0 makes the speed worse, and fixes a non-problem. A few points: 1) The new formatting is NOT the reason for the speed slowdown. So this change at least was a no cost change. No cost to interpreter speed, and no cost as it doesn't replace the old sprintf style. Of all the things to complain about in python 3.0, the format method is the silliest. 2) In my experience, major version changes tend to be slower than before. When a lot of things change, especially if very low-level things change, as happened in python 3.0, the new code has not yet went through many years of revision and optimization that the old code has. In my opinion, python 3 was rushed out the door a bit. It could have done with a few more months of optimization and polishing. However, on the other hand, it is going to take so long for python infrastructure to convert to python 3, that an earlier release makes sense, even if it hasn't been excessively polished. The biggest reason for the speed change is the rewritten stdio and unicode-everything. Hopefully this stuff can be improved in future updates. I don't think anyone WANTS cpython to be slower. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, 20 Dec 2008 22:15:23 -0800, r wrote: It would be nice to get a vote together and see what does the average pythoneer want? What do they like, What do they dislike. What is the state of the Python Union? Does anybody know, Does anybody care? I think python is slipping away from it's dominate foothold on the world. Google's use of python may be the only thing holding this house of cards together. Ruby's hype is defiantly growing and unless we strive for greatness, python may fail. I think ruby may have their act together a little better than us right now. And since Ruby is such a hodge-podge of different languages, the __init__ hold is there for many. what does joe-python want??? That's not completely irrelevant but I think one of Python's strength is that we have a BDFL who decides carefully what he thinks is best for the language instead of integrating every random idea some newbie comes up with and which might sound useful at first sight. Python has its quirks but even with things I don't like I often realize later it was a wise decision that integrates well into the language whereas my ideas for fixes of the quirks wouldn't. joe-python most often doesn't see the whole picture and demands changes that look easy at first sight, but are hard to implement right and efficient or just shifts the problem somewhere else where the next joe-python trips over it. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, 20 Dec 2008 15:27:43 -0800, walterbyrd wrote: On Dec 19, 10:25 am, Michael Torrie torr...@gmail.com wrote: Personally the new string formatter is sorely needed in Python. Really? You know, it's funny, but when I read problems that people have with python, I don't remember seeing that. Loads of people complain about the white space issue. Some people complain about the speed. Lots of complaints about certain quirky behavior, but I have not come across any complaints about the string formatting. Many newbie code I have seen avoids it by string concatenation: greeting = 'Hello, my name is ' + name + ' and I am ' + str(age) + ' old.' That's some kind of indirect complaint. :-) In fact, from what I have seen, many of the problems being fixed seem to be non-problems. And even if nobody has problems with the limitations of ``%`` string formatting why shouldn't they add a more flexible and powerful way!? Python 3.0 is not a bug fix release. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sun, 21 Dec 2008 00:57:46 -0800, Patrick Mullen wrote: 2) In my experience, major version changes tend to be slower than before. When a lot of things change, especially if very low-level things change, as happened in python 3.0, the new code has not yet went through many years of revision and optimization that the old code has. I was around for the change from Python 1.5 - 2.x. By memory, I skipped a couple of versions... I think I didn't make the move until Python 2.2 or 2.3 was released. Python 2.0 was significantly slower than 1.5 in a number of critical areas, but not for long. Actually, it's quite possible that Python 1.5 is still faster than Python 2.x in some areas -- but of course it misses a lot of features, and at the end of the day, the difference between your script completing in 0.03 seconds or in 0.06 seconds is meaningless. In my opinion, python 3 was rushed out the door a bit. It could have done with a few more months of optimization and polishing. However, on the other hand, it is going to take so long for python infrastructure to convert to python 3, that an earlier release makes sense, even if it hasn't been excessively polished. The biggest reason for the speed change is the rewritten stdio and unicode-everything. Hopefully this stuff can be improved in future updates. I don't think anyone WANTS cpython to be slower. I understand that the 3.0.1 release due out around Christmas will have some major speed-ups in stdio. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 20, 8:26 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: On Sat, 20 Dec 2008 17:55:35 -0800, Aaron Brady wrote: snip This behavior is currently legal: %i %%i % 0 % 1 '0 1' So, just extend it. (Unproduced.) %i %i % 0 % 1 '0 1' Errors should never pass silently, unless explicitly silenced. You have implicitly silenced the TypeError you get from not having enough arguments for the first format operation. That means that you will introduce ambiguity and bugs. No, it's not part of the (new) '%' operation. '%' handles one flag at a time. It's not an error if the author intends it. %i %i %i %i % 5 % 3 %7 Here I have four slots and only three numbers. Which output did I expect? '%i 5 3 7' '5 %i 3 7' '5 3 %i 7' '5 3 7 %i' Anything, so long as it's (contraction) consistent and general. Or more likely, the three numbers is a mistake, there is supposed to be a fourth number there somewhere, only now instead of the error being caught immediately, it won't be discovered until much later. Leave that to unit testing and your QA team. To make the change, the burden of proof (which is large) would fall to me. However, in the abstract case, it's not clear that either one is favorable, more obvious, or a simpler extrapolation. Bug-proneness is an argument against a construction, just not a conclusive one. How heavy is it in this case? -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 20, 8:49 pm, MRAB goo...@mrabarnett.plus.com wrote: Aaron Brady wrote: On Dec 20, 7:38 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Go on. Take your time. I'll be waiting. Hi, not to take sides, but, there is a possibility. This behavior is currently legal: %i %%i % 0 % 1 '0 1' So, just extend it. (Unproduced.) %i %i % 0 % 1 '0 1' %r %i % (2, 3, 4) % 1 '(2, 3, 4) 1' %r %i % (2, 3, 4) '(2, 3, 4) %i' Which is quite clever and way ahead of its (posessive) time. A couple of problems: 1. How do you handle a literal '%'? If you just double up then you'll need to fix the string after all your substitutions. 2. What if a substitution introduces a '%'? I suppose a possible solution would be to introduce a special format string, including a literal, eg: f%r %i % (2, 3, 4) % 1 and then convert the result to a true string: print(str(f%r %i % (2, 3, 4) % 1)) (although print() would call __str__ anyway). The format string would track where the last substitution occurred. Hmm... I think I'll just learn the new method. :-) Now that I'm fighting 'r's war for him/her... Um, here's one possibility. On the first interpolation, flags are noted and stored apart from subsequent interpolations. Then, use a sentinel to terminate the interpolation. (Unproduced.) %r %i % ( 2, 3 ) % 0 '(2, 3) 0' %% %r % ( 2, 3 ) % str.interp_end '% (2, 3)' %sss%i % %d % 0 '%dss0' The first %s is replaced with %d, but doesn't hijack the '0'. If you want to interpolate the %d, use the sentinel. The sentinel is what causes '%%' to be handled. %sss%i % %d % 0 % 1 Traceback (most recent call last): File stdin, line 1, in module TypeError: not all arguments converted during string formatting %sss%i % %d % 0 % str.interp_end % 1 '1ss0' Treating tuples as a special case appears to be the simpler solution, but this, 'chaining', to adopt the term, is still feasible. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Steven D'Aprano st...@remove-this-cybersource.com.au wrote: Errors should never pass silently, unless explicitly silenced. You have implicitly silenced the TypeError you get from not having enough arguments for the first format operation. That means that you will introduce ambiguity and bugs. %i %i %i %i % 5 % 3 %7 Here I have four slots and only three numbers. Which output did I expect? '%i 5 3 7' '5 %i 3 7' '5 3 %i 7' '5 3 7 %i' Or more likely, the three numbers is a mistake, there is supposed to be a fourth number there somewhere, only now instead of the error being caught immediately, it won't be discovered until much later. You seem to have made an unwarranted assumption, namely that a binary operator has to compile to a function with two operands. There is no particular reason why this has to always be the case: for example, I believe that C# when given several strings to add together optimises this into a single call to a concatenation method. Python *could* do something similar if the appropriate opcodes/methods supported more than two arguments: a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string concatenations or matrix operations, and a%b%c%d might execute as a.__mod__(b,c,d). In that alternate universe your example: %i %i %i %i % 5 % 3 %7 simply throws TypeError: not enough arguments for format string, and %s % (1,2,3) just converts the tuple as a single argument. It also provides the answer to how you put a percent in the format string (double it) and what happens if a substitution inserts a percent (it doesn't interact with the formatting operators). -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sun, 21 Dec 2008 12:45:32 +, Duncan Booth wrote: You seem to have made an unwarranted assumption, namely that a binary operator has to compile to a function with two operands. There is no particular reason why this has to always be the case: for example, I believe that C# when given several strings to add together optimises this into a single call to a concatenation method. Python *could* do something similar if the appropriate opcodes/methods supported more than two arguments: a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string concatenations or matrix operations, and a%b%c%d might execute as a.__mod__(b,c,d). But that needs special casing strings and ``%`` in the comiler, because it might not be always safe to do this on arbitrary objects. Only in cases where the type of `a` is known at compile time and ``a % b`` returns an object of ``type(a)``. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sun, 21 Dec 2008 12:45:32 +, Duncan Booth wrote: Steven D'Aprano st...@remove-this-cybersource.com.au wrote: Errors should never pass silently, unless explicitly silenced. You have implicitly silenced the TypeError you get from not having enough arguments for the first format operation. That means that you will introduce ambiguity and bugs. %i %i %i %i % 5 % 3 %7 Here I have four slots and only three numbers. Which output did I expect? '%i 5 3 7' '5 %i 3 7' '5 3 %i 7' '5 3 7 %i' Or more likely, the three numbers is a mistake, there is supposed to be a fourth number there somewhere, only now instead of the error being caught immediately, it won't be discovered until much later. You seem to have made an unwarranted assumption, namely that a binary operator has to compile to a function with two operands. There is no particular reason why this has to always be the case: for example, I believe that C# when given several strings to add together optimises this into a single call to a concatenation method. [...] Python *could* do something similar if the appropriate opcodes/methods supported more than two arguments: a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string concatenations or matrix operations, and a%b%c%d might execute as a.__mod__(b,c,d). That's only plausible if the operations are associative. Addition is associative, but string interpolation is not: %%%s % (%s % b) '%b' (%%%s % %s) % b Traceback (most recent call last): File stdin, line 1, in module TypeError: not all arguments converted during string formatting Since string interpolation isn't associative, your hypothetical __mod__ method might take multiple arguments, but it would have to deal with them two at a time, unlike concatenation where the compiler could do them all at once. So whether __mod__ takes two arguments or many is irrelevant: its implementation must rely on some other function which takes two arguments and must succeed or fail on that. Either that, or we change the design of % interpolation, and allow it to silently ignore errors. I assumed that is what Aaron wanted. In that alternate universe your example: %i %i %i %i % 5 % 3 %7 simply throws TypeError: not enough arguments for format string That has a disturbing consequence. Consider that most (all?) operations, we can use temporary values: x = 1 + 2 + 3 + 4 = x == 10 gives the same value for x as: temp = 1 + 2 + 3 x = temp + 4 I would expect that the same should happen for % interpolation: # using Aaron's hypothetical syntax s = %s.%s.%s.%s % 1 % 2 % 3 % 4 = 1.2.3.4 should give the same result as: temp = %s.%s.%s.%s % 1 % 2 % 3 s = temp % 4 But you're arguing that the first version should succeed and the second version, using a temporary value, should fail. And that implies that if you group part of the expression in parentheses, it will fail as well: s = (%s.%s.%s.%s % 1 % 2 % 3) % 4 Remove the parentheses, and it succeeds. That's disturbing. That makes the % operator behave very differently from other operators. Note that with the current syntax, we don't have that problem: short- supplying arguments leads to an exception no matter what. %s % (1,2,3) just converts the tuple as a single argument. It also provides the answer to how you put a percent in the format string (double it) I trust you know that already works, but just in case: %g%% % 12.5 '12.5%' and what happens if a substitution inserts a percent (it doesn't interact with the formatting operators). Ditto: %s % %g '%g' -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
r wrote: On Dec 20, 11:11 pm, walterbyrd walterb...@iname.com wrote: On Dec 20, 5:05 pm, Roy Smith r...@panix.com He got really hung up on the % syntax. I guess it's good to know that there is, at least, one person in the world doesn't like the % formatting. As least the move was not entirely pointless. But, you must admit, of all the things people complain about with Python, the % formatting is probably one of the least common complaints. Complaints about Python's speed seem much more common. Yet, 3.0 makes the speed worse, and fixes a non-problem. I can see where the new formatting might be helpful in some cases. But, I am not sure it's worth the cost. This all really comes down to the new python users. Yea, i said it. Not rabid fanboys like Steven and myself.(i can't speak for walter but i think he would agree) Are we going to make sure joe-blow python newbie likes the language. And doesn't get turned off and run over to ruby or whoever. Like it or not, without newusers python is doomed to the same fate as all the other great languages who had their 15 mins of fame. We must proactively seek out the wants of these new users and make sure python stays alive. But we also must not sell are pythonic souls that's our (possessive), r, not are (verb) in the process. It would be nice to get a vote together and see what does the average pythoneer want? What do they like, What do they dislike. What is the state of the Python Union? Does anybody know, Does anybody care? I think python is slipping away from it's dominate foothold on the world. Google's use of python may be the only thing holding this house of cards together. Ruby's hype is defiantly growing and unless we strive for greatness, python may fail. I think ruby may have their act together a little better than us right now. And since Ruby is such a hodge-podge of different languages, the __init__ hold is there for many. what does joe-python want??? Don't make the mistake of assuming there is a Joe Python whose needs neatly encapsulate the sum of all Python users' needs. There's plenty of evidence from this group that different people like, want or need different things from Python, and attempting to measure user requirements by democratic means is not likely to produce much useful information. There is no such thing as the average Python programmer: an average can only be measured for one-dimensional values on some sort of linear continuum. Python users live in a multi-dimensional space where the concept of an average has little meaning and less use. As for your assertion that Google's use of Python may be the only thing maintaining Python's popularity, it's complete twaddle. Take a look around at who's involved in using Python. I suspect Industrial Light and Magic ,may have more Python programmers than Google, who also make extensive use of Java and one other language (C++?), as well as a bevy of others as justified by project needs. Rackspace, NASA, Canonical and many others are keen supporters of the language, and they put their money where their mouths are by incorporating it into their products. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Marc Many newbie code I have seen avoids it by string concatenation: Marc greeting = 'Hello, my name is ' + name + ' and I am ' + str(age) + ' old.' Marc That's some kind of indirect complaint. :-) I see Python code like that written by people with a C/C++ background. I don't think you can necessarily chalk that up to %-string avoidance. They learn that + will concatenate two strings and don't look further. -- Skip Montanaro - s...@pobox.com - http://smontanaro.dyndns.org/ -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Marc 'BlackJack' Rintsch bj_...@gmx.net wrote: a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string concatenations or matrix operations, and a%b%c%d might execute as a.__mod__(b,c,d). But that needs special casing strings and ``%`` in the comiler, because it might not be always safe to do this on arbitrary objects. Only in cases where the type of `a` is known at compile time and ``a % b`` returns an object of ``type(a)``. I could be wrong, but I don't see that would be the case. I think it would be safe (in this hypothetical universe) any time that 'a' had a method __mod__ which accepted more than one argument. It might be simpler if I'd suggested an imaginary __mmod__ method so the opcode for multiple-mod could check for that method or fall back to doing mod of the first two values and then mmod of the result and any remaining values until only two remain. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Steven D'Aprano st...@remove-this-cybersource.com.au wrote: a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string concatenations or matrix operations, and a%b%c%d might execute as a.__mod__(b,c,d). That's only plausible if the operations are associative. Addition is associative, but string interpolation is not: Addition is not associative on arbitrary types. %%%s % (%s % b) '%b' (%%%s % %s) % b Traceback (most recent call last): File stdin, line 1, in module TypeError: not all arguments converted during string formatting Since string interpolation isn't associative, your hypothetical __mod__ method might take multiple arguments, but it would have to deal with them two at a time, unlike concatenation where the compiler could do them all at once. So whether __mod__ takes two arguments or many is irrelevant: its implementation must rely on some other function which takes two arguments and must succeed or fail on that. I don't see that. What I suggested was that a % b % c would map to a.__mod__(b,c). (a % b) % c would also map to that, but a % (b % c) could only possibly map to a.__mod__(b.__mod__(c)) -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 21, 7:34 am, Marc 'BlackJack' Rintsch bj_...@gmx.net wrote: On Sun, 21 Dec 2008 12:45:32 +, Duncan Booth wrote: You seem to have made an unwarranted assumption, namely that a binary operator has to compile to a function with two operands. There is no particular reason why this has to always be the case: for example, I believe that C# when given several strings to add together optimises this into a single call to a concatenation method. Python *could* do something similar if the appropriate opcodes/methods supported more than two arguments: a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string concatenations or matrix operations, and a%b%c%d might execute as a.__mod__(b,c,d). But that needs special casing strings and ``%`` in the comiler, because it might not be always safe to do this on arbitrary objects. Only in cases where the type of `a` is known at compile time and ``a % b`` returns an object of ``type(a)``. 'x+y' makes no guarantees whatsoever. It could return an object of type(x), type(y), or neither. 'a%b' in the case of strings is just, str.__mod__, returning string. In a+b+c, 'a' gets dibs over what the rest see, so there's no more danger in the multi-ary case, than in binary; and that hasn't stopped us before. You might be confusing the cases of arbitrary operators vs. uniform operators. 'a' does not get dibs in 'a+b*c'; 'b*c' are allowed to carry out their affairs. But in 'a+b+c', 'a*b*c', 'a%b%c', and so on, 'a' has final say on b's and c's behaviors via its return value, so loses nothing by combining such a call. In short, you can force it anyway, so it's syntactic sugar after that. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 21, 8:50 am, Steve Holden st...@holdenweb.com wrote: r wrote: snip This all really comes down to the new python users. Yea, i said it. Not rabid fanboys like Steven and myself.(i can't speak for walter but i think he would agree) Are we going to make sure joe-blow python newbie likes the language. And doesn't get turned off and run over to ruby or whoever. Like it or not, without newusers python is doomed to the same fate as all the other great languages who had their 15 mins of fame. We must proactively seek out the wants of these new users and make sure python stays alive. But we also must not sell are pythonic souls that's our (possessive), r, not are (verb) in the process. It would be nice to get a vote together and see what does the average pythoneer want? What do they like, What do they dislike. What is the state of the Python Union? Does anybody know, Does anybody care? I think python is slipping away from it's dominate foothold on the world. Google's use of python may be the only thing holding this house of cards together. Ruby's hype is defiantly growing and unless we strive for greatness, python may fail. I think ruby may have their act together a little better than us right now. And since Ruby is such a hodge-podge of different languages, the __init__ hold is there for many. what does joe-python want??? Don't make the mistake of assuming there is a Joe Python whose needs neatly encapsulate the sum of all Python users' needs. There's plenty of evidence from this group that different people like, want or need different things from Python, and attempting to measure user requirements by democratic means is not likely to produce much useful information. There is no such thing as the average Python programmer: an average can only be measured for one-dimensional values on some sort of linear continuum. Python users live in a multi-dimensional space where the concept of an average has little meaning and less use. You've confused dimensions with modes. There is such thing as the center of a bivariate distribution--- it is merely the most common of the individual variables, the top of a 3-D hill, or the center of mass. However, an average only makes sense for unimodal distributions. If the distribution is bi-modal, there's no average in the neat sense. Dollars earned per hour spent writing in Python is a good candidate. There are two modes in that distribution. One at 0, the other in the tens or hundreds. And the global average is less common than either mode individually. So in this case, we have one Joe Py for every mode: Joe Free Py, and Joe Paid Py. (You might actually get multi- modal on that one-- Joe Salary Py, Joe Wage Py, Joe Stipend Py, Joe Free Py, but $0.01/hr. is less common than 0, and less common than $50.) You might also argue that the standard deviation is so high as to make any one data point unrepresentative of many others. But if you have variables in two dimensions, they're independent by definition (or there exists a basis set that is). -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Duncan Booth wrote: I don't see that. What I suggested was that a % b % c would map to a.__mod__(b,c). (a % b) % c would also map to that, but a % (b % c) could only possibly map to a.__mod__(b.__mod__(c)) There's a compiling problem here, no? You don't want a%b%c to implement as a.__mod__(b,c) if a is a number. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sun, 21 Dec 2008 15:30:34 +, Duncan Booth wrote: Marc 'BlackJack' Rintsch bj_...@gmx.net wrote: a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string concatenations or matrix operations, and a%b%c%d might execute as a.__mod__(b,c,d). But that needs special casing strings and ``%`` in the comiler, because it might not be always safe to do this on arbitrary objects. Only in cases where the type of `a` is known at compile time and ``a % b`` returns an object of ``type(a)``. I could be wrong, but I don't see that would be the case. I think it would be safe (in this hypothetical universe) any time that 'a' had a method __mod__ which accepted more than one argument. And returns an object of ``type(a)`` or at least a duck type so that it is guaranteed that ``a.__mod__(b, c)`` really has the same semantics as ``a.__mod__(b).__mod__(c)``. For arbitrary objects `a`, `b`, and `c` that are not known at compile time, how could the compiler decide if it is safe to emit code that calls `a.__mod__()` with multiple arguments? Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Aaron Brady wrote: On Dec 20, 8:49 pm, MRAB goo...@mrabarnett.plus.com wrote: Aaron Brady wrote: On Dec 20, 7:38 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Go on. Take your time. I'll be waiting. Hi, not to take sides, but, there is a possibility. This behavior is currently legal: %i %%i % 0 % 1 '0 1' So, just extend it. (Unproduced.) %i %i % 0 % 1 '0 1' %r %i % (2, 3, 4) % 1 '(2, 3, 4) 1' %r %i % (2, 3, 4) '(2, 3, 4) %i' Which is quite clever and way ahead of its (posessive) time. A couple of problems: 1. How do you handle a literal '%'? If you just double up then you'll need to fix the string after all your substitutions. 2. What if a substitution introduces a '%'? I suppose a possible solution would be to introduce a special format string, including a literal, eg: f%r %i % (2, 3, 4) % 1 and then convert the result to a true string: print(str(f%r %i % (2, 3, 4) % 1)) (although print() would call __str__ anyway). The format string would track where the last substitution occurred. Hmm... I think I'll just learn the new method. :-) Now that I'm fighting 'r's war for him/her... Um, here's one possibility. On the first interpolation, flags are noted and stored apart from subsequent interpolations. Then, use a sentinel to terminate the interpolation. (Unproduced.) %r %i % ( 2, 3 ) % 0 '(2, 3) 0' %% %r % ( 2, 3 ) % str.interp_end '% (2, 3)' %sss%i % %d % 0 '%dss0' The first %s is replaced with %d, but doesn't hijack the '0'. If you want to interpolate the %d, use the sentinel. The sentinel is what causes '%%' to be handled. %sss%i % %d % 0 % 1 Traceback (most recent call last): File stdin, line 1, in module TypeError: not all arguments converted during string formatting %sss%i % %d % 0 % str.interp_end % 1 '1ss0' Treating tuples as a special case appears to be the simpler solution, but this, 'chaining', to adopt the term, is still feasible. A possible solution occurred to me shortly after I posted, but I decided that sleep was more important. :-) The original format is a string. The result of '%' is a string if there's only 1 placeholder to fill, or a (partial) format object (class Format?) if there's more than one. Similarly, the format object supports '%'. The result of '%' is a string if there's only 1 placeholder to fill, or a new (partial) format object if there's more than one. f = %r %i type(f) type 'str' f = f % (2, 3, 4) type(f) type 'Format' f = f % 1 type(f) type 'str' -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 21, 10:31 am, MRAB goo...@mrabarnett.plus.com wrote: Aaron Brady wrote: On Dec 20, 8:49 pm, MRAB goo...@mrabarnett.plus.com wrote: Aaron Brady wrote: On Dec 20, 7:38 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Go on. Take your time. I'll be waiting. Hi, not to take sides, but, there is a possibility. This behavior is currently legal: %i %%i % 0 % 1 '0 1' So, just extend it. (Unproduced.) %i %i % 0 % 1 '0 1' %r %i % (2, 3, 4) % 1 '(2, 3, 4) 1' %r %i % (2, 3, 4) '(2, 3, 4) %i' Which is quite clever and way ahead of its (posessive) time. A couple of problems: 1. How do you handle a literal '%'? If you just double up then you'll need to fix the string after all your substitutions. 2. What if a substitution introduces a '%'? I suppose a possible solution would be to introduce a special format string, including a literal, eg: f%r %i % (2, 3, 4) % 1 and then convert the result to a true string: print(str(f%r %i % (2, 3, 4) % 1)) (although print() would call __str__ anyway). The format string would track where the last substitution occurred. Hmm... I think I'll just learn the new method. :-) Now that I'm fighting 'r's war for him/her... Um, here's one possibility. On the first interpolation, flags are noted and stored apart from subsequent interpolations. Then, use a sentinel to terminate the interpolation. (Unproduced.) %r %i % ( 2, 3 ) % 0 '(2, 3) 0' %% %r % ( 2, 3 ) % str.interp_end '% (2, 3)' %sss%i % %d % 0 '%dss0' The first %s is replaced with %d, but doesn't hijack the '0'. If you want to interpolate the %d, use the sentinel. The sentinel is what causes '%%' to be handled. %sss%i % %d % 0 % 1 Traceback (most recent call last): File stdin, line 1, in module TypeError: not all arguments converted during string formatting %sss%i % %d % 0 % str.interp_end % 1 '1ss0' Treating tuples as a special case appears to be the simpler solution, but this, 'chaining', to adopt the term, is still feasible. A possible solution occurred to me shortly after I posted, but I decided that sleep was more important. :-) The original format is a string. The result of '%' is a string if there's only 1 placeholder to fill, or a (partial) format object (class Format?) if there's more than one. Similarly, the format object supports '%'. The result of '%' is a string if there's only 1 placeholder to fill, or a new (partial) format object if there's more than one. f = %r %i type(f) type 'str' f = f % (2, 3, 4) type(f) type 'Format' f = f % 1 type(f) type 'str' Alright, so how are you handling: f= %s %i type( f ) type 'str' f= f% '%i' #now '%i %i' type( f ) type 'Format' f= f% 1 type( f ) ? In other words, are you slipping '1' in to the very first available slot, or the next, after the location of the prior? -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Aaron Brady wrote: On Dec 21, 10:31 am, MRAB goo...@mrabarnett.plus.com wrote: Aaron Brady wrote: On Dec 20, 8:49 pm, MRAB goo...@mrabarnett.plus.com wrote: Aaron Brady wrote: On Dec 20, 7:38 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Go on. Take your time. I'll be waiting. Hi, not to take sides, but, there is a possibility. This behavior is currently legal: %i %%i % 0 % 1 '0 1' So, just extend it. (Unproduced.) %i %i % 0 % 1 '0 1' %r %i % (2, 3, 4) % 1 '(2, 3, 4) 1' %r %i % (2, 3, 4) '(2, 3, 4) %i' Which is quite clever and way ahead of its (posessive) time. A couple of problems: 1. How do you handle a literal '%'? If you just double up then you'll need to fix the string after all your substitutions. 2. What if a substitution introduces a '%'? I suppose a possible solution would be to introduce a special format string, including a literal, eg: f%r %i % (2, 3, 4) % 1 and then convert the result to a true string: print(str(f%r %i % (2, 3, 4) % 1)) (although print() would call __str__ anyway). The format string would track where the last substitution occurred. Hmm... I think I'll just learn the new method. :-) Now that I'm fighting 'r's war for him/her... Um, here's one possibility. On the first interpolation, flags are noted and stored apart from subsequent interpolations. Then, use a sentinel to terminate the interpolation. (Unproduced.) %r %i % ( 2, 3 ) % 0 '(2, 3) 0' %% %r % ( 2, 3 ) % str.interp_end '% (2, 3)' %sss%i % %d % 0 '%dss0' The first %s is replaced with %d, but doesn't hijack the '0'. If you want to interpolate the %d, use the sentinel. The sentinel is what causes '%%' to be handled. %sss%i % %d % 0 % 1 Traceback (most recent call last): File stdin, line 1, in module TypeError: not all arguments converted during string formatting %sss%i % %d % 0 % str.interp_end % 1 '1ss0' Treating tuples as a special case appears to be the simpler solution, but this, 'chaining', to adopt the term, is still feasible. A possible solution occurred to me shortly after I posted, but I decided that sleep was more important. :-) The original format is a string. The result of '%' is a string if there's only 1 placeholder to fill, or a (partial) format object (class Format?) if there's more than one. Similarly, the format object supports '%'. The result of '%' is a string if there's only 1 placeholder to fill, or a new (partial) format object if there's more than one. f = %r %i type(f) type 'str' f = f % (2, 3, 4) type(f) type 'Format' f = f % 1 type(f) type 'str' Alright, so how are you handling: f= %s %i type( f ) type 'str' f= f% '%i' #now '%i %i' type( f ) type 'Format' f= f% 1 type( f ) ? In other words, are you slipping '1' in to the very first available slot, or the next, after the location of the prior? Let's assume that Format objects display their value like the equivalent string format: f = %r %i f '%r %i' f = f % (2, 3, 4) f Format '(2, 3, 4) %i' f = f % 1 f '(2, 3, 4) 1' f = %s %i f '%s %i' f = f % '%i' f Format '%%i %i' f = f % 1 f '%%i 1' -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
MRAB: Interesting. The re module uses a form of bytecode. Not sure about the relative cost of the dispatch code, though. I was talking about the main CPython VM, but the same ideas may be adapted for the RE engine too. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Patrick Mullen schrieb: 2) In my experience, major version changes tend to be slower than before. When a lot of things change, especially if very low-level things change, as happened in python 3.0, the new code has not yet went through many years of revision and optimization that the old code has. In my opinion, python 3 was rushed out the door a bit. It could have done with a few more months of optimization and polishing. However, on the other hand, it is going to take so long for python infrastructure to convert to python 3, that an earlier release makes sense, even if it hasn't been excessively polished. The biggest reason for the speed change is the rewritten stdio and unicode-everything. Hopefully this stuff can be improved in future updates. I don't think anyone WANTS cpython to be slower. The 3.0 release targets third party developers. Authors of 3rd party extensions and libraries need a stable API to port their software to a new major release. The main objective was feature completeness and stability. If you need speed either stick to the 2.x series or wait until 3.1 is out. We could have waited a few more months or even a few more years with a 3.0 release. There is always - I repeat ALWAYS - work to do. For an open source project like Python release early, release often works better. Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
I noticed when i mentioned self nobody wants to touch that subject. There could be many reasons why... 0.) nobody but the 10 regulars i see here exists 1.) nobody cares(doubt it) 2.) nobody is brave enough to question it(maybe) 3.) most people like to type self over and over again(doubt it) 4.) most people here have given up on changing the BDFL's mind about it. (good possibility) 5.) this is a hot-button topic(no doubt in my mind!) I think Guido's intension's are pure, but this is a major turnoff to new users. Do we really need to hold a new users hand that much. Does it really matter if they know the path of said obj. If you can't fiqure this out for yourself you have much greater problems. I do not like self, and i lamented it from day one, now it is second nature to me but does that mean it is really needed?? I feel i have been brainwashed into its usage. This was the reason for using indention over the bracket plague in python. REDUNDANCY!!! Why not dump self and make the language cleaner. I love python's classes, but HATE self.redundant! This really needs to be fixed, and you have not heard the last from me about it!!! 3000 would have been the perfect time to dump self and really clean up the language, and it's not too late, dawn is not upon us yet. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Quoting r rt8...@gmail.com: I noticed when i mentioned self nobody wants to touch that subject. There could be many reasons why... 0.) nobody but the 10 regulars i see here exists 1.) nobody cares(doubt it) 2.) nobody is brave enough to question it(maybe) 3.) most people like to type self over and over again(doubt it) 4.) most people here have given up on changing the BDFL's mind about it. (good possibility) 5.) this is a hot-button topic(no doubt in my mind!) You forgot 6.) it is the best, cleanest, most consistent and extensible way to do it. This was the reason for using indention over the bracket plague in python. REDUNDANCY!!! Why not dump self and make the language cleaner. I love python's classes, but HATE self.redundant! This really needs to be fixed, and you have not heard the last from me about it!!! Do you also hate cls.redundant on a classmethod? Would you rather type 'self' even when it is referring to a class? Would you like to resort to a hack, like C#3.0's 'this' explicit argument, when monkey-patching? I used to hate 'self'. Then I met classmethods, metaclasses and decorators, and the 'new'/'types' modules. It's just one of those examples where Guido's time machine works flawlessly. 3000 would have been the perfect time to dump self and really clean up the language, and it's not too late, dawn is not upon us yet. No need to wait for python 3000. You can have a 'selfless metaclass' right now: http://www.voidspace.org.uk/python/articles/metaclasses.shtml (BTW, I really hope you are complaining about the explicit self on the argument list, and not about the 'self.' prefix - if that were the case, what magic would you propose for the compiler to guess when you are referring to locals, globals, class or instance variables?) -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
r wrote: I noticed when i mentioned self nobody wants to touch that subject. There could be many reasons why... 0.) nobody but the 10 regulars i see here exists 1.) nobody cares(doubt it) 2.) nobody is brave enough to question it(maybe) 3.) most people like to type self over and over again(doubt it) 4.) most people here have given up on changing the BDFL's mind about it. (good possibility) 5.) this is a hot-button topic(no doubt in my mind!) 6.) nobody here wants to go through that whole discussion yet again -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sun, Dec 21, 2008 at 11:26 AM, r rt8...@gmail.com wrote: I noticed when i mentioned self nobody wants to touch that subject. There could be many reasons why... 0.) nobody but the 10 regulars i see here exists 1.) nobody cares(doubt it) 2.) nobody is brave enough to question it(maybe) 3.) most people like to type self over and over again(doubt it) 4.) most people here have given up on changing the BDFL's mind about it. (good possibility) 5.) this is a hot-button topic(no doubt in my mind!) It's a combination between (4) (5) and (6). 6 being, we have discussed self every week for the past 6 years, it hasn't changed yet, it's not going away, it's not a trivial problem, deal with it. (0) is ridiculous, there are more than 10 respondents to this post alone. (1) - if nobody cared it wouldn't come up every week, but it's been discussed so much most are tired of it (2) - people question it all the time, usually people who are new to the language but not always. The discussion generally doesn't amount to anything (3) - It's not about wanting to type self over and over again, it's about being able to start with functions or start with classes, and easily refactor to the other way when needed; and never having a chance to wonder where a variable came from. There are ups and downs to self, it is generally more work to remove it than it is worth, what would the gain be? We'd be trading some ups and downs for some other ups and downs. And no, BDFL is not going to bend on self. He almost bent on the issue a few weeks ago, but his proposition merely changed some syntax - self was still there. On Sun, Dec 21, 2008 at 11:01 AM, Christian Heimes li...@cheimes.de wrote: We could have waited a few more months or even a few more years with a 3.0 release. There is always - I repeat ALWAYS - work to do. For an open source project like Python release early, release often works better. Good point, and I agree. It's too early for people to complain about python 3 being slow. It's also too both too late and too early to complain about things in python 3 that are thought of as a step backward. It's too late, because python 3 is out and it's already been changed! Things are not going to change back. Complaints are a bit useless at this point, except to let off steam. It's too early, because without using python3 in a major project, from the ground up, with the new features, the benefits or negatives for all of the changes cannot truly be known. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
r a écrit : (snip clueless rant) One more big complaint THE BACKSLASH PLAGUE. ever tried regexp? Yes. exp = re.compile(rno \problem \with \backslashes) , or file paths?. You mean _dos/windows_ file path separator ? It was indeed a stupid choice _from microsoft_ to choose the by then well established escape char (the backslash) as a file path separator. But hopefully, Python handles it gracefully: you can either use raw strings (which I stronly advise you learn about instead of whining) or just the traditional unix one (forward slash) instead. All because that little backslash char is a line continuation character, Totally clueless, as usual... Why don't you just READ THAT FUCKING MANUAL ? -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
walterbyrd a écrit : On Dec 20, 5:05 pm, Roy Smith r...@panix.com He got really hung up on the % syntax. I guess it's good to know that there is, at least, one person in the world doesn't like the % formatting. As least the move was not entirely pointless. But, you must admit, of all the things people complain about with Python, the % formatting is probably one of the least common complaints. Complaints about Python's speed seem much more common. dead-horse-beaten-to-hell-and-back People complaining about the perceived issues wrt/ Python's speed are welcome to fix it. As far as I'm concerned, I find the perfs more than acceptable when you take Python's dynamism into account. Strange enough, no one seems to complain about PHP or Ruby's performances... /dead-horse-beaten-to-hell-and-back Yet, 3.0 makes the speed worse, first make it right, then make it fast... and fixes a non-problem. I can see where the new formatting might be helpful in some cases. But, I am not sure it's worth the cost. Err... _Which_ cost exactly ? -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
r a écrit : I noticed when i mentioned self nobody wants to touch that subject. There could be many reasons why... 0.) nobody but the 10 regulars i see here exists 1.) nobody cares(doubt it) 2.) nobody is brave enough to question it(maybe) 3.) most people like to type self over and over again(doubt it) 4.) most people here have given up on changing the BDFL's mind about it. (good possibility) 5.) this is a hot-button topic(no doubt in my mind!) 6.) you are definitevely clueless. (snip) I love python's classes, but HATE self.redundant! This declaration only makes clear that answer to your above question is #6. This really needs to be fixed, Your ignorance needs to be fixed, yes, indeed. Please go and fix it - all the relevant materials is available in (or linked from somewhere in) this newgroup's archives. and you have not heard the last from me about it!!! As far as I'm concerned, yes. Welcome to my bozo filter. Please come back when you'll have grown a brain. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Hey Bruno, Thanks for spelling it out for me :D -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Bruno, I thought i had already gone up, up, and away to your kill filter. hmm, guess you had a change of heart ;D -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sun, Dec 21, 2008 at 2:26 PM, r rt8...@gmail.com wrote: I noticed when i mentioned self nobody wants to touch that subject. There could be many reasons why... 0.) nobody but the 10 regulars i see here exists if you only see 10 people, you must not be following this list very well. 1.) nobody cares(doubt it) If people cared that much, they wouldn't use python. 2.) nobody is brave enough to question it(maybe) Check the archives. There have been plenty of people who questioned it. People got so bored with them that the only answer you're likely to get now is people quoting the zen. 3.) most people like to type self over and over again(doubt it) You have to type self over and over again? I don't know about the other editors, about Eclipse/PyDev's autocomplete will add it to any function declared within a class unless it has @staticmethod or @classmethod above it. 4.) most people here have given up on changing the BDFL's mind about it. (good possibility) 5.) this is a hot-button topic(no doubt in my mind!) Not really. Again, if you care that much about explicit self, use another language. I think Guido's intension's are pure, but this is a major turnoff to new users. Do we really need to hold a new users hand that much. Does it really matter if they know the path of said obj. If you can't fiqure this out for yourself you have much greater problems. I do not like self, and i lamented it from day one, now it is second nature to me but does that mean it is really needed?? I feel i have been brainwashed into its usage. This was the reason for using indention over the bracket plague in python. REDUNDANCY!!! Why not dump self and make the language cleaner. I love python's classes, but HATE self.redundant! This really needs to be fixed, and you have not heard the last from me about it!!! 3000 would have been the perfect time to dump self and really clean up the language, and it's not too late, dawn is not upon us yet. yes, it is too late. Python 3 is out and done. There will be no more sweeping, backwards-incompatible changes until Python 4. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 21, 10:58 am, MRAB goo...@mrabarnett.plus.com wrote: Aaron Brady wrote: On Dec 21, 10:31 am, MRAB goo...@mrabarnett.plus.com wrote: snip The original format is a string. The result of '%' is a string if there's only 1 placeholder to fill, or a (partial) format object (class Format?) if there's more than one. Similarly, the format object supports '%'. The result of '%' is a string if there's only 1 placeholder to fill, or a new (partial) format object if there's more than one. f = %r %i type(f) type 'str' f = f % (2, 3, 4) type(f) type 'Format' f = f % 1 type(f) type 'str' Alright, so how are you handling: f= %s %i type( f ) type 'str' f= f% '%i' #now '%i %i' type( f ) type 'Format' f= f% 1 type( f ) ? In other words, are you slipping '1' in to the very first available slot, or the next, after the location of the prior? Let's assume that Format objects display their value like the equivalent string format: f = %r %i f '%r %i' f = f % (2, 3, 4) f Format '(2, 3, 4) %i' f = f % 1 f '(2, 3, 4) 1' f = %s %i f '%s %i' f = f % '%i' f Format '%%i %i' f = f % 1 f '%%i 1' I assume you meant '%i 1' since there are no more flags in f, and it's returned to a regular string. 'f %= 1' doesn't work any more as in-place modulo, since one time, 'f' is a Format object, the other, 'f' is a string. Just raise an exception for that (or assign to __class__ IINM if I'm not mistaken). Actually, the class you showed is kind of nifty. Tuples are correctly interpolated. I think on the whole you'll use more parenthesis, since each term in the tuple appears separately, and might be an expression (have a lower-precedence op.), as well as more modulo signs. You can currently do-it-yourself, you just need a constructor in the format string. f = Format(%r %i) type(f) type 'Format' f = f % (2, 3, 4) type(f) type 'Format' Or, as someone suggested earlier, a new literal marking: f = f%r %i type(f) type 'Format' -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Aaron Brady wrote:
On Dec 21, 10:58 am, MRAB goo...@mrabarnett.plus.com wrote:
Aaron Brady wrote:
On Dec 21, 10:31 am, MRAB goo...@mrabarnett.plus.com wrote:
snip
The original format is a string. The result of '%' is a string if
there's only 1 placeholder to fill, or a (partial) format object (class
Format?) if there's more than one. Similarly, the format object
supports '%'. The result of '%' is a string if there's only 1
placeholder to fill, or a new (partial) format object if there's more
than one.
f = %r %i
type(f)
type 'str'
f = f % (2, 3, 4)
type(f)
type 'Format'
f = f % 1
type(f)
type 'str'
Alright, so how are you handling:
f= %s %i
type( f )
type 'str'
f= f% '%i' #now '%i %i'
type( f )
type 'Format'
f= f% 1
type( f )
?
In other words, are you slipping '1' in to the very first available
slot, or the next, after the location of the prior?
Let's assume that Format objects display their value like the equivalent
string format:
f = %r %i
f
'%r %i'
f = f % (2, 3, 4)
f
Format '(2, 3, 4) %i'
f = f % 1
f
'(2, 3, 4) 1'
f = %s %i
f
'%s %i'
f = f % '%i'
f
Format '%%i %i'
f = f % 1
f
'%%i 1'
I assume you meant '%i 1' since there are no more flags in f, and it's
returned to a regular string.
Correct.
'f %= 1' doesn't work any more as in-place modulo, since one time, 'f'
is a Format object, the other, 'f' is a string. Just raise an
exception for that (or assign to __class__ IINM if I'm not mistaken).
All assignments rebind, even the augmented form:
class C1(object):
def __mod__(self, value):
return C2()
class C2(object):
def __mod__(self, value):
return C2()
f = C1()
f
__main__.C1 object at 0x00D144F0
f % 0
__main__.C2 object at 0x00D143F0
f %= 0
f
__main__.C2 object at 0x00D145B0
Actually, the class you showed is kind of nifty. Tuples are correctly
interpolated. I think on the whole you'll use more parenthesis, since
each term in the tuple appears separately, and might be an expression
(have a lower-precedence op.), as well as more modulo signs.
You can currently do-it-yourself, you just need a constructor in the
format string.
f = Format(%r %i)
type(f)
type 'Format'
f = f % (2, 3, 4)
type(f)
type 'Format'
Or, as someone suggested earlier, a new literal marking:
Yes, I suggested that earlier, but it isn't needed because you can
create a format object with Format(string). However, most of the time
you won't bother to create a format object explicitly because of:
class str(object):
def __mod__(self, value):
return Format(self) % value
f = f%r %i
type(f)
type 'Format'
# Explicitly
f = Format(%r %i)
f
Format '%r %i'
f % (2, 3, 4)
Format '(2, 3, 4) %i'
# Implicitly, relying on the __mod__ method of str
f = %r %i
f
'%r %i'
f % (2, 3, 4)
Format '(2, 3, 4) %i'
I'd also like to add that there's nothing to prevent format objects from
having other methods where multiple placeholders can be filled in one call:
# By position
f = Format(%r %i)
f
Format '%r %i'
f.fill([(2, 3, 4), 1])
'(2, 3, 4) 1'
# By name
f = Format(%{tuple}r %{int}i)
f
Format '%{tuple}r %{int}i'
f.fill({tuple: (2, 3, 4), int: 1})
'(2, 3, 4) 1'
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 21, 10:11 am, r rt8...@gmail.com wrote: Most of the complaints i hear are the redundant use of self. Which I lamented about but have become accustom(brainwashed) to it. I would remove this if it where up to me. It's a shame Python wasn't released under some kind of license, one that allowed its source to be, say, opened and modified. Otherwise you would just implement this yourself and submit patches, right? -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Mon, Dec 22, 2008 at 11:37 AM, alex23 wuwe...@gmail.com wrote: On Dec 21, 10:11 am, r rt8...@gmail.com wrote: Most of the complaints i hear are the redundant use of self. Which I lamented about but have become accustom(brainwashed) to it. I would remove this if it where up to me. It's a shame Python wasn't released under some kind of license, one that allowed its source to be, say, opened and modified. Otherwise you would just implement this yourself and submit patches, right? +1 :) -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 21, 6:14 pm, MRAB goo...@mrabarnett.plus.com wrote:
Aaron Brady wrote:
On Dec 21, 10:58 am, MRAB goo...@mrabarnett.plus.com wrote:
Aaron Brady wrote:
On Dec 21, 10:31 am, MRAB goo...@mrabarnett.plus.com wrote:
snip
The original format is a string. The result of '%' is a string if
there's only 1 placeholder to fill, or a (partial) format object (class
Format?) if there's more than one. Similarly, the format object
supports '%'. The result of '%' is a string if there's only 1
placeholder to fill, or a new (partial) format object if there's more
than one.
f = %r %i
type(f)
type 'str'
f = f % (2, 3, 4)
type(f)
type 'Format'
f = f % 1
type(f)
type 'str'
Alright, so how are you handling:
f= %s %i
type( f )
type 'str'
f= f% '%i' #now '%i %i'
type( f )
type 'Format'
f= f% 1
type( f )
?
In other words, are you slipping '1' in to the very first available
slot, or the next, after the location of the prior?
Let's assume that Format objects display their value like the equivalent
string format:
f = %r %i
f
'%r %i'
f = f % (2, 3, 4)
f
Format '(2, 3, 4) %i'
f = f % 1
f
'(2, 3, 4) 1'
f = %s %i
f
'%s %i'
f = f % '%i'
f
Format '%%i %i'
f = f % 1
f
'%%i 1'
I assume you meant '%i 1' since there are no more flags in f, and it's
returned to a regular string.
Correct.
'f %= 1' doesn't work any more as in-place modulo, since one time, 'f'
is a Format object, the other, 'f' is a string. Just raise an
exception for that (or assign to __class__ IINM if I'm not mistaken).
All assignments rebind, even the augmented form:
class C1(object):
def __mod__(self, value):
return C2()
class C2(object):
def __mod__(self, value):
return C2()
f = C1()
f
__main__.C1 object at 0x00D144F0
f % 0
__main__.C2 object at 0x00D143F0
f %= 0
f
__main__.C2 object at 0x00D145B0
Actually, the class you showed is kind of nifty. Tuples are correctly
interpolated. I think on the whole you'll use more parenthesis, since
each term in the tuple appears separately, and might be an expression
(have a lower-precedence op.), as well as more modulo signs.
You can currently do-it-yourself, you just need a constructor in the
format string.
f = Format(%r %i)
type(f)
type 'Format'
f = f % (2, 3, 4)
type(f)
type 'Format'
Or, as someone suggested earlier, a new literal marking:
Yes, I suggested that earlier, but it isn't needed because you can
create a format object with Format(string). However, most of the time
you won't bother to create a format object explicitly because of:
class str(object):
def __mod__(self, value):
return Format(self) % value
f = f%r %i
type(f)
type 'Format'
# Explicitly
f = Format(%r %i)
f
Format '%r %i'
f % (2, 3, 4)
Format '(2, 3, 4) %i'
# Implicitly, relying on the __mod__ method of str
f = %r %i
f
'%r %i'
f % (2, 3, 4)
Format '(2, 3, 4) %i'
I'd also like to add that there's nothing to prevent format objects from
having other methods where multiple placeholders can be filled in one call:
# By position
f = Format(%r %i)
f
Format '%r %i'
f.fill([(2, 3, 4), 1])
'(2, 3, 4) 1'
# By name
f = Format(%{tuple}r %{int}i)
f
Format '%{tuple}r %{int}i'
f.fill({tuple: (2, 3, 4), int: 1})
'(2, 3, 4) 1'
You're choosing to favor the '.chain()' method over the '.fill()'
method for the behavior of '%'. I don't think you've justified it
though.
Format( %r %i ).chain( ( 2, 3, 4 ) ).chain( 0 )
'(2, 3, 4) 0'
Format( %r %i ).fill( ( 2, 3, 4 ), 0 )
'(2, 3, 4) 0'
Plus, I almost think we've almost attained defeating the purpose.
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Aaron Brady wrote:
On Dec 21, 6:14 pm, MRAB goo...@mrabarnett.plus.com wrote:
Aaron Brady wrote:
On Dec 21, 10:58 am, MRAB goo...@mrabarnett.plus.com wrote:
Aaron Brady wrote:
On Dec 21, 10:31 am, MRAB goo...@mrabarnett.plus.com wrote:
snip
The original format is a string. The result of '%' is a string if
there's only 1 placeholder to fill, or a (partial) format object (class
Format?) if there's more than one. Similarly, the format object
supports '%'. The result of '%' is a string if there's only 1
placeholder to fill, or a new (partial) format object if there's more
than one.
f = %r %i
type(f)
type 'str'
f = f % (2, 3, 4)
type(f)
type 'Format'
f = f % 1
type(f)
type 'str'
Alright, so how are you handling:
f= %s %i
type( f )
type 'str'
f= f% '%i' #now '%i %i'
type( f )
type 'Format'
f= f% 1
type( f )
?
In other words, are you slipping '1' in to the very first available
slot, or the next, after the location of the prior?
Let's assume that Format objects display their value like the equivalent
string format:
f = %r %i
f
'%r %i'
f = f % (2, 3, 4)
f
Format '(2, 3, 4) %i'
f = f % 1
f
'(2, 3, 4) 1'
f = %s %i
f
'%s %i'
f = f % '%i'
f
Format '%%i %i'
f = f % 1
f
'%%i 1'
I assume you meant '%i 1' since there are no more flags in f, and it's
returned to a regular string.
Correct.
'f %= 1' doesn't work any more as in-place modulo, since one time, 'f'
is a Format object, the other, 'f' is a string. Just raise an
exception for that (or assign to __class__ IINM if I'm not mistaken).
All assignments rebind, even the augmented form:
class C1(object):
def __mod__(self, value):
return C2()
class C2(object):
def __mod__(self, value):
return C2()
f = C1()
f
__main__.C1 object at 0x00D144F0
f % 0
__main__.C2 object at 0x00D143F0
f %= 0
f
__main__.C2 object at 0x00D145B0
Actually, the class you showed is kind of nifty. Tuples are correctly
interpolated. I think on the whole you'll use more parenthesis, since
each term in the tuple appears separately, and might be an expression
(have a lower-precedence op.), as well as more modulo signs.
You can currently do-it-yourself, you just need a constructor in the
format string.
f = Format(%r %i)
type(f)
type 'Format'
f = f % (2, 3, 4)
type(f)
type 'Format'
Or, as someone suggested earlier, a new literal marking:
Yes, I suggested that earlier, but it isn't needed because you can
create a format object with Format(string). However, most of the time
you won't bother to create a format object explicitly because of:
class str(object):
def __mod__(self, value):
return Format(self) % value
f = f%r %i
type(f)
type 'Format'
# Explicitly
f = Format(%r %i)
f
Format '%r %i'
f % (2, 3, 4)
Format '(2, 3, 4) %i'
# Implicitly, relying on the __mod__ method of str
f = %r %i
f
'%r %i'
f % (2, 3, 4)
Format '(2, 3, 4) %i'
I'd also like to add that there's nothing to prevent format objects from
having other methods where multiple placeholders can be filled in one call:
# By position
f = Format(%r %i)
f
Format '%r %i'
f.fill([(2, 3, 4), 1])
'(2, 3, 4) 1'
# By name
f = Format(%{tuple}r %{int}i)
f
Format '%{tuple}r %{int}i'
f.fill({tuple: (2, 3, 4), int: 1})
'(2, 3, 4) 1'
You're choosing to favor the '.chain()' method over the '.fill()'
method for the behavior of '%'. I don't think you've justified it
though.
Format( %r %i ).chain( ( 2, 3, 4 ) ).chain( 0 )
'(2, 3, 4) 0'
Format( %r %i ).fill( ( 2, 3, 4 ), 0 )
'(2, 3, 4) 0'
Plus, I almost think we've almost attained defeating the purpose.
The disadvantage of the chaining method is that it's positional,
left-to-right. For the purposes of i18n you want tagged placeholders,
whether they be integers or names. I think... OK, if the placeholders
include a positional tag, eg %(0)s %(1)s, then they could be filled in
according to _that_ order. Not sure about named placeholders, though.
Perhaps, like at present, if a dict is given to a format with named
placeholders then several placeholders could be filled, the problem
being how to fill a _single_ named placeholder with a dict.
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, Dec 20, 2008 at 12:30 AM, r rt8...@gmail.com wrote: Why could't we improve on what we had instead of making radical changes? Thats all i am asking. -- http://mail.python.org/mailman/listinfo/python-list Often times improving on what you have involves radical changes, especially if the goals of what you have change, or were not fully understood during their original implementation. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Steven D'Aprano wrote: I have no objection to the addition of the format() method (although I wonder whether it might have been better as a function). I actually learned about the String.format() method in Java a while after having read about str.format() in Python, and my first reaction was to recognise how stupid you'd have to be to make that a static method that ignores the string it's called on. :) I think '...'.format() makes sense given that we already have '...'.join(). Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Fri, 19 Dec 2008 17:12:00 -0800, r wrote: Marc, Why move away from a concise and widely accepted way of sting formatting, just to supposedly make it a little easier for n00bs? (which i disagree this is easier) In turn, creating more syntactical clutter. (%s %f %d) is all you need to remember. If people can't understand that, i fear for the future of Humans as a species! Yeah, doomsday is near. Curly brackets and a number instead of a percent sign followed by an 's' is a sure sign of the end… You're a funny little troll, Sir. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Stefan Behnel wrote: [...] I think '...'.format() makes sense given that we already have '...'.join(). Sure it does, but that doesn't stop a lot of people disliking str.join() regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
r wrote: On Dec 19, 10:04 pm, Steve Holden st...@holdenweb.com wrote: r wrote: Thanks Steven, We need a real Pepsi challenge here to show the insignificance of this change. I am not against change. But when we lose something as - compact- as %formating i'm going to want to see a damn good reason for it! Especially when this breaks code, and the French Connection is not good enough reason for me :) Christian said this was not going to be depreciated until 3.2, but that still puts the accepted way on the chopping block. If Python is so important to you it's a pity you haven't been playing any active role in its development. Do you expect the developers to be psychic? Steve, I just recently started to have an opinion about these things. The squeaky wheel get the grease, just allowing my voice be heard. It might seem that i am trashing Python dev, but that could not be further from the truth. Many great changes have been made in 3.0, i just feel strongly about C style formating. Why could't we improve on what we had instead of making radical changes? Thats all i am asking. I wasn't really a part of the decision-making process, but I anticipate that the developers' reply would be that the new scheme is much more adaptable, both to new data types (which can implement their own __format__ method) and to internationalization (because it's possible to alter word order in the format strings). Thanks for clarifying your approach, by the way, which isn't as unreasonable as it first seemed if you've only recently started using Python. You will find over time that the developers are right about these decisions much more than they are wrong, and you still have a couple of years to get used to it ;-) regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 19, 12:43 pm, excord80 excor...@gmail.com wrote:
Also, I like having only *one* special symbol (`%') to worry
about in my strings instead of two (`{' and `}').
Actually the new way has, at least three special symbols: ( '{', '}' ,
'.') as well as the method name format so
%s=%s % (k, v) for k, v in params.items()
becomes:
{0}={1}.format((k, v) for k, v in params.items())
or something like that.
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 19, 10:25 am, Michael Torrie torr...@gmail.com wrote: Personally the new string formatter is sorely needed in Python. Really? You know, it's funny, but when I read problems that people have with python, I don't remember seeing that. Loads of people complain about the white space issue. Some people complain about the speed. Lots of complaints about certain quirky behavior, but I have not come across any complaints about the string formatting. In fact, from what I have seen, many of the problems being fixed seem to be non-problems. I dunno, maybe it's just me. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Walter, Would you be kind enough to translate this code to the new syntax? s = 'python' n = 12 f = 1.3 '%s %05d %0.2f' %(s,n,f) 'python 00012 1.33' i want to see how casting is handled. Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 19, 10:55 am, bearophileh...@lycos.com wrote: Regarding the speed of Python3 programs, they will go faster The net result of the 3.0 generalizations is that Python 3.0 runs the pystone benchmark around 10% slower than Python 2.5. http://docs.python.org/dev/3.0/whatsnew/3.0.html (Ruby programs are often slower than Python ones (because Ruby is a little higher level than Python) As I understand it, that may have been true at one time. But, Ruby 1.9 very significantly sped up the language. While Python has been made slower, Ruby has been made much faster. I am no expert on the subject, I am just going by stuff I have read on web. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 20, 4:34 pm, r rt8...@gmail.com wrote: Walter, Would you be kind enough to translate this code to the new syntax? I am sorry, but I just don't know the new syntax well enough. I am not sure if the examples that I have posted, so far, are correct. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Thanks, i understand. Maybe some of the pro new syntax guys will show a translation -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
walterbyrd wrote:
On Dec 19, 12:43 pm, excord80 excor...@gmail.com wrote:
Also, I like having only *one* special symbol (`%') to worry
about in my strings instead of two (`{' and `}').
Actually the new way has, at least three special symbols: ( '{', '}' ,
'.') as well as the method name format so
%s=%s % (k, v) for k, v in params.items()
becomes:
{0}={1}.format((k, v) for k, v in params.items())
or something like that.
{0}={1}.format(k, v) for k, v in params.items()
or:
{0}={1}.format(*i) for i in params.items()
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Just to be on record, i am OK with adding a new way to do this as long as the old C style str format does not ever go away. I don't like 20 ways to do the same thing, but i really like the compact way of %formating now. My complaint is the deprecation of %formating. Maybe i'll use the new syntax to print a tuple or two, but that is the only use i have for it ;). Slowing down Python even more than it is, is suicide. Sure high level languages are slower than there complied brethren, but a line has to be drawn in the sand somewhere. As CPU speeds increase so does the complexity's of modern software. GUI toolkits hog more resources as they need eye pleasing glass effects. You can't just blindly Parrot off.. well CPU's get faster every year. Python must stay fast, and simplistic(but not too simplistic), to compete with other high level languages. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
In article b58f588a-e8db-41df-a488-f7df62d56...@w39g2000prb.googlegroups.com, walterbyrd walterb...@iname.com wrote: On Dec 19, 10:25 am, Michael Torrie torr...@gmail.com wrote: Personally the new string formatter is sorely needed in Python. Really? You know, it's funny, but when I read problems that people have with python, I don't remember seeing that. Loads of people complain about the white space issue. Some people complain about the speed. Lots of complaints about certain quirky behavior, but I have not come across any complaints about the string formatting. In fact, from what I have seen, many of the problems being fixed seem to be non-problems. I dunno, maybe it's just me. I had an interesting experience with this recently. I was giving a co-worker quick python into. He's an experienced programer in various languages, but this was his first exposure to python. He got really hung up on the % syntax. By (bad) luck, he was trying to print a tuple (let's call it t), did format % t and was surprised at the result. It set him off on a but that's stupid, blah, blah, blah rant. I haven't absorbed the new syntax well enough to figure out if people will get hung up by this with the new syntax. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 20, 5:27 pm, walterbyrd walterb...@iname.com wrote: On Dec 19, 10:25 am, Michael Torrie torr...@gmail.com wrote: Personally the new string formatter is sorely needed in Python. Really? You know, it's funny, but when I read problems that people have with python, I don't remember seeing that. Loads of people complain about the white space issue. Some people complain about the speed. Lots of complaints about certain quirky behavior, but I have not come across any complaints about the string formatting. In fact, from what I have seen, many of the problems being fixed seem to be non-problems. I dunno, maybe it's just me. You are exactly right Walter. I have not even considered this angle yet. Most of the complaints i hear are the redundant use of self. Which I lamented about but have become accustom(brainwashed) to it. I would remove this if it where up to me. I also hear a lot of complaints about speed. But never once in my life a problem with new users and string formatting. hmmm... food for thought -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
r wrote:
Walter,
Would you be kind enough to translate this code to the new syntax?
s = 'python'
n = 12
f = 1.3
'%s %05d %0.2f' %(s,n,f)
'python 00012 1.33'
i want to see how casting is handled. Thanks
'{0} {1:05} {2:.2}'.format(s, n, f)
'python 00012 1.3'
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 20, 6:05 pm, Roy Smith r...@panix.com wrote: In article b58f588a-e8db-41df-a488-f7df62d56...@w39g2000prb.googlegroups.com, walterbyrd walterb...@iname.com wrote: On Dec 19, 10:25 am, Michael Torrie torr...@gmail.com wrote: Personally the new string formatter is sorely needed in Python. Really? You know, it's funny, but when I read problems that people have with python, I don't remember seeing that. Loads of people complain about the white space issue. Some people complain about the speed. Lots of complaints about certain quirky behavior, but I have not come across any complaints about the string formatting. In fact, from what I have seen, many of the problems being fixed seem to be non-problems. I dunno, maybe it's just me. I had an interesting experience with this recently. I was giving a co-worker quick python into. He's an experienced programer in various languages, but this was his first exposure to python. He got really hung up on the % syntax. By (bad) luck, he was trying to print a tuple (let's call it t), did format % t and was surprised at the result. It set him off on a but that's stupid, blah, blah, blah rant. I haven't absorbed the new syntax well enough to figure out if people will get hung up by this with the new syntax. It is stupid, more reason to fix the current problem instead creating a whole new one. One more big complaint THE BACKSLASH PLAGUE. ever tried regexp?, or file paths?. All because that little backslash char is a line continuation character, maybe we should fix that. Would your life end if '\' was not a continuation char? Mine would not because i don't write my code to need it. Python has real warts that need fixing, and thats really hard for me to say, because i am such a fanboy of Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Thanks MRAB, except the float is not 2 decimal places, but its there Come on... They did this for the interpreter not us. It's easer to parse this string with positional arguments and a dict of format descriptions. Come on pydev, at least be honest about it! -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
walterbyrd: As I understand it, that may have been true at one time. But, Ruby 1.9 very significantly sped up the language. While Python has been made slower, Ruby has been made much faster. I have already answered regarding Python3 in this thread. Regarding Ruby you are right, in computer science there are lot of ways to speed up things. So it may be quite possible for Ruby to become faster than CPython. For example this may speed up the PythonVM some: Optimizing direct threaded code by selective inlining: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.23.8829rep=rep1type=pdf Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
In article 6b4176c3-49ce-4e7c-bced-07d8d19bc...@s20g2000yqh.googlegroups.com, r rt8...@gmail.com wrote: You can't just blindly Parrot off.. well CPU's get faster every year. Sure you can :-) There was a nice treatment of this on slashdot today (http://www.codinghorror.com/blog/archives/001198.html). The executive summary is I'm willing to accept that Python is (big handwave) 10x slower than C++, because *I'm* 10x faster writing in Python than I am in C++, and I cost more than my computer. Moore's laws says (small handwave) CPU speed doubles every 24 months. At that rate, and assuming I remember enough high-school algebra to solve a compound interest problem, hardware gets 10% faster every 3 months. If Python gets 10% slower every 10 years or so, it's ahead of the curve. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
r wrote:
Thanks MRAB,
except the float is not 2 decimal places, but its there
Oops!
'{0} {1:05} {2:.2f}'.format(s, n, f)
'python 00012 1.33'
'{0:s} {1:05d} {2:.2f}'.format(s, n, f)
'python 00012 1.33'
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, 20 Dec 2008 16:20:38 -0800, r wrote: On Dec 20, 6:05 pm, Roy Smith r...@panix.com wrote: I had an interesting experience with this recently. I was giving a co-worker quick python into. He's an experienced programer in various languages, but this was his first exposure to python. He got really hung up on the % syntax. By (bad) luck, he was trying to print a tuple (let's call it t), did format % t and was surprised at the result. It set him off on a but that's stupid, blah, blah, blah rant. I haven't absorbed the new syntax well enough to figure out if people will get hung up by this with the new syntax. It is stupid, more reason to fix the current problem instead creating a whole new one. Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Go on. Take your time. I'll be waiting. One more big complaint THE BACKSLASH PLAGUE. ever tried regexp?, or file paths?. All because that little backslash char is a line continuation character, maybe we should fix that. This makes no sense whatsoever. How does the line continuation character make any difference to backslashes inside a regex or a file path? Again, instead of whinging, what's your suggestion to fix it? Another suggestion, because your first: Would your life end if '\' was not a continuation char? is just stupid. The line continuation character is *irrelevant* to the problem of backslashes inside strings. For all the use it is, you might as well suggest changing the name None to Null. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, 20 Dec 2008 15:27:43 -0800, walterbyrd wrote: On Dec 19, 10:25 am, Michael Torrie torr...@gmail.com wrote: Personally the new string formatter is sorely needed in Python. Really? You know, it's funny, but when I read problems that people have with python, I don't remember seeing that. Loads of people complain about the white space issue. Some people complain about the speed. Lots of complaints about certain quirky behavior, but I have not come across any complaints about the string formatting. There are some things that some people whinge about, often just to hear the sound of their own voice (or the look of their own font, if you prefer). Whitespace and speed are two of those: they attract trolls and sooks. (That's not to say that there aren't real problems related to them. But it seems to me that the real problems are drowned out by the trolls.) Then there are things that people don't complain about, they just shrug and code a work-around. If % doesn't do what you want, do you cry about it, or do you code around it? I can't speak for others, but what I did was ask the question, discover that % was not powerful enough, and coded around it: http://mail.python.org/pipermail/python-list/2006-April/376641.html In fact, from what I have seen, many of the problems being fixed seem to be non-problems. I dunno, maybe it's just me. It's just you. Sheesh, I've never seen such a bunch of cry-babies sooking that their favourite language just got *more* power and flexibility. If functionality was being removed, I could understand the response, but this? It's just crazy. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 20, 7:38 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: On Sat, 20 Dec 2008 16:20:38 -0800, r wrote: On Dec 20, 6:05 pm, Roy Smith r...@panix.com wrote: I had an interesting experience with this recently. I was giving a co-worker quick python into. He's an experienced programer in various languages, but this was his first exposure to python. He got really hung up on the % syntax. By (bad) luck, he was trying to print a tuple (let's call it t), did format % t and was surprised at the result. It set him off on a but that's stupid, blah, blah, blah rant. I haven't absorbed the new syntax well enough to figure out if people will get hung up by this with the new syntax. It is stupid, more reason to fix the current problem instead creating a whole new one. Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Go on. Take your time. I'll be waiting. One more big complaint THE BACKSLASH PLAGUE. ever tried regexp?, or file paths?. All because that little backslash char is a line continuation character, maybe we should fix that. This makes no sense whatsoever. How does the line continuation character make any difference to backslashes inside a regex or a file path? Again, instead of whinging, what's your suggestion to fix it? Another suggestion, because your first: Would your life end if '\' was not a continuation char? is just stupid. The line continuation character is *irrelevant* to the problem of backslashes inside strings. For all the use it is, you might as well suggest changing the name None to Null. -- Steven i prefer None over Null myself, just another Pythonic beauty! ;) Steven, Would you like to elaborate on -why- escaped backslashes are needed in strings... i waiting??? -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 20, 7:38 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Go on. Take your time. I'll be waiting. Hi, not to take sides, but, there is a possibility. This behavior is currently legal: %i %%i % 0 % 1 '0 1' So, just extend it. (Unproduced.) %i %i % 0 % 1 '0 1' %r %i % (2, 3, 4) % 1 '(2, 3, 4) 1' %r %i % (2, 3, 4) '(2, 3, 4) %i' Which is quite clever and way ahead of its (posessive) time. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, 20 Dec 2008 16:01:58 -0800, r wrote: Just to be on record, i am OK with adding a new way to do this as long as the old C style str format does not ever go away. I don't like 20 ways to do the same thing, but i really like the compact way of %formating now. % formatting isn't compact unless you are only doing trivial substitutions. My complaint is the deprecation of %formating. % formatting hasn't been deprecated. All this Sturm und Drang over nothing. Maybe i'll use the new syntax to print a tuple or two, but that is the only use i have for it ;). Good for you. If your code is that trivial, then you're lucky. Slowing down Python even more than it is, is suicide. Oh noes, we're all gonna die!!! Just out of curiosity r, how old are you? 14? 15? You're remarkably mature for a 15 year old. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, 20 Dec 2008 17:54:09 -0800, r wrote: Would you like to elaborate on -why- escaped backslashes are needed in strings... i waiting??? If you can't escape backslashes in strings, how do you create a string containing a backslash? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
bearophileh...@lycos.com wrote: walterbyrd: As I understand it, that may have been true at one time. But, Ruby 1.9 very significantly sped up the language. While Python has been made slower, Ruby has been made much faster. I have already answered regarding Python3 in this thread. Regarding Ruby you are right, in computer science there are lot of ways to speed up things. So it may be quite possible for Ruby to become faster than CPython. For example this may speed up the PythonVM some: Optimizing direct threaded code by selective inlining: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.23.8829rep=rep1type=pdf Interesting. The re module uses a form of bytecode. Not sure about the relative cost of the dispatch code, though. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Answering a question with a question, that leaves me with a question of my own?? Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Instead of being a blind fanboy and chastising everyone who dares to question pydev, Guido, or YOU... why don't you offer a good rebuttal? If i did not give a rats behind about Python i would not be here arguing with you. I would give up and require my packages ;). I prefer to import I believe Python has the best chance of surviving and becoming the king of high level languages, IF we don't muck it up! -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, 20 Dec 2008 17:55:35 -0800, Aaron Brady wrote: On Dec 20, 7:38 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Go on. Take your time. I'll be waiting. Hi, not to take sides, but, there is a possibility. This behavior is currently legal: %i %%i % 0 % 1 '0 1' So, just extend it. (Unproduced.) %i %i % 0 % 1 '0 1' Errors should never pass silently, unless explicitly silenced. You have implicitly silenced the TypeError you get from not having enough arguments for the first format operation. That means that you will introduce ambiguity and bugs. %i %i %i %i % 5 % 3 %7 Here I have four slots and only three numbers. Which output did I expect? '%i 5 3 7' '5 %i 3 7' '5 3 %i 7' '5 3 7 %i' Or more likely, the three numbers is a mistake, there is supposed to be a fourth number there somewhere, only now instead of the error being caught immediately, it won't be discovered until much later. (BTW, if you want that behaviour, you should look at the string module.) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Aaron Brady wrote: On Dec 20, 7:38 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Go on. Take your time. I'll be waiting. Hi, not to take sides, but, there is a possibility. This behavior is currently legal: %i %%i % 0 % 1 '0 1' So, just extend it. (Unproduced.) %i %i % 0 % 1 '0 1' %r %i % (2, 3, 4) % 1 '(2, 3, 4) 1' %r %i % (2, 3, 4) '(2, 3, 4) %i' Which is quite clever and way ahead of its (posessive) time. A couple of problems: 1. How do you handle a literal '%'? If you just double up then you'll need to fix the string after all your substitutions. 2. What if a substitution introduces a '%'? I suppose a possible solution would be to introduce a special format string, including a literal, eg: f%r %i % (2, 3, 4) % 1 and then convert the result to a true string: print(str(f%r %i % (2, 3, 4) % 1)) (although print() would call __str__ anyway). The format string would track where the last substitution occurred. Hmm... I think I'll just learn the new method. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, 20 Dec 2008 18:23:00 -0800, r wrote: Answering a question with a question, that leaves me with a question of my own?? Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Instead of being a blind fanboy and chastising everyone who dares to question pydev, Guido, or YOU... why don't you offer a good rebuttal? Because I thought it was obvious even you could see it. I'm disappointed to be proven wrong. A binary operator can only take two arguments: one on the left, and one on the right: 2 + 3 5 * 7 x == 2 %i % 7 The typical use-case for string formatting operations requires more than two arguments. Since % is a binary operator, it can only take two arguments. One of those arguments must be the template string, so the other argument has to wrap all the rest of the arguments into one object: The %s ate %d slices of %s. % (python, 7, spam) Python could have insisted that even single arguments be wrapped in a tuple: %s % (python,) At the cost of breaking backwards compatibility, that would solve the problem of treating tuples as a special case, but it seems wasteful and silly to be forced to write this: The answer is: %d % (5,) instead of The answer is: %d % 5 especially when people will invariably leave out the comma and then complain about the wart or bug that: The answer is: %d % (5) doesn't do what they expect. So tuples are treated as a special case: you only need to wrap a single argument in a tuple if that argument itself is a tuple: %s % ((0, 1, 2),) and everything else just works as you would expect. Again, at the cost of breaking backwards compatibility, Python could change the special case from tuples to something else, but what? And why bother? There will always be a special case, one way or another. Consequently, there is no way to fix the special casing of tuples without just shifting the problem. The problem is fundamental to the nature of binary operators: you can't fit an arbitrary number of arguments into two places (the left hand side, and the right hand side) of the % operator without having to special case something. The real solution is to stop trying to force arbitrary numbers of arguments into a single place, and instead use a function or method that takes multiple arguments. That's what the .format() method and the format() function do. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 20, 5:05 pm, Roy Smith r...@panix.com He got really hung up on the % syntax. I guess it's good to know that there is, at least, one person in the world doesn't like the % formatting. As least the move was not entirely pointless. But, you must admit, of all the things people complain about with Python, the % formatting is probably one of the least common complaints. Complaints about Python's speed seem much more common. Yet, 3.0 makes the speed worse, and fixes a non-problem. I can see where the new formatting might be helpful in some cases. But, I am not sure it's worth the cost. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On 20 Dez., 02:54, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: Debated by who? The entire Python-using community? Every single Python programmer? Or just the small proportion of Python developers who are also core developers? If I'd asked people what they wanted, they would have asked for a better horse. Henry Ford -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 20, 11:11 pm, walterbyrd walterb...@iname.com wrote: On Dec 20, 5:05 pm, Roy Smith r...@panix.com He got really hung up on the % syntax. I guess it's good to know that there is, at least, one person in the world doesn't like the % formatting. As least the move was not entirely pointless. But, you must admit, of all the things people complain about with Python, the % formatting is probably one of the least common complaints. Complaints about Python's speed seem much more common. Yet, 3.0 makes the speed worse, and fixes a non-problem. I can see where the new formatting might be helpful in some cases. But, I am not sure it's worth the cost. This all really comes down to the new python users. Yea, i said it. Not rabid fanboys like Steven and myself.(i can't speak for walter but i think he would agree) Are we going to make sure joe-blow python newbie likes the language. And doesn't get turned off and run over to ruby or whoever. Like it or not, without newusers python is doomed to the same fate as all the other great languages who had their 15 mins of fame. We must proactively seek out the wants of these new users and make sure python stays alive. But we also must not sell are pythonic souls in the process. It would be nice to get a vote together and see what does the average pythoneer want? What do they like, What do they dislike. What is the state of the Python Union? Does anybody know, Does anybody care? I think python is slipping away from it's dominate foothold on the world. Google's use of python may be the only thing holding this house of cards together. Ruby's hype is defiantly growing and unless we strive for greatness, python may fail. I think ruby may have their act together a little better than us right now. And since Ruby is such a hodge-podge of different languages, the __init__ hold is there for many. what does joe-python want??? -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On 19 Dic, 17:01, walterbyrd walterb...@iname.com wrote:
I have not worked with Python enough to really know. But, it seems to
me that more I look at python 3.0, the more I wonder if it isn't a
step backwards.
To me, it seems that this:
print %s=%d % ('this',99)
Is much easier, and faster, to type, and is also easier to read and
understand. It also allows people to leverage their knowledge of C.
This (if it's right) is much longer, and requires more special
characters.
print( {0}={1}.format('this',99))
Maybe it's worth all the extra trouble, and breaking backward
compatibilty, and all. But, I never had the idea that the old way was
all that big a problem. Of course, I could be wrong. Was the old way
all that big of a problem?
You can use the old 2.x syntax also in Python 3.x:
C:\C:\python30\python.exe
Python 3.0 (r30:67507, Dec 3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win
32
Type help, copyright, credits or license for more information.
print(%s=%d % ('this',99))
this=99
--- Giampaolo
http://code.google.com/p/pyftpdlib/
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
if 3.0 looks like... print( {0}={1}.format('this',99)) , WTF...
thats retarded and looks like Ruby code. Thats not intuitive thats
madness! What happens when you need a conversion to string from an
integer, more code?? My faith is slipping. Have the python Gods gone
mad??. Please tell me i am wrong.
Pythons likeness to C is one of its great powers. I always thought of
Python as an intuitive way to write C code.
I am sticking with 2x(which i had planned to do anyway) I have heard
of nothing significant enough to compel me to make the change yet. And
with that example from 3.0, i am really setting my ways now. i may
have to support the continuation of 2.x beyond 2.9.
Guido! please don't play Russian roulette with Python! I have loved
python all the way up through the 2.x line. And i carry a great
respect for you and your accomplishments. Python must feel at home to
a C programmer. That, i feel, is the professional following for
Python. I also feel Python is a gateway to the C language for n00b
programmers. Let Ruby have the Perl programmers, we don't need them!
Excuse me, I think i am going to cry now :(
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 19, 9:13 am, Giampaolo Rodola' gne...@gmail.com wrote: You can use the old 2.x syntax also in Python 3.x: Yeah, but it's deprecated, and - as I understand it - may be removed completely in future versions. Also, in the future, if you are working with code from another developer, it's likely that developer will use the new format. I suppose you can use both - but what an awful mess that would be. It seems to me that 3.0 is changing a lot of non-problems. And it's going to be slower to boot. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
r wrote:
if 3.0 looks like... print( {0}={1}.format('this',99)) , WTF...
thats retarded and looks like Ruby code. Thats not intuitive thats
madness! What happens when you need a conversion to string from an
integer, more code?? My faith is slipping. Have the python Gods gone
mad??. Please tell me i am wrong.
You are wrong.
Pythons likeness to C is one of its great powers. I always thought of
Python as an intuitive way to write C code.
I have to confess, I have no idea what you are talking about. I have
never ever seen Python as an intuitive way to write C code. That's kind
of bizarre.
I am sticking with 2x(which i had planned to do anyway) I have heard
of nothing significant enough to compel me to make the change yet. And
with that example from 3.0, i am really setting my ways now. i may
have to support the continuation of 2.x beyond 2.9.
Guido! please don't play Russian roulette with Python! I have loved
python all the way up through the 2.x line. And i carry a great
respect for you and your accomplishments. Python must feel at home to
a C programmer. That, i feel, is the professional following for
Python. I also feel Python is a gateway to the C language for n00b
programmers. Let Ruby have the Perl programmers, we don't need them!
Excuse me, I think i am going to cry now :(
Okay, you're welcome to.
So funny that now that Python 3.0 is actually released we have people
acting all surprised like they've never seen any of the new features in
Python 3.0 coming. However these features have been discussed for
years! And debated!
Personally the new string formatter is sorely needed in Python. And
they way it has been implemented is a thing of beauty. Basically the
burden of formatting strings has been moved from the print
statement/function to the objects themselves. Furthermore, the new {}
notation allows many, many more options for formatting to be used. Want
to display a floating point number with $#.## notation, and ($#.##) for
negative? It's all now possible. Couldn't be done before. Want to
have the ability to format your own custom object in a particular way
when printing with print()? Just define a __format__ method in your
object. print() will ask it to format itself.
In short, this is a huge improvement, and backwards compatibility is
preserved for the 2.x style for those that wish it.
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
walterbyrd wrote: On Dec 19, 9:13 am, Giampaolo Rodola' gne...@gmail.com wrote: You can use the old 2.x syntax also in Python 3.x: Yeah, but it's deprecated, and - as I understand it - may be removed completely in future versions. Also, in the future, if you are working with code from another developer, it's likely that developer will use the new format. I suppose you can use both - but what an awful mess that would be. It seems to me that 3.0 is changing a lot of non-problems. And it's going to be slower to boot. How is this? With projects like PyPy eventually enabling the JIT'ing of python3 code, I don't see how this is going to be slower. If anything we have a python that can be made to run faster than ever before. Please qualify your remarks. Are you a Python core developer? -- http://mail.python.org/mailman/listinfo/python-list
