Mailman 3 May 2001 - Python-Dev

non-mutating 'choose' to go with 'dict.popitem'?
by Greg Wilson 09 May '01

09 May '01

Has anyone else found themselves wanting a method that chooses and returns a dictionary element at random, without removing it (as popitem does)? Or is there some way to tell popitem to return a value without mutating the container? If neither, would this be useful, or is it DHG? Thanks Greg

3 3

Re: [Python-Dev] Recent change to termios module breaks build on FreeBSD
by Michael Hudson 08 May '01

08 May '01

"Fred L. Drake, Jr." <fdrake(a)acm.org> writes: > Michael Hudson writes: > > If you don't include termio.h the build breaks on alpha/OSF1. This > > sounds to me like OSF1's headers are broken (you can't include > > sys/ioctl.h without including termio.h first, it seems, or you get > > complaints about struct termio being undefined). So I'd suggest > > > > +#ifdef __osf__ > > #include <termio.h> > > +#endif > > > > and then see if the build breaks anywhere else (I love unix). > > Does it make more sense to do this or to test for termio.h in > configure? If you're asking *me*, I have no idea. I'd hope that no system would be as broken as osf1 is in this regard, but then I'd have hoped that osf1 wasn't this broken too... I guess the test in configure is "safer" in some sense. Getting this perfectly right would probably require more autoconf hackery than one can possibly imagine... ncurses generates an amk script from ./configure that is then run to produce term.h, but I'm not sure that all of that is devoted to including the right headers. can-we-just-have-TERMIOS-back?-ly y'rs M. -- Good? Bad? Strap him into the IETF-approved witch-dunking apparatus immediately! -- NTK now, 21/07/2000

1 0

Re: [Python-Dev] Moving MacPython to sourceforge
by Jack Jansen 08 May '01

08 May '01

> I'd say merge, except that the number '1000' is very large. Is it really > 1000 ? The current Python tree contains only 304 .c and .h files, about 1000 > .py files spread out over the tree (567 of which in Lib, the rest in > Demo/Tools) and obviously some misc files and CVS stuff, for a total of > around 2500 files. Is that 1000 a real number ? No temp files, > auto-generated files, .o files etc ? How large are they ? (the average size > in the current CVS tree is about 10k) It's actually 830 files. This is 320 .py files (130 in Lib, the rest in Tools/scripts/etc) 120 .c/.h files, 110 XML and exp files (for the build system), 30 resource files and then assorted things (html documentation, scripts to drive the distribution builder, etc). The .xml and .exp files and about 20 of the .c files are machine generated, so they could technically be left out of the repository. The generation process of these files is a bit painful, though, so I've added them as a convenience (the reasoning is a bit along the lines of the Grammar stuff of the core). The one thing that I should do is clean out the "Unsupported" directory before doing the merge. It contains some stuff that is long dead. But then, it isn't all that many files. -- 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

3 2

Recent change to termios module breaks build on FreeBSD
by Favas, Mark (EM, Floreat) 08 May '01

08 May '01

A change to termios.c in the last couple of days to #include termio.h as well as termios.h breaks the build on FreeBSD, which has only termios.h - needs an autoconf test? There'll probably be other similar systems. Cheers, Mark

3 2

Re: [Python-Dev] Recent change to termios module breaks build on FreeBSD
by Michael Hudson 08 May '01

08 May '01

Guido van Rossum <guido(a)digicool.com> writes: > > A change to termios.c in the last couple of days to #include termio.h > > as well as termios.h breaks the build on FreeBSD, which has only > > termios.h - needs an autoconf test? There'll probably be other similar > > systems. > > Frankly, I don't see the point of including termio.h at all -- it > seems to be a backwards compatibility file. If you don't include termio.h the build breaks on alpha/OSF1. This sounds to me like OSF1's headers are broken (you can't include sys/ioctl.h without including termio.h first, it seems, or you get complaints about struct termio being undefined). So I'd suggest +#ifdef __osf__ #include <termio.h> +#endif and then see if the build breaks anywhere else (I love unix). Using the sf compile farm, I've tested this on FreeBSD, Linux/x86, Linux/PPC, OSF1/alpha, Linux/sparc, Solaris/sparc (using gcc; cc gives a pile of warnings from redefined macros and then dies 'cause it can't find a valiud license file). So we might need some more magic for solaris using cc. Cheers, M. -- Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jeff Raskin

2 1

Re: [Python-Dev] Moving MacPython to sourceforge
by Jack Jansen 08 May '01

08 May '01

> We have platform-specific subdirectories for so many projects that > it's a shame we don't have the Mac code in there as well! Great! I'll pack up my repository and send it to the sourceforge-powers-that-be shortly. The write permission for other MacPython developers shouldn't be a problem, I think Just is currently the only person with write permission (but I have to check). > (Jack, regarding your Makefile and setup.py changes: I'd wait for > opinions on your patches from Neil and Andrew. I don't see why > they would have an objection to adding these features, but the > specific implementation you propose might be subject to comments.) Definitely. I'll put them up as patches and then see what happens. -- 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

2 1

Moving MacPython to sourceforge
by Jack Jansen 08 May '01

08 May '01

Folks, now that there's finally a decent (well, somewhat decent:-) Mac CVS client that supports ssh I'd like to move MacPython to sourceforge. There's two ways I can go about this: start a new MacPython project or merge the MacPython stuff into the main Python CVS repository. The Mac specific stuff for Python is all concentrated in a single subtree Mac of the main Python tree (the subtree has its own hierarchy of Python/Modules/Lib/etc directories), so putting it in the main repository should not pollute the filenamespace all that much. It would also have the advantage that a single "cvs update" would update everything (whereas the current situation for Mac developers, where Python/Mac is from a different CVSROOT than Python, does not have that advantage). The downside is that everyone who does a full checkout of the tree would get an extra 1000 or so files on their disk that are pretty useless unless they have a mac. Oh yes, another plus for putting stuff in the main repository is MacOSX support. Some MacPython modules have been "ported" to MacOSX, and I've started on adding them to setup.py, and life would become a lot simpler for people compiling on MacOSX if they had everything available automatically. -- 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/ ++++

3 2

Multiple inheritance
by Paul F. Dubois 08 May '01

08 May '01

Pardon if this is brief and suggestive only, I am on deadlines. Super is a mistaken concept in multiple inheritance languages. Fortunately, Python is not brain-damaged. Its multiple inheritance model can be fixed easily to be fully capable. Here is a suggestive example of implementing the Eiffel model (the only one that is theoretically sound) using "pretend" Python syntax (keyword conservationists might like "import" where I have "rename"): 1. The simple case, X inherits from Y and in defining foo and bar needs to use Y's version: class X (Y rename foo as _sfoo, bar as _sbar ): def foo (self): self._sfoo() myfoostuff Suppose D inherits from B and C, which both inherit from A. A has a method a1 that is redefined in B but not in C. D wishes to use both A's version as inherited via C and B's version. class D (B rename a1 as ba1, C rename a1 as ca1): can now use self.ca1, self.a1 Renaming is also useful where you inherit from a utility class and the lingo is different in the class where you want to use it. E.g. class Window (Tree rename children as subWindows) Reference: Meyer, B. "Object-Oriented Software Construction", 2nd Edition.

8 9

Help with SF bug 105470
by Tim Peters 08 May '01

08 May '01

An ancient bug just got (re?)discovered on c.l.py, which I entered into SF: http://sourceforge.net/tracker/?func=detail&aid=422177&group_id=5470& atid=105470 This has to do w/ gross loss of precision in manifest Python float constants, if and only if a module is loaded from .pyc or .pyo format. Since's it's fp-related, and fp is tricky x-platform, I'd like some volunteers to test this before I check it in. Current CVS Python contains a dormant test case. There's a patch attached to the bug report that activates the test case, and tries to repair the problem. After the patch, the fix works if and only if test_import doesn't fail, neither after deleting all .pyc/.pyo files first, nor if run a second time w/o deleting .pyc/.pyo. Works on Win98SE, but you may have already guessed that <wink>.

1 0

Moving MacPython to sourceforge
by Martin v. Loewis 07 May '01

07 May '01

> I don't know much about modules, but would this allow Jack to check > out the main code and the MacPython code into a single work > directory (which he needs)? Using CVS modules allows to merge parts of the tree into a single sandbox. E.g. you could do macpython python/dist/src &Mac 'cvs co macpython' then would give you a dist/src directory, which also contains a Mac directory (where Mac is another module, alongside with /python, or a CVSROOT/modules entry). You could use an exclude list, e.g. macpython !PC !PCbuild !RISCOS python/dist/src &Mac What you *cannot* do is to merge modules on a per-directory basis; all files in a single directory must come from the same CVS module - you can think of ampersand modules similar to Unix mount(1)ed file systems. Regards, Martin

1 0