hello, friendliest prog lang community on earth ;)
i'm feeling that
(0) delegation pattern thru descriptor encourages dedicated delegate
for each task, if feeling: print(benefits)
(1) the delegate is designed to be blind about the class on which the
delegate is attached to
isn't that the two stre
if we limit our discussion to py:
why __{get|set|delete}__ don't receive the 'name' & 'class' from
__{getattribute|{set|del}attr}__
'name' is the name that is searched
'class' is the class whose __dict__ has 'name' bound to descriptor
delegator & delegator are terms from delegation pattern (oop) w
i'm confused which part that doesn't make sense?
this is my 2nd attempt to py, the 1st was on april this year, it was
just a month, i'm afraid i haven't got the fundamentals right yet. so
i'm gonna lay out how i got to this conclusion, CMIIW
**explanation of feeling (0) on my 1st post**
to me, des
thanks Greg,
you get most of what i meant
like i said before, i suspect descriptor encourages dedicated / not
shared descriptor obj. this encouragement is expressed in the design,
and the reasons behind the design were the ones that i was asking
about, not how to get around it
now, i'm asking anot
On Jul 5, 3:42 pm, Bruno Desthuilliers wrote:
> kedra marbun a écrit :
>
>
>
> > i'm confused which part that doesn't make sense?
> > this is my 2nd attempt to py, the 1st was on april this year, it was
> > just a month, i'm afraid i haven't go
On Jul 5, 7:49 am, Gregory Ewing wrote:
> kedra marbun wrote:
> > now, i'm asking another favor, what about the 2nd point in my 1st post?
>
> Your original post has dropped off my newsscope, so
> you'll have to remind me what the 2nd point was.
>
> --
> Gr
On Jul 5, 6:29 am, Steven D'Aprano wrote:
> On Sun, 04 Jul 2010 21:05:56 +, Tobiah wrote:
> > foo.py:
>
> > import bar
> > bar.show_importer()
>
> > output:
>
> > 'foo' or 'foo.py' or 'path/to/foo' etc.
>
> > Possible?
>
> I don't think so. Your question isn't even well-defined. Given three
>
On Jul 5, 4:05 am, Tobiah wrote:
> foo.py:
>
> import bar
> bar.show_importer()
>
> output:
>
> 'foo' or 'foo.py' or 'path/to/foo' etc.
>
> Possible?
>
> Thanks,
>
> Tobiah
if what you mean by 'importer' is the one that really cause py to load
the mod, then why not dynamically set it?
foo.py
---
module obj is instance of types.ModuleType, which is instance of
'type', where class obj is instance of 'type'. even only at this
point, they're diff in to many ways. there are so many things to do
when you truly want module to replace class, as pointed by 2 posts
above
i'm also a beginner, so i c
On Jul 7, 2:46 am, Bruno Desthuilliers
wrote:
> Gregory Ewing a écrit :
>
> > Bruno Desthuilliers wrote:
> >> kedra marbun a écrit :
>
> >>> if we limit our discussion to py:
> >>> why __{get|set|delete}__ don't receive the 'name' &a
On Jul 6, 12:11 pm, Steven D'Aprano wrote:
> On Mon, 05 Jul 2010 21:12:47 -0700, kedra marbun wrote:
> > On Jul 5, 7:49 am, Gregory Ewing wrote:
> >> kedra marbun wrote:
> >> > now, i'm asking another favor, what about the 2nd point in my 1st
> >&
On Jul 8, 4:02 pm, Bruno Desthuilliers wrote:
> kedra marbun a écrit :
>
>
>
> > On Jul 7, 2:46 am, Bruno Desthuilliers
> > wrote:
> >> Gregory Ewing a écrit :
>
> >>> Bruno Desthuilliers wrote:
> >>>> kedra marbun a écrit :
> >
On Jul 8, 5:10 pm, Gregory Ewing wrote:
> kedra marbun wrote:
> > i wonder what are the reasons for
> > not passing the class on which the descriptor is attached to, what
> > pattern is encouraged by this?
>
> The same answer applies. It's assumed that you will be
> from m import f
>
> look for module m in the global cache
> if not there, then:
> search for m.py
> compile it to a Module object
> put the Module object in the cache
> look for object named "f" in the Module object
agree
> create a new name "f" in the local namespace
> set the name
14 matches
Mail list logo
