Mailman 3 July 2012 - Python-ideas

Re: [Python-ideas] Where has packaging gone?
by Michele Lacchia 22 Jul '12

22 Jul '12

> > Thoughts attached. > Yeah that one is great! :) And true. No, the distutils2 project continues and is still being actively > developed. (distutils2 *is* packaging - the name on PyPI is just > different from the name that will be used when it is added to the > standard library). Bento is a project that aims to tackle part of > distutils that distutils2 hasn't really looked at yet: creating a more > flexible build system (or, more accurately, making it easier to hook > into *existing* build systems rather than defining yet another one). Ok. Now the distinction is clear. Good to hear disutils2 is still actively developed. Those PEPs are *already* standards and are actively supported by > external projects today. I just found the wheel project: https://bitbucket.org/dholth/wheel It tries to implement those standards by patching distribute and pip. I run the demo and I think the resulting package format is just amazing. In a nutshell is a binary format (extensions get compiled) which in my opinion is really flexible. I hope it will become standard and will be integrated in the major software someday.

1 0

__sort__ special member
by David Townshend 22 Jul '12

22 Jul '12

I was quite surprised to find that nobody seems to have suggested this before, because it seems like an obvious idea. Basically, add a special method __sort__ which, if specified, is used when sorted() is called. I can think of two immediate use cases: 1. When an object wants sorted() to return something other than a list, e.g. dict.__sort__ could return an OrderedDict. 2. When there is a more efficient method of sorting a specific sequence. E.g. sorting a range object should be trivial. Is there some obvious reason why nobody has suggested this before? Is it worth pursuing? David.

7 10

'' in 'abc' == True
by anatoly techtonik 21 Jul '12

21 Jul '12

I've just spotted inconsistency between string and lists handling: >>> '' in 'abc' True >>> '' in 'abc'.split() False >>> [] in ['a', 'b', 'c'] False Why strings here behave differently than other sequence types? Is that by design?

10 16

Introduce some obvious way to encode and decode filenames from Python code
by Sven Marnach 18 Jul '12

18 Jul '12

Currently, there is no obvious way to encode a filename in the default filesystem encoding. To pipe some filenames to the stdin of a subprocess, I effectively used encoded_name = file_name.encode(sys.getfilesystemencoding()) which mostly worked. There are cases where this fails, though: on Linux with LANG=C and filenames that contain non-ASCII characters, for example, or in any situation where the default filesystem encoding can't decode a filename. The correct way to do this seems to be something like if sys.platform == "nt": errors = "strict" else: errors = "surrogateescape" encoded_name = file_name.encode(sys.getfilesystemencoding() errors=errors) I think there should be (1) some documentation on the issue and (2) a more obvious way to do encode filenames. 1. The most useful reference I could find in the docs is http://docs.python.org/dev/c-api/unicode.html#file-system-encoding and there is a short paragraph at http://docs.python.org/dev/library/os.html#file-names-command-line-argument… The filename encoding applies to basically all Python library functions (including built-ins like `open()`) and should probably be documented at a more prominent spot. The "surrogateescape" error handler isn't mentioned here http://docs.python.org/dev/howto/unicode.html#unicode-filenames 2. There should be some way to access the C API functions for decoding and encoding filenames from Python. I don't have a good idea how to do this – maybe by adding a meta-encoding "filesystem", or by adding functions to the standard library. Did I miss something? Any thoughts? Cheers, Sven

8 13

Where has packaging gone?
by Nick Coghlan 16 Jul '12

16 Jul '12

(the list address on the original email I replied to was broken) On Mon, Jul 16, 2012 at 6:55 PM, Michele Lacchia <michelelacchia(a)gmail.com> wrote: > Hi, > I read this: > http://www.gossamer-threads.com/lists/python/dev/992979 > > but at the end nobody posted to it anymore. I would like to know what will > now happen, since as far as I understood, the development of packaging > has stopped and Bento (David Cournapeau library) has appeared. No, the distutils2 project continues and is still being actively developed. (distutils2 *is* packaging - the name on PyPI is just different from the name that will be used when it is added to the standard library). Bento is a project that aims to tackle part of distutils that distutils2 hasn't really looked at yet: creating a more flexible build system (or, more accurately, making it easier to hook into *existing* build systems rather than defining yet another one). (In fact, the lack of attention to the build system flaws is one of the big reasons distutils2/packaging was deemed unready for stdlib inclusion in 3.3) > So what will happen now? Packaging will continue the development? Or > will be Bento replace it? Personally I don't care which tool will become > standard, > but I do feel the need for a standard to be created. The point of having documented standards in PEP form is that there can (and will) be multiple projects that produce and consume those standard formats. > - PEP 345 (http://www.python.org/dev/peps/pep-0345/) > - PEP 376 (http://www.python.org/dev/peps/pep-0376/) > - PEP 386 (http://www.python.org/dev/peps/pep-0386/) Those PEPs are *already* standards and are actively supported by external projects today. One key missing piece is standard library support, which the packaging module is intended to provide. However, it was deemed that the project was not quite mature enough for 3.3, thus it will continue to be developed (with a faster iteration cycle) as distutils2, with a view to including a more mature version of the API for 3.4. This will likely take the form of additional PEPs that more clearly define what is to be added and *why* it is being added, with one focus being making it easier to build additional tools that produce and consume metadata in the standard formats, rather then being a comparatively unwieldy monolithic system like the original distutils. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

Where has packaging gone?
by Michele Lacchia 16 Jul '12

16 Jul '12

Hi, I read this: http://www.gossamer-threads.com/lists/python/dev/992979 but at the end nobody posted to it anymore. I would like to know what will now happen, since as far as I understood, the development of packaging has stopped and Bento (David Cournapeau library) has appeared. So what will happen now? Packaging will continue the development? Or will be Bento replace it? Personally I don't care which tool will become standard, but I do feel the need for a standard to be created. So I would like to point out that to me these three PEPs seem really important, and hope that will be taken into account: - PEP 345 (http://www.python.org/dev/peps/pep-0345/) - PEP 376 (http://www.python.org/dev/peps/pep-0376/) - PEP 386 (http://www.python.org/dev/peps/pep-0386/) What do you think about all this? Regards, Michele Lacchia

1 0

Syntax for defining parametric decorators
by Mike Graham 12 Jul '12

12 Jul '12

A common stumbling block for new users is writing decorators that take arguments. To create a decorator like @timesn(n) def f(y): ... We write code like def timesn(n) def decorator(f): def inner(y): return n * f(y) return inner return decorator which confuses many users and can be a handful to type. I wonder if it would be clearer for people to write def timesn(n)(f): def inner(y): return n * f(y) return inner which is more concise and looks a lot more like a non-parametric decorator someone might have written already. The syntax is mostly self-explaining and could potentially be useful in other contexts. There exist tools like the decorator library to try to simplify this already, but in my experience they mostly serve to confuse people using decorators for the first time more. One thing I didn't specify was whether `n` was nonlocal or not and the behavior of something that keeps and reuses timesn(some_specific_n) multiple times. Does anyone think a feature like this may be useful? Regards, Mike

16 30

Explanation on how to search the archives
by Christopher Reay 12 Jul '12

12 Jul '12

I have heard two suggestions on how to search the achives one is: If you have time to post and discuss an idea, you have time to search gmane.comp.python.ideas at search.gmane.org and perhaps find out why not to bother posting. And the Other: It's more a matter of working out how to point Google (or the search engine of your choice) at the archives in a useful way. In this case: https://www.google.com/search?q=inurl%3Apython-ideas%20site%3Amail.python.o… This is great information. Is there a page suggesting how to search archives effectively? Whilst much of that skill is generic, and clear concise explanation of what is expected from the polite user of the mailing list (and other Python mailing lists) could help. A link to that page could be put in the footer of the python mailing list emails.. and voila, a very easy thing to reference and get righteous about people not having read. What do you think? Christopher -- Be prepared to have your predictions come true

4 5

itertools recipes: why not add them to the stdlib *somewhere*?
by Jürgen A. Erhard 10 Jul '12

10 Jul '12

I just now ran into (since learning about the recipes) having use for a recipe (then I found out that I can't use it anyway, but that's a different thing) So... I consider it very strange and annoying that there's this code. Ready to use. But you have to copy-and-paste it into your code *somewhere* instead of easily importing it. As to the "it makes using Python harder to learn", I beg to differ: an addition to the *language* (like, say, metaclasses) *can* make it more complicated. But additions to the stdlib? What about "batteries included"? Not a motto anymore (I heard rumors, so maybe that's the case) Putting these in some official(!) iterutils (or name it what you want) package would be a solution for so many people. Yes, not everyone needs grouper's current functionality. But for the many who do, it'd be there already. And someone thought those recipes are useful, didn't you? So why not make them more easily available? And then there's Alex Martelli at http://stackoverflow.com/a/1641242/238406, and I agree with him wholeheartedly. Bye, J

12 14

Re: [Python-ideas] Syntax for defining parametric decorators
by Haoyi Li 09 Jul '12

09 Jul '12

I admit calling it all at once would be very strange, but i still think the "call me three times to get result" comes across waaaay more clearly than with nested defs. Multiple arguments in one list is about the same, it's true, until you really need the curried version, like in decorators, then you end up with the nasty tower-of-defs which sparked this discussion. Regarding "not knowing how many times it should be called", the idea is that you break it up when you have a meaningful, reusable unit. That's to say you wouldn't do a def f(a)(b)(c) Unless f f(1) f(1)(2) f(1)(2)(3) Are all meaningful, useful functions. Doesn't happen very often, granted, but when it does (e.g. for decorator factories and decorators) it'd be nice to have. I view curried defs like default parameters: Doesnt add anything that cant already be done (you can emulate default args with telescoping methods) but cuts boilerplate, makes things clearer and overall nice to have. Whether it's nice enough to justify extra syntax is of course open for debate. From: Stephen J. Turnbull Sent: 7/9/2012 1:48 AM To: Haoyi Li Cc: Nick Coghlan; Python-Ideas Subject: Re: [Python-ideas] Syntax for defining parametric decorators Haoyi Li writes: > However, I think that in the general case, being able to define > curried functions in one line, a.l.a. [...] > def f(a)(b)(c) > > looks much more similar to how you would use it: > > f(1)(2)(3) I don't understand. I wouldn't use it that way! I would think if that were common usage, and the curried form only occasional, def f(a,b,c): pass f(1,2,3) would be more natural in Python (and use functools.partial for the occasional currying). Presumably if you were using this syntax, you'd be doing something more like def f(a)(b)(c): pass def g(h, x): h(x) g(f(1)(2), 3) which doesn't look very nice to me, nor do I find the def to be a particularly intuitive way of reminding me that the proper usage is a call of a function in curried form (specifically, I would not be reminded of whether the expected curried form is a 1st-, 2nd-, or 3rd-order function). I also suppose that you wouldn't be able to do def f(a)(b)(c): pass def g(x,y): pass h(f(1)) h(g) (ie, without LBYL or EAFP constructs in h, which would simply be throwing the complexity into the caller's backyard). Even though def bar(a)(b): pass def baz(x): pass quux(bar(1)) quux(baz) would work fine. So to me, there may be something in this syntax, but my initial impression is that it's trying to turn Python into something it's not.

1 0