Mailman 3 February 2014 - Python-ideas

Re: [Python-ideas] docs.python.org: Short URLs
by Markus Unterwaditzer Feb. 17, 2014

Feb. 17, 2014

And again i forgot to CC the list, my apologies. -------- Original Message -------- Subject: Re: [Python-ideas] docs.python.org: Short URLs Date: 2014-02-17 16:49 From: Markus Unterwaditzer <markus(a)unterwaditzer.net> To: Ryan Hiebert <ryan(a)ryanhiebert.com> On 2014-02-17 16:24, Ryan Hiebert wrote: > I'm not sure that just these URLs are going to be any more helpful > than what we currently have: > ``http://docs.python.org/3.2/library/functions.html#str`` [5] > Are we looking at adding separate pages for each function, to give > more in-depth details to function, or is it really just a redirect? > Ryan A redirect. Content-wise i don't propose any changes.

1 0

@partials = decorators
by Alex Rodrigues Feb. 16, 2014

Feb. 16, 2014

This is a really cool idea. I'm +1. The first time I learned about decorators the way that you pass them arguments was both very non-intuitive and seemed almost like a sneaky hack rather than an intended feature. # In my opinion this is more intuitive than the old way def annotate(msg, foo, *arg, **kwargs): print msg foo(*arg, **kwargs) @annotate("Addition") def func(a, b): print a + b #The old way def annotate(msg): def deco(foo): def wrapper(*args, **kwargs): print msg foo(*args, **kwargs) return wrapper return deco @annotate("Addition") def func(a, b): print a + b (Ironically I had a really hard time getting the "old" one put together correctly). This also very effectively simplifies a lot of closure cases. There is one thing I don't quite understand, is it necessary to explicitly state that some function is a continuation each time you add arguments? As I understand it, that would mean decorators with arguments have to be called by "@@deco(a, b)". This would actually help me out in a real world example at this very moment, which is currently really, really hard to do cleanly. I am using iPython notebook and I'm creating two histograms like so: #data is a pandas Series() objects data.hist() data.hist(log=True) In the notebook these are both reasonably skinny graphs but they stack on top of each other instead of side by side. I looked it up and that can be fixed like so: fig = plt.figure() ax1 = plt.subplot(121) ax2 = plt.subplot(122) data.hist(ax=ax1) data.hist(ax=ax2, log=True) This is pretty cumbersome to write out every time so I wanted a function that could just be called on arbitrary histograms like side_by_side(data1.hist(bottom=0.1, log=True), data2.hist(bins=10)). The problem is that I do not have the axes available when I call the function and once I pass the plots to the function they have already been evaluated and there is no way to add arguments retroactively. With the continuation syntax it would be amazingly easier: def side_by_side(plot1, plot2): fig = plt.figure() ax1 = plt.subplot(121) ax2 = plt.subplot(122) plot1(ax=ax1) plot2(ax=ax2) side_by_side((a)data.hist(), @data.hist(log=True)) #Technically the first one doesn't need to be a continuation, but whatever. tldr; I like it and see a decent number of applications. Also I'm wondering if you'd have to chain continuations @@a('arg1')('arg2')('arg3'). - Alex

2 1

A suggested feature for difflib
by Chris Rose Feb. 16, 2014

Feb. 16, 2014

Right now, any alternative SequenceMatcher implementation in difflib requires that the implementor also reimplement the diff formatting methods (unified_diff and context_diff). I propose something along these lines (patch to follow if the idea is sound): class Differ: def __init__(self, linejunk=None, charjunk=None, sequence_matcher_factory=SequenceMatcher): # and so on def compare(self, a, b): cruncher = self.sequence_matcher_factory(self.linejunk, a, b) # and so on The same general idea with unified_diff, ndiff, and context_diff Basically, there are two obvious points of extension in difflib: The formatting of the output opcodes, and the method used to find sequences. The latter is not easily extended while reusing the former, and I'd like to change that. Note that I'm asking because I'd like to do the work, not because I want someone else to do it. Is this a reasonable idea? -- Chris R. ====== Not to be taken literally, internally, or seriously. Twitter: http://twitter.com/offby1

2 1

Better repr() for sentinel objects
by Chris Angelico Feb. 15, 2014

Feb. 15, 2014

A common pattern, both in the stdlib and in user code, is the dedicated sentinel object to recognize an omitted argument: no_timeout = object() def get_data(source, timeout=no_timeout): if timeout is not no_timeout: source.set_alarm(timeout) return source.pop() This is a bit unclear in the function signature, as seen in help(): """ Help on function get_data in module __main__: get_data(source, timeout=<object object at 0x7f579fe53070>) """ The stdlib does this: """ Help on function create_connection in module socket: create_connection(address, timeout=<object object at 0x7fe52900b080>, source_address=None) """ # chomp docstring """ Help on function urlopen in module urllib.request: urlopen(url, data=None, timeout=<object object at 0x7fe52900b080>, *, cafile=None, capath=None, cadefault=False) """ # no docstring to chomp, actually It's not particularly useful to get the object's address. Proposal: A self-documenting Sentinel class which serves the exact same purpose. class Sentinel: def __init__(self, desc): self.desc = desc def __repr__(self): return "Sentinel(" + repr(self.desc) + ")" This can then be used just like object(), only it retains something for the benefit of its repr: no_timeout = Sentinel("No timeout") # Same function definition """ Help on function get_data in module __main__: get_data(source, timeout=Sentinel('No timeout')) """ I don't know how this interacts with Argument Clinic and C-written functions. If there's something that's being done for those that would make sentinels come out a particular way in their help() info, ideally this should be displayed the same way (or at least similarly). Thoughts? ChrisA

3 3

Re: [Python-ideas] if expensive_computation() as x:
by random832＠fastmail.us Feb. 15, 2014

Feb. 15, 2014

Isn't this whole concept just a way of sneaking in assignments-as-expressions? I'd almost say it would be preferable to _actually_ allow assignments as expressions [maybe with an alternate operator like := if we're too worried about people making a mistake in a condition], rather than invent a new kind of scope and come up with rules as to where this new syntax can be used.

3 4

combining two threads: switch statements and inline functions
by Bruce Leban Feb. 14, 2014

Feb. 14, 2014

What if we had the ability to write dictionaries with inline functions in them. def sample(i, op, j): switcher = {{ '-':: if i > j: return i - j else: return j - i;; '+':: return i + j;; }} return switcher[op]() Please don't pay attention to {{ :: ;; }} which would never be the actual syntax or what this code is doing (nothing useful) or whether i or j should be passed as parameters rather than closure. This is equivalent to: def sample(i, op, j): def diff(): if i > j: return i - j else: return j - i def add(): return i + j switcher = { '-': diff, '+': add, } return switcher[op]() I don't know if there's a good idea here, but I do know that this pattern of writing dispatchable functions like this is fairly common, just as the switch pattern is. There are some obvious problems, most notably that in the switch statement, the scope of the statements is the same as the enclosing scope while in this code, each function has it's own scope. Notwithstanding that, I thought it was an interesting enough idea to share. --- Bruce Learn how hackers think: http://j.mp/gruyere-security

9 20

a in x or in y
by Ram Rachum Feb. 14, 2014

Feb. 14, 2014

Hi, What do you think about adding this to Python: 'whatever a long string' in x or in y I've often wished for this because the current way is quite verbose: 'whatever a long string' in x or 'whatever a long string' in y We might add "and in" wwai\ dafsdfasdfasdfa while we're at it. Ram.

16 38

on colon ':', and some more
by spir Feb. 13, 2014

Feb. 13, 2014

Hello, This is not a proposal for change, rather a few reflexions I guess were worth being shared here, because this is a list where design questions about Python are debated. If you don't care, just press 'del'. I have always been puzzled by Python's usage of colons terminating block headlines. First, this does not match the overall noise-less design of the syntax; second, it compares weirdly with the absence of (required) semi-colons terminating instructions [1]. I stepped several times, in online articles, on vague evocations of "studies" supposed to "show" that this format is clearer to beginners, albeit each time without any reference to said studies [2]. Finally, I recently found what seems to be the actual story of ':' [3], telling that, according to _one_ non-programmer, colons should be added there to play the role of _introducing_ the following block, indented. This notion of _introduction_ endly clicked for me, making some sense. From a distinct perspective: another weird point is using '=' for assignment and '==' for equality [4]. In my view, the right assignment sign (rather: the sign to define a symbol, in general) is ':' precisely [5]. While thinking at syntax for a low-level language, I stepped on the special case of symbols which are labelled blocks (all targets of jumps/goto's, including procedures). In assembly and some other langs, they are usually written 'label:' or ':label:'. And indeed it is clear here that the label introduces the following block, with ':' obviously playing this introductory role. Why is it instead not obvious in Python [6]? Maybe the reason lies in the actual usage of colons, in fact in the actual headlines in python code. In assembly, one could have code looking like: jnz case-true ... (case false) ... case-true: ld rax result ... Here the label is a kind of title line for the block. There is a similar usage in python: def average (numbers): sum = numbers.sum() return sum / len(numbers) Again, here the headline is a kind of title. However, when the block is a control statement if/else, for, while, then the headline is rather an _articulation_ in the discourse: for n in numbers: print(n) while more: go_on() if cond: this() else that() From yet a third perspective: for a high-level language this time, which otherwise uses indented blocks like Python, I was searching for a nice syntax for single-line control blocks [7]. As in python's: for n in numbers: print(n) while cond: go_on() if cond: this() else: that() I first thought at using 'do': for n in numbers do print(n) while cond do go_on() if cond do this() else do that() if cond do this() else do that() which is very nice, I guess. [8] [9] Then, for whatever reason, came to my mind the following: for n in numbers, print(n) while cond, go_on() if cond, this() else, that() if cond, this() else, that() Just using ',', a bare comma. [10] It seems to me that this usage of the comma matches its meaning in ordinary (written) discourse. And there is indeed a question of discourse articulation. Here, of logical articulation, precisely. Maybe this is why, finally, Python's usage of the colon does not meaningfully click as it should: because most of the time it's not a question of a title introducing a block, but of discourse articulation; where ',' would do a better job, maybe. Note: I don't mean this post to introduce (sic!) endless violent discussions (as often, on such topics); and I won't reply if this happens. I wished to share a different view on the topic, for people who care about meaningful syntax. d [1] I think the parser should not an accept optional ';' at end of line. This alternative is never used, and, if it were, would only trouble novice programmers (What the heck does ';' mean? nothing...) [2] Which always made me laugh, knowing how supposed studies in the fields of psychology or sociology usually are highly contestable; so what about programmers or CS professionals driving such studies? [3] Someone will surely have a pointer ;-) [4] Forgetting ':' and using '=' for equality are my favorite syntax errors in Python. I seem to still love them, still after long years of frequentation. [5] Python uses it in dict notation, which is nice. But dict key->value links could use '->', while for symbol defs ':' or '↔' or '⟷' would be perfect. (Actually, the double head arrow is ideal, but unfortunately there is no such key on common keyboards.) [6] Not obvious at all, for me, instead I had to be told about it, I mean to read about it. Maybe it is non-obvious for most people, since this argument does not seem to come up in discussions about ':'. [7] The actual keywords are different, also the syntactic schema for procedure call, but I will use Python's syntax here in examples for readability. [8] However, syntax highlighting for keywords would help, here. [9] Not invent here: Lua uses 'do'; however also for multiline blocks, and only for loops, not for if/else. [10] This is even better in the case of this lang project, where like in Lisp collection items are just separated by spaces: no commas. Thus, the comma has a clear and single role in syntax.

4 4

Re: [Python-ideas] except expression
by Paul Moore Feb. 13, 2014

Feb. 13, 2014

On 12 February 2014 21:02, Ram Rachum <ram.rachum(a)gmail.com> wrote: > I realize that this is a big change and that most people would be opposed to > this... But I guess I just wanted to share my idea :) This was discussed a while ago on the list. I can't find the thread right now, but you may want to search the archives. Paul PS Looks like posting via google groups not only breaks filtering and threading, it also breaks reply-all (as I can't post to the google group). Could you please post direct to the group rather than through the google groups interface? Thanks.

2 2

async: switch_to_loop and loop_affinity
by David Foster Feb. 12, 2014

Feb. 12, 2014

There has been much talk of the use of async libraries (such as Tulip) within the general programming community to avoid the "christmas tree" pattern of code indentation in code that uses a lot of callbacks. For example, consider the following callback-based code: def duplicate_file_async(filepath, done): def exists_async(does_exist): if not does_exist: done(False) return def entire_file_read(contents): if not contents: done(False) return def file_written(success): done(success) write_entire_file_async(filepath + ' copy', contents, file_written) read_entire_file_async(filepath, entire_file_read) exists_async(filepath) This code be rewritten in Tulip as: @async.coroutine def duplicate_file_async(filepath): if not yield from exists_async(filepath): return False contents = yield from read_entire_file_async(filepath) if not contents: return False return yield from write_entire_file_async(filepath + ' copy', contents) Much more clear, no? Tulip, however, does not appear to address a slightly different problem I run into where I need different parts of the same conceptual function to run on specific *different* threads. Consider the following code which needs different parts executed on a UI thread, database thread, and background thread: def tree_node_clicked(tree_node): print('Clicked: ' + repr(tree_node)) def db_task(): db_node = fetch_node_from_db(tree_node) def process_node(db_node): tree_node.set_contents(db_node.contents) # (done) if db_node is not None: def bg_task(): db_node = fetch_node_from_internet(tree_node.url) def db_task(): insert_into_db(db_node) ui_call_soon(process_node, db_node) db_call_soon(db_task) bg_call_soon(bg_task) else: ui_call_soon(process_node, db_node) db_call_soon(db_task) Imagine if you could write this function like the following: ui_loop = ... db_loop = ... bg_loop = ... @async.coroutine def tree_node_clicked(tree_node): print('Clicked: ' + repr(tree_node)) yield from switch_to_loop(db_loop) db_node = fetch_node_from_db(tree_node) if db_node is not None: yield from switch_to_loop(bg_loop) db_node = fetch_node_from_internet(tree_node.url) yield from switch_to_loop(db_loop) insert_into_db(db_node) yield from switch_to_loop(ui_loop) tree_node.set_contents(db_node.contents) Or even better: If you created a decorators like @loop_affinity(*_loop) that automatically called switch_to_loop(...) if the current event loop wasn't correct, you could even write the following even-more simplified version: @async.coroutine def tree_node_clicked(tree_node): print('Clicked: ' + repr(tree_node)) db_node = yield from fetch_node_from_db(tree_node) if db_node is not None: db_node = yield from fetch_node_from_internet(tree_node.url) yield from insert_into_db(db_node) yield from tree_node.set_contents(db_node.contents) @async.loop_affinity(db_loop) def fetch_node_from_db(...): ... @async.loop_affinity(bg_loop) def fetch_node_from_internet(...): ... @async.loop_affinity(db_loop) def insert_into_db(...): ... @async.loop_affinity(ui_loop) def set_contents(...): ... Wouldn't that be just grand? I have prototyped switch_to_loop(...) successfully in Tulip, albeit with a race condition I was unable to isolate. How about some equivalent to switch_to_loop(...) and loop_affinity(...) in a future version of Tulip? -- David Foster http://dafoster.net/

4 3