headers
Tim Peters | 2 Jan 2000 06:52
Picon

RE: Re: [Distutils] Questions about distutils strategy

Briefly backtracking to an old thread:

[Guido]
> ...
> The problem lies in which key is used.  All versions of
> Python 1.5.x (1.5, 1.5.1, 1.5.2) use the same key!  This
> is a main cause of trouble, because it means that different
> versions cannot peacefully live together even if the user
> installs them into different directories -- they will all
> use the registry keys of the last version installed.  This,
> in turn, means that someone who writes a Python application
> that has a dependency on a particular Python version (and
> which application worth distributing doesn't :-) cannot
> trust that if a Python installation is present, it is the
> right one.  But they also cannot simply bundle the standard
> installer for the correct Python version with their program,
> because its installation would overwrite an existing Python
> application, thus breaking some *other* Python apps that
> the user might already have installed.

Right, that's one class of intractable problem under Windows.

*Inside* my workplace, another kind of problem is caused when people try to
make a Python app available over the Windows network.  They stick the Python
they want and its libraries out on the network, with python.exe in the same
directory as the app.  Now some people have highly customized Python setups,
and the network Python picks up "the wrong" site.py etc.  That sucks, and
there appears no sane way to stop it.

Telling internal app distributors they need to invent a unique registry key
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg Stein | 3 Jan 2000 03:53

new imputil.py

Happy New Year!

I've attached a new imputil.py to this message. It isn't posted on my page
yet, as I'd like some feedback before declaring this new version viable.

In this imputil, there is an ImportManager class. It gets installed as the
import hook, with the presumption that it is the only import hook
(technically, it could chain, but I've disabled that for now). I think
Python 1.6 should drop the __import__ builtin and move to something like
sys.import_hook (to allow examination and change). Another alternative
would be sys.get_import_hook() and sys.set_import_hook().
[ I don't think we would want a "set" that returned the old version as the
  only way to get the current hook function; we want to be able to easily 
  find the ImportManager instance. ]

The ImportManager knows how to scan sys.path when it needs to find a
top-level module/package (e.g. given a.b.c, the "a" is the top-level; b.c
falls "below" that). sys.path can contain strings which specify a
filesystem directory, or it can contain Importer instances.

The manager also records an ordered list of suffix/importer pairs. The
add_suffix() method is used to append new suffixes, but clients can also
access the .suffixes attribute for fine-grained manipulation/ordering.

There is a new importer called _FilesystemImporter which understands how
to look into a directory for Python modules. It borrows/refers to the
ImportManager's .suffixes attribute, using that to find modules in a
directory. This is also the Importer that gets associated with each
filesystem-based module.
(Continue reading)

Permalink | Reply | 9 comments |
headers
M.-A. Lemburg | 3 Jan 2000 13:28

Re: new imputil.py

Happy New Year :-)

[new imputil.py]

I tried the new module with the following code:

import imputil,sys

if sys.argv[1] != 'standard':
    print 'Installing imputil...',
    imputil.ImportManager().install()
    sys.path.insert(0, imputil.BuiltinImporter())
    print 'done.'
else:
    print 'Using builtin importer.'

print

print 'Importing standard stuff...',
import string,re,os,sys
print 'done.'

print 'Importing mx Extensions...',
from mx import DateTime,TextTools,ODBC,HTMLTools,UID,URL
print 'done.'

###

The new importer does load everything in the test set
(top level modules, packages, extensions within packages)
(Continue reading)

Permalink | Reply | 5 comments |
headers
Greg Stein | 3 Jan 2000 14:53

Re: new imputil.py

Excellent... thanx for the feedback!

Comments:

On Mon, 3 Jan 2000, M.-A. Lemburg wrote:
>...
> The new importer does load everything in the test set
> (top level modules, packages, extensions within packages)
> without problems on Linux.

Great!

> Some comments:
> 
> · Why is the sys.path.insert(0,imputil.BuiltinImporter()) 
> needed in order to get b/w compatibility ?

Because I didn't want to build too much knowledge into the ImportManager.
Heck, I think adding sys.path removed some of the design elegence; adding
real knowledge of builtins... well, we'll just not talk about that. :-)

We could certainly do it this way; let's see what Guido says. I'm not
truly adverse to it, but I'd recommend against adding a knowledge of
BuiltinImporter to the ImportManager.

> · Why is there no __path__ aware code in imputil.py (this is
> definitely needed in order to make it a drop-in replacement) ?

Because I don't like __path__ :-)  I don't think it would be too hard to
add, though.
(Continue reading)

Permalink | Reply | 1 comment |
headers
gvwilson | 3 Jan 2000 15:02

Software Carpentry: GUI Toolkit?

Hi, folks.  I'm putting together guidelines for submissions to the
Software Carpentry design competition (www.software-carpentry.com), and
would like to know what I should recommend as a Python GUI toolkit.  As I
understand it, the alternatives are:

- Tkinter: the "standard" answer, but many people think it's showing its
  age, and it's an installation and update headaches because of its Tcl
  dependencies.

- some other GUI toolkit: but there's no consensus on which one, and
  documentation is lacking.

- CGI scripts (i.e. all interfaces are web pages): has the virtue of
  simplicity, but could also make some useful interfaces difficult to
  build (e.g. no drag and drop), and would require users to run a server,
  or at least get exec privileges, which can be an installation headache.

If I've missed a good answer, or if there's somewhere else I should look
for a solution, I'd be grateful for a pointer.

Thanks,
Greg
Permalink | Reply | 0 comments |
headers
James C. Ahlstrom | 3 Jan 2000 15:31

Re: new imputil.py

Greg Stein wrote:

> I've attached a new imputil.py to this message. It isn't posted on my page

I don't think you should be using "public domain" as a
copyright because you should be protecting the code.
Better to use "all rights transferred to CNRI pursuant
to the Python contribution agreement", or just copyright
it yourself for now.

You didn't incorporate the ZipImporter in
  ftp://ftp.interet.com/pub/importer.py
Is that because you want me to, or doesn't it work?

JimA
Permalink | Reply | 1 comment |
headers
Gordon McMillan | 3 Jan 2000 15:38

Re: new imputil.py

Greg Stein wrote:
> On Mon, 3 Jan 2000, M.-A. Lemburg wrote:
[big snip]
> > · Wish list: a distutils importer hooked to a list of standard
> > package repositories, a module to file location mapper to speed
> > up file system based imports, 

> For a mapper, we can definitely have a custom Importer that knows
> where certain modules are found. However, I suspect you're
> looking for some kind of a cache, but there isn't a hook to say
> "I found <foo> at <this> location" (which would be used to build
> the mapping).
> 
> Suggestions on both of these would be most welcome!

Haven't played with the new one yet. But for awhile I've been 
considering a scheme where sys.path[0] has a cache of 
known binary extensions { logicalname: fullpath, ... } and 
sys.path[-1] is the brute force importer.

For standalones, sys.path[0] could be hardcoded. For normal 
installations, sys.path[-1] could inform sys.path[0] when a .so 
/ .dll / .pyd is found. So when a new one is installed, the first 
use will be expensive, but subsequent sessions would import 
it in 1 I/O.

I'd also like to point out that archives *can* be used in a 
development situation. Obviously I wouldn't bother putting a 
module under current development into an archive. But if the 
source is still installed and you haven't mucked with the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Greg Stein | 3 Jan 2000 15:57

Re: new imputil.py

On Mon, 3 Jan 2000, James C. Ahlstrom wrote:
> Greg Stein wrote:
> > I've attached a new imputil.py to this message. It isn't posted on my page
> 
> I don't think you should be using "public domain" as a
> copyright because you should be protecting the code.
> Better to use "all rights transferred to CNRI pursuant
> to the Python contribution agreement", or just copyright
> it yourself for now.

Public Domain means there are no copyrights on the code. Anybody can claim
copyright to it. Anybody can start with my version, slap their name and
license on it, and do as they wish. There isn't a way for anybody to
"control" public domain software, so there is no need for protection.

I like to use Public Domain for code that I want to see as broadly used as
possible and/or for short things. There is also a lot that I just don't
care what happens with it. If I don't have a vested interest in something,
then PD is fine.

I wrote imputil as a tool for myself. It isn't something that I feel a
need to keep my name on it -- it works for me, it does what I want, it
doesn't matter what others do it. It does matter than other people *can*
do stuff with it, and PD gives them the most options.

Shades of grey... hard to fully explain in an email... but that's the
general sentiment. I've got a few things under other licenses, but PD
seemed best for imputil.

> You didn't incorporate the ZipImporter in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fred L. Drake, Jr. | 3 Jan 2000 21:05
Picon
Favicon
Gravatar

Re: new imputil.py

Gordon McMillan writes:
 > I'd also like to point out that archives *can* be used in a 
 > development situation. Obviously I wouldn't bother putting a 
 > module under current development into an archive. But if the 
 > source is still installed and you haven't mucked with the 
 > __file__ attribute when you put it in the archive, then 
 > tracebacks will show you what you need. IDLE doesn't know 
 > the difference. So for most developers, the standard library 
 > can be served from an archive with no effect (other than speed).

  I don't see why we can't just add the source to the archive as well; 
this would allow proper tracebacks even outside the development of the 
library.  Not including sources would cleanly result in the same
situation as we currently see when there's only a .pyc file.
  Am I missing something fundamental?

  -Fred

--
Fred L. Drake, Jr.	  <fdrake at acm.org>
Corporation for National Research Initiatives
Permalink | Reply | 0 comments |
headers
M.-A. Lemburg | 3 Jan 2000 19:22

Re: Better text processing support in py2k?

Tim Peters wrote:
> 
> >> This is why I do complex string processing in Icon <0.9 wink>.
> 
> [MAL]
> > You can have all that extra magic via callable tag objects
> > or callable matching functions. It's not exactly nice to
> > write, but I'm sure that a meta-language could do the
> > conversions for you.
> 
> That wasn't my point:  I do it in Icon because it *is* "exactly nice to
> write", and doesn't require any yet-another meta-language.  It's all
> straightforward, in a way that separate schemes pasted together can never be
> (simply because they *are* "separate schemes pasted together" <wink>).
>
> The point of my Python examples wasn't that they could do something
> mxTextTools can't do, but that they were *Python* examples:  every variation
> I mentioned (or that you're likely to think of) was easy to handle for any
> Python programmer because the "control flow" and "data type" etc aspects
> could be handled exactly the way they always are in *non* pattern-matching
> Python code too, rather than recoded in pattern-scheme-specific different
> ways (e.g., where I had a vanailla "if/break", you set up a special
> exception to tickle the matching engine).
> 
> I'm not attacking mxTextTools, so don't feel compelled to defend it --

Oh, I wasn't defending it -- I know that it is cryptic and sometimes
a pain to use. But given that you don't have to invoke a C compiler
to get a raw speed I find it a rather useful alternative to code
fast utility functions which would otherwise have to be written
(Continue reading)

Permalink | Reply | 0 comments |

Gmane