Mailman 3 November 2013 - Python-ideas

Improving Clarity of re Module
by Alex Seewald 29 Nov '13

29 Nov '13

For a match object, m, m.group(0) is the semantics for accessing the entire span of the match. For newcomers to regular expressions who are not familiar with the concept of a 'group', the name group(0) is counter-intuitive. A more natural-language-esque alias to group(0), perhaps 'matchSpan', could reduce the time novices spend from idea to working code. Of course, this convenience would introduce a bit of complexity to the codebase, so it may or may not be worth it to add an alias to group(0). What do people think? -- Alex Seewald

12 16

Improving Clarity of re Module
by Popa Claudiu 28 Nov '13

28 Nov '13

On 11/27/2013 11:06 AM, Ned Batchelder wrote: >* While we're at it, how can it be that we haven't improved the __repr__ after all *>* these years? *>>* >>> m = re.search("[ab]", "xay") *>* >>> m *>* <_sre.SRE_Match object at 0x10a2ce9f0> *>>* _sre? SRE_Match? huh? :) *>> * --Ned.* Actually, it's fixed in Python 3.4, see http://bugs.python.org/issue17087. Python 3.4.0b1 (default:9c7ab3e68243, Nov 26 2013, 19:42:06) [GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd8 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.search('aaa', 'aaab') <_sre.SRE_Match object; span=(0, 3), match='aaa'> >>>

1 0

Update the required C compiler for Windows to a supported version.
by Vernon D. Cole 28 Nov '13

28 Nov '13

Before anyone starts flaming me about "off topic" -- I already know that my suggestion is going to be different from what is usually discussed on this group. I may not write often, but I am a faithful reader (a.k.a. lurker). Please bear with me. I am not aware of any other place where what I am about to say is _on_ topic. ... Yesterday, I set out to try installing a medium-size django application on Windows. It did not go well. It is now 24 hours later -- and I have tried many things. The problem was that "pip" needed to compile a module. There was no C compiler on the machine. After 24 hours of web searching and trying many things, I have come to the following conclusion: I cannot compile a Python extension module with any Microsoft compiler I can obtain. My new Windows 8.1 computer is running Visual Studio 2013 -- which would be fine if I wanted to compile my own Python interpreter, I suppose. I spent most of the day trying to find a working Visual Studio 2008 or C++ 7.1 compiler. The only things I could find to download were patches for Visual Studio 2010. I tried several variations to install it on my old Windows 7 laptop -- all to no avail. May I humbly suggest that Python 3.4 be released using Microsoft Visual Studio Express 2013 for Windows Desktop<http://www.visualstudio.com/en-us/downloads>, a (free) compiler which will actually run on the current version of Windows? That's the Python Idea that I am requesting.

6 7

Using yield inside a comprehension.
by Jonathan Slenders 27 Nov '13

27 Nov '13

Where do I find the PEP that describes that the following statement assigns a generator object to `values`? values = [ (yield x) for x in range(10) ] I assume it's equivalent to the following: values = (x for x in range(10)) The reason for asking this is that I see no point in using the first syntax and that the first has another meaning in Python 2.7, if used inside a function.

4 8

Re: [Python-ideas] Python-ideas Digest, Vol 84, Issue 94
by Alex Seewald 27 Nov '13

27 Nov '13

As MRAB noticed, my suggested alias 'matchSpan' is flawed because the word span is already in use. As spir pointed out, 'snippet' would be a better name for the alias to group(). >However, isn't it group() alone, without 0? Both group() and group(0) have the same effect. >> Of course, this convenience would introduce a bit of complexity to the >> codebase, so it may or may not be worth it to add an alias to group(0). >> What do people think? >At first sight, does not seem that complicated (also, the code exist for >group()). How clear is the existing implementation? The existing implementation is clear enough and the alias would not add much complexity. I meant that any alias is a source of complexity and the tradeoff at hand is for convenience. On 26 November 2013 17:52, <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 > https://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. Re: Using yield inside a comprehension. (Nick Coghlan) > 2. Improving Clarity of re Module (Alex Seewald) > 3. Re: Improving Clarity of re Module (MRAB) > 4. Re: Improving Clarity of re Module (spir) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 27 Nov 2013 08:01:46 +1000 > From: Nick Coghlan <ncoghlan(a)gmail.com> > To: Jonathan Slenders <jonathan(a)slenders.be> > Cc: python-ideas(a)python.org > Subject: Re: [Python-ideas] Using yield inside a comprehension. > Message-ID: > < > CADiSq7dh9HYQDPHnSBMkc-o-aY9KDnjd4QmNRGga4TJBy0TpCA(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > On 27 Nov 2013 01:35, "Jonathan Slenders" <jonathan(a)slenders.be> wrote: > > Futher, there is a really weird constructs possible: > > > > list((yield x) for x in range(10)) > > [0, None, 1, None, 2, None, 3, None, 4, None, 5, None, 6, None, 7, None, > 8, None, 9, None] > > > > > > It's a logical consequence from the translation, but I don't get the > point. > > Can't we create a local namespace, without wrapping it in a function? > > That was the original implementation I tried, and it turned out to be > inordinately difficult to get the semantics right for lambda expressions > that referenced iteration variables from inside the comprehension. There > are also some ugly edge cases involving the locals() builtin that would > need to have their semantics defined. Switching to a full lexical scope > instead turned out to be much easier to implement while still providing > closure semantics that matched those of generator expressions, so that's > what I ended up implementing. This approach also resolved the "How does > locals() work in a 3.x comprehension?" question in favour of making it work > the same way it does in a generator expression. > > As others have noted, this approach of using an implicit function > definition also results in the behaviour of yield expressions inside > comprehensions being entirely consistent with their behaviour inside def > statements and lambda expressions - it turns an ordinary function into a > generator function. Is this particularly useful? Not that I've seen (while > you can do some kinda neat one-liner hacks with it, they're basically > incomprehensible to the reader). It's just a natural consequence of making > comprehension semantics more consistent with those of generator expressions > (which were already consistent with nested def statements and lambda > expressions), and there's no compelling justification to disallow it. > > Regarding the PEP question, there's no dedicated PEP for the change, just a > line item in PEP 3100 to make comprehensions more like generator > expressions by hiding the iteration variable. There's probably a thread or > two on the old python-3000 list about using a full function scope to do it, > though (I seem to recall posting about it after my original pseudo-scope > based approach failed to handle closures properly). > > Cheers, > Nick. > > > > > > > > > > > 2013/11/26 Andrew Barnert <abarnert(a)yahoo.com> > >> > >> On Nov 26, 2013, at 6:32, Oscar Benjamin <oscar.j.benjamin(a)gmail.com> > wrote: > >> > >> > On 26 November 2013 13:54, Jonathan Slenders <jonathan(a)slenders.be> > wrote: > >> >> > >> >> Where do I find the PEP that describes that the following statement > assigns > >> >> a generator object to `values`? > >> > > >> > I don't think there was a PEP for this but it's a consequence of the > >> > change to binding in list comprehensions introduced in Python 3.x > >> > which is mentioned here: > >> > > > http://python-history.blogspot.co.uk/2010/06/from-list-comprehensions-to-ge… > >> > > >> > Essentially this: > >> > > >> >> values = [ (yield x) for x in range(10) ] > >> > > >> > Translates to the following in Python 2.x: > >> > > >> > _tmp = [] > >> > for x in range(10): > >> > _tmp.append((yield x)) > >> > values = _tmp > >> > > >> > However in 3.x it translates to something like: > >> > > >> > def _tmpfunc(): > >> > _tmp = [] > >> > for x in range(10): > >> > _tmp.append((yield x)) > >> > return _tmp > >> > values = _tmpfunc() > >> > > >> > This change was made to prevent the comprehension variable from > >> > leaking to the enclosing scope, but as you say if the code is nested > >> > in a function then it affects which function contains the yield > >> > statement and the presence of a yield statement radically alters the > >> > behaviour of a function. So in 2.x the enclosing function must become > >> > a generator function. However in 3.x the function that is supposed to > >> > implement the list comprehension is changed into a generator function > >> > instead. > >> > > >> > $ python3 > >> > Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 > >> > 32 bit (Intel)] on win32 > >> > Type "help", "copyright", "credits" or "license" for more information. > >> >>>> values = [(yield x) for x in range(10)] > >> >>>> values > >> > <generator object <listcomp> at 0x00E24508> > >> >>>> def _tmpfunc(): > >> > ... _tmp = [] > >> > ... for x in range(10): > >> > ... _tmp.append((yield x)) > >> > ... return _tmp > >> > ... > >> >>>> values = _tmpfunc() > >> >>>> values > >> > <generator object _tmpfunc at 0x00E2F7B0> > >> > > >> >> I assume it's equivalent to the following: > >> >> values = (x for x in range(10)) > >> > > >> > It will yield the same values but it will also build a list of Nones > >> > and attach it to StopIteration: > >> > >> Unless you call .send on it, in which case it'll build a list of the > values you send it and attach _that_ to StopIteration, of course. > >> > >> So I suppose you could use it as a coroutine version of the list > function. Except that the number of values it takes is specified on the > wrong end. > > > > > > > > _______________________________________________ > > Python-ideas mailing list > > Python-ideas(a)python.org > > https://mail.python.org/mailman/listinfo/python-ideas > > >

1 0

Re: [Python-ideas] Replacing the if __name__ == "__main__" idiom (was Re: making a module callable)
by Skip Montanaro 26 Nov '13

26 Nov '13

> I still don't think the current idiom is problematic, so I'm -0.8 on > the whole thing :-) I'm with Antoine. I don't find it particularly onerous to type (how often do you start a new program/script from scratch anyway?), and if it was a big enough barrier, I'd capture the keystrokes in an Emacs macro (including skeletal main and usage functions, and corresponding imports of sys and os modules). I trust vim users could do something similar. Skip

1 0

making a module callable
by Gregory P. Smith 26 Nov '13

26 Nov '13

While I don't ordinarily endorse this use case it'd be nice not to require hacks involving sys.modules monkeying such as: https://github.com/has207/flexmock/pull/89 specifically: https://github.com/has207/flexmock/commit/bd47fa8189c7dff349de257c0e061b9fc… to make a module callable. This obviously touches on the larger ideas of what is a module vs a class and why are they different given that they're "just" namespaces. (sorry. not offering ideas myself just hoping others have them) -gps

19 49

Dart-like method cascading operator in Python
by Perešíni Peter 26 Nov '13

26 Nov '13

Recently I fell in love with Dart method cascading operator .. to the degree that I find it really convenient and I am missing it in the Python. The cascade operator myObj ..setX(5) ..y=6 is the syntactic sugar equivalent of the following: tmp = myObj tmp.setX(5) tmp.y=6 This can be used to greatly simplify instantiating objects and can also enable creating domain specific languages in Python. In particular, we can make this much more powerful in Python (as opposed to Dart) because Python recognizes scope by indentation and therefore it would be possible to do something like gnuplot.newPlot() ..set("xrange [0:5]") ..set("yrange [0:20]") ..newPlot() ..addSeries("Linear", [1,2,3]) ..addSeries("Quadratic", [1,4,6]) ..run() or template = HtmlTemplate() ..head() ..script(src="xyz") ..body() ..div(class="main") ..paragraph("I am the first paragraph") ..paragraph("I am the second paragraph") Note that this is strictly better than method chaining, e.g. template = MyObject().setX(1).setY(2) because a) method chaining is hard to write on multiple lines, the only two options are template = MyObject() \ .setX(1) \ .setY(2) which is fragile (explicit line continuation is discouraged in Python) or (template = MyObject() .setX(1) .setY(2)) which looks weird. b) method chaining cannot take advantage of multiple scoping, e.g. the only way to write Gnuplot example is (Gnuplot() .set("...") .newPlot() .addSeries() .addSeries() *.endPlot()* .run() ) with added method *endPlot()* to the Plot class. Moreover, Plot class now needs a direct reference to its parent (e.g. Gnuplot) so it can return its reference. This adds unnecessary cyclic dependencies. c) method chaining needs specialized API, e.g. each method needs to return self d) method chaining cannot be used with attributes, e.g. there is no equivalent to obj = MyObject() ..x=1 ..y=2 Note that this proposal is different from "in" statement [ https://mail.python.org/pipermail/python-ideas/2012-November/017736.html] in the sense that this proposal does not bring anything new into the scope, e.g. obj1 ..obj2 ..x = y translates to tmp1 = obj1 tmp2 = obj2 tmp2.x = y or (simplified) obj1.obj2.x = y no matter if obj2 or obj1 contains variable y. In my opinion, such cascading operator would greatly help creating domain specific languages APIs in Python which are 1) easily readable. It is better than being lost in a repetitive stream of lines looking like obj.x(), obj.y(), obj.z(). Note that repetitive stream of lines (apart from being too verbose) also introduces a possibility of mistyping the name of the object 2) easy to implement (no special API considerations as returning self from each function call) What do you think? Peter

13 41

CC0 for Python Documentation
by anatoly techtonik 24 Nov '13

24 Nov '13

Adding python-legal-sig(a)python.org to CC. Please, follow up on python-ideas. CC0 is a way to free public works from legal burden: https://creativecommons.org/about/cc0 Here is the reasoning why people do this: https://creativecommons.org/tag/cc0 At first I thought about CC-BY, but then realized that no authorship is respected. As you may see here - http://docs.python.org/3/copyright.html - PSF is the sole owner of the docs with no reference to the work of people who have contributed. No wonder that there is not much motivation to collaborate. So, given all the above I'd like to propose using CC0 for Python documentation. Benefits: - you don't need to ask PSF for permissions and clarification of your rights - you can still count and credit contributions regardless of is there is copyright signature of the owner or not - this also makes it clear that docs are from community for community, you can fork and enhance - you don't have to sign exclusive CLA to make edits to documentation - you don't have to supply huge license file if you copy/paste relevant pieces from the docs Now the questions that needs to be answered. PSF is made to protect Python. How sitting on top of Python documentation copyright helps it to do so? What are consequences if Python Documentation is released with CC0 license? Do you think it will hurt Python? If yes, then how? Do you think that current CLA is impediment for contributing patches to documentation? Do you think that using CC0 will increase contributions and tools for working with Python docs? Do you think that current situation is better? Do you think that CC-BY is better? Do you think that CC-BY-SA is better? It looks like a poll. Maybe PSF should create one? -- anatoly t.

4 8

solution to cross-platform path handling problems
by anatoly techtonik 24 Nov '13

24 Nov '13

I will talk about separating "mount"s and "path" concepts in path handling. On the great talk about writing cross-platform applications back in 2010 there is a good point about Python's cross-platform abstraction to path issues. http://clanmills.com/files/dist/doc/cross_platform.html#python-batteries-in… Recent noize around new pathlib and my own experience with os.path made me change my mind that Python has a convenient library for cross-platform path handling. It is much better than dealing with slashed strs (true), but there are still hidden issues (that I can not even summarize, because I don't know what tracker query should I run to get it). While criticizing "pathlib" to see what I dislike about it, I realized that there is a lot of ambiguity in the world of filesystem/resource paths. Every platform-specific path library fails, because from one side people don't know differences between all operating systems, probably because they don't want, don't have time or info. On the other side people need to write cross-platform apps. "pathlib" does a good job by providing PEP with info, but I think that architecturally it doesn't solve the problem of path handling complexity. Syntax sugar - yes, explicit approach - yes, time savings - no, more readable code - "no > yes", code that frees you from thinking how "these three lines" will work on MacOS/Unix/Windows - no. The root of the problem is in traditional "relative" vs "absolute" path approach. Take "Definitions" from PEP 428. """ 1. All paths can have a drive and a root. For POSIX paths, the drive is always empty. 2. A relative path has neither drive nor root. 3. A POSIX path is absolute if it has a root. A Windows path is absolute if it has both a drive and a root. A Windows UNC path (e.g.\\host\share\myfile.txt) always has a drive and a root (here, \\host\share and \, respectively). 4. A path which has either a drive or a root is said to be anchored. Its anchor is the concatenation of the drive and root. Under POSIX, "anchored" is the same as "absolute". """ Good decomposition and problem overview, but hardly a solution or a "correct" representation as I see it. All terminology above can be reduced to just two cross-platform terms: "mount point" and "path". "path" is always relative to "mount point". Either can be missing. "mount point" is system-dependent. 1. All paths may have the mount point. 2. All paths without mount point are relative. 3. Default mount point for POSIX to make path absolute is '/'. Default mount point on Windows is current drive (e.g. 'c:/'), or UNC server address (e.g.\\host\). 4. Any (absolute?) path may be the mount point itself 5. path without mount point is called "relative" I don't know that should be API for that, but I'd be interesting to try it. One of the reasons I want to do this terminology is that semantically I do work more with URL paths than with file system paths and I don't see difference between them. When I move application from www.com site root to some www.com/endpoint, my app doesn't stop working, because it is written to work with any www.com/endpoint - not just with absolute paths that point to site root. I think that is the value that Python can provide to help build apps that are architecturally more "correct" and system-independent. -- anatoly t.

2 1