Sorry to annoy the very busy core devs :) out of the blue
I quite noticed people were
1) wanting to have a new dict for Xmas
2) strongly resenting dict addition.
Even though I am not a good developper, I have come to a definition of
addition that would follow algebraic rules, and not something of a
dutch logic. (it is a jest, not a troll)
I propose the following code to validate my point of view regarding
the dictionnatry addition as a proof of concept :
It follows all my dusty math books regarding addition + it has the
amability to have rules of conservation.
I pretty much see a real advantage in this behaviour in functional
programming (map/reduce). (see the demonstrate.py), and it has a sense
(if dict can be seen has vectors).
I have been told to be a troll, but I am pretty serious.
Since, I coded with luck, no internet, intuition, and a complete
ignorance of the real meaning of the magic methods most of the time,
thus the actual implementation of the addition surely needs a complete
Currently if you work in console and define a function and then
immediately call it - it will fail with SyntaxError.
For example, copy paste this completely valid Python script into console:
There is an issue for that that was just closed by Eric. However, I'd
like to know if there are people here that agree that if you paste a
valid Python script into console - it should work without changes.
What's the python-dev view on this?
-------- Original Message --------
Subject: Anyone still using Python 2.5?
Date: Wed, 21 Dec 2011 07:15:46 +0000
From: Chris Withers <chris(a)simplistix.co.uk>
To: Python List <python-list(a)python.org>,
What's the general consensus on supporting Python 2.5 nowadays?
Do people still have to use this in commercial environments or is
everyone on 2.6+ nowadays?
I'm finally getting some continuous integration set up for my packages
and it's highlighting some 2.5 compatibility issues. I'm wondering
whether to fix those (lots of ugly "from __future__ import
with_statement" everywhere) or just to drop Python 2.5 support.
What do people feel?
Simplistix - Content Management, Batch Processing & Python Consulting
-----BEGIN PGP SIGNED MESSAGE-----
Working in the DTRACE probes, I think I can simplify the build logic
quite a bit using the GNU Makefile conditional execution:
In concrete, I have object files that must be compiled and linked, or
not, according to a "configure" test result.
But currently I think we are not using these features. Maybe because
we don't want to force the use of GMAKE, I don't know.
If this is a policy, I would like to know.
And if somebody has a suggestion to cope with this difficulty...
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
jabber / xmpp:email@example.com _/_/ _/_/ _/_/_/_/_/
. _/_/ _/_/ _/_/ _/_/ _/_/
"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.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
I have started HandBrakeCLI using subprocess.popen but the output is multiline and not terminated with \n so i am not able to read it using readline() while the HandBrakeCLI is running. kindly suggest some alternative. i have attached the output in a file.
I have some features I need to add to lib2to3 to make it more useful for
our purposes at work supporting our massive code base in a Python 2 to 3
transition. Which tree should I develop these and check these into?
Can I backport this to 3.2 and 2.7? It counts as a feature addition which
is normally a no-no for backports. But in this case I'm enhancing 2to3
which is a useful tool.
No big deal to me _personally_ if I can't backport from 3.3
(cpython/default) as I'd apply the changes to our copy at work internally
but it seems wise to me for us to keep enhancing and improving 2to3 in a
Python 2.x/3.x release independent manner to make people's conversions
The features I want to commit (all pretty easy additions) are command line
flag / constructor option support for:
1) writing output files to a different directory tree instead of
overwriting the input file.
2) modifying the output filename by altering the suffix (.py -> .py3 for
3) always writing output files even if there were no changes to make
(useful in combination with the above to effectively act as a "copy library
X to this directory converting it to python 3 syntax along the way").
The old http://hg.python.org/2to3/ tree exists but it really looks like an
out of date version.