Formatted and finished Rebert's solution to this issue
But the question of where to put it is still open ( shutil.open vs.
shutil.launch vs. os.startfile ):
1. `shutil.open()` will break anyone that does `from shutil import *` or
edits the shutil.py file and tries to use the builtin open() after the
2. `shutil.launch()` is better than shutil.open() due to reduced breakage,
but not as simple or DRY or reverse-compatible as putting it in
os.startfile() in my mind. This fix just implements the functionality of
os.startfile() for non-Windows OSes.
3. `shutil.startfile()` was recommended against by a developer or two on
this mailing list, but seems appropriate to me. The only upstream
"breakage" for an os.startfile() location that I can think of is the
failure to raise exceptions on non-Windows OSes. Any legacy (<3.0) code
that relies on os.startfile() exceptions in order to detect a non-windows
OS is misguided and needs re-factoring anyway, IMHO. Though their only
indication of a "problem" in their code would be the successful launching
of a viewer for whatever path they pointed to...
4. `os.launch()` anyone? Not me.
On Mon, Apr 23, 2012 at 6:00 PM, <python-ideas-request(a)python.org> wrote:
> Send Python-ideas mailing list submissions to
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> You can reach the person managing the list at
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-ideas digest..."
> Today's Topics:
> 1. Anyone working on a platform-agnostic os.startfile() (Hobson Lane)
> 2. Re: Anyone working on a platform-agnostic os.startfile()
> (Chris Rebert)
> Message: 1
> Date: Mon, 23 Apr 2012 13:21:10 +0800
> From: Hobson Lane <hobsonlane(a)gmail.com>
> To: python-ideas(a)python.org
> Cc: Hobson's Totalgood Aliases <knowledge(a)totalgood.com>
> Subject: [Python-ideas] Anyone working on a platform-agnostic
> Content-Type: text/plain; charset="iso-8859-1"
> There is significant interest in a cross-platform
> file-launcher. The ideal implementation would be
> an operating-system-agnostic interface that launches a file for editing or
> viewing, similar to the way os.startfile() works for Windows, but
> generalized to allow caller-specification of view vs. edit preference and
> support all registered os.name operating systems, not just 'nt'.
> Mercurial has a mature python implementation for cross-platform launching
> of an editor (either GUI editor or terminal-based editor like vi).
> The python std lib os.startfile obviously works for Windows.
> The Mercurial functionality could be rolled into os.startfile() with
> additional named parameters for edit or view preference and gui or non-gui
> preference. Perhaps that would enable backporting belwo Python 3.x. Or is
> there a better place to incorporate this multi-platform file launching
> : http://selenic.com/repo/hg-stable/file/2770d03ae49f/mercurial/ui.py
In a function you can use a return statement to break out of execution
in the middle of the function. With modules you have no recourse.
This is akin to return statements being allowed only at the end of a
There are a small number of ways you can work around this, but they
aren't great. This includes using wrapper modules or import hooks or
sometimes from-import-*. Otherwise, if your module's execution is
conditional, you end up indenting everything inside an if/else
Proposal: introduce a non-error mechanism to break out of module
execution. This could be satisfied by a statement like break or
return, though those specific ones could be confusing. It could also
involve raising a special subclass of ImportError that the import
machinery simply handles as not-an-error.
This came up last year on python-list with mixed results. 
However, time has not dimmed the appeal for me so I'm rebooting here.
While the proposal seems relatively minor, the use cases are not
extensive. <wink> The three main ones I've encountered are these:
1. C extension module with fallback to pure Python:
from _extension_module import *
break # or whatever color the bikeshed is
# pure python implementation goes here
2. module imported under different name:
if __name__ != "expected_name":
from expected_name import *
# business as usual
3. module already imported under a different name:
if "other_module" in sys.modules:
exec("from other_module import *", globals())
# module code here
I looked through the man page for python's interpreter and appears
that there is no way to properly distinguish between error messages
output to stderr by the interpreter and output produced the by a
user-program to stderr.
What I would really like to have are two things:
1) an option to output interpreter generated messages to a specified
file, whether these messages are uncatchable syntax errors, or
catchable runtime errors that result in the termination of the
interpreter. This feature would allow a wrapper program to distinguish
between user-output and python interpreter output.
2) an option to provide a structured error output in some common
easy-to-parse and extendable format that can be used to associate the
file, line number, error type/number in some post-processing error
handler. This feature would make the parsing of error messages more
deterministic, and would be of significant benefit if other
compilers/interpreters also provide the same functionality in the same
Does anyone know if there is already such a way to do what I've asked?
If not, do you think having such features added to python would be
something that would actually be included?
The other day a colleague of mine submitted this challenge taken from
some website to us coworkers:
Have the function ArrayAddition(arr) take the array of numbers stored
in arr and print true if any combination of numbers in the array can
be added up to equal the largest number in the array, otherwise print
false. For example: if arr contains [4, 6, 23, 10, 1, 3] the output
should print true because 4 + 6 + 10 + 3 = 23. The array will not be
empty, will not contain all the same elements, and may contain
I proposed this solution:
from itertools import combinations, chain
biggest = max(arr)
my_comb = chain(*(combinations(arr,i) for i in range(1,len(arr)+1)))
for one_comb in my_comb:
if sum(one_comb) == biggest:
return True, one_comb
But then somebody else submitted this Haskell solution:
f :: (Ord a,Num a) => [a] -> Bool
f lst = (\y -> elem y $ map sum $ subsequences $ [ x | x <- lst, x /=
y ]) $ maximum lst
I wonder if we should add a subsequences function to itertools or make
the "r" parameter of combinations optional to return all combinations
up to len(iterable).
> On 4/22/2012 11:18 PM, Chris Rebert wrote:
> > On Sun, Apr 22, 2012 at 7:55 PM, Terry Reedy<tjreedy(a)udel.edu> wrote:
> >> On 4/22/2012 9:07 PM, Nestor wrote:
> > <snip>
> >>> false. For example: if arr contains [4, 6, 23, 10, 1, 3] the output
> >>> should print true because 4 + 6 + 10 + 3 = 23.
> >> Since the order of the numbers is arbitrary and irrelevant to the
> >> it should be formulated in term of a set of numbers.
> > Er, multiplicity still matters, so it should be a multiset/bag. One
> > possible representation thereof would be a list...
> Er, yes. Given the examples, I (too quickly) misread 'will not contain
> all the same elements' as 'no duplicates'. In any case, a set was needed
And doesn't ordering matter too (for efficiency). A sorted list of the
positive integers may solve in much less less time, right?
Thanks, that's fair, for consistency.
One use case for my question was a stackoverflow question regarding merging
two dict's. If update() returned its own reference, and if we explicitly
wanted a copy (instead of an in-place modification), we could have used
given x and y are both dict() instances.
On 20 April 2012 22:35, Laurens Van Houtven <_(a)lvh.cc> wrote:
> As a general rule, methods/functions in Python either *mutate* or
> *return*. (Obviously, mutating methods also return, they just return None)
> For example: random.shuffle shuffles in place so doesn't return anything
> list.sort sorts in place so doesn't return anything
> sorted creates a new sorted thing, so returns that sorted thing
> On 20 Apr 2012, at 14:32, Xavier Ho wrote:
> > Hello,
> > What's the rationale behind the fact that `dict().update()` return
> nothing? If it returned the dictionary reference, at least we could chain
> methods, or assign it to another variable, or pass it into a function, etc..
> > What's the design decision made behind this?
> > Cheers,
> > Xav
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas(a)python.org
> > http://mail.python.org/mailman/listinfo/python-ideas
What's the rationale behind the fact that `dict().update()` return nothing?
If it returned the dictionary reference, at least we could chain methods,
or assign it to another variable, or pass it into a function, etc..
What's the design decision made behind this?
Suppose I model a game of cards, where suits don't matter. I might find the
integer representation of cards (14 for "Ace", 13 for "King", ..., 2 for
"2") to be convenient.
The deck has 4 copies of each card, which I need to distinguish.
I was thinking to model a card as follows:
__hash__ = int.__hash__
def __eq__(self, other):
return self is other
This works precisely as I want (at least in CPython 3.2):
x = Card(14)
y = Card(14)
assert x != y # x and y are two different Aces
z = x
assert x == z # x and z are bound to the same Ace
But this behavior is implementation dependent, so the above code may one
day break (very painfully for whoever happens to maintain it at the time).
Is it possible to add a guarantee to the language that would make the above
code safe to use? Currently the language promises:
"For immutable types, operations that compute new values may actually
return a reference to any existing object with the same type and value,
while for mutable objects this is not allowed."
Nowhere in the documentation is it clearly defined which objects are
considered "immutable" for the purpose of this promise. As a result, a
Python implementation, now or in the future, may decide that it's ok to
return a reference to an existing object when a Card instance is created -
since arguably, class Card is immutable (since it derives from an immutable
base class, and doesn't add any new attributes).
Perhaps a change like this would be fine (it obviously won't break any
"For certain types, operations that compute new values may actually return
a reference to an existing object with the same type and value. The only
types for which this may happen are:
- built-in immutable types
- user-defined classes that explicitly override __new__ to return a
reference to an existing object
Note that a user-defined class that inherits from a built-in immutable
types, without overriding __new__, will not exhibit this behavior."
I'm pleased to announce the first beta release of Pythonect interpreter.
Pythonect is a new, experimental, general-purpose dataflow programming
language based on Python.
It aims to combine the intuitive feel of shell scripting (and all of its
perks like implicit parallelism) with the flexibility and agility of
Pythonect interpreter (and reference implementation) is written in Python,
and is available under the BSD license.
Here's a quick tour of Pythonect:
The canonical "Hello, world" example program in Pythonect:
>>> "Hello World" -> print
<MainProcess:Thread-1> : Hello World
'->' and '|' are both Pythonect operators.
The pipe operator (i.e. '|') passes one item at a item, while the other
operator passes all items at once.
Python statements and other None-returning function are acting as a
>>> "Hello World" -> print -> print
<MainProcess:Thread-2> : Hello World
<MainProcess:Thread-2> : Hello World
>>> 1 -> import math -> math.log
Parallelization in Pythonect:
>>> "Hello World" -> [ print , print ]
<MainProcess:Thread-4> : Hello World
<MainProcess:Thread-5> : Hello World
['Hello World', 'Hello World']
>>> range(0,3) -> import math -> math.sqrt
[0.0, 1.0, 1.4142135623730951]
In the future, I am planning on adding support for multi-processing, and
even distributed computing.
The '_' identifier allow access to current item:
>>> "Hello World" -> [ print , print ] -> _ + " and Python"
<MainProcess:Thread-7> : Hello World
<MainProcess:Thread-8> : Hello World
['Hello World and Python', 'Hello World and Python']
>>> [ 1 , 2 ] -> _**_
True/False return values as filters:
>>> "Hello World" -> _ == "Hello World" -> print
<MainProcess:Thread-9> : Hello World
>>> "Hello World" -> _ == "Hello World1" -> print
>>> range(1,10) -> _ % 2 == 0
[2, 4, 6, 8]
Last but not least, I have also added extra syntax for making remote
procedure call easy:
>> 1 -> inc@xmlrpc://localhost:8000 -> print
<MainProcess:Thread-2> : 2
Download Pythonect v0.1.0 from:
More information can be found at: http://www.pythonect.org
I will appreciate any input / feedback that you can give me.
Also, for those interested in working on the project, I'm actively
interested in welcoming and supporting both new developers and new users.
Feel free to contact me.
Itzik Kotler | http://www.ikotler.org