Mailman 3 December 2003 - Python-Dev

2.3.3 released?
by Andrew Koenig Dec. 19, 2003

Dec. 19, 2003

It appears that the main python.org page is announcing the release of 2.3.3 final, but the release page http://www.python.org/2.3.3/ does not show a place to download the Windows executable. Have I caught it in mid-transition?

5 5

rexec.py unuseable
by Luke Kenneth Casson Leighton Dec. 19, 2003

Dec. 19, 2003

i tried to reuse some code that i wrote for a project back when python 2.0 and 2.1 were in use. i must be about the only person in existence who wrote some code that uses - and totally relies on - the rexec.py module. what that code does (did) was to provide a database-based method of running restricted programs for use to monitor and manage remote servers. i.e. it became in effect a distributed python operating system. what happened was that the name of a python script, its arguments, a … [View More]relevant ip address and the server on which the script was to be run were all entered into a database table, and the server picked that up, loaded the script and its arguments from the database and then ran the script, which usually involved contacting the remote ip address. so, not only was rhooks used to overload "import" such that libraries used by scripts in the database could _also_ be loaded from the database, but rexec.py was also used to restrict what functions could be accessed. i was quite happy with rexec.py as it stood. it was the c++ functional equivalent of the "protected" convention for c++ classes. at the time that i tried to reuse the code, i discovered the lovely "this module is broken in python 2.2 and 2.3" message. well, uhm, if it's broken, why hasn't it been reverted to the 2.0 code? i noted, some time about a year ago, that someone attempted to drill down the rexec security into sub-modules. i.e. they attempted to add the c++ functional equivalence of the "private" convention for c++ classes. consequently, a number of routines that wrote to files that i had DELIBERATELY wrapped and made available to first-level rexec-restricted library routines, e.g. the logging functions which output debug information to log files, suddenly stopped working. why? whereas before, the debug routine could be called directly but the write operation could not, because of the drill-down effect, all of a sudden the write operation, as called _by_ the debug routine, is now restricted in the 2.1 (or early 2.2) code, and my debug library routine now doesn't work, nor indeed does anything else. the thing is that the functionality of the python 2.0 rexec.py was _exactly_ as i would have expected it to be, and it was working _perfectly_ according to my expectations of that code. i therefore believe that the attempts to take rexec one step further, aka a "drill-down" effect, by making all functions that rexec functions import _also_ restricted, to have been a mistake. or, at least, not carefully thought out. if such additional restrictions are to be added, i believe that they should be added as a user-configureable parameter (e.g. named recursive-restrict) _please_ could the functionality of rexec.py be restored to python 2.0 functionality, with the "rexec.py is broken" message only coming up when the suggested-named parameter "recursive-restrict" is set. maybe then i can consider reviving that code and re-releasing it, because at the moment it's totally going to waste. many many thanks, l. -- -- expecting email to be received and understood is a bit like picking up the telephone and immediately dialing without checking for a dial-tone; speaking immediately without listening for either an answer or ring-tone; hanging up immediately and then expecting someone to call you (and to be able to call you). -- every day, people send out email expecting it to be received without being tampered with, read by other people, delayed or simply - without prejudice but lots of incompetence - destroyed. -- please therefore treat email more like you would a CB radio to communicate across the world (via relaying stations): ask and expect people to confirm receipt; send nothing that you don't mind everyone in the world knowing about... [View Less]

7 20

RE: open == file considered harmful (Re: [Python-Dev] RE: rexec.pyunuseable)
by Michael Chermside Dec. 18, 2003

Dec. 18, 2003

[Michael Chermside] > ... INSTANCES of 'file' and could access > f.__class__. [...] so for restricted code we return something > like this: > > class FakeFile: > def __eq__(self, other): > return other == file > [Guido] > Are you aware of the original issue, which is that as soon as you have > a file *instance* (which might have been given to you by a very > restrictive open() variant), you can always get to the file *class* > using … [View More]

3 2

RE: [Python-Dev] Relative import
by Gordon McMillan Dec. 18, 2003

Dec. 18, 2003

I am +10e6 on disambiguating imports. I am +0 on "scan". I am +0.01 on "explicit relative". I can live with any syntax Guido can, so I'm just voting on functionality. The use cases for "ambiguous" imports amount to: 1) I use this cool package, but I'm too lazy to keep up with new releases or document the release required & ensure that it's available & further I'm so arrogant that I don't care that my users might run into problems having 2 copies of the code or that … [View More]

1 0

syncing between projects?
by Skip Montanaro Dec. 18, 2003

Dec. 18, 2003

The python-mode.el file in the python-mode project is now at 4.41, while the version in Python's Misc directory is still at 4.38. Is there a way to sync them in one cvs operation so they have the same version? Thx, Skip

2 1

RE: open == file considered harmful (Re: [Python-Dev] RE: rexec.pyunuseable)
by Greg Ewing Dec. 18, 2003

Dec. 18, 2003

Michael Chermside <mcherm(a)mcherm.com>: > Greg: > > In light of this, it may have been a serious mistake to > > unify the 'file' type and the 'open' function. Is it too > > late to back out of that decision? > > Guido: > > I think so. > > I disagree. Right now, having access to a class object basically > gives one the ability to create new objects of that type. I > think that's just fine... and I don't mind applying it to the > file … [View More]

3 4

Importing packages from command line
by Dmitry Vasiliev Dec. 18, 2003

Dec. 18, 2003

Just an idea... 1. python -p package_name Equivalent to: import package_name 2. python -p package.zip Equivalent to: import sys sys.insert(0, "package.zip") import package -- Dmitry Vasiliev (dima at hlabs.spb.ru)

1 0

Python 2.3.3 documentation
by Fred L. Drake, Jr. Dec. 18, 2003

Dec. 18, 2003

Formatted copies of the Python 2.3.3 documentation is available at: ftp://ftp.python.org/pub/python/doc/2.3.3/ The website has not yet been updated. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

1 0

Looking for master thesis ideas involving Python
by Brett C. Dec. 18, 2003

Dec. 18, 2003

Today I got the wheels turning on my masters thesis by getting an adviser. Now I just need a topic. =) The big goal is to do something involving Python for a thesis to be finished by fall of next year (about October) so as to have it done, hopefully published (getting into LL4 would be cool), and ready to be used for doctoral applications come January 2005. So, anyone have any ideas? The best one that I can think of is optional type-checking. I am fairly open to ideas, though, in … [View More]

15 46

Doc/ tree closed on 2.3 branch
by Fred L. Drake, Jr. Dec. 18, 2003

Dec. 18, 2003

Python's Doc/ tree is closed on the release23-maint branch. Commits may still be made on the trunk. The final 2.3.3 documentation will appear in the development area on python.org shortly: http://www.python.org/dev/doc/ The branch will be open once the 2.3.3 release has been completed. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

1 0