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.
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 +--------------------------------------+
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
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
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
> > 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
> 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
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
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
#- 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