Mailman 3 এপ্রিল 1999 - Python-Dev

More flexible namespaces.
by Mark Hammond 12 জুন, 1999

12 জুন, 1999

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.

11 37

LLNL C++ as base for Python 2?
by skip＠mojam.com 28 এপ্রিল, 1999

28 এপ্রিল, 1999

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

3 2

Re: [Python-Dev] numpy
by Jack Jansen 28 এপ্রিল, 1999

28 এপ্রিল, 1999

> [...] 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

1 0

numpy
by David Ascher 28 এপ্রিল, 1999

28 এপ্রিল, 1999

What are the thoughts on NumPy integration into the core? --David

4 5

Public or private python-dev archives?
by Guido van Rossum 27 এপ্রিল, 1999

27 এপ্রিল, 1999

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/)

6 5

Why unbundle Tools and Demo?
by David Ascher 26 এপ্রিল, 1999

26 এপ্রিল, 1999

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

2 3

Notice of intent: rich comparisons
by David Ascher 26 এপ্রিল, 1999

26 এপ্রিল, 1999

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

12 16

Re: [Python-Dev] Notice of intent: rich comparisons
by Fred L. Drake 23 এপ্রিল, 1999

23 এপ্রিল, 1999

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

4 5

ZServer 1.0b1: spurious colon in HTTP response line
by skip＠mojam.com 21 এপ্রিল, 1999

21 এপ্রিল, 1999

(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> <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

1 0