Mailing List Archive

import question
Bill Wilkinson <yopen@my-Deja.com> wrote:
> I have searched the documentation but have not found anything that helps me
> with this.
>
> I want to be able to import a module from a variable instead of a file. I
> need to do this because all my modules are going to be in a database. So I
> want have something like this:
>
> s = "lots of classes and functions loaded from a database"
> import s
> s.run_function()

check out the imputil.py module in greg stein's "small"
distribution kit [1] (also in gordon's installer kit [2]). it
allows you to create and install custom importers using
only a few lines of Python code.

</F>

1) http://www.lyra.org/greg/small/
2) http://starship.python.net/crew/gmcm/install.html
Re: Import question [ In reply to ]
Circular import issues can usually be resolved by moving import
statements into the bodies of functions which aren't executed when the
module itself is imported. Simple example:

---- fileA.py ------

import fileB as fb
foo = 10 # we're going to access foo from fileB

fb.do_something_with_foo()

---- fileB.py ------

def do_something_with_foo():
import fileA as fa # import is INSIDE the function
print "foo is ", fa.foo

----------------------

--
http://mail.python.org/mailman/listinfo/python-list
Re: Import question [ In reply to ]
ncf wrote:
> In file A, I have an instance of a class and then I import file B
> (import fileB as fb). In file B, I need to access file A's class
> instance. Is there anyway I can do this? (I hope that was descriptive
> enough :\)

Let's see...

# -- fileA.py
class Test(object): pass

myInstance = Test()

import fileB as fb
fb.myInstance = myInstance
fb.test()

# -- fileB.py
myInstance = None

def test():
print "myInstance is %s" % myInstance

if __name__ == "__main__":
test()

# -- now to the command line to test:
pmcnett@sol:~/projects/dabo/dabo/ui/uiwx $ python fileB.py
myInstance is None
pmcnett@sol:~/projects/dabo/dabo/ui/uiwx $ python fileA.py
myInstance is <__main__.Test object at 0xb7dfcf6c>

Is this what you want? BTW, what you call "files", we refer to as
"scripts" (if run) or "modules" (if imported).

--
Paul McNett
http://paulmcnett.com

--
http://mail.python.org/mailman/listinfo/python-list
Re: Import question [ In reply to ]
Hmm...thanks for the replies. Judging by this, it looks like I might
still be in a slight perdiciment with doing it all, but time will tell.
I wish there were a way I could reference across multiple modules.

Well, thanks for your help. Hopefully I'll be able to work out some
*simple* solution for all of this.

-Wes

--
http://mail.python.org/mailman/listinfo/python-list
Re: Import question [ In reply to ]
ncf wrote:
> Hmm...thanks for the replies. Judging by this, it looks like I might
> still be in a slight perdiciment with doing it all, but time will tell.
> I wish there were a way I could reference across multiple modules.
>
> Well, thanks for your help. Hopefully I'll be able to work out some
> *simple* solution for all of this.

What exactly is it that you're trying to do? You don't need access to
the class definition (which would be in a module) if you just want to
manipulate a particular _instance_. Advantage of dynamic typing and all.

For example:

module1:
def function(x):
x.method(1)

module2:
class foobar:
def method(x):
print 'I received', x, ', aren't I happy?!'

import module1
obj = foobar()
module1.function(obj)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Import question [ In reply to ]
I've got multiple instances I want globally available in the secondary
modules, which can't easily be passed around with every function call
without driving me nuts, so I wish to have all variables from the Main
module passed to each of the other modules it creates.

One such example would be in Main, we call the SettingsParse() function
or whatever, which creates a Settings class storing all settings. This
class needs to be readily accessible by extensions (dynamically loaded)
and almost all other modules in the project.

-Wes

--
http://mail.python.org/mailman/listinfo/python-list
Re: Import question [ In reply to ]
Crap. Forgot to mention that in some instances, I do want the class
definitions to create new instances and such. Sorry :)

--
http://mail.python.org/mailman/listinfo/python-list
Re: Import question [ In reply to ]
Lamonte Harris wrote:
> can I import more then one modules like this:
>
> import module,module2
So your'e basically saying that you haven't tried it?

/W
--
http://mail.python.org/mailman/listinfo/python-list
Re: Import question [ In reply to ]
Lamonte Harris wrote:
> On 8/22/07, *Wildemar Wildenburger* <wildemar@freakmail.de
> <mailto:wildemar@freakmail.de> > wrote:
>
> So your'e basically saying that you haven't tried it?
>
> No I haven't. Thats why I asked? Common sense?
Sorry. Excuse my sarcasm. The common way for answering easy questions like this one is firing up the interpreter and trying it for yourself.
You don't go up to a shoestore clerk to ask whether your shoes might fall off if you tie them sloppily, do you? Thats just wasting everyones time.

And regarding your question:
Python 2.5 (r25:51908, Apr 10 2007, 10:29:13)
[GCC 4.1.2 20070403 (Red Hat 4.1.2-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, datetime
>>> sys.platform, datetime.datetime.now()
('linux2', datetime.datetime(2007, 8, 23, 0, 1, 41, 727155))


Hint for the future: Please try these things before asking. If *then* you have a problem, ask.
/W

--
http://mail.python.org/mailman/listinfo/python-list
Re: Import question [ In reply to ]
En Fri, 05 Feb 2010 13:21:47 -0300, Andrew Degtiariov
<andrew.degtiariov@gmail.com> escribió:

> Code of our project has split into several packages and we deploy the
> project using buildout.
> All worked fine until I need to dynamically inspect python modules.

Entirely by luck, I'd say :)

> ├───project.api.config
> │ ├───project
> │ │ └───api
> │ │ └───config
> │ │ └───settings
> │ └───project.api.config.egg-info
> ├───project.api.contacts
> │ ├───project
> │ │ └───api
> │ │ └───contacts
> │ │ ├───importer
> │ │ └───views
> │ └───project.api.contacts.egg-info

> Regular code like "import project.api.config" worked fine, but now I'm
> tryed
> __import__('project.api.config'):
>
> $ bin/python
>
>>>> import project.api.config
>>>> __import__('project.api.config')
> <module 'project from
> 'c:\users\ad\project\src\project.api.contacts\project\__init__.pyc'>

You can't use dots neither in module names nor package names as they're
identifiers [1]. It's like trying to use an attribute named 'foo.bar': you
can handle it with getattr/setattr, but normal attribute access won't work:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: X instance has no attribute 'foo'
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: X instance has no attribute 'foo'
1

[1] http://docs.python.org/reference/simple_stmts.html#the-import-statement

> What's wrong? We really need to split the code for several eggs and want
> that all of our package's names starts from 'project.api'

The only sane solution is to avoid using dots in package names. Sorry, but
having project.api.config, project.api.contacts as directory names is
simply crazy.
Looks like you actually wanted to use this layout:

project/
api/
config/
...
contacts/
...
core/
...

but made a wrong turn in the road...

--
Gabriel Genellina

--
http://mail.python.org/mailman/listinfo/python-list
Re: Import question [ In reply to ]
2010/2/6 Gabriel Genellina <gagsl-py2@yahoo.com.ar>

> En Fri, 05 Feb 2010 13:21:47 -0300, Andrew Degtiariov
> <andrew.degtiariov@gmail.com> escribió:
>
>
> Code of our project has split into several packages and we deploy the
>> project using buildout.
>> All worked fine until I need to dynamically inspect python modules.
>>
>
> Entirely by luck, I'd say :)
>
>
> ├───project.api.config
>> │ ├───project
>> │ │ └───api
>> │ │ └───config
>> │ │ └───settings
>> │ └───project.api.config.egg-info
>> ├───project.api.contacts
>> │ ├───project
>> │ │ └───api
>> │ │ └───contacts
>> │ │ ├───importer
>> │ │ └───views
>> │ └───project.api.contacts.egg-info
>>
>
> Regular code like "import project.api.config" worked fine, but now I'm
>> tryed
>> __import__('project.api.config'):
>>
>> $ bin/python
>>
>> import project.api.config
>>>>> __import__('project.api.config')
>>>>>
>>>> <module 'project from
>> 'c:\users\ad\project\src\project.api.contacts\project\__init__.pyc'>
>>
>
>
>
If someone is interesting - __import__ works but imp doesn't.
In my example:
>>> m = __import__('project.api.config')
>>> m
<module 'project from
'c:\users\ad\project\src\project.api.contacts\project\__init__.pyc'>
>>> m.api
<module 'project.api from
'c:\users\ad\project\src\project.api.contacts\project\api\__init__.pyc'>
>>> m.api.config
<module 'project.api.config'
from'c:\users\ad\project\src\project.api.config\project\api\config\__init__.pyc'>

Please note that the m and m.api pointed to first installing package with
namespace project.api but m.api.config have pointed to the proper file.

And releasing code with several distributions it is one of goals of
Distribute. And you might look to pypi for... zope. There is lot of package
which names starts from "zope."
It's really convenient

--
Andrew Degtiariov
DA-RIPE
Re: Import question [ In reply to ]
En Mon, 08 Feb 2010 06:37:53 -0300, Andrew Degtiariov
<andrew.degtiariov@gmail.com> escribió:
> 2010/2/6 Gabriel Genellina <gagsl-py2@yahoo.com.ar>
>> En Fri, 05 Feb 2010 13:21:47 -0300, Andrew Degtiariov
>> <andrew.degtiariov@gmail.com> escribió:
>>
>>
>>> Code of our project has split into several packages and we deploy the
>>> project using buildout.
>>> All worked fine until I need to dynamically inspect python modules.
>> Entirely by luck, I'd say :)
>>
>>
>> ├───project.api.config
>>> │ ├───project
>>> │ │ └───api
>>> │ │ └───config
>>> │ │ └───settings
>>> │ └───project.api.config.egg-info
>>> ├───project.api.contacts
>>> │ ├───project
>>> │ │ └───api
>>> │ │ └───contacts
>>> │ │ ├───importer
>>> │ │ └───views
>>> │ └───project.api.contacts.egg-info
>>>

> If someone is interesting - __import__ works but imp doesn't.
> In my example:
>>>> m = __import__('project.api.config')
>>>> m
> <module 'project from
> 'c:\users\ad\project\src\project.api.contacts\project\__init__.pyc'>
>>>> m.api
> <module 'project.api from
> 'c:\users\ad\project\src\project.api.contacts\project\api\__init__.pyc'>
>>>> m.api.config
> <module 'project.api.config'
> from'c:\users\ad\project\src\project.api.config\project\api\config\__init__.pyc'>
>
> Please note that the m and m.api pointed to first installing package with
> namespace project.api but m.api.config have pointed to the proper file.
>
> And releasing code with several distributions it is one of goals of
> Distribute. And you might look to pypi for... zope. There is lot of
> package
> which names starts from "zope."
> It's really convenient

Those are called namespace packages. Zope and Plone (ab)use them
extensively. The intended usage is to break up a big, monolithic package
[0] in parts that can be distributed independently. To implement a
namespace package, you need an empty __init__.py file with only these
lines [1]:

from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)

But think carefully if you really need namespace packages; they solve a
specific problem, aren't a general purpose technique. See [2] for a
discussion.

[0] Think of a huge behemoth with a "Z O P E" sign on both sides :)
[1] http://docs.python.org/library/pkgutil.html
[2] http://weblion.psu.edu/news/are-we-overusing-namespace-packages

--
Gabriel Genellina

--
http://mail.python.org/mailman/listinfo/python-list
Re: Import question [ In reply to ]
Those are called namespace packages. Zope and Plone (ab)use them

> extensively. The intended usage is to break up a big, monolithic package
> [0] in parts that can be distributed independently. To implement a
> namespace package, you need an empty __init__.py file with only these
> lines [1]:
>
> from pkgutil import extend_path
> __path__ = extend_path(__path__, __name__)
>
> But think carefully if you really need namespace packages; they solve a
> specific problem, aren't a general purpose technique. See [2] for a
> discussion.
>
> [0] Think of a huge behemoth with a "Z O P E" sign on both sides :)
> [1] http://docs.python.org/library/pkgutil.html
> [2] http://weblion.psu.edu/news/are-we-overusing-namespace-packages
>
>
Hm.. We are using pkg_resources.declare_namespace(__name__) but I think
pkgutil is much better.
And we are using buildout so the omelette might help me. Link [2] very
interesting.
Thank you, Gabrial.

--
Andrew Degtiariov
DA-RIPE
Re: Import Question [ In reply to ]
Il 20/02/2013 21:53, eli m ha scritto:
> How long does it take for the program to import something? I am asking this because i have like 7 imports at the beginning of my program and i am thinking thats the reason why it is slow to start up. Thanks in advance.
It depend of your code module code..

if inside your module there is some code (no def or class) this code
will be executed, and if for example you have some loop or some db query
this will be executed too.


regards,
Matteo



--
http://mail.python.org/mailman/listinfo/python-list
Re: Import Question [ In reply to ]
you can check each import as it varies in loading time: time python -c
"import [name of module]"

example: time python -c "import flask"

On Wed, Feb 20, 2013 at 12:53 PM, eli m <techgeek201@gmail.com> wrote:

> How long does it take for the program to import something? I am asking
> this because i have like 7 imports at the beginning of my program and i am
> thinking thats the reason why it is slow to start up. Thanks in advance.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
Re: Import Question [ In reply to ]
On 02/20/2013 03:53 PM, eli m wrote:
> How long does it take for the program to import something? I am asking this because i have like 7 imports at the beginning of my program and i am thinking thats the reason why it is slow to start up. Thanks in advance.
>

That would be easy to measure. If you just want a visible indication,
put a print before and after those imports, and see how long between.
Or use the time module to measure it.

Notice that it's possible to write a module that consumes hours during
import. All top level code will be executed. So if there's any
substantial code there that's not conditional, it'll cost you.

For the rest of the message, I'll assume you don't have any
time-consuming initialization code.

Since there are dozens of imports that happen before your code even
begins, I doubt if your own imports make that much difference. Further,
some of them are probably already imported, and it's very fast to
"import" something already in the cache. About as long as a dict lookup
followed by an assignment.

When I look at

len(list(sys.modules.iterkeys()))

in Python 2.7.3, I get the value 243 Some of them are binary modules,
which load pretty much instantaneously, and the others are probably
precompiled, but I still expect them to swamp the 7 you're doing. BTW,
if you measure it, be aware that the first time you import a module, it
must be compiled, but then it saves as a .pyc file, and the next time
it'll be much quicker.


--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: import question [ In reply to ]
On Fri, Nov 19, 2021 at 7:09 AM lucas <sjlukacs@gmail.com> wrote:
>
> hello one and all,
>
> are there any other ways to import a module or package other then the "import" or "from...import..." statements? i ask because i'm allowing programming on my web2py website and i don't want any accessing packages like os or sys.
>
> thank you in advance and have a great day, lucas
>

Yes, there are many. For starters, the importlib module can do
anything that importing can do, as can the __import__ function. Plus,
with Python code, you could open the file, read from it, and exec it.
There are myriad ways to fetch up code, and it's even possible to
break out of a sandbox without ever using a single underscore.

If you're trying to make a Python-in-Python sandbox, I recommend not.
Instead, use an OS-level sandbox (a chroot, probably some sort of CPU
usage limiting, etc), and use that to guard the entire Python process.
Python-in-Python will basically *never* be secure.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: import question [ In reply to ]
On Thu, Nov 18, 2021 at 12:21 PM Chris Angelico <rosuav@gmail.com> wrote:

> If you're trying to make a Python-in-Python sandbox, I recommend not.
> Instead, use an OS-level sandbox (a chroot, probably some sort of CPU
> usage limiting, etc), and use that to guard the entire Python process.
> Python-in-Python will basically *never* be secure.
>

Good advice to not try to sandbox python.

But chroot can sometimes be broken out of. It isn't a cure-all.
--
https://mail.python.org/mailman/listinfo/python-list
Re: import question [ In reply to ]
On 2021-11-17, lucas <sjlukacs@gmail.com> wrote:

> are there any other ways to import a module or package other then
> the "import" or "from...import..." statements? i ask because i'm
> allowing programming on my web2py website and i don't want any
> accessing packages like os or sys.

Safely allowing people to enter/upload and then execute Python code is
very difficult. From my brief research into that question a little
while (a year or two) ago, the answer was that can't really be done in
any general way. IIRC, some promising work was done in PyPy to address
this problem, but the sandbox stuff never got moved to Py3?

--
Grant
--
https://mail.python.org/mailman/listinfo/python-list
Re: import question [ In reply to ]
On Fri, Nov 19, 2021 at 11:24 AM Dan Stromberg <drsalists@gmail.com> wrote:
>
>
> On Thu, Nov 18, 2021 at 12:21 PM Chris Angelico <rosuav@gmail.com> wrote:
>>
>> If you're trying to make a Python-in-Python sandbox, I recommend not.
>> Instead, use an OS-level sandbox (a chroot, probably some sort of CPU
>> usage limiting, etc), and use that to guard the entire Python process.
>> Python-in-Python will basically *never* be secure.
>
>
> Good advice to not try to sandbox python.
>
> But chroot can sometimes be broken out of. It isn't a cure-all.
>

That's true, but it's way better than attempting Python-in-Python
sandboxing. In any case, all the options worth investigating will be
at the OS level.

(Or maybe higher, but I can't imagine it being practical to create
individual VMs for each client who comes to the web site.)

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: import question [ In reply to ]
On Thu, Nov 18, 2021 at 6:19 PM Chris Angelico <rosuav@gmail.com> wrote:

> On Fri, Nov 19, 2021 at 11:24 AM Dan Stromberg <drsalists@gmail.com>
> wrote:
> >
> >
> > On Thu, Nov 18, 2021 at 12:21 PM Chris Angelico <rosuav@gmail.com>
> wrote:
> >>
> >> If you're trying to make a Python-in-Python sandbox, I recommend not.
> >> Instead, use an OS-level sandbox (a chroot, probably some sort of CPU
> >> usage limiting, etc), and use that to guard the entire Python process.
> >> Python-in-Python will basically *never* be secure.
> >
> >
> > Good advice to not try to sandbox python.
> >
> > But chroot can sometimes be broken out of. It isn't a cure-all.
> >
>
> That's true, but it's way better than attempting Python-in-Python
> sandboxing. In any case, all the options worth investigating will be
> at the OS level.
>
> (Or maybe higher, but I can't imagine it being practical to create
> individual VMs for each client who comes to the web site.)
>

Actually, there are ports of CPython and Micropython that run inside a web
browser over WASM. Going with one of these might be safer.
--
https://mail.python.org/mailman/listinfo/python-list
Re: import question [ In reply to ]
On Fri, Nov 19, 2021 at 3:00 PM Dan Stromberg <drsalists@gmail.com> wrote:
>
>
> On Thu, Nov 18, 2021 at 6:19 PM Chris Angelico <rosuav@gmail.com> wrote:
>>
>> On Fri, Nov 19, 2021 at 11:24 AM Dan Stromberg <drsalists@gmail.com> wrote:
>> >
>> >
>> > On Thu, Nov 18, 2021 at 12:21 PM Chris Angelico <rosuav@gmail.com> wrote:
>> >>
>> >> If you're trying to make a Python-in-Python sandbox, I recommend not.
>> >> Instead, use an OS-level sandbox (a chroot, probably some sort of CPU
>> >> usage limiting, etc), and use that to guard the entire Python process.
>> >> Python-in-Python will basically *never* be secure.
>> >
>> >
>> > Good advice to not try to sandbox python.
>> >
>> > But chroot can sometimes be broken out of. It isn't a cure-all.
>> >
>>
>> That's true, but it's way better than attempting Python-in-Python
>> sandboxing. In any case, all the options worth investigating will be
>> at the OS level.
>>
>> (Or maybe higher, but I can't imagine it being practical to create
>> individual VMs for each client who comes to the web site.)
>
>
> Actually, there are ports of CPython and Micropython that run inside a web browser over WASM. Going with one of these might be safer.
>

Hmm, interesting point. I'd mentally ruled out the in-browser options
since the performance hit is usually far too costly, but if this is
basically an educational site, it MAY be sufficient (people won't need
spectacular performance when they're just learning the basics).

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: import question [ In reply to ]
ok. all good advice. thank you for that. and with all that I've decided what to do.

I'm going to close off any server-side python access so that I don't expose my server or the file system to vulnerabilities and/or wonton attacks. I am building a site for education and what I will configure is allow students to setup and save their projects on the server but only direct them to program in client-side Brython, which is a javascript translation of python for browsers, hence "Brython" or "browser python". my server will provide the javascript files for Brython and its standard libraries and any processing of the student's projects will be directly on the client-side. this way there is no access to the server or cpu or memory management problems. the server will simply server html and Brython-based text, i.e., static pages, to the client browser and the browser will process and interact with the Brython directly.

overall, the server will stay secure and the students can learn python through Brython. sound, right? Lucas
--
https://mail.python.org/mailman/listinfo/python-list
Re: import question [ In reply to ]
On 11/18/21 21:00, Dan Stromberg wrote:
> On Thu, Nov 18, 2021 at 6:19 PM Chris Angelico <rosuav@gmail.com> wrote:
>
>> On Fri, Nov 19, 2021 at 11:24 AM Dan Stromberg <drsalists@gmail.com>
>> wrote:
>>>
>>>
>>> On Thu, Nov 18, 2021 at 12:21 PM Chris Angelico <rosuav@gmail.com>
>> wrote:
>>>>
>>>> If you're trying to make a Python-in-Python sandbox, I recommend not.
>>>> Instead, use an OS-level sandbox (a chroot, probably some sort of CPU
>>>> usage limiting, etc), and use that to guard the entire Python process.
>>>> Python-in-Python will basically *never* be secure.
>>>
>>>
>>> Good advice to not try to sandbox python.
>>>
>>> But chroot can sometimes be broken out of. It isn't a cure-all.
>>>
>>
>> That's true, but it's way better than attempting Python-in-Python
>> sandboxing. In any case, all the options worth investigating will be
>> at the OS level.
>>
>> (Or maybe higher, but I can't imagine it being practical to create
>> individual VMs for each client who comes to the web site.)
>>
>
> Actually, there are ports of CPython and Micropython that run inside a web
> browser over WASM. Going with one of these might be safer.

indeed... see pyodide

https://github.com/pyodide/pyodide


--
https://mail.python.org/mailman/listinfo/python-list
Re: import question [ In reply to ]
On 20/11/2021 03.38, lucas wrote:
> ok. all good advice. thank you for that. and with all that I've decided what to do.
>
> I'm going to close off any server-side python access so that I don't expose my server or the file system to vulnerabilities and/or wonton attacks. I am building a site for education and what I will configure is allow students to setup and save their projects on the server but only direct them to program in client-side Brython, which is a javascript translation of python for browsers, hence "Brython" or "browser python". my server will provide the javascript files for Brython and its standard libraries and any processing of the student's projects will be directly on the client-side. this way there is no access to the server or cpu or memory management problems. the server will simply server html and Brython-based text, i.e., static pages, to the client browser and the browser will process and interact with the Brython directly.
>
> overall, the server will stay secure and the students can learn python through Brython. sound, right? Lucas


Alternately, 'stand on the shoulders of giants' and consider
https://pythontutor.com/visualize.html#mode=edit

This has the additional value for your trainees of showing a visual
execution of their code. They can see step-by-step how Python/the
computer interprets their (?perfect) instruction and exactly where
things fall-over - with-out the added complication/cognitive-load of
having to master a debugger!

If you're still determined to invest a lot of time, it looks as if Phil
has invested a lot of time, more recently, in widening the range of
languages, (which is perhaps why(?)) the system has fallen behind in
Python release.
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list