Mailman 3 September 2001 - Python-Dev

Broken build
by barry＠zope.com 19 Sep '01

19 Sep '01

Does anybody else see this? ... gcc -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function `posix_nice': ./Modules/posixmodule.c:1145: warning: implicit declaration of function `getpriority' ./Modules/posixmodule.c:1145: `PRIO_PROCESS' undeclared (first use in this function) ./Modules/posixmodule.c:1145: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:1145: for each function it appears in.) make: *** [Modules/posixmodule.o] Error 1 I just did a fresh cvs update -A, make distclean, configure, make. This on a RH6.1-ish Linux box, with uname -a: Linux anthem 2.2.18 #21 SMP Mon Jan 8 00:33:29 EST 2001 i686 unknown This bit of code doesn't appear to have changed in a while, so maybe something else in the configure/build process has changed to break this? From ./configure: ... checking for getpriority... yes ... checking for broken nice()... yes -Barry

4 7

fredrik?
by Jeremy Hylton 19 Sep '01

19 Sep '01

I've tried to send mail to Fredrik as fredrik(a)pythonware.com and effbot(a)users.sourceforge.net. Both attempts today bounced. Has anyone else reached him lately? Perhaps a different email address? Jeremy

4 3

RE: [Pythonmac-SIG] Mac Python and line-endings
by Schollnick, Benjamin 18 Sep '01

18 Sep '01

> Should a file being read be required to have a single line termination > type, or could they be mixed and matched? The prototype code allows mix > and match, but I'm not married to that idea. If it requires a single > terminator, then some performance could be gained by checking the > terminator type when opening the file, and using the existing native > text file code when it is a native file. I'm not aware of any type of text file, that supports switching line deliminators inside of the same file.... Now that doesn't mean it couldn't exist, but logically that would be a strange file.... I think it's a even bet that a file would have the same deliminator throughout the file. > My proposed solution to these problems is to have a new type of file: a > "Universal" text file. This would be a text file that would do line-feed > translation to the internal representation on the fly as the file was > being read (like the current text file type), but it would translate any > of the known text file formats automatically (\r\n, \r, \n Any > others???). That would be a interesting idea... I'm not sure how much of a performance hit we'd see, but that would certainly solve a PC / MAC issue I'm having.... (Any chance we could see the code?) Regarding your points on changing the default text file type.... There are several different ways to solve this. * Don't have the Universal be the default text file type, instead offer it as a different class, or as a open('garbage.txt', "r", universal), or some other optional switch. - Advantages being that this allows the programmer to control of the Universal usage. * Just the opposite, the programmer explicitly tells Python not to support universal... * Have the programmer subclass the File Type? * Add a global directive? * Specifically import a "universal" which will depreciate the "standard" text file IO routines... * Actually I think this sounds like the easiest and fastest way to deal with it. This way, you could add a extension library to speed it up, or whatever... (This idea is very much along the lines (??) of the STRING / STROP import) - Benjamin

5 7

MacPython 2.2a3 available
by Jack Jansen 18 Sep '01

18 Sep '01

In an unprecedented move MacPython 2.2a3 is available only a scant 26 hours or so after the unix/windows distribution of 2.2a3. MacPython 2.2a3 is available via http://www.cwi.nl/~jack/macpython.html, as usual, and in hqx or macbinary form, as a full installer, an active installer and a source distribution (as usual:-). Aside from the general new 2.2a3 features there are three specific changes in MacPython that are worth mentioning: - The structure of the MacOS toolbox modules has changed. All the modules have been put into a "Carbon" package (which, despite the name, runs fine in the classic PPC runtime model). There is a backwards compatibility folder on sys.path that will keep imports with the old names working (with an obnoxious warning). - Plugin modules are now in :Lib:lib-dynload in stead of in :Mac:PlugIns, to make the installed tree look more like the unix tree. - On input, unix line-endings are now acceptable for all text files. This is an experimental feature (awaiting a general solution, for which a PEP has been promised but not started yet, the giulty parties know who they are:-), and it can be turned off with a preference. The downside of the quick release is that the installer has only been tested on MacOSX 10.0.4 and MacOS 9.1. Please report problems on older releases of MacOS asap. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

2 1

test_socketserver fails
by Jeremy Hylton 18 Sep '01

18 Sep '01

I just tried to run the socketserver test and got an unexpected failure. I've never run the test before, so far as I know. Has anyone else? Should I expect it to work? Jeremy Python 2.2a3+ (#336, Sep 17 2001, 12:56:00) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import test.test_socketserver ADDR = ('localhost', 13511) CLASS = SocketServer.TCPServer server created server running thread: creating server thread: serving three times test client 0 test client 1 test client 2 thread: done waiting for server done ADDR = ('localhost', 13512) CLASS = SocketServer.ThreadingTCPServer server created server running thread: creating server thread: serving three times test client 0 Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.2/test/test_socketserver.py", line 162, in ? main() File "/usr/local/lib/python2.2/test/test_socketserver.py", line 158, in main testall() File "/usr/local/lib/python2.2/test/test_socketserver.py", line 148, in testall testloop(socket.AF_INET, tcpservers, MyStreamHandler, teststream) File "/usr/local/lib/python2.2/test/test_socketserver.py", line 124, in testloop testfunc(proto, addr) File "/usr/local/lib/python2.2/test/test_socketserver.py", line 65, in teststream buf = data = receive(s, 100) File "/usr/local/lib/python2.2/test/test_socketserver.py", line 49, in receive raise RuntimeError, "timed out on %s" % `sock` RuntimeError: timed out on <socket object, fd=7, family=2, type=1, protocol=0>

4 8

REMINDER: 10th Python Conference -- Deadline reminder
by David Ascher 17 Sep '01

17 Sep '01

The deadline for paper submissions for the 10th Python Conference is coming up soon: !!! October 8, 2001 !!! The conference will be February 4-7, 2002 in Alexandria, VA. See www.python10.org for details. Contact me if you have questions. -- David Ascher Program Chair 10th International Python Conference.

1 1

Re: PEP 269
by Jonathan Riehl 17 Sep '01

17 Sep '01

On Fri, 14 Sep 2001, Martin von Loewis wrote: (In response to Samuele Pedroni) > > - if it's purpose is to offer a framework for small languages > > support, there are already modules around that support that > > (SPARK, PLY ...), the only advantage of PEP 269 being speed > > wrt to the pure python solutions, because of the use of the internal > > CPython parser, OTOH the other solutions are more flexible... > > I agree. I'd like to see (or perhaps write myself) a proposal for > adding one or two of these packages to the Python core (two are > probably better, since there is no one-size-fits-all parser framework, > and adding two avoids the impression that there is a single "blessed" > parser). I would like to note that integration with these other systems are in the plans for my Basil project (http://wildideas.org/basil/). I just felt that a pgen integration would be better suited to the native code base rather than copying the code over to another project and building it as an extension module (which was a route being explored by Mobius Python.) > > It should be considered that Jython does not contain a parser > > similar to CPython one. Because of this jython does not offer parser > > module support. So implementing the PEP for Jython would require > > writing a Java or pure python equivalent of the CPython parser. I am all for writing a pgen implementation in pure Python. The reason I am not going this route from the get go is to do what is easy before we do what is less easy. If, for example, a reference implementation of a Python type system was to be adopted as standard, I would think that making the new system easy to add to Jython would be a prerequisite. Hence, we would need to develop a Jython parser that uses the grammar from CPython. > If the goal is to play with extensions to the Python grammar, I think > this is less of an issue. Of course, anybody wanting to extend the C > grammar could easily modify the Python interpreter itself. > So I think I'm -1 on this PEP, on the basis that this is code bloat > (i.e. new functionality used too rarely). As stated in the PEP, one of the primary motiviations for the proposal is to allow grammar extensions to be prototyped in Python (esp. optional static typing.) I would argue that making actual changes to CPython is much more expensive than writing a front end in Python. By adding a pgen module to Python, I feel that we are not bloating Python so much as we are exposing funtionality already built into Python. Thanks, -Jon

2 1

nested-scopes redux (fwd)
by aahz＠panix.com 17 Sep '01

17 Sep '01

Haven't seen any response to this, and I think it deserves one (then again, I could be wrong): ------- start of forwarded message ------- From: Cliff Wells <logiplexsoftware(a)earthlink.net> Newsgroups: comp.lang.python Subject: nested-scopes redux Date: Wed, 12 Sep 2001 15:45:17 -0700 Message-ID: <mailman.1000335016.31172.python-list(a)python.org> Reply-To: logiplexsoftware(a)earthlink.net To: python-list(a)python.org Sorry to bring this subject back up again, but I just noticed a somewhat annoying feature of the current nested-scope implementation. One of the big pluses of nested scopes is doing away with default arguments in lambda functions. Unfortunately the following bits of code behave differently: foo = [] for i in [1, 2]: foo.append(lambda i = i: i) and from __future__ import nested_scopes foo = [] for i in [1, 2]: foo.append(lambda: i) In the first case the output from foo[0]() and foo[1]() is 1 and 2, respectively - and it's what one would probably want. In the second case, the output is always 2. This may be the expected behavior, but it kind of does away with the benefits to providing a cleaner lambda call. -- Cliff Wells Software Engineer Logiplex Corporation (www.logiplex.net) (503) 978-6726 x308 (800) 735-0555 x308 ------- end of forwarded message -------

3 2

なんごくＭａｇ
by DoCoNo 15 Sep '01

15 Sep '01

南国いろメガネはこちらから http://www.justinmail.net/testpage/gate/gate.htm １８才未満はエロめがねをかけてもみれません -Remove Mail- ash(a)docono.org

1 0

Re: [Types-sig] Re: PEP 269
by Samuele Pedroni 14 Sep '01

14 Sep '01

[jriehl] > > On Fri, 14 Sep 2001, Martin von Loewis wrote: (In response to Samuele > Pedroni) > > > - if it's purpose is to offer a framework for small languages > > > support, there are already modules around that support that > > > (SPARK, PLY ...), the only advantage of PEP 269 being speed > > > wrt to the pure python solutions, because of the use of the internal > > > CPython parser, OTOH the other solutions are more flexible... > > > > I agree. I'd like to see (or perhaps write myself) a proposal for > > adding one or two of these packages to the Python core (two are > > probably better, since there is no one-size-fits-all parser framework, > > and adding two avoids the impression that there is a single "blessed" > > parser). > > I would like to note that integration with these other systems are in > the plans for my Basil project (http://wildideas.org/basil/). Which is not in the scope of the PEP. > I just felt > that a pgen integration would be better suited to the native code base > rather than copying the code over to another project and building it as an > extension module (which was a route being explored by Mobius Python.) I see, but as you can see there are other issues that come into play. Jython and first the appropriateness of the interface. > > > > It should be considered that Jython does not contain a parser > > > similar to CPython one. Because of this jython does not offer parser > > > module support. So implementing the PEP for Jython would require > > > writing a Java or pure python equivalent of the CPython parser. > > I am all for writing a pgen implementation in pure Python. The reason I > am not going this route from the get go is to do what is easy before we do > what is less easy. :) > If, for example, a reference implementation of a > Python type system was to be adopted as standard, I would think that > making the new system easy to add to Jython would be a prerequisite. > Hence, we would need to develop a Jython parser that uses the grammar > from CPython. Of course Jython has a (different and not run-time configurable) parser that can be extended in case, so I don't get the point. > > > If the goal is to play with extensions to the Python grammar, I think > > this is less of an issue. Of course, anybody wanting to extend the C > > grammar could easily modify the Python interpreter itself. > > > So I think I'm -1 on this PEP, on the basis that this is code bloat > > (i.e. new functionality used too rarely). > > As stated in the PEP, one of the primary motiviations for the proposal is > to allow grammar extensions to be prototyped in Python (esp. optional > static typing.) I would argue that making actual changes to CPython is > much more expensive than writing a front end in Python. But you could write that using one of the SPARK, PLY ... tools And in any case the PEP is ignoring the part about how to produce the actual code from a Python front-end. And how to add possibly necessary new bytecodes... > By adding a pgen > module to Python, I feel that we are not bloating Python so much as we are > exposing funtionality already built into Python. > Yes but how much is worth to expose such functionality depends on the whole picture: how you want to concretely use the exposed functionality? It is all but clear, how you can exploit a python exposed pgen and parser in order to make as easy as possible for a casual user to experiment with a grammar extension? In an ideal scenario the user would install somefile in his python installation and start python having access to the extension. How this can work is unanswered by the PEP. I think that a PEP that adress the whole problem would make more sense and would be more easy to evaluate. regards.

1 0