Here is a bit of an idea that I first came up with some years ago. Guido's
response at the time was "sounds reasonable as long as we dont slow the
normal case down".
To cut a long story short, I would like eval and exec to be capable of
working with arbitrary mapping objects rather than only dictionaries. The
general idea is that I can provide a class with mapping semantics, and pass
this to exec/eval.
This would give us 2 seriously cool features (that I want <wink>), should
anyone decide to write code that enables them:
* Case insensitive namespaces. This would be very cool for COM, and as far
as I know would please the Alice people. May open up more embedding
opportunities that are lost if people feel strongly about this issue.
* Dynamic name lookups. At the moment, dynamic attribute lookups are
simple, but dynamic name lookups are hard. If I execute code "print foo",
foo _must_ pre-exist in the namespace. There is no reasonable way I can
some up with so that I can fetch "foo" as it is requested (raising the
NameError if necessary). This would also be very cool for some of the COM
work - particularly Active Scripting.
Of course, these would not be enabled by standard Python, but would allow
people to create flexible execution environments that suit their purpose.
Any comments on this? Is it a dumb idea? Anyone have a feel for how deep
these changes would cut? Its not something I want to happen soon, but it
does seem a reasonable mechanism that can provide very flexible
solutions...
Mark.
Have we been talking about Python 2 or Python 1.6? If we're talking about
Python 2, has anyone given a serious look at the LLNL gang's C++/Python
stuff? If I recall Paul Dubois' talk at the last conference, it sounded
like their work made it much easier to implement extension modules.
Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/
skip(a)mojam.com | Musi-Cal: http://www.musi-cal.com/
518-372-5583
> [...] Guido has offered in-principle support for moving
> some of the Win32 stuff into the core - particularly the Registry stuff and
> the native Window Handle support...
I think it would be nice to put all the stuff that is shared between modules
(I think that's only PyWinTypes, but who am I to think I have a clue about the
windows port:-) into the core.
I just did the same for MacPython, and it makes life a whole lot easier.
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
In a private mail, Greg Stein suggested that the python-dev archives
should be restricted to the members of the list. I prefer to make
them public, but I won't want to impose this on others without
discussion. So I've made the archives private for the time being
while we discuss this meta-issue. (Also, the existence of the list
isn't announced by mailman on its listinfo page.)
Here's my argument for open archives. I don't think that we have
anything to hide from the public -- I think of us as a technical forum
whose discussions may affect others (e.g. Python users) and I think
it's often useful for those others to be able to see what we've said.
I want to keep membership of the list closed as a gentle way to
enforce focus and quality of discussion.
Jeremy pointed out that there's no restiction on posting, and
mentioned that together with open archives this makes the list just as
open as an open-subscription list. I don't see this equivalence --
certainly it makes a difference in practice, and the open posting is
simply a mechanism to allow members with multiple email addresses to
post from whereever they are. If we regularly get spammed or find the
list is targeted by angry Python users we might have to restrict
posting to members (and deal with the multiple address problem).
I hope the discussion about this issue will be short (otherwise it
would detract from the real goal of this list). I'll follow the
desire of the majority of current members; once we have a decision I
propose to stick with it and simply present new members with the
facts.
--Guido van Rossum (home page: http://www.python.org/~guido/)
Several people argue for unbundling Tools/ and Demo/ in 1.6. I'd like to
argue to leave them in. They're not especially big, and IMHO they are
quite valuable, *especially* to the novice user. In fact, I'd like to
argue that Demo/ should be promoted to the same status as Tools/ (by which
I mean included in the Windows binary distribution). Unbundling Tools/
would mean unbundling IDLE, which IMHO would be a big strategic mistake.
However, I wouldn't be against a cleanup of said directories. Some things
should probably be removed (anything which uses stdwin), some of the code
in classes is showing its age (notes about "being upgraded for Python 1.1"
=), etc. That said, the tkinter/ directory is the best place to look for
simple Tkinter code, and should be included, IMHO.
--david
Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the
rich comparisons.
Guido, how do you envision python-dev working? Do you want to hand out a
TODO list for 1.6?
--david
David Beazley writes:
> Maybe I'm just lucky, but I've written nothing but ANSI C for the last
> 8 years and have never had a problem compiling it on any machine. I
> don't see this as being a huge issue.
Wasn't SunOS 4.x the problem child here? There are still a lot of
people using these systems, for reasons that aren't clear to me. (Did
support for some older hardware get dropped? Sounds like the most
reasonable reason to use the old OS is legacy hardware.)
-Fred
--
Fred L. Drake, Jr. <fdrake(a)acm.org>
Corporation for National Research Initiatives
(Also reported to the bug catcher.)
I'm trying to migrate from ZopeHTTPServer to ZServer 1.0b1. I was seeing
the ZServer headers turning up in pages generated by the process. When I
viewed the page source of the generated HTML I saw:
HTTP/1.0: 200 OK
Server: Zope/experimental ZServer/1.1b1
Date: Wed, 21 Apr 1999 13:00:38 GMT
X-Powered-By: Zope (www.zope.org), Python (www.python.org)
Connection: close
Content-Type: text/html
Content-Length: 7802
<!-- -*-html-helper -*- -->
<HTML>
<HEAD>
<TITLE>Musi-Cal... Concert Schedules: Folk Music, Country Music, Rock Music & more!</TITLE>
...
I run ZServer behind an Apache 1.3.3 running mod_proxy. Apparently Apache
doesn't recognize the HTTP response when there is a colon following the
version number and adds a simple set of headers itself. I guess web
browsers either ignore that line or are more lenient in their parsing of the
response.
The following simple patch corrects the problem:
diff -c2 HTTPResponse.py.~1~ HTTPResponse.py
*** HTTPResponse.py.~1~ Tue Apr 13 15:21:12 1999
--- HTTPResponse.py Wed Apr 21 09:05:00 1999
***************
*** 146,150 ****
# status header must come first.
! append("HTTP/%s: %s" % (self._http_version, status))
if headers.has_key('status'):
del headers['status']
--- 146,150 ----
# status header must come first.
! append("HTTP/%s %s" % (self._http_version, status))
if headers.has_key('status'):
del headers['status']
***************
Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/
skip(a)mojam.com | Musi-Cal: http://www.musi-cal.com/
518-372-5583
