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 code injection exploits. m -- Matt Billenstein matt(a)vazor.com http://www.vazor.com/

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 > > # 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) >> >

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: > > '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.

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 bytes instance just blows up: >>> xmlrpc.client.dumps((b'foo',)) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/xmlrpc/client.py", line 956, in dumps data = m.dumps(params) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/xmlrpc/client.py", line 506, in dumps dump(v, write) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/xmlrpc/client.py", line 530, in __dump f(self, value, write) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/xmlrpc/client.py", line 569, in dump_string write(escape(value)) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/xmlrpc/client.py", line 156, in escape s = s.replace("&", "&") TypeError: expected an object with the buffer interface >>> xmlrpc.client.dumps((xmlrpc.client.Binary(b'foo'),)) '<params>\n<param>\n<value><base64>\nZm9v\n\n</base64></value>\n</param>\n</params>\n' I think it would be worthwhile to do the following: * Have xmlrpc.client treat dumping `bytes` (and related objects, such as bytearray or memoryview) as if they were `Binary`-wrapped (by b64encoding them and shipping them as binary data, which they are) * Add a flag to xmlrpc.client's `ServerProxy` and `loads` to have binary data (<base64> nodes of xmlrpc) decode to `bytes` rather than `Binary` instances. This option would likely be `False` by default, at least to start with, so as not to break compatibility with Python 3.1 and 3.2 code. PS: as seen above, xmlrpc claims to require objects "with the buffer interface", Python's documentation (http://docs.python.org/py3k/library/stdtypes.html?highlight=memoryview#memo…) claims bytes and bytearray implement "the buffer protocol". Who is lying?

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 example readily at hand: > >>>> def f(a,b,c,d=None): pass > ... >>>> f(1,2,d=4) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: f() takes at least 3 arguments (3 given) Isn't this already fixed for Python 3.3? Python 3.3.0a0 (default:a8748022504f, Sep 2 2011, 12:32:36) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def f(a, b, c, d=None): pass ... [63593 refs] >>> f(1, 2, d=4) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: f() missing 1 required positional argument: 'c' [63624 refs]

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 structures. > ======================================================= > How about only require indentation > to freely break lines? Here is an example: > x = firstpart * secondpart #line breaks here > + anotherpart #continue by indentation > + stillanother #continue on. > #until here, another line starts by dedentation > y = some_expression - another_one > All this would be completely compatible with former code, while > having almost free line breaking! Plus, indentation makes it pretty. > Really hope Python can have freedom in breaking lines. > Yingjie

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 introspection will be required. --- Steven Klass (480) 225-1112 sklass(a)pointcircle.com

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 programs. > Most people seems to like an indentation on the continuing lines, Most of the time, yes, but sometimes not. For example, in generating text, it's often useful to dedent substantially so you can have a nearly normal length line in the literal strings being concatenated. Or you might have a pattern like this: x = long_named_variable_a - long_named_variable_a_base + long_named_variable_b - long_named_variable_b_base which your parser would raise an error on, I presume. That's not freedom!<wink />

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 breaking and indentation of long expressions is an art, and people have different opinions on "readability" and "beauty." Achieving a compromise that is workable even for a few major styles is likely to be annoying and bug-prone. Pretty much every program I write seems to have a continued list of data or a multi-line dictionary display as data. It's not unusual for me to comment the formal arguments in a function definition, or the parent classes of a class definition. The exception for parenthesized objects is something I depend on for what I consider good style. Of course I could use explicit continuation, but in a long table that's ugly and error-prone. Long expressions that need to be broken across lines, on the other hand, often indication that I haven't thought carefully enough about that component of the program, and an extra pair of parentheses or a terminal backslash just isn't that "heavy" or ugly in the context of such long expressions. For me, they're also pretty rare; many programs I write have no explicit continuations in them at all. YMMV, of course, but I find the compromise that Python arrived at to be very useful, and I must suppose that it was substantially easier to implement than "fully free" line breaking (whatever that means to you).

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. Without a convincing > use-case, I don't think that will happen. > > So even though I think this would be a neat feature to have, and > possibly even useful, I don't think it is useful enough to justify the > work needed to make it happen. > > -- > Steven I don't agree with you when you say there is no necessary use case, e.g. I have two images in a gui and they must stay at the same position (relatively one to the other) but follow the movements of the arrow keys (truthful!). You can't do it by using an intermediate list because the list object is mutable but his data not: ------------------------ >>> list = [3,] >>> a = list[0] >>> list[0] = 6 >>> a 3 ------------------------- I really don't see any other solution, even I'm sure it would be a twisted operation and I don't find it very pythonic... Amicalement, Peio

8 11