Gerald Britton wrote:
Nope. it's nothing to do with imports. It's about objects passed to
methods at run time. Complicated objects with many levels. Not about
modules at all.
Who is providing these objects ?
- Your code ? => as said before, you can fix your design with a proper
object
Gerald Britton wrote:
however, considering what
"import a.module.that.is.quite.nested as myModule"
Won't work since I get the objects at run time
myModule = __import__('whatever.module.imported.at.run.time', globals(),
locals(), [], -1)
See http://docs.python.org/library/function
Gerald Britton wrote:
Hi all,
Today I was thinking about a problem I often encounter.
[snip]
1. You need to call this thing many times with different arguments, so
you wind up with:
x = some.deeply.nested.object.method(some.other.deeply.nested.object.value1)
y = some.deeply.nested.obj
On 1/30/11 1:13 PM, rantingrick wrote:
> On Jan 30, 12:53 pm, Stephen Hansen wrote:
>> OH MY GOD. How can someone be expected to understand what a function does!
>
> Yes, and also how decorators word and generators work, and ...
>
>> Be serious! You can't expect that of them.
>
> I don't. I don
On Sun, 30 Jan 2011 12:51:20 -0500, Gerald Britton wrote:
> Hi all,
>
> Today I was thinking about a problem I often encounter. Say that I have
> (seems I often do!) a deeply nested object, by which I mean object
> within object with object, etc.
>
> For example:
>
> x =
> some.deeply.ne
>
> I don't. I don't expect anyone to write 10 lines of obfuscation code
> when just two will suffice. Maybe you should join the perl group as
> they would proud!
But Stephen's 10 lines of somewhat obscure code actually works, and your two
lines of code doesn't. I know which one I would prefer.
On Jan 30, 12:53 pm, Stephen Hansen wrote:
> On 1/30/11 10:35 AM, rantingrick wrote:
>
> > Well congratulations Stephen, you win the obfuscation prize of the
> > year!
>
> Yes,
>
> On 1/30/11 10:09 AM, rantingrick wrote:
>
> > Here is how a pythonic local block would look
>
> > with this as localv
On 30/01/2011 17:51, Gerald Britton wrote:
Hi all,
Today I was thinking about a problem I often encounter. Say that I
have (seems I often do!) a deeply nested object, by which I mean
object within object with object, etc.
For example:
x = some.deeply.nested.object.method(some.other.deeply
On 1/30/11 10:35 AM, rantingrick wrote:
> Well congratulations Stephen, you win the obfuscation prize of the
> year!
Yes,
On 1/30/11 10:09 AM, rantingrick wrote:
> Here is how a pythonic local block would look
>
> with this as localvar:
> localvar.do_something()
verses
with my(this) as loca
On Jan 30, 12:23 pm, Stephen Hansen wrote:
> --- start
> from contextlib import contextmanager
>
> class Item(object): pass
>
> deeply = Item()
> deeply.nested = Item()
> deeply.nested.thing = Item()
>
> @contextmanager
> def my(thing):
> yield thing
>
> with my(deeply.nested.thing) as o:
>
On 1/30/11 9:51 AM, Gerald Britton wrote:
> 1. If you had to choose between approaches 1 and 2, which one would
> you go for, and why?
Neither. Ideally, I'd tweak the API around so the deeply nested
structure isn't something I need to access regularly. But! If you can't
do that, I'd do something l
In article ,
Gerald Britton wrote:
> 1. You need to call this thing many times with different arguments, so
> you wind up with:
>
> x =
> some.deeply.nested.object.method(some.other.deeply.nested.object.value1)
> y =
> some.deeply.nested.object.method(some.other.deeply.nested.object.val
On Jan 30, 11:51 am, Gerald Britton wrote:
[...]
> that I might confuse with the first. To make it look better I might do this:
>
> _o = some.deeply.nested.object
> _o.method(_o.value)
>
> which is fine, I suppose.
It is very fine. And you "supposed" correctly!
> Then, putting on my co
13 matches
Mail list logo
