Prev: Why Python forbids multiple instances of one module?
Next: eric 5.0.0 released
From: Anthra Norell on 5 Jul 2010 05:07
I try to use "new.new.classobj (name, baseclass, dict)" and have no clue
what the "dict" of the current name space is. I can name dicts of
imported modules, because their name exists in the current name space.
If, for instance, I import a module "service" then that module's name
space would be "service.__dict__". But if I import * from service, then
I incorporate that name space into the current one and I cannot name it,
because the current module's name is not part of the module's own name
space. "dir (service)" is equivalent to "service.__dict__.keys ()" if
service is importet. "dir ()" is equivalent to "?.__dict__.keys ()"
where "?" is the name of the current module, itself not part of the
current module's name space. So the question mark stands for an implicit
name that can be neither named nor dropped. So my question is: how does
one name the dictionary of the name space one is in?

Frederic

From: Thomas Jollans on 5 Jul 2010 05:27
On 07/05/2010 11:07 AM, Anthra Norell wrote:
> I try to use "new.new.classobj (name, baseclass, dict)" and have no clue
> what the "dict" of the current name space is. I can name dicts of
> imported modules, because their name exists in the current name space.
> If, for instance, I import a module "service" then that module's name
> space would be "service.__dict__". But if I import * from service, then
> I incorporate that name space into the current one and I cannot name it,
> because the current module's name is not part of the module's own name
> space. "dir (service)" is equivalent to "service.__dict__.keys ()" if
> service is importet. "dir ()" is equivalent to "?.__dict__.keys ()"
> where "?" is the name of the current module, itself not part of the
> current module's name space. So the question mark stands for an implicit
> name that can be neither named nor dropped. So my question is: how does
> one name the dictionary of the name space one is in?

either globals() or locals(), depending on what you mean.

>
> Frederic
>

From: Chris Rebert on 5 Jul 2010 06:03
On Mon, Jul 5, 2010 at 2:07 AM, Anthra Norell <anthra.norell(a)bluewin.ch> wrote:
> I try to use "new.new.classobj (name, baseclass, dict)" and have no clue

Slight tangent:
Note that both the `new` module and old-style classes (which are what
`classobj` produces) are deprecated.
To produce new-style classes dynamically, use `type`.

Cheers,
Chris
--
http://blog.rebertia.com
From: Anthra Norell on 5 Jul 2010 08:16
Thomas Jollans wrote:
> On 07/05/2010 11:07 AM, Anthra Norell wrote:
>
>> I try to use "new.new.classobj (name, baseclass, dict)" and have no clue
>> what the "dict" of the current name space is. I can name dicts of
>> imported modules, because their name exists in the current name space.
>> If, for instance, I import a module "service" then that module's name
>> space would be "service.__dict__". But if I import * from service, then
>> I incorporate that name space into the current one and I cannot name it,
>> because the current module's name is not part of the module's own name
>> space. "dir (service)" is equivalent to "service.__dict__.keys ()" if
>> service is importet. "dir ()" is equivalent to "?.__dict__.keys ()"
>> where "?" is the name of the current module, itself not part of the
>> current module's name space. So the question mark stands for an implicit
>> name that can be neither named nor dropped. So my question is: how does
>> one name the dictionary of the name space one is in?
>>
>
> either globals() or locals(), depending on what you mean.
>
>
>> Frederic
>>
>>

Thomas,
Thanks a million. Just the tip I needed.
Frederic

From: Anthra Norell on 5 Jul 2010 09:26
Chris Rebert wrote:
> On Mon, Jul 5, 2010 at 2:07 AM, Anthra Norell <anthra.norell(a)bluewin.ch> wrote:
>
>> I try to use "new.new.classobj (name, baseclass, dict)" and have no clue
>>
>
> Slight tangent:
> Note that both the `new` module and old-style classes (which are what
> `classobj` produces) are deprecated.
> To produce new-style classes dynamically, use `type`.
>
> Cheers,
> Chris
> --
> http://blog.rebertia.com
>
>
Chris,
I noticed the deprecation situation reading the doc, but opted for
what I thought might be more backward-compatible. Your suggestion
prompted me to take a closer look and it turns out that "types" is
compatible as far back as I have to go (2.5). So I use "types" with
thanks to you.
 |  Next  |  Last
Pages: 1 2
Prev: Why Python forbids multiple instances of one module?
Next: eric 5.0.0 released