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: "{0.display_name}" 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 "{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 29, 9:44 pm, Steven D'Aprano 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?
On Mon, 29 Dec 2008 09:50:14 -0800, walterbyrd wrote: > On Dec 21, 12:28 pm, Bruno Desthuilliers > 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, 7:37 pm, Luis M. González 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 19 dic, 13:01, walterbyrd 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 21, 12:28 pm, Bruno Desthuilliers 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 Dec 22, 7:26 pm, Steven D'Aprano wrote: > On Mon, 22 Dec 2008 06:58:06 -0800, walterbyrd wrote: > > On Dec 21, 12:28 pm, Bruno Desthuilliers > > 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?
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 Mon, 22 Dec 2008 06:58:06 -0800, walterbyrd wrote: > On Dec 21, 12:28 pm, Bruno Desthuilliers > 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 Dec 22, 5:53 pm, Aaron Brady wrote: > On Dec 22, 11:40 am, r wrote: > > > > > On Dec 22, 8:58 am, walterbyrd wrote: > > > > On Dec 21, 12:28 pm, Bruno Desthuilliers > > > > 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 Dec 22, 11:40 am, r wrote: > On Dec 22, 8:58 am, walterbyrd wrote: > > > > > On Dec 21, 12:28 pm, Bruno Desthuilliers > > > 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?
Steven D'Aprano 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 "", line 1, in 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, 12:36 pm, Bruno Desthuilliers 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?
walterbyrd a écrit : On Dec 21, 12:28 pm, Bruno Desthuilliers 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, 8:58 am, walterbyrd wrote: > On Dec 21, 12:28 pm, Bruno Desthuilliers > > 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?
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?
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?
walterbyrd wrote: > On Dec 21, 12:28 pm, Bruno Desthuilliers > 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: > 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?
On Dec 21, 12:28 pm, Bruno Desthuilliers 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?
On Dec 21, 8:42 pm, MRAB wrote: > Aaron Brady wrote: > > On Dec 21, 6:14 pm, MRAB 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) > >>> > >> >>> # Explicitly > >> >>> f = Format("%r %i") > >> >>> f > >> > >> >>> f % (2, 3, 4) > >> > > >> >>> # Implicitly, relying on the __mod__ method of str > >> >>> f = "%r %i" > >> >>> f > >> '%r %i' > >> >>> f % (2, 3, 4) > >> > > >> 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 > >> > >> >>> f.fill([(2, 3, 4), 1]) > >> '(2, 3, 4) 1' > > >> >>> # By name > >> >>> f = Format("%{tuple}r %{int}i") > >> >>> f > >> > >> >>> 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?
Aaron Brady wrote: On Dec 21, 6:14 pm, MRAB wrote: Aaron Brady wrote: On Dec 21, 10:58 am, MRAB wrote: Aaron Brady wrote: On Dec 21, 10:31 am, MRAB 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) >>> f = f % (2, 3, 4) >>> type(f) >>> f = f % 1 >>> type(f) Alright, so how are you handling: f= "%s %i" type( f ) f= f% '%i' #now '%i %i' type( f ) 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 >>> f = f % 1 >>> f '(2, 3, 4) 1' >>> f = "%s %i" >>> f '%s %i' >>> f = f % '%i' >>> f >>> 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) f = f % (2, 3, 4) type(f) 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) >>> # Explicitly >>> f = Format("%r %i") >>> f >>> f % (2, 3, 4) >>> >>> # Implicitly, relying on the __mod__ method of str >>> f = "%r %i" >>> f '%r %i' >>> f % (2, 3, 4) 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 >>> f.fill([(2, 3, 4), 1]) '(2, 3, 4) 1' >>> >>> # By name >>> f = Format("%{tuple}r %{int}i") >>> f >>> 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 Dec 21, 6:14 pm, MRAB wrote: > Aaron Brady wrote: > > On Dec 21, 10:58 am, MRAB wrote: > >> Aaron Brady wrote: > >>> On Dec 21, 10:31 am, MRAB 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) > > >>> f = f % (2, 3, 4) > >>> type(f) > > >>> f = f % 1 > >>> type(f) > > >>> Alright, so how are you handling: > >> f= "%s %i" > >> type( f ) > >>> > >> f= f% '%i' #now '%i %i' > >> type( f ) > >>> > >> 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 > >> > >> >>> f = f % 1 > >> >>> f > >> '(2, 3, 4) 1' > > >> >>> f = "%s %i" > >> >>> f > >> '%s %i' > >> >>> f = f % '%i' > >> >>> f > >> > >> >>> 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) > > > f = f % (2, 3, 4) > type(f) > > > > > 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) > > > > >>> # Explicitly > >>> f = Format("%r %i") > >>> f > > >>> f % (2, 3, 4) > > >>> > >>> # Implicitly, relying on the __mod__ method of str > >>> f = "%r %i" > >>> f > '%r %i' > >>> f % (2, 3, 4) > > > 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 > > >>> f.fill([(2, 3, 4), 1]) > '(2, 3, 4) 1' > >>> > >>> # By name > >>> f = Format("%{tuple}r %{int}i") > >>> f > > >>> 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?
On Mon, Dec 22, 2008 at 11:37 AM, alex23 wrote: > On Dec 21, 10:11 am, r 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, 10:11 am, r 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?
Aaron Brady wrote: On Dec 21, 10:58 am, MRAB wrote: Aaron Brady wrote: On Dec 21, 10:31 am, MRAB 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) >>> f = f % (2, 3, 4) >>> type(f) >>> f = f % 1 >>> type(f) Alright, so how are you handling: f= "%s %i" type( f ) f= f% '%i' #now '%i %i' type( f ) 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 >>> f = f % 1 >>> f '(2, 3, 4) 1' >>> >>> f = "%s %i" >>> f '%s %i' >>> f = f % '%i' >>> f >>> 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) f = f % (2, 3, 4) type(f) 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) >>> # Explicitly >>> f = Format("%r %i") >>> f >>> f % (2, 3, 4) >>> >>> # Implicitly, relying on the __mod__ method of str >>> f = "%r %i" >>> f '%r %i' >>> f % (2, 3, 4) 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 >>> f.fill([(2, 3, 4), 1]) '(2, 3, 4) 1' >>> >>> # By name >>> f = Format("%{tuple}r %{int}i") >>> f >>> 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:58 am, MRAB wrote: > Aaron Brady wrote: > > On Dec 21, 10:31 am, MRAB 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) > >> > >> >>> f = f % (2, 3, 4) > >> >>> type(f) > >> > >> >>> f = f % 1 > >> >>> type(f) > >> > > > Alright, so how are you handling: > > f= "%s %i" > type( f ) > > > f= f% '%i' #now '%i %i' > type( f ) > > > 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 > > >>> f = f % 1 > >>> f > '(2, 3, 4) 1' > >>> > >>> f = "%s %i" > >>> f > '%s %i' > >>> f = f % '%i' > >>> f > > >>> 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) >>> f = f % (2, 3, 4) >>> type(f) Or, as someone suggested earlier, a new literal marking: >>> f = f"%r %i" >>> type(f) -- 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 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?
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?
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?
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?
walterbyrd a écrit : On Dec 20, 5:05 pm, Roy Smith 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. 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... 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 : (snip clueless rant) One more big complaint "THE BACKSLASH PLAGUE". ever tried regexp? Yes. exp = re.compile(r"no \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?
On Sun, Dec 21, 2008 at 11:26 AM, 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!) 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 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 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?
Quoting r : > 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?
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?
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?
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?
Aaron Brady wrote: On Dec 21, 10:31 am, MRAB wrote: Aaron Brady wrote: On Dec 20, 8:49 pm, MRAB wrote: Aaron Brady wrote: On Dec 20, 7:38 pm, Steven D'Aprano 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 "", line 1, in 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) >>> f = f % (2, 3, 4) >>> type(f) >>> f = f % 1 >>> type(f) Alright, so how are you handling: f= "%s %i" type( f ) f= f% '%i' #now '%i %i' type( f ) 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 >>> f = f % 1 >>> f '(2, 3, 4) 1' >>> >>> f = "%s %i" >>> f '%s %i' >>> f = f % '%i' >>> f >>> f = f % 1 >>> f '%%i 1' -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 21, 10:31 am, MRAB wrote: > Aaron Brady wrote: > > On Dec 20, 8:49 pm, MRAB wrote: > >> Aaron Brady wrote: > >>> On Dec 20, 7:38 pm, Steven D'Aprano >>> 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 "", line 1, in > > 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) > > >>> f = f % (2, 3, 4) > >>> type(f) > > >>> f = f % 1 > >>> type(f) > Alright, so how are you handling: >>> f= "%s %i" >>> type( f ) >>> f= f% '%i' #now '%i %i' >>> type( f ) >>> 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 20, 8:49 pm, MRAB wrote: Aaron Brady wrote: On Dec 20, 7:38 pm, Steven D'Aprano 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 "", line 1, in 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) >>> f = f % (2, 3, 4) >>> type(f) >>> f = f % 1 >>> type(f) -- 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 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?
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 Dec 21, 8:50 am, Steve Holden 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?
On Dec 21, 7:34 am, Marc 'BlackJack' Rintsch 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?
Steven D'Aprano 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 "", line 1, in > 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?
Marc 'BlackJack' Rintsch 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?
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?
r wrote: > On Dec 20, 11:11 pm, walterbyrd wrote: >> On Dec 20, 5:05 pm, Roy Smith >> >>> 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?
On Sun, 21 Dec 2008 12:45:32 +, Duncan Booth wrote: > Steven D'Aprano 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 "", line 1, in 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?
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?
Steven D'Aprano 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 Dec 20, 8:49 pm, MRAB wrote: > Aaron Brady wrote: > > On Dec 20, 7:38 pm, Steven D'Aprano > 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 "", line 1, in 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?
On Dec 20, 8:26 pm, Steven D'Aprano 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 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 Sat, 20 Dec 2008 15:27:43 -0800, walterbyrd wrote: > On Dec 19, 10:25 am, Michael Torrie 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 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, Dec 20, 2008 at 10:15 PM, r wrote: > On Dec 20, 11:11 pm, walterbyrd wrote: >> On Dec 20, 5:05 pm, Roy Smith >> >> > 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 Dec 20, 11:11 pm, walterbyrd wrote: > On Dec 20, 5:05 pm, Roy Smith > > > 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 20 Dez., 02:54, Steven D'Aprano 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, 5:05 pm, Roy Smith > 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 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?
Aaron Brady wrote: On Dec 20, 7:38 pm, Steven D'Aprano 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 17:55:35 -0800, Aaron Brady wrote: > On Dec 20, 7:38 pm, Steven D'Aprano 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?
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?
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.8829&rep=rep1&type=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?
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?
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 Dec 20, 7:38 pm, Steven D'Aprano 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 Dec 20, 7:38 pm, Steven D'Aprano wrote: > On Sat, 20 Dec 2008 16:20:38 -0800, r wrote: > > On Dec 20, 6:05 pm, Roy Smith 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 Sat, 20 Dec 2008 15:27:43 -0800, walterbyrd wrote: > On Dec 19, 10:25 am, Michael Torrie 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 Sat, 20 Dec 2008 16:20:38 -0800, r wrote: > On Dec 20, 6:05 pm, Roy Smith 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?
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?
In article <6b4176c3-49ce-4e7c-bced-07d8d19bc...@s20g2000yqh.googlegroups.com>, r 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?
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.8829&rep=rep1&type=pdf Bye, bearophile -- 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?
On Dec 20, 6:05 pm, Roy Smith wrote: > In article > , > > walterbyrd wrote: > > On Dec 19, 10:25 am, Michael Torrie 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?
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, 5:27 pm, walterbyrd wrote: > On Dec 19, 10:25 am, Michael Torrie 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?
In article , walterbyrd wrote: > On Dec 19, 10:25 am, Michael Torrie 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?
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?
walterbyrd wrote: On Dec 19, 12:43 pm, excord80 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?
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?
On Dec 20, 4:34 pm, r 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?
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?
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:25 am, Michael Torrie 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?
On Dec 19, 12:43 pm, excord80 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?
r wrote: > On Dec 19, 10:04 pm, Steve Holden 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?
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?
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?
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 Sat, Dec 20, 2008 at 12:30 AM, r 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?
On Dec 19, 10:04 pm, Steve Holden 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Quoth Steven D'Aprano : > Whether using % or format(), I don't see the need to change the code, > only the strings. > > Using positional arguments is not really that different: > > "{0} {1}".format("dead", "parrot") > "{0} {1}".format("perroquet", "mort") This should be something like: _("{0} {1}").format(_("dead"), _("parrot")) where il8n would substitute the template "{1} {0}" when doing French. > versus: > > "%s %s" % ("dead", "parrot") > "%s %s" % ("perroquet", "mort") > > In this case, the template on the left remains the same, you just have to > reorder the string arguments on the right. Clearly less satisfactory than > the solution using keyword substitution, but whatever solution you pick, > I don't see any advantage to format() over % formatting. Can you show an > example? Not less satisfactory, but rather unworkable. You can't do proper il8n with %s formatting, since there is no way for the il8n machinery to reorder the argument tuple. It can only translate the template string. So when doing il8n, the {} syntax wins out for brevity over the equivalent % syntax (%s(somename)s). Not that brevity is that important an argument. The new system is just so much more flexible than the old. As someone else said, the design is beautiful :) I have a couple thousand lines of python code I wrote a while back to layer on a system with this kind of flexibility...I was shocked and pleased when I saw the PEP, since it echoed so many of the ideas I had implemented in that code, plus more. And all done better of course :) --RDM -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
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? 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?
Steven D'Aprano wrote: > On Fri, 19 Dec 2008 10:25:30 -0700, Michael Torrie wrote: > >> 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! > > 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? > > Are you *really* surprised that some people had never heard of the > changes being debated until it was too late? > It isn't the least surprising that some people have been taken by surprise by the changes. Neither is it surprising that some of them don't like the changes that much. However, at least in the open source world one has the *opportunity* to make one's voice heard and one's opinion known, even thought he majority prefer to remain consumers of the output of open source projects. Where commercial projects are concerned the major influence one has is a post-facto vote with one's wallet. I hope, however, that those who don't like the changes but didn't bother to track developments don't feel in any way disenfranchised. They are still welcome to make their input, and of course there is nothing to stop them keeping Python 2.X alive for as long as they wish. [misconception about print's role] >> 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. > > Of course it could be. You just needed to write your own formatting > engine. What you mean is that it couldn't be done with % formatting and > nothing else. > > >> In short, this is a huge improvement, and backwards compatibility is >> preserved for the 2.x style for those that wish it. > > > There clearly is a need for a more heavyweight formatting solution than % > and string.Template. There are things that can't be done easily with % > alone, and format() will make them much simpler. I have no objection to > the addition of the format() method (although I wonder whether it might > have been better as a function). > That's doubtless a debate that will play for a long time, with no really clear advantage either way. Programmers just like to debate these things. Of course it's a trivial addition: def format(s, *args, **kw): return s.format(*args, **kw) [I put **kw in becuase it's easier than checking the docs to se whether keyword arguments are specified]. This doesn't mean there won't be fifteen more posts on this thread about 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 Sat, 20 Dec 2008 01:54:35 +, Steven D'Aprano wrote: > There clearly is a need for a more heavyweight formatting solution than > % and string.Template. There are things that can't be done easily with % > alone, and format() will make them much simpler. I have no objection to > the addition of the format() method (although I wonder whether it might > have been better as a function). Except of course there is a format() function. Like len(), str() etc, it just calls the appropriate special method on the argument: format(obj, format_spec) -> obj.__format__(format_spec) -- Steven -- http://mail.python.org/mailman/listinfo/python-list