I find the following two operations functions useful and general enough that I
would like to propose them for addition to itertools:
it = iter(iterable)
first_item = it.next()
raise ValueError, "empty iterable passed to 'single_valued()'"
for other_item in it:
if other_item != first_item:
raise ValueError, "non-single-valued iterable'"
This first one embodies the assertion that all values of the iterable are
identical. If they are, that value is returned. Otherwise, an exception is
thrown. Maybe this should be rephrased such that the assertion part is
evaluated via an actual "assert", thereby turning it off in optimized mode.
Example use case: You get a list of lists, and expect each to be the same
length. Typical treatment:
list_len = len(lists)
list_len = single_valued(len(l) for l in lists)
Added benefits: The assumption is verified and clearly visible from the
source. "lists" may now be an iterable.
it = iter(iterable)
v = it.next()
raise ValueError, "empty iterable passed to 'one()'"
v2 = it.next()
raise ValueError, "iterable with more than one entry passed
This one is a blatant rip-off from SQLAlchemy. It basically allows most
searches to be written using generator expressions:
what_i_am_looking_for = one(item for item in items if predicate(item))
This also encodes and checks the assumption that the sought item is unique
within the list of candidates. Again, the assertion part could be turned off
in optimized mode.
I'm hoping to draw somebody's attention to this before it's too late.
This affects multiple stdlib modules:
The new timeout support in 2.6 makes use of new function
socket.create_connection(). socket.create_connection() provides no way to
disable timeouts, other than by relying on socket.getdefaulttimeout()
returning None. This is unfortunate, because it was the purpose of the
new timeout support to allow control of timeouts without reliance on
The author of the patch that introduced this problem (Facundo Batista) has
admitted that the behaviour he implemented does not match the discussion
about the feature that took place on python-dev, but has not found time to
review my patch in the last two months. I fear this broken API will make
it into 2.6 (and 3.0?).
More could be done here re other issues introduced by the patch (I've
listed those that I noticed on issue 2451 -- including at least one other
API issue), but the patch attached to issue2451 at least resolves the most
A thread in PyAr raised the question that, considering that strings
are immutable, why a slice of a string is a copy and not a reference
to a part of that string.
I couldn't answer why, so I'm asking here...Is it because the
reference counting will be complicated? Is it because it'd be
inefficient in other way? It's something else? Or is something that
could be done... but is not done yet?
Thank you very much!
I tracked down a testing failure for Cython tests
on the Windows platform to be the result of how the
Visual C environment variables are being detected.
In the function, query_vcvarsall, the .bat file:
"C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"
is being run with the arguments:
x86 & set
This in turn calls the platform-specific file vcvars32.bat (or other).
In this file, the PATH, INCLUDE, and LIBPATH environment variables are
simply being appended/prepended with their values.
initialize() then just overrides the os.environ values with these
monotonically growing variables.
It seems that duplicate names should be filtered out from these paths
to prevent overflow.
The attached patch seems to fix this issue, if a bit brute force.
Please review as a candidate.
.NET Framework 3.5 (Pre-Release
--- msvc9compiler.py.orig 2008-05-26 12:29:18.529288200 -0700
+++ msvc9compiler.py 2008-05-26 12:34:11.403841800 -0700
@@ -193,6 +193,17 @@
+ """Remove duplicate values of an environment variable.
+ oldList = variable.split(os.pathsep)
+ newList = 
+ for i in oldList:
+ if i not in newList:
+ newVariable = os.pathsep.join(newList)
+ return newVariable
"""Find the vcvarsall.bat file
@@ -257,7 +268,7 @@
if key in interesting:
value = value[:-1]
- result[key] = value
+ result[key] = removeDuplicates(value)
if len(result) != len(interesting):
_zip_directory_cache is a cache for modules imported by zipimporter.
It's a normal dictionary exposing gory details of zipimport
implementation. It wouldn't be a bad thing on it's own, but pkgutil.py
uses this knowledge, while _zip_directory_cache has no single test nor
documentation (besides info in docstring). It's a bit of a pain to
actually implement this in other python implementations (especially
that cache can be internal and exposed differently). I think it should
be either specified better (and stripped from _) or zipimport should
expose some nicer interface to it's cache. What do you think?
> A thread in PyAr raised the question that, considering that strings
> are immutable, why a slice of a string is a copy and not a reference
> to a part of that string.
> I couldn't answer why, so I'm asking here...Is it because the
> reference counting will be complicated? Is it because it'd be
> inefficient in other way? It's something else? Or is something that
> could be done... but is not done yet?
> Thank you very much!
We implemented this feature in pypy. It's turned of by default, because
nobody could come out with a real world example benefiting from it.
Regarding worst-case scenario, we only create this special object
if slice length is not shorter than some percentage of source string
(I think 75%,
can be tuned).
You still need to pay for a dispatch (even if small price) wherever
you use string,
to check if this is special object or not.
Hello fellow developers!
I've been busy with personal work in the past weeks. At present I'm
still moving into my new apartment. It has been a real challenge to
install an IKEA kitchen in a house built before WW2 all by myself. On
the one hand it's fun but on the other hand it costs me most of my free
time at night. At least this building has a shelter in its cellar so I'm
mostly protected in the case of an air strike. *g*
In order to get all code merged before the first betas I need your help.
Please everybody grab a couple of your checkins and merge them yourself.
You can find the list of required merges at http://rafb.net/p/cghbTk63.html
For those of you who have been using my Mercurial mirrors of the Python SVN
repository, I had to move them to another site as the original site has been
down for a few days for unknown reasons. Here are the new URLs:
If you want those to become the default pulling location, you just have to edit
the .hg/hgrc for your local clone(s) and fill in the appropriate URL.
-----BEGIN PGP SIGNED MESSAGE-----
I just committed pybsddb 4.6.4 to python svn. My next step (after a
successfull buildbot cycle, I hope!) is to commit the new testsuite.
First I need to review any changes there since I maintain pybsddb.
The testsuite creates a lot of files/directories while working. Fine,
since it cleans later, unless some test crashes hard. My testcode
defines a variable to the path I want to use to keep those files/dirs.
Currently it is "/tmp/z-BerkeleyDB", or something like that.
Since my code allows for testcases to be run in multiple threads and/or
processes, where would be a sensible path choice for temporal files?.
Current working directory would be fine, if "somebody" is cleaning after
running all tests.
Ramdisk ("/tmp" in some systems, for example Solaris) would be nice,
since some test uses transactions, and transactions are write-synchronous.
In my system, runnning all tests serially (you can run all of them in
parallel, if you wish) takes about 15-20 seconds. Far faster than
current tests in python svn, and that can be improved even more.
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
jabber / xmpp:firstname.lastname@example.org _/_/ _/_/ _/_/_/_/_/
~ _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----