Mailman 3 September 2005 - Python-Dev

removing nested tuple function parameters
by Brett Cannon Sept. 20, 2005

Sept. 20, 2005

Is anyone truly attached to nested tuple function parameters; ``def fxn((a,b)): print a,b``? At one of the PyCon sprints Guido seemed okay with just having them removed when Jeremy asked about ditching them thanks to the pain they caused in the AST branch. I personally don't see them being overly useful thanks to assignment unpacking. Plus I don't think they are used very much (gut feeling, though, and not based on any grepping). Would anyone really throw a huge fit if they went away? I am willing to write a PEP for their removal in 2.6 with a deprecation in 2.5 if people are up for it. Otherwise I say they should definitely go in Python 3. -Brett

12 21

Re: [Python-Dev] list splicing
by Michael Chermside Sept. 20, 2005

Sept. 20, 2005

Karl Chen writes: > Hi, has anybody considered adding something like this: > a = [1, 2] > [ 'x', *a, 'y'] > > as syntactic sugar for > a = [1, 2] > [ 'x' ] + a + [ 'y' ]. A bit later in the thread, Josiah Carlson replies: > I don't think the parser would get measureably more complex, but I > believe that any work to support this uncommon (from my experience) > operation, rather than the dozens of other usable RFEs in the tracker, > would be misspent time. I'd just like to point out that this is a FRF (Frequently Requested Feature). I'm not arguing in favor of it, just pointing out that using "star unpacking" in tuple and list literals is an idea that I'm sure I've seen proposed at least a couple of times before. This doesn't necessarily make it a good idea, nor a bad one. -- Michael Chermside

3 3

For/while/if statements/comprehension/generator expressions unification
by Alexander Myodov Sept. 20, 2005

Sept. 20, 2005

Hello, Well, we have "for", "while" and "if". We also have statements, list generator expressions and list comprehensions. In comprehensions we have the opportunity to use several for-s and in a same expression (for i in range (0, 640) for j in range (0, 640)), in loops we cannot; in comprehensions, we can use if-s to filter the items; in loops, we cannot, and we have to write an inner comparison instead. My opinion is that in so smart language as Python is, it would be great to have them generalized, so that the features available in list comprehensions should be available in statements, vice versa. All three statements (for/while/if) could be joined together into a single common one, where any of these could be combined and used multiple times (but for the cases when a "else"/"elif" etc causes are required, old-school one-statements should be left); and for such common expressions, they should be equal for both loop statements and list comprehensions/generator expressions. That is, the following loops should be possible: ------- # This gives us some sugar to get rid of unnecessary indentations for x in range (0, 640) for y in range (0, 480): ------- for x in range (0, 640) if should_handle_this_column(x) \ for y in range (0, 480) if should_handle_this_row(y): ------- for nX, nY in ( f(x), f(y) for x in range (0, 640) if should_handle_this_column(x) for y in range (0, 480) if should_handle_this_row(y) ): ------- for x in range (0, 640) for y in range (0, 480) while(!timeout()): ------- for x in range (0, 640) while(!timeout_pos_in_row()) for y in range (0, 480) while(!timeout_rows()): ------- # And the latest and the hugest one: for x in range (0, 640) if should_handle_this_column(x) while(!timeout_pos_in_row()) \ for y in range (0, 480) if should_handle_this_row(y) while(!timeout_rows() : ------- # And almost the same as generator expression: for x, y in ( f(x), f(y) for x in range (0, 640) if should_handle_this_column(x) while(!timeout_pos_in_row()) for y in range (0, 480) if should_handle_this_row(y) while(!timeout_rows() ) ------- Hope I didn't miss something important... -- With best regards, Alexander mailto:maa_public@sinn.ru

2 1

removing nested tuple function parameters
by Jim Jewett Sept. 19, 2005

Sept. 19, 2005

Andrew Koenig wrote: > It is possible to imagine using the feature to catch some > type errors at the point of call, rather than having to get into the > function itself before detecting them. There can certainly be value in type-checking parameters and return values, but in this case, I think the (mental) cost is too high. With nested tuples, it hasn't actually ever helped me, but I have been burned by the extra fragility it introduces. Nesting encourages complicated parameter lists. Nested variables can (wrongly) match if your data itself is made of tuples. If the function signature changes, it is a lot harder to notice or track down. Normally, I can defend against some of this by using keywords -- but not if the parameter list is nested. Sure, it makes def __getitem__(self, (x, y)) easier -- but I don't think that is a good thing. When working with someone else's code, I would much rather *read* def __getitem__(self, keytuple): x, y = keytuple -jJ

1 0

Mixins.
by Sokolov Yura Sept. 19, 2005

Sept. 19, 2005

Excuse my english. Is there any pythonic way to make real mixin into a class? Problem: Django model (and may be SQLObject). I have a common peaces of model declaration. Sometimes they are in table definition together, sometimes table have just one of them. I cannot use inheritance, cause Django doesn't handle it in right way (like mixins). Would it be usefull to define new magic class variable __mixins__ for a new style classes, which will accept list of classes and will drop all members of them into definition of class before they went to metaclass. Possible example (my wish in Django's Model): class time_from_to: time_from=meta.DateTimeField(default=datetime(1900,1,1,0,0,0)) time_to=meta.DateTimeField(default=datetime(3000,1,1,0,0,0)) class ident(meta.Model): __mixin__=[time_from_to] ident = meta.TextField() Or, as alternative: class time_from_to(mixin): time_from=meta.DateTimeField(default=datetime(1900,1,1,0,0,0)) time_to=meta.DateTimeField(default=datetime(3000,1,1,0,0,0)) class ident(time_from_to,meta.Model): ident = meta.TextField() You say: "It is problem of Django". Yes, you are right. It is common to use multiple inheritace in place of mixin. But it is handled not all time. Django does not at the moment (I hope, it would). To handle it, library writers, who implements their metaclasses, ought to write similar code again and again. I think, it would be simpler to make mixins in one true standart way. I can be mistaken.

2 1

test__locale on Mac OS X
by skip＠pobox.com Sept. 18, 2005

Sept. 18, 2005

test__locale still fails for me on Mac OS X 10.3.9. This is on both the 2.4 branch and HEAD. Does it succeed for anyone on 10.4? If not, perhaps we should list that as an expected failure on that platform? Skip

2 1

Re: [Python-Dev] Variant of removing GIL.
by Luis P Caamano Sept. 17, 2005

Sept. 17, 2005

On 9/17/05, python-dev-request(a)python.org <python-dev-request(a)python.org> wrote: > > Message: 9 > Date: Fri, 16 Sep 2005 21:07:23 -0500 > From: skip(a)pobox.com > Subject: Re: [Python-Dev] Variant of removing GIL. > Message-ID: <17195.31323.202978.650080(a)montanaro.dyndns.org> > > > Martin> However, this is really hard to do correctly - if it were > Martin> simple, it would have been done long ago. > > I don't believe difficulty is the only (or primary) barrier. I think > *someone* would have tackled it since Greg Stein did back in 1.4(?) or his > free-threading changes would have been incorporated into the core had they > yielded speedups on multiprocessors and not hurt performance on > uniprocessors. > > Skip > It did yield speedups on multiprocessors. The uniprocessor part could've been solved just like most kernels do, one binary for UP and another for MP. That's what IBM, RedHat, Solaris, and almost all other modern kernels that support SMP machines do. In theory, if we had those changes in the CPython interpreter, we could've been running at 1.6 times the speed on dual processor machines today (according to Greg's benchmark data) and at the same speed on UP machines running the UP compiled CPython interpreter, which would not have had all the locking calls not needed on a UP machine that would hurt its performance. By now, we probably could've improved on the scalability of MP performance when running on machines with more than three processors. Mind you though, I'm not trying to oversimplify the issue. I was not using python yet at that time (I started around 1.5/1.6) and I didn't see all the info involved in the decision making process, so I'm sure there were other issues that contributed to the decision of not keeping Greg's free threading changes. My point is that not yielding speedups on multiprocessors and hurting performance on uniprocessors is not a good or valid reason to drop free-threading. -- Luis P Caamano Atlanta, GA USA

3 4

Python 2.5a1, ast-branch and PEP 342 and 343
by Nick Coghlan Sept. 16, 2005

Sept. 16, 2005

I think this is mainly a question for Guido - where do we stand with respect to the ast-branch for Python 2.5? If we're targetting a March release for 2.5a1, then we probably need to land implementations for PEP 342 and PEP 343 at least a couple of months before that, and the current patches on Sourceforge are against HEAD, not ast-branch (for obvious reasons). So, not only does ast-branch need to be brought up to Python 2.4 compliance and checked for any memory leaks when compilation attempts fail (I suspect there are a few of those), but additional work is needed to implement PEP 342 and PEP 343 as well. For Python 2.4, Guido gave a target date well before the first alpha release for landing the ast-branch if it was going to be included. Is the same thing going to happen for Python 2.5 (setting the target date, that is - not the fact that the ast-branch didn't get included!) Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com

1 0

Compatibility between Python 2.3.x and Python 2.4.x
by Rich Burridge Sept. 16, 2005

Sept. 16, 2005

Hi, I'm involved with the team that's working towards installing Python 2.4.x as part of a future release of the Solaris O/S. We currently have Python 2.3.x installed. We are trying to determine just how compatible these two release are (at both the binary and source levels). In other words, with Python 2.3.x .py, .pyc and .pyo files work correctly with Python 2.4.x ? Can somebody point me at this information please? Thanks. -- Rich Burridge Email: rich.burridge(a)Sun.COM Sun Microsystems Inc. (MPK14-260), Phone: +1.650.786.5188 4150 Network Circle, AIM/YAHOO: RicBurridge Santa Clara, CA 95054 Blog: http://blogs.sun.com/richb

6 7

C coding experiment
by Raymond Hettinger Sept. 16, 2005

Sept. 16, 2005

If anyone wants a small, but interesting C project, let me know. The project does not require much familiarity with the CPython implementation; all that is needed are basic C coding skills and a puzzle solving mentality. The goal is to determine whether the setobject.c implementation would be improved by recoding the set_lookkey() function to optimize key insertion order using Brent's variation of Algorithm D (See Knuth vol. III, section 6.4, page 525). It has the potential to boost performance for uniquification applications with duplicate keys being identified more quickly (usually with just a single probe). The function may also result in more frequent retirement of dummy entries during insertion operations. The function can be coded from scratch or adapted from Lua's source code. Raymond

3 3