would be nice: import from archive

[Dan Perl]

Here is a python feature that I would like: to be able to import modules
from an archive like the jar files in Java. Maybe a regular tar file?
Maybe a python specific file type, let's call it a 'par' file?

It would be useful in packaging an python library. Sure, there's always the
python packages, but a single file instead of a whole directory tree would
be more convenient. I am particularly interested because I am working on a
framework/toolkit and I am using a configuration divided into several
modules. It would be nice to be able to save configurations (combinations
of several modules) into single archive files and then switch between
configurations by pointing to one such archive file.

I am quite new to python so I should ask first whether there is already
something like that, although I did a search already. Or maybe such a
feature has already been discussed somewhere? If this is an original idea,
how can I propose it for future releases?

Dan Perl
(yes, I'm Mr. Perl, but I'm using Python, after all Perl is not my middle
name, it's my last name)

[Paul Rubin]

"Terry Reedy" <tj*****@udel.e du> writes:

'import x' is syntactic sugar for 'x = __import__('x') '. I do not see it
as necessary that sugar for the common case need cover every possible case.
So, how about giving __import__ had an optional param 'signed' defaulted to
False, to allow signed =True or signed = CA?

Man, that __import__ thing is ugly. I think it's better to extend the
syntax, e.g.
import x(a,b) => __import__('x', {'a':None, 'b':None})
import x(a=v1,b=v2)=> __import__('x', {'a':v1, 'b':v2})

so you could say
import x(signed)
or
import x(signed, certfile='mycer ts.pem')

or whatever.

[Terry Reedy]

"Paul Rubin" <"http://phr.cx"@NOSPAM. invalid> wrote in message
news:7x******** ****@ruckus.bro uhaha.com...

"Terry Reedy" <tj*****@udel.e du> writes:

'import x' is syntactic sugar for 'x = __import__('x') '. I do not see
it
as necessary that sugar for the common case need cover every possible
case.
So, how about giving __import__ had an optional param 'signed' defaulted
to
False, to allow signed =True or signed = CA?
Man, that __import__ thing is ugly.

Yes... but importing from signed zips is sufficiently rare and esoteric
that I would not see surface ugliness that accompanies using current syntax
as the most important consideration.

I think it's better to extend the syntax, e.g.
import x(a,b) => __import__('x', {'a':None, 'b':None})
import x(a=v1,b=v2)=> __import__('x', {'a':v1, 'b':v2})

Identifier(args ) is currently a call of identifier with args and
overloading that syntax to mean somthing similar but different is, to me,
even uglier in a different sort of way.

Terry J. Reedy

[Paul Rubin]

"Terry Reedy" <tj*****@udel.e du> writes:

I think it's better to extend the syntax, e.g.
import x(a,b) => __import__('x', {'a':None, 'b':None})
import x(a=v1,b=v2)=> __import__('x', {'a':v1, 'b':v2})

Identifier(args ) is currently a call of identifier with args and
overloading that syntax to mean somthing similar but different is, to me,
even uglier in a different sort of way.

Ok, use brackets instead: import x[a,b].
Then it's just a matter of overloading the index operator on __import__.

[Peter Otten]

Paul Rubin wrote:

"Terry Reedy" <tj*****@udel.e du> writes:

> I think it's better to extend the syntax, e.g.
> import x(a,b) => __import__('x', {'a':None, 'b':None})
> import x(a=v1,b=v2)=> __import__('x', {'a':v1, 'b':v2})

Identifier(args ) is currently a call of identifier with args and
overloading that syntax to mean somthing similar but different is, to me,
even uglier in a different sort of way.

Ok, use brackets instead: import x[a,b].
Then it's just a matter of overloading the index operator on __import__.

@signed
@certfile('myce rts.pem')
import x

anybody?
Peter

[Jorge Godoy]

Just <ju**@xs4all.nl > writes:

The zipimport module will never write to the zip archive, so for most
efficient imports, you have to store .pyc data in there yourself.
zipimport is mostly meant as a repackaging tool, and typical zip files
only contain .pyc files.

They aren't created even outside of the zip archive, this is what I
meant ;-)

--
Godoy. <go***@ieee.org >

[Just]

In article <m3************ @g2ctech.com>, Jorge Godoy <go***@ieee.org >
wrote:

Just <ju**@xs4all.nl > writes:

The zipimport module will never write to the zip archive, so for most
efficient imports, you have to store .pyc data in there yourself.
zipimport is mostly meant as a repackaging tool, and typical zip files
only contain .pyc files.

They aren't created even outside of the zip archive, this is what I
meant ;-)

But since .pyc's are always generated in the same directory as the .py
files, where else would you expect them to be generated?

Just

[Jorge Godoy]

Just <ju**@xs4all.nl > writes:

But since .pyc's are always generated in the same directory as the .py
files, where else would you expect them to be generated?

At the directory where the zip archive is stored.

--
Godoy. <go***@ieee.org >

[Just]

In article <m3************ @g2ctech.com>, Jorge Godoy <go***@ieee.org >
wrote:

Just <ju**@xs4all.nl > writes:

But since .pyc's are always generated in the same directory as the .py
files, where else would you expect them to be generated?

At the directory where the zip archive is stored.

How does that follow? The zip archive _itself_ is the "directory" where
the .py files are, why would Python suddenly choose to write .pyc files
one level up? And what about packages? It simply doesn't work that way.

Just

[Martin v. Löwis]

Paul Rubin wrote:

so you could say
import x(signed)
or
import x(signed, certfile='mycer ts.pem')

or whatever.

I believe that import is the wrong point in time for checking
signatures. You want to check the signature when the file is
added to sys.path, i.e.

imp.verify_sign ature(filename)
sys.path.append (filename)

or

imp.verify_all_ signatures(sys. path)

That way, you can guarantee that trusted code is on sys.path
all the time. Then, you can also trust any import statement.

Regards,
Martin

[Jorge Godoy]

Just <ju**@xs4all.nl > writes:

In article <m3************ @g2ctech.com>, Jorge Godoy <go***@ieee.org >
wrote:

Just <ju**@xs4all.nl > writes:

> But since .pyc's are always generated in the same directory as the .py
> files, where else would you expect them to be generated?

At the directory where the zip archive is stored.

How does that follow? The zip archive _itself_ is the "directory" where
the .py files are, why would Python suddenly choose to write .pyc files
one level up? And what about packages? It simply doesn't work that way.

Because the implementation that allowed to unzip the "directory" and
find the files in there would also allow to place the '.pyc' in a
different place such as the real directory where the zip file resides.

Python didn't use to open zip files also, and now it does. I don't see
nothing wrong with making it also writing the '.pyc' files. Do you?

--
Godoy. <go***@ieee.org >