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 would like to add a "%b" format for converting
numbers to binary format (1's and 0's). I realize
this isn't a C-ism, but it would be very useful for
teaching purposes, as newcomers find 101101 a lot
easier to understand than 0x2D.
Reactions?
Greg
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
On Mon, May 14, 2001 at 07:14:46PM -0700, Guido van Rossum wrote:
> Update of /cvsroot/python/python/dist/src/Modules
> In directory usw-pr-cvs1:/tmp/cvs-serv26415/Modules
>
> Modified Files:
> stropmodule.c
> Log Message:
> Add warnings to the strop module, for to those functions that really
> *are* obsolete; three variables and the maketrans() function are not
> (yet) obsolete.
>
> Add a compensating warnings.filterwarnings() call to test_strop.py.
>
> Add this to the NEWS.
Something that I ran into the other day...
>>> ob = some_object_implementing_the_buffer_interface
>>> string.find(ob, '.')
(fails because ob does not define the .find method)
>>> strop.find(ob, '.')
(succeeds)
The point is that strop uses the t# to get a ptr/len pair to do its work.
Thus, it can work on many things that export the buffer interface. Dropping
strop means we no longer have many of those functions. Instead, the
functionality must be copied to *every* object that implements the buffer
interface.
We can say ob.find() now, but we can't say find(ob) any longer. And saying
that all objects (which implement the buffer API) must now implement a bunch
of "standard" methods is awfully burdensome.
In my particular case, I was trying to do a find on a BufferObject referring
to a subset of another object. Blam. No good. Thankfully, when I did a
find() on a mmap object, it worked simply because mmaps happen to define a
.find method.
[ of course, the find method on an mmap was totally broken, but I checked in
a fix for that (last week or so) ]
So... my question is: is there any way that we can retain a generic find()
(and similar functions from the string/strop module) that operates on any
type that implements the buffer API?
Maybe there is some way we can do a mixin for Python types? e.g. "this mixin
implements some standard methods for 8-bit character data (using the buffer
API), which can be mixed into new Python types" That would reduce the burden
for new types.
Thoughts?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
If anyone has an app known or suspected to be sensitive to dict timing,
please try the patch here. Best I've been able to tell, it's a win. But
it's a radical change in approach, so I don't want to rush it.
This gets rid of the polynomial machinery entirely, along with the branches
associated with updating the things, and the dictobject struct member
holding the table's poly. Instead it relies on that
i = (5*i + 1) % n
is a full-period RNG whenever n is a power of 2 (that's what guarantees it
will visit every slot), but perturbs that by adding in a few bits from the
full hash code shifted right each time (that's what guarantees every bit of
the hash code eventually influences the probe sequence, avoiding simple
quadratic-time degenerate cases).
Guido's on vacation. Anyone have an answer for this? I don't, and can't
make time to dig into now.
If you can, David's address showed up as mailto:boogiemorg@aol.com
> -----Original Message-----
> From: python-list-admin(a)python.org
> [mailto:python-list-admin@python.org]On Behalf Of David Morgenthaler
> Sent: Wednesday, May 23, 2001 6:20 PM
> To: python-list(a)python.org
> Subject: What happened to Idle's extend.py?
>
>
> Idle-0.3, shipped with Python 1.5.2 had an extend.py module that was
> used to extend Idle. We've used this extensively, building entire
> "applications" as Idle extensions.
>
> Now that we're moving to Python 2.1, we find the same old directions
> for extending Idle (in extend.txt), but there appears to be no
> extend.py in Idle-0.8.
>
> Does anyone know how we can add extensions to Idle-0.8?
>
> Thanks in advance,
> David
> --
> http://mail.python.org/mailman/listinfo/python-list
I just updated httplib.py to expand the list of names in its __all__ list.
I was operating on version 1.34. After the checkin I am looking at version
1.34.2.1. I see that Lib/CVS/Tag exists in my directory tree and says
"release21-maint". Did I muff it? If so, how should I do an unmuff
operation?
Skip
Tried the patch (thanks, Tim!) - but I guess the things I'm running
aren't too sensitive to dict speed <grin>. I see a slight speed-up,
around 1-2%... Nice, elegant patch that should go places! Maybe the
bio-informatics people on c.l.py (Andrew Dalke?) would be interested in
trying it out?
--
Mark Favas - m.favas(a)per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA
I'm using Gnome under Mandrake 8.0 and getting very strange results using
webbrowser (indirectly via pydoc). Apparently, Gnome's init code sets the
BROWSER environment variable to "nautilus" (much to my surprise) and
webbrowser trusts it as the god's honest truth, even though nautilus has not
been registered with the webbrowser module (am I supposed to add that sort
of stuff to site.py?). Accordingly, _tryorder is ['nautilus'] but doesn't
appear in _browser.keys() is ['lynx', 'links', 'netscape', 'kfm',
'mozilla']. I think webbrowser should either ignore elements of BROWSER if
they have not previously been registered (and can't be found by _iscommand)
or try to register them using GenericBrowser. Users are apparently not the
only people setting BROWSER, so the comment in the code:
# It's the user's responsibility to register handlers for any unknown
# browser referenced by this value, before calling open().
seems like flawed logic to me.
Skip
>>>>> "Robin" == Robin Becker <robin(a)jessikat.fsnet.co.uk> writes:
Robin> from httplib import *
Robin> class Bongo(HTTPConnection):
Robin> pass
...
Robin> NameError: name 'HTTPConnection' is not defined
It was a brain fart on my part when creating httplib.__all__.
HTTPConnection was not included in that list. I will check in a fix.
In the 2.1 release __all__ was defined as
__all__ = ["HTTP"]
I have changed that to
__all__ = ["HTTP", "HTTPResponse", "HTTPConnection", "HTTPSConnection",
"HTTPException", "NotConnected", "UnknownProtocol",
"UnknownTransferEncoding", "IllegalKeywordArgument",
"UnimplementedFileMode", "IncompleteRead",
"ImproperConnectionState", "CannotSendRequest", "CannotSendHeader",
"ResponseNotReady", "BadStatusLine", "error"]
and will check the change into CVS shortly. (Thomas, keep an eye open for
this as an addition to 2.1.1.)
The workaround I would choose is to not use from "httplib import *":
import httplib
class Bongo(httplib.HTTPConnection):
pass
Robin> Changing the * to HTTPConnection in ttt.py removes the problem.
Yup, that will also work.
Before anyone asks, "Who died and make Skip King?", the scenario as I recall
it was that the semantics of __all__ got settled on during discussions on
python-dev (the goal of __all__ being to minimize namespace pollution by
"from ... *"), but nobody stepped up immediately to do the gtunt work, so I
volunteered. The problem in relying on one person (well, at least this one
person) to do this was that I had only the following tools at my disposal to
decide what belonged in __all__:
* what was documented in the lib reference manual (which was at times
incomplete)
* my experience with the various modules (some of which was specialized,
some of which was nonexistent)
* the standard library (which generally doesn't use "from ... *" much)
* input from python-dev (whose members also appear not to use "from
... *" very liberally)
In retrospect, I probably should have polled c.l.py with a summary of what I
came up with before the 2.1 ship date. If people would like me to do that
now (before 2.2 gets anywhere close to release) to try and fill in as many
missing symbols as possible, let me know.
--
Skip Montanaro (skip(a)pobox.com)
(847)971-7098
Greg Ewing writes:
> Another advantage of changing both together is that
> we can continue to describe listcomp semantics in terms
> of for-loops instead of lambdas.
Is this really an advantage? To me, the lambda semantics are a lot
more intuitive in terms of matching the way that list comprehensions
are actually used and ought to work (although I will agree that the
for-loop explanation is a good way to describe the internals of what a
list comprehension actually does).
I think I would be opposed to changing normal for-loop semantics to
match any change made in list-comprehensions. There are too many cases
where you use a loop variable after finishing a loop and I suspect
that this would break a huge amount of code. For example:
for i in r:
...
if whatever: break
print i
Besides, the semantic mismatch created between a listcomp and a
for-loop pales in comparison to the mismatch that currently exists
between the behavior of listcomps and all of the other operators. Of
course, that's just my opinion--I could be wrong.
> Then we won't have to go
> into hiding until Guido dies or lifts the fatwah against us.
fatwah? Uh... should I start talking to the witness protection
program folks?
Cheers,
Dave
