Mailman 3 September 2011 - Python-ideas

Re: [Python-ideas] List Revolution
by Matt Billenstein Sept. 10, 2011

Sept. 10, 2011

On Sat, Sep 10, 2011 at 02:14:13PM -0500, Massimo Di Pierro wrote: > Not to open a can of worms but why not use eval in this example? > It is faster. It is 5x more compact. It allows me to take advantage of the > Python parser instead of reinventing the wheel. It is less error prone and > easier to understand. It is a python keyword. I wouldn't worry too much about the implementation details of a clearly insane idea... And eval generally has high "code-smell" -- it can lead to … [View More]

1 0

Re: [Python-ideas] List Revolution
by Massimo Di Pierro Sept. 10, 2011

Sept. 10, 2011

On Sep 10, 2011, at 2:07 PM, Massimo Di Pierro wrote: > Not to open a can of worms but why not use eval in this example? > It is faster. It is 5x more compact. It allows me to take advantage of the Python parser instead of reinventing the wheel. It is less error prone and easier to understand. It is a python keyword. > > # with eval > if not re.compile('^[\*\+\d]+$').match(name): raise AttributeError > try: number = eval(name) > except: raise AttributeError > … [View More] > # without eval > tokenizer = re.compile('\+|$\+|\(|$|\*|[\d]+') > stack = [0] > while name: > token = tokenizer.match(name) > if not token: raise AttributeError > elif token.group() in ('(','(+'): stack.append(0) > elif token.group().isdigit(): stack.append(int(token.group())) > elif token.group() in ')+' and len(stack)>1: stack[-2:]=[stack[-1]+stack[-2]] > elif token.group()=='*': > name = name[1:] > token = tokenizer.match(name) > if not token or not token.group().isdigit(): raise AttrbuteError > stack[-1:]=[stack[-1]*int(token.group())] > name = name[token.end():] > number = sum(stack) > > > > Massimo > > > On Sep 10, 2011, at 1:50 PM, Massimo Di Pierro wrote: > >> Of course. It was a proof of concept. Here is with an inline parser: >> >> class List(list): >> """ >>>>> a=List() >>>>> for i in range(100000): a.append(i) >>>>> print a.first >> 0 >>>>> print a.second >> 1 >>>>> print a.third >> 2 >>>>> print a.twentieth >> 19 >>>>> print a.twentysecond >> 21 >>>>> print a.onehundredthirtyfifth >> 134 >>>>> print a.onethousandfivehundredthirtyeighth >> 1537 >> """ >> def __getattr__(self,name): >> if name.endswith('first'): name = name[:-5]+'one' >> elif name.endswith('second'): name = name[:-6]+'two' >> elif name.endswith('third'): name = name[:-5]+'three' >> elif name.endswith('fth'): name = name[:-3]+'ve' >> elif name.endswith('hth'): name = name[:-3]+'th' >> elif name.endswith('ieth'): name = name[:-4]+'y' >> elif name.endswith('th'): name = name[:-2] >> subs = [ >> ("eleven","+11"), >> ("twelve","+12"), >> ("thirteen","+13"), >> ("fourteen","+14"), >> ("fiftheen","+15"), >> ("sixteen","+16"), >> ("seventeen","+17"), >> ("eighteen","+18"), >> ("nineteen","+19"), >> ("ten","+10"), >> ("twenty","+20"), >> ("thirty","+30"), >> ("fourty","+40"), >> ("fifty","+50"), >> ("sixty","+60"), >> ("seventy","+70"), >> ("eighty","+80"), >> ("ninety","+90"), >> ("one","+1"), >> ("two","+2"), >> ("three","+3"), >> ("four","+4"), >> ("five","+5"), >> ("six","+6"), >> ("seven","+7"), >> ("eigth","+8"), >> ("nine","+9"), >> ("ten","+10"), >> ("hundred",")*100+("), >> ("thousand",")*1000+("), >> ("million",")*1000000+("), >> ("billion",")*1000000000+("), >> ("trillion",")*100000000000+("), >> ("and","")] >> for key,value in subs: name = name.replace(key,value) >> if '(' in name: name='('+name+')' >> name.replace('()','1') >> ## parser >> import re >> tokenizer = re.compile('\+|$\+|\(|$|\*|[\d]+') >> stack = [0] >> while name: >> token = tokenizer.match(name) >> if not token: raise AttributeError >> if token.group() in ('(','(+'): stack.append(0) >> if token.group().isdigit(): stack.append(int(token.group())) >> if token.group() in ')+' and len(stack)>1: stack[-2:]=[stack[-1]+stack[-2]] >> if token.group()=='*': >> name = name[1:] >> token = tokenizer.match(name) >> if not token or not token.group().isdigit(): raise AttrbuteError >> stack[-1:]=[stack[-1]*int(token.group())] >> name = name[token.end():] >> number = sum(stack) >> ## end parser >> try: return self[number-1] >> except: raise IndexError >> >> >> >> >> On Sep 10, 2011, at 1:00 PM, Guido van Rossum wrote: >> >>> I thought we were all just having a little bit of fun with what's >>> obviously the least-likely-to-be-accepted proposal to have hit >>> python-ideas in a long time; and now I see serious questions about it >>> on Twitter and Quora... Time to start adding smileys to all posts! :-) >>> >>> (Though seriously, Massimo, you should be able to implement the same >>> idea without using eval() at all.) >>> >>> --Guido >>> >>> On Sat, Sep 10, 2011 at 10:50 AM, Massimo Di Pierro >>> <massimo.dipierro(a)gmail.com> wrote: >>>> Anyway ... mine was not a serious proposal. I like python lists as they are. >>>> >>>> On Sep 10, 2011, at 12:43 PM, Devin Jeanpierre wrote: >>>> >>>>>> Damn dollar signs. >>>>>> if not re.compile('^[\d\+\*]+$').match(name): return AttributeError >>>>> >>>>> '(2**1024)**(2**1024)' etc. >>>>> >>>>> Devin >>>>> >>>>> On Sat, Sep 10, 2011 at 1:05 PM, Massimo Di Pierro >>>>> <massimo.dipierro(a)gmail.com> wrote: >>>>>> LOL. >>>>>> >>>>>> Damn dollar signs. >>>>>> if not re.compile('^[\d\+\*]+$').match(name): return AttributeError >>>>>> >>>>>> On Sep 10, 2011, at 11:45 AM, Stefan Behnel wrote: >>>>>> >>>>>>> Massimo Di Pierro, 10.09.2011 18:35: >>>>>>>> [...] >>>>>>>> if not re.compile('[\d\+\*]+').match(name): return AttributeError >>>>>>>> [...] >>>>>>>> I would like to stress that the use of eval in this case is safe as the expression is first validated against a regex. >>>>>>> >>>>>>> Nice try. And it would even be ok if you had assured that the *entire* expression was validated against the regex. >>>>>>> >>>>>>> Stefan >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Python-ideas mailing list >>>>>>> Python-ideas(a)python.org >>>>>>> http://mail.python.org/mailman/listinfo/python-ideas >>>>>> >>>>>> _______________________________________________ >>>>>> Python-ideas mailing list >>>>>> Python-ideas(a)python.org >>>>>> http://mail.python.org/mailman/listinfo/python-ideas >>>>>> >>>> >>>> _______________________________________________ >>>> Python-ideas mailing list >>>> Python-ideas(a)python.org >>>> http://mail.python.org/mailman/listinfo/python-ideas >>>> >>> >>> >>> >>> -- >>> --Guido van Rossum (python.org/~guido) >> > [View Less]

1 0

Deprecating bytes.swapcase and friends [was: Maintenance burden of str.swapcase]
by Stephen J. Turnbull Sept. 7, 2011

Sept. 7, 2011

This is all speculation and no hint of implementation at this point ... redirecting this subthread to Python-Ideas. Reply-To set accordingly. Nick Coghlan writes: > Heh, I knew as soon as I sent that message that someone would be able > to point out a counter example. I agree that RFC 822 (and > case-insensitive ASCII comparison in general) is enough to save > lower() and upper() and co, but what about this even further reduced > list of text-specific methods: > … [View More]> 'capitalize' > 'istitle' > 'swapcase' > 'title' > > While case-insensitive comparison makes sense for wire level data, > where do these methods fit in, even when embedded ASCII text fragments > are involved? Well, 'capitalize' could theoretically be used to "beautify" RFC 822 field names, but realistically, to me they're a litmus test for packages I probably don't want on my system.<0.5 wink> I don't know if it's worth the effort to deprecate them, though. There is a school of thought (represented on python-dev by Philip Eby and Antoine Pitrou, among others, I would say) that says that text with an implicit encoding is still text if you can figure out what the encoding is, and the syntactically important tokens are invariably ASCII, which often is enough information to do the work. So if you can do some operation without first converting to str, let's save the cycles and the bytes (especially in bit-shoveling applications like WSGI)! I disagree, but "consenting adults" and all that. It occurs to me that the bit-shoveling applications would generally be sufficiently well-served with a special "codec" that just stuffs the data pointer in a bytes object into the latin1 member of the data pointer union in a PEP 393 Unicode object, and marks the Unicode object as "ascii-compatible", ie, anything ASCII can be manipulated as text, but anything non-ASCII is like a private character that Python doesn't know anything about, and can't do anything useful with, except delete or pass through verbatim (perhaps as a slice). This may be nonsense; I don't know enough about Python internals to be sure. And it would be a change to PEP 393, since the encoding of the 8-bit representation would no longer be Unicode. I wouldn't blame Martin one bit if he hated the idea in principle! On the other hand, the "Latin-1 can be used to decode any binary content" end-around makes that point moot IMO. This would give a somewhat safer way of doing that. But if feasible and a Pythonic implementation could be devised, that would take much of the wind out of the sails of the "implicitly it's ASCII text" crowd. The whole "it's inefficient in time and space to work with 'str'" argument goes away, leaving them with "it's verbose" as the only reason for not doing the conversion. I don't know if there would be any use case left for bytes at that point ... but that's clearly a py4k discussion. [View Less]

3 2

xmlrpc.client to deprecate Binary for bytes?
by Masklinn Sept. 6, 2011

Sept. 6, 2011

Not sure if this is an actual idea/feature request or a bug. Might be half/half In Python 2, many actual strings were "packaged" through the str type, so xmlrpclib had to provide an other wrapper (xmlrpclib.Binary) to differentiate between actual strings (to insert as-is) and binary blobs, to b64encode. Among Python 3 fixes are the stricter separation between bytestrings (bytes) and text strings (str), but xmlrpc.client *still* requires the usage of a Binary wrapper, and trying to encode a … [View More]

1 0

Improving this? - foo() takes at least 6 arguments (6 given)
by Mark Dickinson Sept. 5, 2011

Sept. 5, 2011

On Sat, Sep 3, 2011 at 9:59 AM, Eli Stevens (Gmail) <wickedgrey(a)gmail.com> wrote: > On Thu, Sep 1, 2011 at 10:19 AM, Ethan Furman <ethan(a)stoneleaf.us> wrote: >>> Colleague: "So my code is apparently asking for 6 arguments and it >>> appears that I gave it 6 arguments" >>> Me: "Oh that - Yeah... your short one. It really wants 7.." >> >> How did you get this? > > Having seen this bite someone recently, I have an … [View More]

3 2

Re: [Python-ideas] allow line break at operators
by Matt Joiner Sept. 4, 2011

Sept. 4, 2011

I guess the issue here is that you can't tell if an expression is complete without checking the indent of the following line. This is likely not desirable. On Thu, Sep 1, 2011 at 11:43 PM, Yingjie Lan <lanyjie(a)yahoo.com> wrote: > Hi Matt, > ======================================================= > From: Matt Joiner <anacrolix(a)gmail.com> > > The "trailing \" workaround is nonobvious. Wrapping in () is noisy and > already heavily used by other syntactical … [View More]

5 5

Improving this? - foo() takes at least 6 arguments (6 given)
by Steven Klass Sept. 3, 2011

Sept. 3, 2011

Hi all, Most of us who have been coding for awhile have often seen this error and understand the "self" concept. I was helping a junior colleague out and he came to me with this problem. Colleague: "So my code is apparently asking for 6 arguments and it appears that I gave it 6 arguments" Me: "Oh that - Yeah... your short one. It really wants 7.." That got me thinking and here is the post. Now while this seems simple to fix I know this isn't that simple and a healthy dose of … [View More]

4 3

Re: [Python-ideas] allow line break at operators
by Stephen J. Turnbull Sept. 3, 2011

Sept. 3, 2011

Yingjie Lan writes: > Python uses indentation for blocks, and by the same mechanism, line > breaking can be accommodated without requiring parenthesis or > ending backslashes. Possibly, but now you have a problem that a dedent has ambiguous meaning. It might mean that you're ending a suite, or it might mean you're ending a continued expression. This probably can be disambiguated, but I don't know how easy that will be to do perfectly, including in reporting ill-formed … [View More]

1 0

Re: [Python-ideas] allow line break at operators
by Stephen J. Turnbull Sept. 3, 2011

Sept. 3, 2011

Yingjie Lan writes: > Have you considered line continuation by indentation? It seems to > meet the design principle. I think it is the most natural way to > allow free line breaking in Python. Briefly, yes, and I think it would need a lot of tuning and probably complex rules. Unlike statements, where everybody (except the judges of the Obfuscated C Contest) agrees on a simple rule: "In a control structure, the controlled suite should be uniformly indented one level", line … [View More]

1 0

Re: [Python-ideas] aliasing
by Peio Borthelle Sept. 2, 2011

Sept. 2, 2011

Le 31 août 2011 à 17:20, python-ideas-request(a)python.org a écrit : > I have often thought that would be a nice to have feature, but to be > honest, I have never found a use for it that was absolutely necessary. I > have always found another way to solve the problem. > > To make it work using just ordinary assignment syntax, as you suggest, > requires more than just an "alias" function. It would need changes to > the Python internals. Possibly very large changes. … [View More]

8 11