On Jan 31, 12:27 am, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
> Python stores filename and line number information in code objects
> (only). If you have a reference to any code object (a method, a
> function, a traceback...) inspect can use it to retrieve that
> information.
Aside from general
Peter Schuller <[EMAIL PROTECTED]> writes:
> I *DON'T* want anything to depend on the physical location on disk.
Importing the code in the first place will — unavoidably, it seems to
me — depend on the file location from which to load the module.
After that, nothing depends on the physical locat
> It what sense will it not be? Why do you care so much about where the
> source code for Monkey is defined? If you actually want to read the
> source, you might need to follow the chain from "animal", see that Monkey
> is imported from "monkey", and go look at that. But the rest of the time,
>
> Well, all I will say is that many people on this list, myself
> included, do know Python internals, and we use the method we've been
> suggesting here, without problems.
Ok. That is useful to know (that it is being done in practice without
problems).
Thanks!
--
/ Peter Schuller
PGP userID: 0
On Jan 30, 4:31 am, Peter Schuller <[EMAIL PROTECTED]>
wrote:
> I don't know Python internals enough to state of believe with any
> authority wither, let's say, stomping __module__ and hacking
> sys.modules would be enough to *truly* do it correctly in a proper way
> such that it is entirely transp
On 30 ene, 12:00, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> I call that a bug in the inspect module. In fact, looking at the source
> for the findsource() function, I can see no fewer than two bugs, just in
> the way it handles classes:
>
> (1) it assumes that the only way to
On Tue, 29 Jan 2008 06:48:59 -0600, Peter Schuller wrote:
>> You can also put, in animal/__init__.py:
>> from monkey import Monkey
>> and now you can refer to it as org.lib.animal.Monkey, but keep the
>> implementation of Monkey class and all related stuff into
>> .../animal/monkey.py
>
> The pr
On Tue, 29 Jan 2008 13:44:33 -0600, Robert Kern wrote:
> Carl Banks wrote:
>> On Jan 29, 7:48 am, Peter Schuller <[EMAIL PROTECTED]> wrote:
You can also put, in animal/__init__.py:
from monkey import Monkey
and now you can refer to it as org.lib.animal.Monkey, but keep the
imp
>> The problem is that we are now back to the identity problem. The class
>> won't actually *BE* org.lib.animal.Monkey.
>
> The usage is the same; it works in all cases once you redefine
> __module__. Who cares what it really is?
The cases I listed were just examples. My point was that I wanted i
Carl Banks wrote:
> On Jan 29, 7:48 am, Peter Schuller <[EMAIL PROTECTED]>
> wrote:
>>> You can also put, in animal/__init__.py:
>>> from monkey import Monkey
>>> and now you can refer to it as org.lib.animal.Monkey, but keep the
>>> implementation of Monkey class and all related stuff into
>>> ..
On Jan 29, 7:48 am, Peter Schuller <[EMAIL PROTECTED]>
wrote:
> > You can also put, in animal/__init__.py:
> > from monkey import Monkey
> > and now you can refer to it as org.lib.animal.Monkey, but keep the
> > implementation of Monkey class and all related stuff into
> > .../animal/monkey.py
>
>
> You can reassign the class's module:
>
> from org.lib.animal.monkey import Monkey
> Monkey.__module__ = 'org.lib.animal'
>
>
> (Which, I must admit, is not a bad idea in some cases.)
Is there a sense whether this is truly a supported way of doing this,
in terms of not running into various uninte
> You can also put, in animal/__init__.py:
> from monkey import Monkey
> and now you can refer to it as org.lib.animal.Monkey, but keep the
> implementation of Monkey class and all related stuff into
> .../animal/monkey.py
The problem is that we are now back to the identity problem. The class
Carl Banks <[EMAIL PROTECTED]> writes:
> On Jan 25, 6:45 pm, Ben Finney <[EMAIL PROTECTED]>
> wrote:
> > "Gabriel Genellina" <[EMAIL PROTECTED]> writes:
> > > You can also put, in animal/__init__.py:
> > > from monkey import Monkey
> > > and now you can refer to it as org.lib.animal.Monkey, but ke
On Jan 25, 6:45 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> "Gabriel Genellina" <[EMAIL PROTECTED]> writes:
> > You can also put, in animal/__init__.py:
> > from monkey import Monkey
> > and now you can refer to it as org.lib.animal.Monkey, but keep the
> > implementation of Monkey class and all re
"Gabriel Genellina" <[EMAIL PROTECTED]> writes:
> You can also put, in animal/__init__.py:
> from monkey import Monkey
> and now you can refer to it as org.lib.animal.Monkey, but keep the
> implementation of Monkey class and all related stuff into
> .../animal/monkey.py
This (as far as I can unde
En Thu, 24 Jan 2008 11:57:49 -0200, Peter Schuller
<[EMAIL PROTECTED]> escribió:
> In this case my
> problem is more related to the "file == module" and "directory ==
> module" semantics, since I want to break contents in a single module
> out into several files.
You already can do that, just i
>> Not necessarily. In part it is the name, in that __name__ will be
>> different. But to the extent that calling code can potentially import
>> them under differents names, it's identity. Because importing the same
>> module under two names results in two distinct modules (two distinct
>> module o
En Thu, 24 Jan 2008 05:16:51 -0200, Peter Schuller
<[EMAIL PROTECTED]> escribió:
>>> I do *not* want to simply break out X into org.lib.animal.x, and
>>> have org.lib.animal import org.lib.animal.x.X as X.
>>
>>> While this naively solves the problem of being able to refer to X as
>>> org.lib.an
On Jan 23, 4:49 am, Peter Schuller <[EMAIL PROTECTED]>
wrote:
> I do *not* want to simply break out X into org.lib.animal.x, and have
> org.lib.animal import org.lib.animal.x.X as X. While this naively
> solves the problem of being able to refer to X as org.lib.animal.X,
> the solution is anything
>> I do *not* want to simply break out X into org.lib.animal.x, and
>> have org.lib.animal import org.lib.animal.x.X as X.
>
> Nevertheless, that seems the best (indeed, the Pythonic) solution to
> your problem as stated. Rather than just shooting it down, we'll have
> to know more about ehat actua
Peter Schuller <[EMAIL PROTECTED]> writes:
> Let me just shoot down one possible suggestion right away, to show
> you what I am trying to accomplish:
>
> I do *not* want to simply break out X into org.lib.animal.x, and
> have org.lib.animal import org.lib.animal.x.X as X.
Nevertheless, that seem
On Wed, 23 Jan 2008 03:49:56 -0600, Peter Schuller wrote:
> Let me just shoot down one possible suggestion right away, to show you
> what I am trying to accomplish:
>
> I do *not* want to simply break out X into org.lib.animal.x, and have
> org.lib.animal import org.lib.animal.x.X as X.
Then you
Hello,
In writing some non-trivial amount of Python code I keep running into
an organizational issue. I will try to state the problem fairly
generally, and follow up with a (contrived) example.
The root cause of my difficulties is that by default, the relationship
between a module hierarchy and t
24 matches
Mail list logo
