Mailman 3 May 2012 - Python-ideas

PEP for Python folder structure
by Armin Wieser May 30, 2012

May 30, 2012

Hi, I would like to write a PEP about folder structure in python projects. You will think that there is no need for that, because everything is documented (package, module, setuptools). But it should contain something like [0]. If you aren't into those concepts, never have pushed some package to pypi, and you only have written some scripts, it's hard to find out how to structure your folders. Therefore i think a PEP would be a great way to show how you can do it. What do you think about it?… [View More]

5 4

a simple namespace type
by Eric Snow May 30, 2012

May 30, 2012

Below I've included a pure Python implementation of a type that I wish was a builtin. I know others have considered similar classes in the past without any resulting change to Python, but I'd like to consider it afresh[1][2]. class SimpleNamespace: """A simple attribute-based namespace.""" def __init__(self, **kwargs): self.__dict__.update(kwargs) # or self.__dict__ = kwargs def __repr__(self): keys = sorted(k for k in self.__dict__ if not k.startswith(… [View More]'_')) content = ("{}={!r}".format(k, self.__dict__[k]) for k, v in keys) return "{}({})".format(type(self).__name__, ", ".join(content)) This is the sort of class that people implement all the time. There's even a similar one in the argparse module, which inspired the second class below[3]. If the builtin object type were dict-based rather than slot based then this sort of namespace type would be mostly superfluous. However, I also understand how that would add an unnecessary resource burden on _all_ objects. So why not a new type? Nick Coghlan had this objection recently to a similar proposal[4]: Please, no. No new just-like-a-namedtuple-except-you-can't-iterate-over-it type, and definitely not one exposed in the collections module. We've been over this before: collections.namedtuple *is* the standard library's answer for structured records. TOOWTDI, and the way we have already chosen includes iterability as one of its expected properties. As you can see he's referring to "structured records", but I expect that his objections could be extended somewhat to this proposal. I see where he's coming from and agree relative to structured records. However, I also think that a simple namespace type would be a benefit to different use cases, namely where you want a simple dynamic namespace. Making a simple namespace class is trivial and likely just about everyone has written one: "class Namespace: pass" or even "type('Namespace', (), {})". Obviously the type in this proposal has more meat, but that's certainly not necessary. So why a new type? The main reason is that as a builtin type the simple namespace type could be used in builtin modules[5][6][7]. Thoughts? -eric [1] http://mail.python.org/pipermail/python-dev/2012-May/119387.html [2] http://mail.python.org/pipermail/python-dev/2012-May/119393.html [3] http://hg.python.org/cpython/file/dff6c506c2f1/Lib/argparse.py#l1177 [4] http://mail.python.org/pipermail/python-dev/2012-May/119412.html [5] http://mail.python.org/pipermail/python-dev/2012-May/119395.html [6] http://mail.python.org/pipermail/python-dev/2012-May/119399.html [7] http://mail.python.org/pipermail/python-dev/2012-May/119402.html -------------------------- class Namespace(SimpleNamespace): def __dir__(self): return sorted(k for k in self.__dict__ if not k.startswith('_')) def __eq__(self, other): return self.__dict__ == other.__dict__ def __ne__(self, other): return self.__dict__ != other.__dict__ def __contains__(self, name): return name in self.__dict__ [View Less]

10 18

Reimplementing collections.deque as a dynamic array
by Julian Berman May 29, 2012

May 29, 2012

I've occasionally had a need for a container with constant-time append to both ends without sacrificing constant-time indexing in the middle. collections.deque will in these cases narrowly miss the target due to linear indexing (with the current use case being for two deques storing the lines of text surrounding the cursor in a text editor while still being randomly indexed occasionally). Wikipedia lists at least two common deque implementations: http://en.wikipedia.org/wiki/Double-… [View More]

3 2

from foo import bar.baz
by Devin Jeanpierre May 29, 2012

May 29, 2012

Has it irritated anyone else that this syntax is invalid? I've wanted it a couple of times, to be equivalent to: import foo.bar.baz from foo import bar del foo # but only if we didn't import foo already before" The idea being that one wants access to foo.bar.baz under the name bar.baz , for readability purposes or what have you. I played around with adding this, but I seem to have really bad luck with extending CPython... -- Devin

3 2

pmap, preduce, pmapreduce?
by Mike Meyer May 26, 2012

May 26, 2012

Another crazy idea that may not be possible, based on my finally getting around to watching Guy Steele's talks about what he's up to these days (http://vimeo.com/6624203). Given a function that takes a list (or a container class which len doesn't consume) and a function, and then applies that function to the list in some way: either element wise, or in pairs of elements/results, but does it in parallel. It will hold the GIL, but run the function calls in distinct threads, meaning two … [View More]

4 4

Add a generic async IO poller/reactor to select module
by Giampaolo Rodolà May 26, 2012

May 26, 2012

Including an established async IO framework such as Twisted, gevent or Tornado in the Python stdlib has always been a controversial subject. PEP-3153 (http://www.python.org/dev/peps/pep-3153/) tried to face this problem in the most agnostic way as possible, and it's a good starting point IMO. Nevertheless, it's still vague about what the actual API should look like and AFAIK it remained stagnant so far. There's one thing in the whole async stack which is basically the same for all … [View More]

8 20

Minimal built-ins (+ tiny doc suggestion)
by Mark Summerfield May 25, 2012

May 25, 2012

Hi, Built-ins: In an effort to keep the core language as small as possible (to keep it "brain sized":-) would it be reasonable to deprecate filter() and map() and to move them to the standard library as happened with reduce()? After all, don't people mostly use list comprehensions and generator expressions for these nowadays? Docs: The Python Module Index http://docs.python.org/dev/py-modindex.html Shows _ | a | b | ... This is prettier than _ | A | B | ... but also harder to click because … [View More]

8 8

Composability and concurrent.futures
by Adrian Sampson May 24, 2012

May 24, 2012

The concurrent.futures module in the Python standard library has problems with composability. If I start a ThreadPoolExecutor to run some library functions that internally use ThreadPoolExecutor, I will end up with many more worker threads on my system than I expect. For example, each parallel execution wants to take full advantage of an 8-core machine, I could end up with as many as 8*8=64 competing worker threads, which could significantly hurt performance. This is because each instance of … [View More]

3 4

Extended "break" "continue" in "for ... in" block.
by 海韵 May 24, 2012

May 24, 2012

Hi all... i'd like to propose a syntax extend of "break" and "continue" to let them work together with "yield". Syntax: continue_stmt: "continue" [ test ] break_stmt: "break" [ test ] it is only valid in "for ... in" block. when we writing "for <fields> in <container>: <suite>", we can say there is a generator ("__g = iter(<container>)") providing values ("<fields> = next(__g)") and the values are processing by <suite>. <suite> implenetments … [View More]

4 3

[...].join(sep)
by anatoly techtonik May 23, 2012

May 23, 2012

I am certain this was proposed many times, but still - why it is rejected? "real man don't use spaces".split().join('+').upper() instead of '+'.join("real man don't use spaces".split()).upper() The class purity (not being dependent from objects of other class) is not an argument here: string.join() produces list, why list.join() couldn't produce strings? The impedance mismatch can be, but it is a pain already and string.join() doesn't help: that means you still get exception … [View More]

6 6