Mailman 3 April 2013 - Python-ideas

Re: [Python-ideas] [pydotorg-www] Poll about -h,--help options
by M.-A. Lemburg 14 Apr '13

14 Apr '13

[Taking pydotorg-www off CC - this doesn't have anything to do with the website] On 14.04.2013 13:06, Antoine Pitrou wrote: > On Mon, 18 Feb 2013 10:40:07 +0300 > anatoly techtonik <techtonik(a)gmail.com> > wrote: >> Hi, >> >> Is it interesting to know if people expect -h to work as a --help >> equivalent by default? > > Yes, I do expect it. > (and I find it quite annoying when it doesn't) Same here. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 14 2013) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2013-04-09: Released mxODBC.Connect 2.0.3 ... http://egenix.com/go42 2013-04-02: Released mxODBC Zope DA 2.1.1 ... http://egenix.com/go41 ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

1 0

Poll about -h,--help options
by anatoly techtonik 14 Apr '13

14 Apr '13

Hi, Is it interesting to know if people expect -h to work as a --help equivalent by default? As it directly affects best practices of using Python in command line, can we run such poll on python.org? I thought that this stuff is obvious, but it appears that it is not, so I'd like to see this usability study - it will be interesting for the Python community to know itself better. -- anatoly t.

7 7

Re: [Python-ideas] Allow key='attribute_name' to various sorting functions
by Markus Unterwaditzer 12 Apr '13

12 Apr '13

Ram Rachum <ram.rachum(a)gmail.com> wrote: >That would work for me, +1. (Though I imagine this idea will be >showered >with -1 from ebd...) > > >On Fri, Apr 12, 2013 at 9:19 PM, Markus Unterwaditzer < >markus(a)unterwaditzer.net> wrote: > >> Ram Rachum <ram.rachum(a)gmail.com> wrote: >> >> >I often want to sort objects by an attribute. It's cumbersome to do >> >this: >> > >> > sorted(entries, key=lambda entry: entry.datetime_created) >> > >> >Why not allow this instead: >> > >> > sorted(entries, key='datetime_created') >> > >> >The `sorted` function can check whether the `key` argument is a >string, >> >and >> >if so do an attribute lookup. >> > >> >Since I see no other possible use of a string input to `key`, I >don't >> >see >> >how this feature would harm anyone. >> > >> >What do you think? >> > >> > >> >Thanks, >> >Ram. >> > >> > >> >>------------------------------------------------------------------------ >> > >> >_______________________________________________ >> >Python-ideas mailing list >> >Python-ideas(a)python.org >> >http://mail.python.org/mailman/listinfo/python-ideas >> >> I think it's a very bad idea to try to overload the key argument, imo >a >> separate kwarg of sorted would be fine though. E.g: >> >> sorted(iterable, attribute='someattr') >> >> -- Markus (from phone) >> Although i think it's better to use attrgetter, since it is more easily reusable and so on. -- Markus (from phone)

1 0

Allow key='attribute_name' to various sorting functions
by Ram Rachum 12 Apr '13

12 Apr '13

I often want to sort objects by an attribute. It's cumbersome to do this: sorted(entries, key=lambda entry: entry.datetime_created) Why not allow this instead: sorted(entries, key='datetime_created') The `sorted` function can check whether the `key` argument is a string, and if so do an attribute lookup. Since I see no other possible use of a string input to `key`, I don't see how this feature would harm anyone. What do you think? Thanks, Ram.

12 16

Proposal: itertools.batch
by Blagoj Petrushev 09 Apr '13

09 Apr '13

Hello, I have an idea for a new function in the itertools module. I've been using this pattern quite a lot, so maybe someone else would think it is useful as well. The purpose is to split an iterable into batches with fixed size, and each yielded batch should be an iterator as well. def batch(iterable, batch_size): exhausted = False batch_range = range(batch_size) while not exhausted: def current(): nonlocal exhausted for _ in batch_range: try: yield next(iterable) except StopIteration: exhausted = True yield current() There are problems with this implementation: - the use of try/except is an overkill (the exception is raised only once, so maybe it's not that scarry) - it goes on forever if the batches are not actually consumed - it yields additional empty iterator if the original iterable's length is an exact multiple of batch_size. Here is a simplified version which yields batches as tuples (this is the variation I use in practice): def batch_tuples(iterable, batch_size): while True: batch_ = tuple(itertools.islice(iterable, 0, batch_size)) if len(batch_) == 0: break yield batch_ This is my first proposal, and first email on this list, so take it easy on me :) petrushev --------- https://github.com/petrushev

2 1

itertools.chunks()
by Wolfgang Maier 09 Apr '13

09 Apr '13

>Also I find myself often writing helper functions like these: > >def chunked(sequence,size): > i = 0 > while True: > j = i > i += size > chunk = sequence[j:i] > if not chunk: > return > yield chunk This is just an alternate version of the grouper recipe from the itertools documentation, just that grouper should be way faster and will also work with iterators. We just had a thread on variations of the grouper recipe under *zip_strict() or similar in itertools*. Wolfgang

2 7

Name mangling and code repetition (with cooperative inheritance use case)
by Zahari Petkov 09 Apr '13

09 Apr '13

Hello everyone, In a certain implementation where I was doing some form of dispatch using composition, I decided to try out cooperative inheritance with super. However, I stumbled at something unexpected - there was nothing wrong with cooperative inheritance with super, but the implementation started to have repetative code, which could not be easily resolved, because of how name mangling of private attribute works. In short my proposal is for a language feature or mechanism, which will allow automatic redefinition of methods through the descendants of a superclass during compilation time - at the same time name unmangling is done. In the example below I use a decorator - just to illustrate the idea in a very simple way: class A: __val = 'a' @propagate_through_descendants def print_val(self): print(self.__val) class B(A): __val = 'b' b = B() b.print_val() Please, check the following gist for a bit more concrete example (short and working) with cooperative inheritance: https://gist.github.com/majorz/5341333 The code duplication is very obvious and unavoidable (the two __call__ methods have exactly the same code, which cannot be moved to the superclass). I tried some metaprogramming, but even then it was hard to resolve, since name unmangling seems to happen during complilation time as far as I understand. Thanks, Zahari

6 12

An iterable version of find/index for strings?
by Tom Schumm 09 Apr '13

09 Apr '13

Should Python strings (and byte arrays, and other iterables for that matter) have an iterator form of find/rfind (or index/rindex)? I've found myself wanting one on occasion, and having more iterable things seems to be the direction the language is moving. Currently, looping over the instances of a substring in a larger string is a bit awkward. You have to keep track of where you are, and you either have have to watch for the -1 sentinel value or catch the ValueError. A "for idx in ..." construction would just be cleaner. You could use re.finditer, but a string method seems a more lightweight/efficient/obvious. The best name I can think of would be "finditer()" like re.finditer(). Using "ifind" (like izip) would be confusing, because it could be mistaken for case- insensitive find. I thought of "iterfind" like the old dict.iteritems, and ElementTree.iterfind but "iterrfind" (iterable rfind) is unattractive. I also think "find" is a more obvious verb than "index". I've got a simple Python implementation on gist: https://gist.github.com/fwiffo/5233377 It includes an option to include overlapping instences, which may not be necessary (it's not present in e.g. re.finditer). I could imagine it as a method on str/unicode/bytes/list/tuple objects, or maybe as a function in itertools. -- Tom Schumm http://www.fwiffo.com/

13 19

mixing tabs and spaces
by Neal Becker 08 Apr '13

08 Apr '13

I was noticing the complaint about mixing tabs and spaces on python.general list. It occurs to me, that a simple solution would be to allow a comment at the top of the file to specify a tab-space equivalency. something similar to the coding magic comment: # -*- coding: <encoding name> -*- Perhaps: # -*- tab: 8 -*-

8 8

Reviving PEP 3140 - "str(container) should call str(item), not repr(item)"
by Piotr Dobrogost 08 Apr '13

08 Apr '13

Hi! Having str(container) calling str(item) and not repr(item) sounds like the right thing to do. However, PEP 3140 was rejected on the basis of the following statement of Guido: "Let me just save everyone a lot of time and say that I'm opposed to this change, and that I believe that it would cause way too much disturbance to be accepted this close to beta." Thu, 29 May 2008 12:32:04 -0700<http://www.mail-archive.com/search?l=python-3000@python.org&q=date:20080529>( http://www.mail-archive.com/python-3000@python.org/msg13686.html) Does anyone know what's the reason Guido was opposed to this change? Is there any chance to revive this PEP? Regards, Piotr Dobrogost

8 13