Mailman 3 July 2001 - Python-Dev

Improving nested-scope warnings?
by Guido van Rossum 12 Jul '01

12 Jul '01

Someone on SF made a point: the warnings you get about nested scopes aren't always as helpful as they could be. > My "user experience" of porting my 2.0 code to 2.1 is > however fairly pityful. Here some destilled suggestions: > * separate warnings for "potential" "import *" problems for > standard > modules (as in the examples) -- sure we know what math > exports > right now and "from math import *" is a common idiom. > * run-time warnings for shadowed constructs > * listing of the variables that are imported and one may > want to > import by name instead (or qualify) > > While I really like the new scoping rules and they support > my programming style their practical impact on existing code > is quite > large. A better support would be fairly important -- I have > 50.000 lines of code to port .... (From http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440497&group_id…) Anybody interested in implementing some of these? I guess this would be in the 2.1.1 branch, as in the 2.2 branch we're about to enable the future... --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

RE: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distu tils] Package DB: strawman PEP)
by Moore, Paul 12 Jul '01

12 Jul '01

From: M.-A. Lemburg [mailto:mal@lemburg.com] Tim Peters wrote: > Umm, what am I missing? The change to site.py was so simple you could have > committed it yourself quicker than it took to write the above. I committed > it a few minutes ago. If something else is needed, someone else will have > to do it (or explain it to me in detail so precise they could do it themself > 10x quicker <wink>). > Cool, but what about the changes needed in distutils to actually > utilize the new directory and the changes to the Windows installer > to create the directory at installation time ? The patch I sent along with the final version of the PEP included the distutils change (it's only one line, but it's on the PC at home, so I can't quote it here). I assume that the Python install should ensure that the site-packages exists (it does at the moment) so I don't see a need for the wininst installer to check. Paul. PS [After a quick rummage...] I *think* the following patch is what is needed for distutils: I haven't tested it, though, so it would be better to check the original version (which I did test...) --- sysconfig.py.orig Thu Apr 19 10:24:24 2001 +++ sysconfig.py Thu Jul 12 09:32:34 2001 @@ -87,7 +87,7 @@ elif os.name == "nt": if standard_lib: - return os.path.join(PREFIX, "Lib") + return os.path.join(PREFIX, "Lib", "site-packages") else: return prefix

2 1

XML-RPC docs are in
by Eric S. Raymond 11 Jul '01

11 Jul '01

I have spent the afternoon writing, and the first version of xmlrpclib docs is checked in. It probably has markup errors; it is not complete, and could probably stand to have some of the internal things like Marshaller documented. But I think it does a decent job on the entry points and externally visible things. We have more to do. Fred D. and Fredrik L. should proof this sucker for errors. Fredrik L. should add stuff on some of the internals and quasi-internals I haven't described, like the loads and dumps functions. Then, as Eric Kidd pointed out, we really ought to support an XML-RPC server class wrapped around Fredrik's stubs. There appears to be one in the xmlrpclib distribution. Fredrik, are you planning to document that and check it in? This is a feature set to make serious noise about in the publicity for 2.2. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, Historical Review of Pennsylvania, 1759.

1 0

TypeError and AttributeError
by James_Althoff＠i2.com 11 Jul '01

11 Jul '01

Given that except (TypeError, AttributeError): is the "safest across releases" idiom (as suggested by Tim Peters), would it make sense to make AttributeError a subclass of TypeError so that except (TypeError): would become equally "safe" (and simpler)? Potentially, some exception handling code would behave differently (break?), but apparently this is already the case given that what is raised (AttributeError or TypeError) changes between releases. Jim

5 4

Method resolution order
by Neil Schemenauer 11 Jul '01

11 Jul '01

Guido van Rossum wrote: > Using the classic [depth-first, left-right] lookup rule, construct the > list of classes that would be searched, including duplicates. Now for > each class that occurs in the list multiple times, remove all > occurrences except for the last. The resulting list contains each > ancestor class exactly once Is this original or is it used by other languages as well? My books on Dylan and CLOS are at home but I think they do something similar. Neil

2 1

beopen.com e-mail addresses in CVS
by Andrew Kuchling 11 Jul '01

11 Jul '01

I noticed that Tools/compiler has jeremy(a)beopen.com as the author's address. A quick grep: ./Lib/test/test_gettext.py:# Barry Warsaw <bwarsaw(a)beopen.com>, 2000. ./Lib/test/test_gettext.py:"Last-Translator: Barry A. Warsaw <bwarsaw(a)beopen.com>\n" ./Misc/RPM/Tkinter/setup.cfg:packager = Jeremy Hylton <jeremy(a)beopen.com> ./Misc/RPM/Tkinter/setup.py: author_email="pythoneers(a)beopen.com", ./Misc/RPM/beopen-python.spec:Packager: Jeremy Hylton <jeremy(a)beopen.com> ./Misc/RPM/beopen-python.spec:* Mon Oct 9 2000 Jeremy Hylton <jeremy(a)beopen.com> ./Misc/RPM/beopen-python.spec:* Thu Oct 5 2000 Jeremy Hylton <jeremy(a)beopen.com> ./Misc/RPM/beopen-python.spec:* Tue Sep 26 2000 Jeremy Hylton <jeremy(a)beopen.com> ./Misc/RPM/beopen-python.spec:* Tue Sep 12 2000 Jeremy Hylton <jeremy(a)beopen.com> ./Tools/compiler/setup.py: author_email = "jeremy(a)beopen.com", ./changes:a suggestion from Bob Weiner <weiner(a)beopen.com>. All but the last (and maybe the second) seem to be worth fixing. --amk

1 0

CVS build failures? posixmodule.c on Linux RH6.1
by barry＠digicool.com 11 Jul '01

11 Jul '01

I just did a fresh cvs update, make distclean, configure, make and posixmodule.c is now failing to compile. Looks like it's Thomas recent nice() patch that's failing because PRIO_PROCESS isn't defined unless sys/resource.h is #included (at least on this RH6.1-ish Linux box). The following patch seems to fix the problem for me. Comments? -Barry -------------------- snip snip -------------------- Index: posixmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v retrieving revision 2.191 diff -u -r2.191 posixmodule.c --- posixmodule.c 2001/07/11 14:45:34 2.191 +++ posixmodule.c 2001/07/11 22:04:29 @@ -32,6 +32,12 @@ #include <sys/wait.h> /* For WNOHANG */ #endif +#ifdef HAVE_GETPRIORITY +#ifndef PRIO_PROCESS +#include <sys/resource.h> +#endif /* !PRIO_PROCESS */ +#endif /* HAVE_GETPRIORITY */ + #ifdef HAVE_SIGNAL_H #include <signal.h> #endif

2 2

RE: Python-Dev digest, Vol 1 #1470 - 11 msgs
by Greg Wilson 11 Jul '01

11 Jul '01

> From: Martin Sjögren <martin(a)strakt.com> > Any suggestion where to put it so that it's found? SourceForge, please --- it'll make it easy for others to contribute, and to get. I'm also finding that a lot of sys admins at places I teach have figured SF out, so I can say, "Install this, this, and this," and it just happens. Kind of cool... Thanks, Greg ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intendedf or the addressee(s) only. If you have received this message in error ort here 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 thec ontents of this message by a third party or as a result of any virus beingp assed on. In addition, certain Marketing collateral may be added from time to time top romote 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.

1 0

Python and SSL
by Martin Sj�gren 11 Jul '01

11 Jul '01

Hello I'm currently in the process of developing a basic OpenSSL module for Python. Before you say antyhing, yes I know about M2Crypto and its SSL support, but for a number of reasons, it doesn't fulfill our needs. We found the SSL support in Python to be insufficient (nonexistent :-)) for our needs. We thus decided to write our own module. The module is faaaar from complete as an interface to the general cryptographic functionality of OpenSSl, but it does have basic SSL support, including authorization using certificates, PRNG seeding functions and an error handling system. Since we are using Python extensively and don't have to pay for it, we would like to reply in kind and offer the module back to the Python project. (This is, in case you're missing it, a hint that now that security is the hot subject it is, it's silly for an otherwise so complete language to lack SSL support ;-)) The whole kit (including some documentation) can be found here: http://www.strakt.com/~martin/pyOpenSSL.tar.gz My question is... What do I do now? Where to proceed? Please CC me replies, since I'm (of course) not on the list. Regards, Martin Sjögren AB Strakt -- Martin Sjögren martin(a)strakt.com ICQ : 41245059 Phone: +46 (0)31 405242 Cell: +46 (0)739 169191 GPG key: http://www.strakt.com/~martin/gpg.html

4 4

Publisher seeking technical reviewers for books on Python
by Petra_Recter＠prenhall.com 10 Jul '01

10 Jul '01

Prentice Hall, a leading college publisher, is seeking knowledgeable python programmers to review chapters from technical computer science books. The chapters are posted on an ftp site and reviewers are asked to download the chapters, print it out and make comments on the hard copy. The requested turnaround time is approximately 3 days per chapter. The token honorarium we are offering is $75 per chapter reviewed. If you are interested, please contact Petra Recter (petra_recter(a)prenhall.com) and include your resume. Thanks, Petra Petra Recter Senior Acquisitions Editor, Computer Science Prentice Hall One Lake Street - #3F66 Upper Saddle River, NJ 07458 Email: petra_recter(a)prenhall.com Tel: (201) 236-7186 Fax: (201) 236-7170

1 0