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
This subject was discussed 2.5 years ago:
I opened a feature request ticket:
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?
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?
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.
I remember seeing a bit of discussion about improving Python's default
options parsing... Tornado's seems very impressive :
> 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?
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,
@ <any-expression> # disallowed, SyntaxError
can be implemented, albeit in a more verbose aka less Pythonic was, as:
AnyExpr = <any-expression>
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):
@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
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
(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.
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"), 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.
I've written a function  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
def foo(x=1, y=2):
apply_some(foo, y=0, z="hi") // calls foo(y=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?
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...
* makes your code less readable if there is high density of such
* 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>
I put some sweat into this one so I was hoping to see if you guys like
it or have any ideas for improvement.
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
At the moment annotations are mandatory for explicitness and here's an
from pyopt import CmdPos
from pyopt import parse_cmds
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__":
Notice 4 things:
* an import
* a decorator
* a parse_cmds()
* type-annotations for casting
The following functionality is exposed:
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
2 arguments required, got only 1. Run with ? or -h for more help.
> 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 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.
>>> Can I make another plea for the syntax following '@' to be an
>>> expression? Guido has said he has a 'gut feeling' against this but has
>>> 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,
>>> @ <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"?
>>> AnyExpr = <any-expression>
>>> 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
>>> have their own):
>>> @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
>>> but this doesn't seem a good reason for forbidding the simpler syntax;
>>> all Python allows the simpler syntax in other contexts. Similarly 3.2)
>>> be written as
>>> (As an aside, perhaps a decorator that evaluates to None could be treated
>>> run-time the same as no decorator, i.e. equivalent to the Identity
>>> in the above examples. Currently it naturally raises TypeError:
>>> object is not callable. Just a thought.)
>>> Finally, sorry if I have not sent this e-mail to the right place (I
>>> to attach it to the 'allow lambdas as decorators' thread but don't yet
>>> how to do this). Also sorry that this partly duplicates a message I sent
>>> 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
Psss, psss, put it down! - http://www.cafepress.com/putitdown