RE: [Python-Dev] Importing packages from command line
Dmitry Vasiliev writes:
Just an idea...
1. python -p package_name
Equivalent to:
import package_name
(1) Sourceforge is a great place to request feature enhancements. Suggestions made on this mailing list is likely to be forgotten sooner or later. (2) Can you explain WHY you would want this feature? Is there some use case? I would prefer NOT to have this, because right now if I'm reading code and it uses "package_name.someFunction()" I can scan upward for "package_name" to find out what it's using. With command line imports, I couldn't do that. So unless you've got a good reason for it, I personally wouldn't want this feature. -- Michael Chermside
Dmitry Vasiliev wrote:
The main idea is to treating package as a program and run package initialization code from command line. The advantage is zipping all program modules in one zip archive and running the program from command line without unzipping it, like Java's jar's. But this idea need more thoughts however...
python runzip.py mypkg.zip where runzip.py is a pure Python script that works as you suggest. I'm fairly sure zipimport would allow you to write the program you describe in pure Python. I've obviously never written such a program, though. It's certainly an interesting packaging idea for small Python programs with several files, but for which a full-blown installer would be overkill. Cheers, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan@email.com | Mobile: +61 409 573 268
Michael Chermside wrote:
Just an idea...
1. python -p package_name
Equivalent to:
import package_name
(1) Sourceforge is a great place to request feature enhancements. Suggestions made on this mailing list is likely to be forgotten sooner or later.
Yes, I know, but the request is not formed yet. :-)
(2) Can you explain WHY you would want this feature? Is there some use case? I would prefer NOT to have this, because right now if I'm reading code and it uses "package_name.someFunction()" I can scan upward for "package_name" to find out what it's using. With command line imports, I couldn't do that. So unless you've got a good reason for it, I personally wouldn't want this feature.
Sorry for description absentees. The main idea is to treating package as a program and run package initialization code from command line. The advantage is zipping all program modules in one zip archive and running the program from command line without unzipping it, like Java's jar's. But this idea need more thoughts however... -- Dmitry Vasiliev (dima at hlabs.spb.ru)
On Monday 22 December 2003 12:45 pm, Dmitry Vasiliev wrote: ...
1. python -p package_name
Equivalent to:
import package_name ... The main idea is to treating package as a program and run package initialization code from command line. The advantage is zipping all program modules in one zip archive and running the program from command line without unzipping it, like Java's jar's. But this idea need more thoughts however...
Couldn't you use: python -c "import package_name" for this purpose even today? Alex
On Tuesday 23 December 2003 12:09 pm, Dmitry Vasiliev wrote:
Alex Martelli wrote:
The main idea is to treating package as a program and run package initialization code from command line. The advantage is zipping all program modules in one zip archive and running the program from command line without unzipping it, like Java's jar's. But this idea need more thoughts however...
Couldn't you use: python -c "import package_name" for this purpose even today?
python -c "import sys; sys.path.insert(0, 'module.zip'); import module"
Seems ugly... :)
Well, if the zipfile isn't on your sys.path already, then you'd have to insert it explicitly anyway -- surely, even if a switch "-p" to mean import existed, you wouldn't want it to force python to snoop into EVERY zipfile around?! PYTHONPATH=module.zip python -c "import module" is one way you might express "insert into path and import" using a decent shell (cygwin's bash on Windows, for example). The proposed: PYTHONPATH=module.zip python -p module doesn't appear to offer a _major_ enhancement, just a very minor one, in my personal opinion. One potential advantage of -p might be to let it be present _together_ with one -c (even better might be to allow multiple -c, actually). If you want to run a "while foo.bep(): foo.zlup()" you can do it today only with a shell that allows easy input of one multiline argument. But again it seems a rather marginal issue to me, personally. Alex
Nick Coghlan wrote:
Dmitry Vasiliev wrote:
The main idea is to treating package as a program and run package initialization code from command line. The advantage is zipping all program modules in one zip archive and running the program from command line without unzipping it, like Java's jar's. But this idea need more thoughts however...
python runzip.py mypkg.zip
where runzip.py is a pure Python script that works as you suggest.
I'm fairly sure zipimport would allow you to write the program you describe in pure Python. I've obviously never written such a program, though.
Code is fairly simple. import sys sys.path.insert(0, "module.zip") import module
It's certainly an interesting packaging idea for small Python programs with several files, but for which a full-blown installer would be overkill.
-- Dmitry Vasiliev (dima at hlabs.spb.ru)
Alex Martelli wrote:
The main idea is to treating package as a program and run package initialization code from command line. The advantage is zipping all program modules in one zip archive and running the program from command line without unzipping it, like Java's jar's. But this idea need more thoughts however...
Couldn't you use: python -c "import package_name" for this purpose even today?
python -c "import sys; sys.path.insert(0, 'module.zip'); import module" Seems ugly... :) -- Dmitry Vasiliev (dima at hlabs.spb.ru)
participants (4)
-
Alex Martelli -
Dmitry Vasiliev -
Michael Chermside -
Nick Coghlan