Python-Dev October 2003

python-dev@python.org

130 participants
211 discussions

RE: [Python-Dev] Those import related syntax errors again...

by Samuele Pedroni

Hi. [Mark Hammond] > The point isn't about my suffering as such. The point is more that > python-dev owns a tiny amount of the code out there, and I don't believe we > should put Python's users through this. > > Sure - I would be happy to "upgrade" all the win32all code, no problem. I > am also happy to live in the bleeding edge and take some pain that will > cause. > > The issue is simply the user base, and giving Python a reputation of not > being able to painlessly upgrade even dot revisions. I agree with all this. [As I imagined explicit syntax did not catch up and would require lot of discussions.] [GvR] > > Another way is to use special rules > > (similar to those for class defs), e.g. having > > > > <frag> > > y=3 > > def f(): > > exec "y=2" > > def g(): > > return y > > return g() > > > > print f() > > </frag> > > > > # print 3. > > > > Is that confusing for users? maybe they will more naturally expect 2 > > as outcome (given nested scopes). > > This seems the best compromise to me. It will lead to the least > broken code, because this is the behavior that we had before nested > scopes! It is also quite easy to implement given the current > implementation, I believe. > > Maybe we could introduce a warning rather than an error for this > situation though, because even if this behavior is clearly documented, > it will still be confusing to some, so it is better if we outlaw it in > some future version. > Yes this can be easy to implement but more confusing situations can arise: <frag> y=3 def f(): y=9 exec "y=2" def g(): return y return y,g() print f() </frag> What should this print? the situation leads not to a canonical solution as class def scopes. or <frag> def f(): from foo import * def g(): return y return g() print f() </frag> [Mark Hammond] > > This probably won't be a very popular suggestion, but how about pulling > > nested scopes (I assume they are at the root of the problem) > > until this can be solved cleanly? > > Agreed. While I think nested scopes are kinda cool, I have lived without > them, and really without missing them, for years. At the moment the cure > appears worse then the symptoms in at least a few cases. If nothing else, > it compromises the elegant simplicity of Python that drew me here in the > first place! > > Assuming that people really _do_ want this feature, IMO the bar should be > raised so there are _zero_ backward compatibility issues. I don't say anything about pulling nested scopes (I don't think my opinion can change things in this respect) but I should insist that without explicit syntax IMO raising the bar has a too high impl cost (both performance and complexity) or creates confusion. [Andrew Kuchling] > >Assuming that people really _do_ want this feature, IMO the bar should be > >raised so there are _zero_ backward compatibility issues. > > Even at the cost of additional implementation complexity? At the cost > of having to learn "scopes are nested, unless you do these two things > in which case they're not"? > > Let's not waffle. If nested scopes are worth doing, they're worth > breaking code. Either leave exec and from..import illegal, or back > out nested scopes, or think of some better solution, but let's not > introduce complicated backward compatibility hacks. IMO breaking code would be ok if we issue warnings today and implement nested scopes issuing errors tomorrow. But this is simply a statement about principles and raised impression. IMO import * in an inner scope should end up being an error, not sure about 'exec's. We will need a final BDFL statement. regards, Samuele Pedroni.

15 years, 9 months

Can we please have a better dict interpolation syntax?

by Greg Ewing

I have just had the experience of writing a bunch of expressions of the form "create index %(table)s_lid1_idx on %(table)s(%(lid1)s)" % params and found myself getting quite confused by all the parentheses and "s" suffixes. I would *really* like to be able to write this as "create index %{table}_lid1_idx on %{table}(%{lid1})" % params which I find to be much easier on the eyes. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg(a)cosc.canterbury.ac.nz +--------------------------------------+

16 years, 4 months

Looking for master thesis ideas involving Python

by Brett C.

Today I got the wheels turning on my masters thesis by getting an adviser. Now I just need a topic. =) The big goal is to do something involving Python for a thesis to be finished by fall of next year (about October) so as to have it done, hopefully published (getting into LL4 would be cool), and ready to be used for doctoral applications come January 2005. So, anyone have any ideas? The best one that I can think of is optional type-checking. I am fairly open to ideas, though, in almost any area involving language design. There is no deadline to this, so if an idea strikes you a while from now still let me know. I suspect I won't settle on an idea any sooner than December, and that is only if the idea just smacks me in the face and says, "DO THIS!" Otherwise it might be a while since I don't want to take up a topic that won't interest me or is not helpful in some way. -Brett

16 years, 11 months

Time for py3k@python.org or a Py3K Wiki?

by Skip Montanaro

These various discussions are moving along a bit too rapidly for me to keep up. We have been discussing language issues which are going to impact Python 3.0, either by deprecating current language constructs which can't be eliminated until then (e.g., the global statement) or by tossing around language construct ideas which will have to wait until then for their implementation (other mechanisms for variable access in outer scopes). Unfortunately, I'm afraid these things are going to get lost in the sea of other python-dev topics and be forgotten about then the time is ripe. Maybe this would be a good time to create a py3k(a)python.org mailing list with more restrictions than python-dev (posting by members only? membership by invitation?) so we can more easily separate these ideas from shorter term issues and keep track of them in a separate Mailman archive. I'd suggest starting a Wiki, but that seems a bit too "global". You can restrict Wiki mods in MoinMoin to users who are logged in, but I'm not sure you can restrict signups very well. I also think Guido wants to make a significant leap on his own at Python 3.0, but that is going to require a considerable amount of uninteruppted full-time available for that effort. Given that my 21-year old only recently fled the nest and my 20-year old keeps returning, I'd say Guido's going to have to wait for quite awhile for the "uninterrupted" qualifier to become unconditionally true. ;-) In the meantime, a mailing list archive or Wiki would provide a good place to keep notes which he could refer to. Skip

17 years

Re: [Python-Dev] accumulator display syntax

by Skip Montanaro

Greg> What you're proposing hijacks the indexing syntax and uses it to Greg> mean something completely different from indexing, which is a much Greg> bigger change, and potentially a very confusing one. Greg> So, no, sorry, it doesn't overcome my objection! I agree. Any expression bracketed by '[' and ']', no matter how many other clues to the ultimate result it might contain, ought to result in a list as far as I'm concerned. Skip

17 years

Re: test_bsddb blocks testing popitem - reason

by Gregory P. Smith

> > It is unfortuantely entirely possible that various berkeleydb libraries > > have bugs. Since the BerkeleyDB db->del() call isn't returning it is > > presumably stuck in a lock waiting for who knows what. > > Right. But the SAME berkeley db library is being used for my build of > both Python 2.4 alpha 0, and 2.3 maintenance branch, both from cvs, > and I can't see any difference in what they're doing with bsddb -- so > clearly I must be missing something because it's hanging on EVERY > attempt to run the unittest w/2.4, but never w/2.3. The big difference i see between 2.3cvs and 2.4cvs that could "explain" it is that Lib/bsddb/__init__.py has been updated to use a private (in memory, single process only) DBEnv with locking and thread support enabled. That explains why db->del() would be doing locking. But not why it would deadlock. This is also easily reproducable here. No special platform or berkeleydb version should be required. Looking closer I suspect what is happening is that Lib/bsddb/__init__.py implementation is not threadsafe. It wants to maintain the current iterator location using a DBCursor object. However, having an active DBCursor holds a lock in the database. DictMixin's popitem() is effectively: k, v = self.iteritems().next() del self[k] return (k, v) The iteritems() call creates an internal DBCursor object for the iterator. The next() call on the iterator (DBCursor) looks up the value for k. The following delete attempts to delete the record without using the DBCursor; thus the deadlock. If we implement our own popitem() for the bsddb dictionary object (_DBWithCursor) to perform the delete using the cursor this deadlock in the unit tests would go away. That won't stop users from intermixing iteration over a database with modifications to the database; causing their own deadlocks (very unexpected in single threaded code). Proposed fix: It should be possible for the bsddb object to maintain internal state of its own about what key is is on and close any internal DB cursor on all non-cursor database accesses leaving the iteration functions to detect this and reopen and reposition the cursor. Since the basic bsddb interface doesn't allow databases with duplicate keys it shouldn't be too difficult. Its not efficient but a user who cares about efficient use of berkeleydb should use the real DB/DBEnv interface directly. How do python dictionaries deal with modifications to the dictionary intermixed with iteration? Greg

17 years

RE: [Python-Dev] Looking for master thesis ideas involving Python

by Delaney, Timothy C (Timothy)

> From: Dennis Allison [mailto:allison@sumeru.stanford.EDU] > > How about re-engineering the interpreter to make it more MP friendly? > (This is probably a bigger task than a Masters thesis.) The current > interpreter serializes on the global interpreter lock (GIL) and blocks > everything. To me this would probably be the most interesting thing to tackle - especially since it has been tried before with partial success but overall failure. At the very least that gives a body of work which you can refer to both as a starting point for your work, and to show how your approach differs from and improves on existing work. It would also be of tremendous value to Python IMO if it could be done without negatively impacting performance on single-processor machines. Whether it is too large for a Masters thesis I don't know. Does a Masters thesis require *success* in the stated goal? I've been thinking about doing my own Masters in the not-too-distant future if I can find the time ... Tim Delaney

17 years

Deprecate the buffer object?

by Neil Schemenauer

I happened to be looking at the buffer API today and I came across this posting from Guido: http://mail.python.org/pipermail/python-dev/2000-October/009974.html Over the years there has been a lot of discussion about the buffer API and the buffer object. The general consensus seems to be that the buffer API is not ideal but nonetheless useful. The buffer object, OTOH, is considered fundamentally broken and should be removed. Does anyone object to deprecating the 'buffer' builtin? Eventually we could remove the buffer object completely. Neil

17 years

RE: [Python-Dev] Re: Guido's Magic Code was: inline sort option

by Michael Chermside

Raymond writes: > If only in the C API, I would like to see just such a universalmethod > alternative to classmethod. That would allow different behaviors to be > assigned depending on how the method is called. And that's exactly why I would be wary of it. One of the GREAT SIMPLICITIES of Python is that all calls are "the same". Calling a function works a particular way. Calling a callable object does the same, although the arguments are passed to __call__. Calling a classmethod does the same thing. Calling a bound method does the same thing except that the first argument is curried. Here in the Python community, we think it is a good thing that one must explicitly name "self" as an argument to methods, and that any function CAN be made a method of objects. Now you're proposing a special situation, where what appears to be a single attribute of a class object is actually TWO functions... two functions that have the same name but subtly different behavior. Right now, I presume that if I have: a = A() # a is an instance of A x = a.aMethod('abc') # this is line 1 y = A.aMethod(a, 'abc') # this is line 2 that line 1 and line 2 do the same thing. This is a direct consequence of the fact that methods in Python are just functions with an instance as the first argument. But your "universalmethod" would break this. It might be worth breaking it, if the result is some *very* readable code in a whole variety of situations. And it's certainly okay for Guido to manually create a class which behaves this way via black magic (and for most users, descriptor tricks are black magic). But to make it a regular and supported idiom, I'd want to see much better evidence that it's worthwhile, because there's an important principle at risk here, and I wouldn't want to trade away the ability to explain "methods" in two sentences: A 'method' is just a function whose first argument is 'self'. The method is an atribute of the class object, and when it is called using "a.method(args)", the instance 'a' is passed as 'self'. for a cute way of making double use of a few factory functions. -- Michael Chermside

17 years

RE: [Python-Dev] prePEP: Decimal data type

by Batista, Facundo

#- On Friday 31 October 2003 07:36 pm, Batista, Facundo wrote: #- ... #- > If it all goes ok, it'll be a PEP when I finish #- writing/modifying the code. #- #- I'll gladly help fix the English if needed then, let me know. Always welcomed too, :) #- > When passing floating point to the constructor, what should happen? #- > #- > j. ``Decimal(1.1) == Decimal('1.1')`` #- > k. ``Decimal(1.1) == #- > Decimal('110000000000000008881784197001252...e-51')`` #- #- You forgot an alternative that's likely to be popular on #- python-dev: "an #- exception is raised". (This would change requirement 2. later, of #- course). You're right. So the 'm' choice (votable as the others) is "an exception is raised". . Facundo

17 years

Jump to page:

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev October 2003