Mailman 3 September 2009 - Python-ideas

Add a builtin method to 'int' for base/radix conversion
by Yuvgoog Greenle Sept. 17, 2009

Sept. 17, 2009

I believe int(s, base) needs an inverse function to allow string representation with different bases. An example use case is 'hashing' a counter like video ID's on youtube, you could use a regular int internally and publish a shorter base-62 id for links. This subject was discussed 2.5 years ago: http://mail.python.org/pipermail/python-dev/2006-January/059789.html I opened a feature request ticket: http://bugs.python.org/issue6783 Some of the questions that remain: 1. Whether this should be a method for int or a regular function in a standard library module like math. 2. What should the method/function be called? (base_convert, radix, etc) What do you guys think? RunThePun

10 20

set.add(x) slower than if x in set:set.add(x)
by Gerald Britton Sept. 15, 2009

Sept. 15, 2009

Hi -- This is maybe the wrong list for this question. If would someone please redirect me? I stumbled across a performance anomaly wrt the set.add method. My idea was that if I try to add something via set.add, the method has to first check if the new item is already in the set, since set items are supposed to be unique. Then, on a whim, I stuck an "if x in set" condition in front of it. I was surprised to learn that this latter approach runs faster! Here are some results: $ python -m timeit -n 1000000 -s 'with open("/usr/share/dict/words") as f: s = set(w.strip("\n") for w in f)' 's.add("mother")' 1000000 loops, best of 3: 0.292 usec per loop britton@TheBrittons:~$ python -m timeit -n 1000000 -s 'with open("/usr/share/dict/words") as f: s = set(w.strip("\n") for w in f)' 'if "mother" not in s:s.add("mother")' 1000000 loops, best of 3: 0.185 usec per loop the second example beats the first by about 36% Is the timing difference just the cost of the method lookup for s.add, or is something else happening that I'm not seeing? -- Gerald Britton

8 11

Re: [Python-ideas] IDEA: do not alter default SIGINT handling
by Stephen J. Turnbull Sept. 14, 2009

Sept. 14, 2009

Benjamin Peterson writes: > 2009/9/13 Stephen J. Turnbull <stephen(a)xemacs.org>: > > Benjamin Peterson writes: > > > > > It would actually be a huge compatibility break because finally > > > statments would no longer be garunteed to execute. > > > > Hey, kill -9 trumps any guarantee you can give, and that's what the > > user resorts to in the use case at hand. This is a bad thing, even > > from the point of view of those who use "finally" a lot. > > Naturally, users should be able to control their programs absolutely, > but C-c is supposed to tell the program to clean up all its messes > then exit as gracefully as possible. Sure. But setting things up so that C-c doesn't even get through to the program doesn't help that cause. Since the OP claims it works for him, maybe the "IDEA" has merit in some more limited form, for example, by default uninstalling the Python graceful_SIGINT_handler when calling into a C module. (Probably this would have to be introduced in stages to allow extensions to update their functions as needed -- I suppose this would be a performance hit.) Then you could provide a with-signal-handler form of the standard macro for defining a Python function, with the semantics that the signal handler change gets optimized away if you specify the standard handler. And document that in this form the function needs to handle the SIGINT_signaled flag (or however it works) itself, or accept the possibility of an uninterruptible hang.

1 0

Options parsing in the Tornado Web Server
by Andrey Fedorov Sept. 11, 2009

Sept. 11, 2009

I remember seeing a bit of discussion about improving Python's default options parsing... Tornado's seems very impressive [1]: > from tornado.options import define, options > > define("port", default=8888, help="run on the given port", type=int) > > print options.port > > What does everyone think? - Andrey 1. http://github.com/facebook/tornado/blob/9a8bd2fb6fd6279be16d6f0a2e57e49fe1b…

7 9

Decorator syntax restriction
by Rob Cliffe Sept. 10, 2009

Sept. 10, 2009

Can I make another plea for the syntax following '@' to be an unrestricted expression? Guido has said he has a 'gut feeling' against this but has not as far as I know rationalised it. 1) It is inconsistent with Python in general (unPythonic) to impose arbitrary restrictions in one particular place, and hard to explain to someone learning the language. 2) The restriction is in any case more apparent than real, as @ <any-expression> # disallowed, SyntaxError can be implemented, albeit in a more verbose aka less Pythonic was, as: AnyExpr = <any-expression> @AnyExpr or as def Identity(x): return x ... @Identity( <any-expression> ) # smuggle in as func arg 3) I propose the following as plausible use cases (I know other people will have their own): 3.1) @DecoratorList[index] 3.2) @DecoratorDictionary[key] 3.3) @Decorator1 if <condition> else Decorator2 # Special case of the last one: def Identity(x): return x @Decorator if __debug__ else Identity Xavier Morel has pointed out that 3.1) can be implemented now as @DecoratorList.__getitem__[index] but this doesn't seem a good reason for forbidding the simpler syntax; after all Python allows the simpler syntax in other contexts. Similarly 3.2) can be written as @DecoratorDictionary.get(key) (As an aside, perhaps a decorator that evaluates to None could be treated at run-time the same as no decorator, i.e. equivalent to the Identity function in the above examples. Currently it naturally raises TypeError: 'NoneType' object is not callable. Just a thought.) Finally, sorry if I have not sent this e-mail to the right place (I wanted to attach it to the 'allow lambdas as decorators' thread but don't yet know how to do this). Also sorry that this partly duplicates a message I sent to python-dev. I am still finding my way round the Python mailing lists. Best wishes Rob Cliffe

13 14

data structures should have an .any() method
by Stefan Behnel Sept. 9, 2009

Sept. 9, 2009

Hi, I just had a discussion with a co-worker, and we noticed that there are use cases where you just want the only element in a data structure, or just any of the elements in a data structure because you know that they all contain the same information (with respect to what you are looking for, at least). If you want all items, you can iterate, but if you just want any item or the only item, it's inefficient (and not very explicit code) to create an iterator and take the element out. It's easy to do with ordered data structures such as lists or tuples ("container[0]"), but it's not so obvious for sets (or dicts), which means that you have to know what kind of container you receive to handle it correctly. I know there's .pop() on sets, but that modifies the data structure. It would therefore be nice to have a common ".any()" method on data structures that would just read an arbitrary item from a container. Regarding the special (and probably minor use) case of dicts, I assume it would return any key, so that you could get the value from the dict in a second step if you want. Only returning the value would not easily get you the key itself. Stefan

16 39

Function to apply superset of arguments to a function
by Andrey Fedorov Sept. 9, 2009

Sept. 9, 2009

Hi all, I've written a function [1] called apply_some which takes a set of keywords arguments, filters only those a function is expecting, and calls the function with only those arguments. This is meant to suppress TypeErrors - a way to abstract the logic which checks what arguments a passed-in function accepts. For example: def foo(x=1, y=2): return (x,y) apply_some(foo, y=0, z="hi") // calls foo(y=0) -> (1,0) I'd like to expand this to fill undefined arguments with None, but before I do, does anyone know of any packages/libraries which either do something similar or would make this code cleaner? Cheers, Andrey 1. http://gist.github.com/183375

3 2

Re: [Python-ideas] possible attribute-oriented class
by Jan Kaliszewski Sept. 8, 2009

Sept. 8, 2009

06-09-2009 o 20:20:21 Ethan Furman <ethan(a)stoneleaf.us> wrote: > In the dbf module I wrote, I use both the attribute access and the key > lookup. The attribute access is great for interactive use, and for all > the routines that play with the tables we have at work, where all the > field names are indeed known at compile (aka coding) time. On the other > hand, some routines don't know which fields they'll mucking about with, > and so the key access is vital for them. > > Of course, I could have done the whole thing using key access, and I did > have to impose some restrictions on method names so they wouldn't clash > with possible field names, but I love being able to type > > current_record.full_name == last_record.full_name > > instead of > > current_record['full_name'] == last_record['full_name'] Me too, and I suppose many people too... The latter: * makes your code less readable if there is high density of such expressions; * makes typing much more strenuous/irritating -- what is not very important in case of advanced development (when time of typing is short in relation to time of thinking/reading/testing) but becomes quite important in case of scripting (which is still important area of Python usage). -- Jan Kaliszewski (zuo) <zuo(a)chopin.edu.pl>

4 4

Pyopt - an attempt at a pythonic optparse
by RunThePun Sept. 7, 2009

Sept. 7, 2009

I put some sweat into this one so I was hoping to see if you guys like it or have any ideas for improvement. http://code.google.com/p/pyopt/ Currently there are 2 modes of operation, 1. keyword command-line functions which create switches (-m, -r etc). 2. positional command-line functions which simply translate positional arguments from the command-line to a function. possibly in the future I'll implement a mixed keyword/positional arguments behaviour. At the moment annotations are mandatory for explicitness and here's an example usage: from pyopt import CmdPos from pyopt import parse_cmds @CmdPos def possy(archer:str, boulder:float, magic:int=42): """Shows an example positional command-line function. archer - is a str boulder - should be a float magic - a number that is magical""" print(repr(archer), repr(boulder), repr(magic)) if __name__ == "__main__": parse_cmds() Notice 4 things: * an import * a decorator * a parse_cmds() * type-annotations for casting The following functionality is exposed: C:\>example.py -h Usage: example.py archer boulder [magic] Shows an example positional command-line function. archer - is a str boulder - should be a float magic - a number that is magical C:\>example.py 1 2 3 '1' 2.0 3 C:\>example.py 1 2 '1' 2.0 42 C:\>example.py 13 2 arguments required, got only 1. Run with ? or -h for more help.

10 15

Re: [Python-ideas] Decorator syntax restriction
by Daniel Fetchinson Sept. 7, 2009

Sept. 7, 2009

> I happen to think that the longer forms in all the relevant examples that I > gave are harder to understand, because they introduce an extra step that is > not relevant to the job to be done; rather, it is a distraction that adds an > extra 'kink' in the flow of thought. I actually agree with you, in the case of decorators, and for some of the cases you discussed (for example allowing @decorator[5] syntax), it is true that the short forms are readable and I don't see any problem with them. My only concern was the general statement 'more verbose = unpythonic'. > You may disagree - fine - but it should be up to the judgement of the > programmer, within reason, how concise or how verbose to be. I don't fully agree. Some obfuscated, hard-to-read, etc forms should I think be explicitly forbidden. Luckily, python does forbid lots of constructs which would be very hard to follow. > In this case, > the language should not force me to go the extra mile with an arbitrary > restriction, when there is no reason to (no difficulty of implementation, as > I understand it). Yes, again, I fully agree with you on this particular case. Cheers, Daniel > >>> Can I make another plea for the syntax following '@' to be an >>> unrestricted >>> expression? Guido has said he has a 'gut feeling' against this but has >>> not >>> as far as I know rationalised it. >>> >>> 1) It is inconsistent with Python in general (unPythonic) to impose >>> arbitrary restrictions in one particular place, and hard to explain to >>> someone learning the language. >>> >>> 2) The restriction is in any case more apparent than real, >>> as >>> @ <any-expression> # disallowed, SyntaxError >>> can be implemented, albeit in a more verbose aka less Pythonic was, as: >> >> What makes you think that if something is 'more verbose' it is 'less >> pythonic'? I actually like the fact that python doesn't try condensing >> everything into one-liners and special symbols. >> >> I never really understood this need for being not verbose, but it does >> periodically come up on this list (and pretty much on every other >> programming list). Your fingers get tired? It takes too long to read >> an extra line? You are running out of space on your harddrive? It >> takes too long to transfer the source file over the network because of >> the extra line? >> >> Honestly, why do some people set for themselves the goal of "let's >> have as few characters in a source file as possible"? >> >> Cheers, >> Daniel >> >> >>> AnyExpr = <any-expression> >>> @AnyExpr >>> or as >>> >>> def Identity(x): return x >>> ... >>> @Identity( <any-expression> ) # smuggle in as func arg >>> >>> 3) I propose the following as plausible use cases (I know other people >>> will >>> have their own): >>> >>> 3.1) >>> @DecoratorList[index] >>> >>> 3.2) >>> @DecoratorDictionary[key] >>> >>> 3.3) >>> @Decorator1 if <condition> else Decorator2 >>> # Special case of the last one: >>> def Identity(x): return x >>> @Decorator if __debug__ else Identity >>> >>> Xavier Morel has pointed out that 3.1) can be implemented now as >>> @DecoratorList.__getitem__[index] >>> but this doesn't seem a good reason for forbidding the simpler syntax; >>> after >>> all Python allows the simpler syntax in other contexts. Similarly 3.2) >>> can >>> be written as >>> @DecoratorDictionary.get(key) >>> >>> (As an aside, perhaps a decorator that evaluates to None could be treated >>> >>> at >>> run-time the same as no decorator, i.e. equivalent to the Identity >>> function >>> in the above examples. Currently it naturally raises TypeError: >>> 'NoneType' >>> object is not callable. Just a thought.) >>> >>> Finally, sorry if I have not sent this e-mail to the right place (I >>> wanted >>> to attach it to the 'allow lambdas as decorators' thread but don't yet >>> know >>> how to do this). Also sorry that this partly duplicates a message I sent >>> >>> to >>> python-dev. I am still finding my way round the Python mailing lists. >>> >>> Best wishes >>> Rob Cliffe >> >> >> -- >> Psss, psss, put it down! - http://www.cafepress.com/putitdown >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas(a)python.org >> http://mail.python.org/mailman/listinfo/python-ideas >> > > > -- Psss, psss, put it down! - http://www.cafepress.com/putitdown

1 0