Fast constant functions for Py2.5's defaultdict()

FWIW, here are three ways of writing constant functions for collections.defaultdict(): d = defaultdict(int) # slowest way; works only for zero d = defaultdict(lambda: 0) # faster way; works for any constant d = defaultdict(itertools.repeat(0).next)# fastest way; works for any con

Re: Fast constant functions for Py2.5's defaultdict()

On Feb 13, 5:09 pm, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > > The itertools.repeat(const).next approach wins on speed and > > flexibility. > > But it's the most unreadable too. Not really. It's unusual but plenty readable (no surprise that repeat(0) repeatedly gives you zero). I think it more

Re: builtin set literal

>> What about "{,}"? For consistency "(,)" and "[,]" might >> also have to be permissible, and maybe even "{:}" for an >> empty dict. The notion of a set literal was rejected in PEP 218, http://www.python.org/dev/peps/pep-0218/ . One of the reasons for the rejection was that the small benefit of a

Re: Need an identity operator because lambda is too slow

[Deron Meranda >] I'm looking for something in > Python which would act like an identity operator, or I-combinator: a > do-nothing function. The best I know of is: (lambda x: x), but it is > not ideal. File a feature request on SourceForge and assign to me. This has come up a couple of times a

Re: Some "pythonic" suggestions for Python

On Nov 8, 12:00 pm, Frank Samuelson <[EMAIL PROTECTED]> wrote: > def foo(x,y): ... > assigns the name foo to a function object. > > Why not use the = operator like most other assignments? FWIW, the also binds the __name__ attribute: foo = lambda(x,y): ... foo.__name__ = 'foo' Raymond --

Re: defaultdict and dict?

On Nov 9, 3:01 am, Davy <[EMAIL PROTECTED]> wrote: > In Python 2.5 document, defaultdict is called high performance > container. From document, we can know defaultdict is subclass of dict. > So, why defaultdict have higher performance than dict? And at what > circumstance, we can make use of such h

Re: Define key in nlargest() of heapq?

On Nov 12, 6:56 pm, Davy <[EMAIL PROTECTED]> wrote: > I have a dictionary with n elements, and I want to get the m(m<=n) > keys with the largest values. > > For example, I have dic that includes n=4 elements, I want m=2 keys > have the largest values) > dic = {0:4,3:1,5:2,7:8} > So, the the largest

Re: cmp and sorting non-symmetric types

On Nov 13, 10:51 am, "Adam Olsen" <[EMAIL PROTECTED]> wrote: > Although py3k raises an exception for completely unsortable types, it > continues to silently do the wrong thing for non-symmetric types that > overload comparison operator with special meanings. > To solve this I propose a revived cmp

Re: cmp and sorting non-symmetric types

On Nov 13, 1:18 pm, Carl Banks <[EMAIL PROTECTED]> wrote: > The right solution is to use comparison operators > only for ordered comparisons, not for subset and superset testing. The whole point of the rich comparisons PEP was to be able to override the operators for other purposes. Raymond --

Re: cmp and sorting non-symmetric types

On Nov 13, 2:54 pm, Paul Rubin wrote: > Carl Banks <[EMAIL PROTECTED]> > > > resurrecting the __cmp__ operator. > > I didnd't realize __cmp__ was going. Are we really supposed to > implement all the rich comparison methods to code an ordered class? > Or is there some kin

Re: Best way to merge/sort two sorted lists?...

On Dec 6, 9:30 am, Aaron Watters <[EMAIL PROTECTED]> wrote: > While trying to optimize some NUCULAR libraries I discovered > that the best way to merge 2 sorted lists together > into a new sorted list is to just append > them and re-sort. . . . > I'm beginning to think > a "sorted list merger" mi

Re: Is a "real" C-Python possible?

On Dec 9, 1:14 pm, "Jack" <[EMAIL PROTECTED]> wrote: > I wonder if it's possible to have a Python that's completely (or at > least for the most part) implemented in C, just like PHP - I think > this is where PHP gets its performance advantage. Or maybe I'm wrong > because the core modules that matt

Re: Are Python deques linked lists?

> > I'm looking for a linked list implementation. Something > > iterable with constant time insertion anywhere in the list. I > > was wondering if deque() is the class to use or if there's > > something else. Is there? > > The deque is implemented as a list of arrays. See 5.12.1 Recipes > for t

Re: __init__ method for containers

On Dec 12, 7:22 am, Neil Cerutti <[EMAIL PROTECTED]> wrote: > List and deque disagree on what __init__ does. Which one is > right? File a bug report and assign to me. Raymond -- http://mail.python.org/mailman/listinfo/python-list

Re: __init__ method for containers

On Dec 12, 8:41 am, Calvin Spealman <[EMAIL PROTECTED]> wrote: > It documents that deque.__init__ initializes it, as all __init__ > methods do. All init methods are also assumed to _only_ be called at > the start of the life of the object and never more than once, so > breaking that breaks assumpti

Re: list in a tuple

On Dec 24, 8:22 am, [EMAIL PROTECTED] wrote: > Recently, I got into a debate on programming.reddit.com about > what should happen in the following case: > > >>> a = ([1], 2) > >>> a[0] += [3] > > Currently, Python raises an error *and* changes the first element of > the tuple. Now, this seems like

Re: Feature request: sorting a list slice

George Sakkis wrote: > It would be useful if list.sort() accepted two more optional > parameters, start and stop, so that you can sort a slice in place. In > other words, > > x = range(100) > x.sort(start=3, stop=-1) > > would be equivalent to > > x[3:-1] = sorted(x[3:-1]) > > but more efficien

Re: Feature request: sorting a list slice

Getting a patch ready for checkin (corrected, documented, reviewed, and tested) is only part of the battle. The real challenge of language design is figuring out whether something should be done. Adding optional parameters to a method makes its invocation slower and makes the API harder to learn

Re: iterator? way of generating all possible combinations?

[EMAIL PROTECTED] wrote: > Ok, this is really irritating me. I'm sure there are different ways of > doing this - I'm interested in the algo, not the practical solution, > I'm more trying to play with iterators and recursion. I want to create > a program that generates every possible combination

Re: getting n items at a time from a generator

> >     def chop(iterable, length=2): > >         return izip(*(iter(iterable),) * length) > > Is this *always* guaranteed by the language to work? Yes! Users requested this guarantee, and I agreed. The docs now explicitly guarantee this behavior. Raymond -- http://mail.python.org/mailman/lis

Re: getting n items at a time from a generator

> > Also consider this solution from O'Reilly's Python Cookbook (2nd Ed.) p705 > > >     def chop(iterable, length=2): > >         return izip(*(iter(iterable),) * length) > > However, chop ignores the remainder of the data in the example. There is a recipe in the itertools docs which handles the

Fate of itertools.dropwhile() and itertools.takewhile()

I'm considering deprecating these two functions and would like some feedback from the community or from people who have a background in functional programming. * I'm concerned that use cases for the two functions are uncommon and can obscure code rather than clarify it. * I originally added them

Re: Fate of itertools.dropwhile() and itertools.takewhile()

[bearophile] > Here are my usages (every sub-list is > sorted by inverted frequency usage): > > I use often or very often: > groupby( iterable[, key]) > imap( function, *iterables) > izip( *iterables) > ifilter( predicate, iterable) > islice( iterable, [start,] stop [, step]) > > I use once in whil

Re: Fate of itertools.dropwhile() and itertools.takewhile()

[Michele Simionato] > in my code > base I have exactly zero occurrences of takewhile and > dropwhile, even if I tend to use the itertools quite > often. That should be telling. Thanks for the additional empirical evidence. > I presume you did scans of > large code bases and you did not find occur

Re: Fate of itertools.dropwhile() and itertools.takewhile()

[Marc 'BlackJack' Rintsch] > I use both functions from time to time. > One "recipe" is extracting blocks from text files that are delimited by a > special start and end line. > > def iter_block(lines, start_marker, end_marker): >     return takewhile(lambda x: not x.startswith(end_marker), >      

Re: Fate of itertools.dropwhile() and itertools.takewhile()

FWIW, here is an generator version written without the state flag: def iter_block(lines, start_marker, end_marker): lines = iter(lines) for line in lines: if line.startswith(start_marker): yield line break for line in lines:

Re: Two candies

[bearophileH] > > 1) A fast and memory efficient way to create an array.array at a > certain size. > At the moment I can see some ways to do it: > > from array import array > from itertools import repeat > a = array("l", repeat(0, n)) #3 . . . > - #3 interacts badly with Psyco (Psyco doesn't diges

Re: Two candies

[Raymond] > >#3 is a fine choice. It is memory efficient -- the repeat() itertool > >takes-up only a few bytes. It doesn't need psyco, you already have to fast > >C routines talking to each other without having to go through the > >interpreter loop.< [bearophile] > In my code I have found oth

Re: stupid/style/list question

On Jan 8, 7:34 am, "Giampaolo Rodola'" <[EMAIL PROTECTED]> wrote: > I was wondering... > To flush a list it is better doing "del mylist[:]" or "mylist = []"? > Is there a preferred way? If yes, why? To empty an existing list without replacing it, the choices are "del mylist[:]" and "mylist[:] = [

Re: Structure of packages

[Ben Fisher] > I am trying to learn the best way to do intra-package references. IMO, the email package is a stellar example of best practices using packages. > I have layered the dependencies so that a depends on b, >b depends on c, and c depends on d. For the most part, I think packages tend

Re: Replace stop words (remove words from a string)

On Jan 17, 12:25 am, BerlinBrown <[EMAIL PROTECTED]> wrote: > if I have an array of "stop" words, and I want to replace those values > with something else; > mystr = > kljsldkfjksjdfjsdjflkdjslkf[BAD]Kkjjkkjk[BAD]LSKJFKSFJKSJF;L[BAD2]kjsld­fsd; > if I have an array stop_list = [ "[BAD]", "[BAD2

Re: bags? 2.5.x?

> >> I keep wanting something like them - especially bags with something > >> akin to set union, intersection and difference. > > > How about this recepie > > http://www.ubookcase.com/book/Oreilly/ > > The author of the bag class said that he was planning to submit bags for > inclusion in 2.5 - is

Re: pairs from a list

[Peter Otten] > You can be bolder here as the izip() docs explicitly state > > """ > Note, the left-to-right evaluation order of the iterables is > guaranteed. This makes possible an idiom for clustering a data series into > n-length groups using "izip(*[iter(s)]*n)". > """ . . . > is about zip(),

Re: Cleanup when a object dies

On Jan 22, 7:54 pm, Benjamin <[EMAIL PROTECTED]> wrote: > I writing writing a class to allow settings (options, preferences) to > written file in a cross platform manner. I'm unsure how to go a about > syncing the data to disk. Of course, it's horribly inefficient to > write the data every time som

Re: Index of maximum element in list

On Jan 25, 1:47 pm, Hexamorph <[EMAIL PROTECTED]> wrote: > Henry Baxter wrote: > > Oops, gmail has keyboard shortcuts apparently, to continue: > > > def maxi(l): > >     m = max(l) > >     for i, v in enumerate(l): > >         if m == v: > >             return i > > What's about l.index(max(l)) ?

Re: Why does list have no 'get' method?

[Denis Bilenko] > Why does list have no 'get' method with exactly the same semantics as > dict's get, > that is "return an element if there is one, but do NOT raise > an exception if there is not.": . . . > It is often desirable, for example, when one uses the easiest > command-line options parsin

Re: index() of sequence type?

On Feb 7, 1:57 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote: > Tuples are worse: they implement > __contains__ but not index. So you can say: > > py> 2 in (1,2,4,8) > True > > but not: > > py> (1,2,4,8).index(2) You must be using an old version of Python like 2.5 ;-) As of yesterday, Py2.6 h

Re: Combinatorics

On Feb 11, 11:52 pm, Michael Robertson <[EMAIL PROTECTED]> wrote: > Where is the python equivalent of: > > http://search.cpan.org/~fxn/Algorithm-Combinatorics-0.16/Combinatoric... > > combinations (with and without repetition) > variations (with and without repetition) > permutations > partitions >

Re: Double underscores -- ugly?

[benhoyt] > Is it just me that thinks "__init__" is rather ugly? I also find it unattractive and unpleasant to type. In Py3.0, I would support a single underscore convention, _init_ or somesuch. I'm not sure what the aesthetic reasons are, but somehow the change from double underscores to single

Re: threading/Queue: join() and task_done() not working? (deadlock)

On Feb 27, 11:06 am, Gal Aviel <[EMAIL PROTECTED]> wrote: > Hello All, > > I'm seeing strange behavior where one thread waits on a queue using join() and > the later (or so I think, according to order of the printing in STDOUT) > another > thread calls task_done() on the very same queue, however t

Re: why not bisect options?

[Robert Bossy] > I thought it would be useful if insort and consorts* could accept the > same options than list.sort, especially key and cmp. If you're going to do many insertions or searches, wouldn't it be *much* more efficient to store your keys in a separate array? The sort() function guarant

Re: Polymorphism using constructors

On Mar 3, 12:21 pm, "K Viltersten" <[EMAIL PROTECTED]> wrote: > I'm writing a class for rational numbers > and besides the most obvious constructor > > def __init__ (self, nomin, denom): > > i also wish to have two supporting ones > > def __init__ (self, integ): > self.__init__ (integ, 1) >

Re: for-else

[BearOphile] > So far in Python I've almost hated the 'else' of the 'for' loops FWIW, I'm very happy with for-else. Most of the time, you don't need it, but when you do, it beats the heck out of doing silly tricks with flags. The primary use case is searching a container: prep_tasks() for

Re: islice ==> [::]

[bearophileH] > I find itertools.islice() useful, so for Python 3.x I may like to see > it removed from the itertools module, and the normal slicing syntax > [::] extended to work with generators/iterators too. This is a can of worms. First, remember iterations is a protocol, not a type. So, thi

Re: Can't get items out of a set?

[Cruxic] > Is it possible to get an object out of a set() given another object > that has the same hash code and equality (__hash__() and __eq__() > return the same)? Yes, but it requires an indirect approach. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/499299 Raymond -- http://mail

Re: islice ==> [::]

[castiro] > Slice literals are a logical next step, precedented by raw strings and > bytes. slice= islice is too, precedented by range= xrange. Looking closely at the [::] notation, I think it can easily be confused with an open box of fleas. IMO, the one unequivocal, explicit way of checking fo

Re: Can't get items out of a set?

> > > Is it possible to get an object out of a set() given another object > > > that has the same hash code and equality (__hash__() and __eq__() > > > return the same)? > > > Yes, but it requires an indirect > > approach.http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/499299 > > > Raymond

Re: Can't get items out of a set?

> > The intern() builtin uses this approach: > > >    interned = {} > >    def intern(s): > >         if s in interned: > >             return interned[s] > >         interned[s] = s > >         return s > > If you've seen it before, and have the old one, return the old one. > Do I have this straig

Re: Pycon disappointment

On Mar 16, 4:10 am, Bruce Eckel <[EMAIL PROTECTED]> wrote: > If the following seems unnecessarily harsh, it was even more harsh for > me to discover that the time and money I had spent to get to my > favorite conference had been sold to vendors, presenting me as a > captive audience they could pitc

Re: finding items that occur more than once in a list

On Mar 18, 2:57 am, Simon Forman <[EMAIL PROTECTED]> wrote: > Is there a more efficient way to do this? > > def f(L): > '''Return a set of the items that occur more than once in L.''' > L = list(L) > for item in set(L): > L.remove(item) > return set(L) > > |>> f([0, 0, 1, 1,

Re: Merging a patch/diff generated by difflib?

On Mar 18, 6:08 am, erikcw <[EMAIL PROTECTED]> wrote: > Hi, > > I'm trying to create an undo/redo feature for a webapp I'm working on > (django based). I'd like to have an undo/redo function. > > My first thought was to use the difflib to generate a diff to serve as > the "backup", and then if som

Fate of the repr module in Py3.0

Was looking at PEP 3108, http://www.python.org/dev/peps/pep-3108/ , and saw that the repr module was slated for vaporization. I've only used the module a few times ever. I'm curious if the community wants it kept around or whether it is considered clutter. The PEP is going to be finalized soon,

Re: Filtering a Python list to uniques

On Mar 25, 4:30 pm, kellygreer1 <[EMAIL PROTECTED]> wrote: > What is the best way to filter a Python list to its unique members? > I tried some method using Set but got some "unhashable" error. > > lstone = [ 1, 2, 3, 3, 4, 5, 5, 6 ] > # how do i reduce this to > lsttwo = [ 1, 2, 3, 4, 5, 6 ] If t

Alphametric fun with Python

Thought you guys might enjoy this: http://code.activestate.com/recipes/576615/ SEND + MORE == MONEY 9567 + 1085 == 10652 Raymond Hettinger -- http://mail.python.org/mailman/listinfo/python-list

Re: Alphametric fun with Python

> > Thought you guys might enjoy this: > >    http://code.activestate.com/recipes/576615/ > > Nice and short, but it's also very slow on my PC (Psyco may help). > > This solves them in moments:http://labix.org/python-constraint Intelligent search beats brute force permutation search. The constrain

Counter Class -- Bag/Multiset

The collections module in Python 2.7 and Python 3.1 has gotten a new Counter class that works like bags and multisets in other languages. I've adapted it for Python2.5/2.6 so people can start using it right away: http://docs.python.org/dev/library/collections.html#counter-objects Here's a link

Re: Counter Class -- Bag/Multiset

> I've adapted it for Python2.5/2.6 so people can start using it right > away: That should just be Python2.6. -- http://mail.python.org/mailman/listinfo/python-list

Re: Counter Class -- Bag/Multiset

> That should just be Python2.6. Fixed. Now runs of Python 2.5 as well. -- http://mail.python.org/mailman/listinfo/python-list

Re: Generator slower than iterator?

> FedericoMoreirawrote: > > Hi all, > > > Im parsing a 4.1GB apache log to have stats about how many times an ip > > request something from the server. > > > The first design of the algorithm was > > > for line in fileinput.input(sys.argv[1:]): > >     ip = line.split()[0] > >     if match_counter.

Re: Removing None objects from a sequence

On Dec 12, 7:51 am, Marco Mariani wrote: > Filip Gruszczyński wrote: > > I am not doing it, because I need it. I can as well use "if not elem > > is None", > > I suggest "if elem is not None", which is not quite the same. They are semantically the same. In theory, Filip's would run slower becaus

Re: heapreplace, methodcaller

On Oct 18, 7:01 am, [EMAIL PROTECTED] wrote: > To improve name coherence I think this method of the heapq module: > heapq.heapreplace(heap, item) > > can grow an alias in Python 2.6.1/2.7 and 3.0/3.1: > heapq.heappoppush(heap, item) > > So later the heapreplace() name can be deprecated. Too late f

Re: __metaclass__ and deepcopy issue

On Oct 17, 1:00 am, Wouter DW <[EMAIL PROTECTED]> wrote: > I read the article > onhttp://www.python.org/download/releases/2.2/descrintro/#metaclasses > and started using autoprop. > But now I have a problem I can't seem to solve myself. > > class autoprop(type): >   def __init__(cls, name, bases,

Proposed implementation for an Ordered Dictionary

Here's a proposed implementation for Py2.7 and Py3.1: http://code.activestate.com/recipes/576669/ Would like you guys to kick the tires, exercise it a bit, and let me know what you think. The recipe runs under 2.6 and 3.0 without modification so it should be easy to play with. The main virt

Re: Proposed implementation for an Ordered Dictionary

[Benjamin Peterson] > Why not just inherit from collections.MutableMapping? It makes the recipe shorter to inherit some methods from dict. Also, subclassing from dict gives a speedup for __getitem__(), __len__(), and get(). -- http://mail.python.org/mailman/listinfo/python-list

Re: Proposed implementation for an Ordered Dictionary

[Hrvoje Niksic] > It seems that __delitem__ of an existing key is O(n), whereas it's > amortized constant time for dicts.  (__setitem__ is constant time for > both.)  Is there a way to avoid this? I don't see any fast/clean way. It's possible to tracking pending deletions and do them all at once

Re: Proposed implementation for an Ordered Dictionary

[Paul Rubin] > What about using a second dictionary (indexed by the incrementing > counter) instead of a list to record the insertion order?  Then you > have O(1) deletion, and traversal takes an O(n log n) sorting > operation. My first attempt used exactly that approach and it works fine though i

Re: Proposed implementation for an Ordered Dictionary

> > What about using a second dictionary (indexed by the incrementing > > counter) instead of a list to record the insertion order?  Then you > > have O(1) deletion, and traversal takes an O(n log n) sorting > > operation. > My first attempt used exactly that approach and it works fine > though it

Re: Proposed implementation for an Ordered Dictionary

[Paul Rubin] > Ehh, I guess I'm not surprised at the slowdown and extra complexity > from the second dict.  Oh well.  If the module really turns out to be > really used a lot, another (messy) approach would be to write a C > extension that uses a doubly linked list some day. That seems like an ide

Re: Proposed implementation for an Ordered Dictionary

[Steve Holden] > A sort of premature pessimization, then. QOTW! _ ~ @ @ \_/ Raymond -- http://mail.python.org/mailman/listinfo/python-list

Re: [Python-Dev] RELEASED Python 3.1 alpha 1

[Benjamin Peterson] On behalf of the Python development team and the Python community, I'm happy to announce the first alpha release of Python 3.1. Thanks for the good work. Raymond -- http://mail.python.org/mailman/listinfo/python-list

Candidate for a new itertool

The existing groupby() itertool works great when every element in a group has the same key, but it is not so handy when groups are determined by boundary conditions. For edge-triggered events, we need to convert a boundary-event predicate to groupby-style key function. The code below encapsulates

Re: Candidate for a new itertool

On Mar 7, 7:58 pm, bearophileh...@lycos.com wrote: > Raymond Hettinger, maybe it can be useful to add an optional argument > flag to tell such split_on to keep the separators or not? This is the > xsplit I usually use: In your experiences with xsplit(), do most use cases involve rem

Re: Candidate for a new itertool

[prueba] > The data often contains objects with attributes instead of tuples, and > I expect the new namedtuple datatype to be used also as elements of > the list to be processed. > > But I haven't found a nice generalized way for that kind of pattern > that aggregates from a list of one datatype t

Re: Number Sequencing, Grouping and Filtering

[flebber] > the only issue i can see is that i am using python 2.54 currently as > ifelt it more supported by other programs than 2.6 or 3.0. After > searching it seems that itertools has had a upgrade in 2.61 All of the itertools include pure python equivalents in their docs, so it should be poss

Rough draft: Proposed format specifier for a thousands separator

If anyone here is interested, here is a proposal I posted on the python-ideas list. The idea is to make numbering formatting a little easier with the new format() builtin in Py2.6 and Py3.0: http://docs.python.org/library/string.html#formatspec --

Re: Rough draft: Proposed format specifier for a thousands separator

> If anyone here is interested, here is a proposal I posted on the > python-ideas list. > > The idea is to make numbering formatting a little easier with > the new format() builtin: > http://docs.python.org/library/string.html#formatspec Here's a re-post (hopefully without the line wrapping proble

Re: Rough draft: Proposed format specifier for a thousands separator

[Ulrich Eckhardt] > IOW, why not explicitly say what you want using keyword arguments with > defaults instead of inventing an IMHO cryptic, read-only mini-language? That makes sense to me but I don't think that's the way the format() builtin was implemented (see PEP 3101 which was implemented Py2.

Re: Rough draft: Proposed format specifier for a thousands separator

On Mar 12, 7:51 am, prueba...@latinmail.com wrote: > On Mar 12, 3:30 am, Raymond Hettinger wrote: > > > > > If anyone here is interested, here is a proposal I posted on the > > python-ideas list. > > > The idea is to make numbering formatting a little easier

PyCon Update

As of today, we still have rooms at the Hyatt. If you haven't registered yet and want to attend, it is not sold out. http://us.pycon.org/2009/ Raymond -- http://mail.python.org/mailman/listinfo/python-list

Re: Rough draft: Proposed format specifier for a thousands separator

[Paul Rubin] > It would be nice if the PEP included a comparison between the proposed > scheme and how it is done in other programs and languages. Good idea. I'm hoping that people will post those here. In my quick research, it looks like many languages offer nothing more than the usual C style %

Re: Rough draft: Proposed format specifier for a thousands separator

[Paul Rubin] > I think Common Lisp has a feature for formatting thousands. I found the Common Lisp spec for this and added it to the PEP. Raymond -- http://mail.python.org/mailman/listinfo/python-list

Re: Rough draft: Proposed format specifier for a thousands separator

[Lie Ryan] > A hyphotetical code using conv function and the microlanguage could look > like this: > >  >>> num = 213210.3242 >  >>> fmt = create_format(sep='-', decsep='@') >  >>> print fmt > 50|\/|3_v3ry_R34D4|3L3_C0D3 >  >>> '{0!{1}}'.format(num, fmt) > '213-...@3242' LOL, it's like APL all ove

Re: Rough draft: Proposed format specifier for a thousands separator

[andrew cooke] > would it break anything to also allow > > >>> format(1234567, 'd')       # what we have now >  '1234567' > >>> format(1234567, '.d')      # proposed new option >  '1.234.567' > >>> format(1234.5, ',2f')      # proposed new option >  '1234,50' > >>> format(1234.5, '.,2f')     # prop

Re: Rough draft: Proposed format specifier for a thousands separator

[Paul Rubin] > What if you want to change the separator?  Europeans usually > use periods instead of commas: one thousand = 1.000. That is supported also. -- http://mail.python.org/mailman/listinfo/python-list

Re: Rough draft: Proposed format specifier for a thousands separator

> > The separators can be any one of COMMA, > > SPACE, DOT, UNDERSCORE, or NON-BREAKING-SPACE. > > What if I want other separators? format(n, ',d').replace(",", yoursep) > How about this idea: make the format has "long" format, which is a bit > more verbose, flexible, and unambiguous, and the cu

Re: Rough draft: Proposed format specifier for a thousands separator

Todays updates to: http://www.python.org/dev/peps/pep-0378/ * Detail issues with the locale module. * Summarize commentary to date. -- Opposition to formatting strings in general (preferring a convenience function or PICTURE clause) -- Opposition to any non-locale aware approach * Add

Re: Rough draft: Proposed format specifier for a thousands separator

[Lie Ryan] >  >     In the finance world, output with commas is the norm. > > I can't cite any source, but I am skeptical with that. No doubt that you're skeptical of anything you didn't already know ;-) I'm a CPA, was a 15 year division controller for a Fortune 500 company, and an auditor for an

Re: Rough draft: Proposed format specifier for a thousands separator

[Lie Ryan] > My proposition is: make the format specifier a simpler API to locale > aware You do know that we already have one, right? That's what the existing "n" specifier does. Raymond -- http://mail.python.org/mailman/listinfo/python-list

Ordered Sets

Here's a new, fun recipe for you guys: http://code.activestate.com/recipes/576694/ Enjoy, Raymond -- http://mail.python.org/mailman/listinfo/python-list

Re: Ordered Sets

[Aahz] > The doubly-linked list part is what's sick and perverted. The doubly-linked list part is what gives it big-oh running times the same as regular sets. If the underlying sequence is stored as a list, then deletion goes from O(1) to O(n). If the insertion times are recorded in a dictionary,

Re: Ordered Sets

[Scott David Daniels] > The double-linked list part could be done with weakrefs and > perhaps Aahz would relax a bit. Am thinking that the __del__() takes care of business. The clear() operation removes the links and all references to them (including circular). Raymond -- http://mail.python.org

Re: Ordered Sets

[Terry Reedy] > I think the idea was 2 weakrefs and 1 normal ref instead of 3 normal refs. Right. Here's a link to a weakref version (though I think the previous __del__ version also does the trick): http://code.activestate.com/recipes/576696/ Raymond -- http://mail.python.org/mailman/lis

Re: What way is the best to check an empty list?

On Mar 25, 7:38 am, srinivasan srinivas wrote: > For ex: to check list 'A' is empty or not.. > if A == []: > if A.count == 0: > if len(A) == 0: > if not A: PEP 8 recommends the latter. Raymond -- http://mail.python.org/mailman/listinfo/python-list

Re: Python3: to add, remove and change

On Apr 2, 12:39 am, bearophileh...@lycos.com wrote: > To add again: tuple unpacking in function arguments: it's handy, hi- > level, de-clutters the code and shortens it too. +1 But you will have to talk to Brett about it. He's the one who led the effort to kill it. > To change: I'd like {:

Re: more fun with iterators (mux, demux)

[Miles] > I assume that "smallish values of n" refers to the fact that > itertools.tee places items into every generator's internal deque, > which islice then skips over, whereas your version places items only > into the deque of the generator that needs it. The pure python equivalent listed in th

Re: any(), all() and empty iterable

> The doc should speak to the intended audience: programmers, who like > to make sure all bases and cases are covered. FWIW, I wrote the docs. The pure python forms were put in as an integral part of the documentation. The first sentence of prose was not meant to stand alone. It is a lead-in to

Re: any(), all() and empty iterable

> Thanks for weighing in, Raymond. You're welcome. > As long as people are getting in their > last licks on this one ... > > Including the word "all" in the definition of "all()" is suboptimal. > Especially since the everyday meaning of "all" is ambiguous. Sure, leave > in the code-equivalent to

Re: How do I change the behavior of the 'python-docs' action in IDLE?

On Apr 16, 12:02 pm, samwyse wrote: > In the Windows version of Python 2.5, pressing F1 brought up the > python.chm file.  I've just installed 2.6, and the same action > openshttp://www.python.org/doc/current/.  I'd prefer the former behavior. > I know how to change the key bindings in config-key

Re: and [True,True] --> [True, True]?????

> > No. Tests like > > > if items: > >    ... > > > to verify that items is a non-empty list are a widespread idiom in Python. > > They rely on the behaviour you observe. > > Are they widespread? I haven't noticed, yet. It's the preferred form (as recommended by PEP 8). Raymond -- http://mail.py

Re: generating random tuples in python

[per] > i realize my example in the original post was misleading. i dont want > to maximize the difference between individual members of a single > tuple -- i want to maximize the difference between distinct tuples. in > other words, it's ok to have (.332, .334, .38), as long as the other > tuple i

<    1   2   3   4   5   6   7   8   >