Mailman 3 April 2012 - Python-ideas

Re: [Python-ideas] Python-ideas Digest, Vol 65, Issue 43
by Hobson Lane April 27, 2012

April 27, 2012

Formatted and finished Rebert's solution to this issue http://bugs.python.org/issue3177 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 shutil.open() definition. 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 > python-ideas(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/python-ideas > or, via email, send a message with subject or body 'help' to > python-ideas-request(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)python.org > > 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 > os.startfile() > Message-ID: > <CACZ_DoceeafEpu9wsyG0JPuAGUay0PR91xOZSwzrVy4BGZo1nQ(a)mail.gmail.com > > > Content-Type: text/plain; charset="iso-8859-1" > > There is significant interest in a cross-platform > file-launcher.[1][2][3][4] 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).[5][6] > 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 > capability? > > [1]: > > http://stackoverflow.com/questions/1856792/intelligently-launching-the-defa… > [2]: > > http://stackoverflow.com/questions/434597/open-document-with-default-applic… > [3]: > > http://stackoverflow.com/questions/1442841/lauch-default-editor-like-webbro… > [4]: > > http://stackoverflow.com/questions/434597/open-document-with-default-applic… > [5]: http://selenic.com/repo/hg-stable/file/2770d03ae49f/mercurial/ui.py > [6]: > http://selenic.com/repo/hg-stable/file/2770d03ae49f/mercurial/util.py >

9 12

breaking out of module execution
by Eric Snow April 27, 2012

April 27, 2012

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 function. 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 statement. 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. [1] 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: try: from _extension_module import * except ImportError: pass else: 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 * break # business as usual 3. module already imported under a different name: if "other_module" in sys.modules: exec("from other_module import *", globals()) break # module code here Thoughts? -eric [1] http://mail.python.org/pipermail/python-list/2011-June/1274424.html

22 53

sys.implementation
by Eric Snow April 26, 2012

April 26, 2012

In October 2009 there was a short flurry of interest in adding "sys.implementation" as an object to encapsulate some implementation-specific information [1]. Does anyone recollect where this proposal went? Would anyone object to reviving it (or a variant)? -eric [1] http://mail.python.org/pipermail/python-dev/2009-October/092893.html

7 16

Structured Error Output
by Bryce Boe April 26, 2012

April 26, 2012

Hi, 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 common format. 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? Thanks, Bryce Boe

7 11

Haskell envy
by Nestor April 25, 2012

April 25, 2012

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 negative numbers. Examples: 5,7,16,1,2 3,5,-1,8,12 I proposed this solution: from itertools import combinations, chain def array_test(arr): biggest = max(arr) arr.remove(biggest) 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 return False But then somebody else submitted this Haskell solution: import Data.List 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).

10 13

Re: [Python-ideas] Haskell envy (Terry Reedy)
by Hobson Lane April 25, 2012

April 25, 2012

> 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 > problem, > >> 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?

2 2

Re: [Python-ideas] Have dict().update() return its own reference.
by Xavier Ho April 21, 2012

April 21, 2012

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 dict(x).update(y) given x and y are both dict() instances. Cheers, Xav 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 > > cheers > lvh > > > > 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 > >

10 19

Have dict().update() return its own reference.
by Xavier Ho April 20, 2012

April 20, 2012

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

1 0

Providing a guarantee that instances of user-defined classes have distinct identities
by Max Moroz April 19, 2012

April 19, 2012

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: class Card(int): __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 existing code): "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."

7 11

Pythonect 0.1.0 Release
by Itzik Kotler April 13, 2012

April 13, 2012

Hi All, 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 Python. 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 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 pass-through: >>> "Hello World" -> print -> print <MainProcess:Thread-2> : Hello World <MainProcess:Thread-2> : Hello World Hello World >>> >>> 1 -> import math -> math.log 0.0 >>> 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 ] -> _**_ [1, 4] >>> True/False return values as filters: >>> "Hello World" -> _ == "Hello World" -> print <MainProcess:Thread-9> : Hello World >>> >>> "Hello World" -> _ == "Hello World1" -> print False >>> >>> 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 2 >>> Download Pythonect v0.1.0 from: http://github.com/downloads/ikotler/pythonect/Pythonect-0.1.0.tar.gz 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. Regards, Itzik Kotler | http://www.ikotler.org

3 4