On Tue, 26 Mar 2013 14:19:21 +0800, Shiyao Ma wrote:
> PS, I now python's scoping rule is lexical rule (aka static rule). How
> does LEGB apply to class?
It doesn't. Python does not use the same lookup rules for attributes and
unqualified names.
Attribute lookups follow inheritance rules. `inst
After read Dave's answer, I think I confused LEGB with attribute lookup.
So, a.r has nothing to do with LEGB.
On Tue, Mar 26, 2013 at 7:03 PM, Shiyao Ma wrote:
> Thx, really a nice and detailed explanation.
>
>
> On Tue, Mar 26, 2013 at 6:07 PM, Dave Angel wrote:
>
>> On 03/26/2013 02:17 AM, Sh
Thx, really a nice and detailed explanation.
On Tue, Mar 26, 2013 at 6:07 PM, Dave Angel wrote:
> On 03/26/2013 02:17 AM, Shiyao Ma wrote:
>
>> Hi,
>> suppose I have a file like this:
>> class A:
>> r = 5
>> def func(self, s):
>> self.s = s
>> a = A()
>> print(a.r)# this s
Sorry for my obscure description.
"the name of r" , AFAIK, everything in python is just a reference. For
example, a = 3, means a points to a small integer; b= [] means b points to
a list somewhere in the memory. So I call r as the name of r.
To clarify my question.
say I wanna look up a.r
I guess
On 03/26/2013 02:17 AM, Shiyao Ma wrote:
Hi,
suppose I have a file like this:
class A:
r = 5
def func(self, s):
self.s = s
a = A()
print(a.r)# this should print 5, but where does py store the name of r
a.func(3)
print(a.s)# this should print 3, also where does py store
On 3/26/2013 2:17 AM, Shiyao Ma wrote:
Hi,
suppose I have a file like this:
class A:
r = 5
def func(self, s):
self.s = s
a = A()
print(a.r)# this should print 5, but where does py store the name of r
a.func(3)
print(a.s)# this should print 3, also where does py store t
On Tue, Mar 26, 2013 at 5:17 PM, Shiyao Ma wrote:
> class A:
> r = 5
> def func(self, s):
> self.s = s
> a = A()
> print(a.r)# this should print 5, but where does py store the name of r
What do you mean by "the name of r"?
ChrisA
--
http://mail.python.org/mailman/listinfo/py
PS, I now python's scoping rule is lexical rule (aka static rule). How does
LEGB apply to class?
On Tue, Mar 26, 2013 at 2:17 PM, Shiyao Ma wrote:
> Hi,
> suppose I have a file like this:
> class A:
> r = 5
> def func(self, s):
> self.s = s
> a = A()
> print(a.r)# this should
Hi,
suppose I have a file like this:
class A:
r = 5
def func(self, s):
self.s = s
a = A()
print(a.r)# this should print 5, but where does py store the name of r
a.func(3)
print(a.s)# this should print 3, also where does py store this name.
what's the underlying difference b
On 21 Giu, 06:06, Ben Finney wrote:
> Chris Angelico writes:
> > On Tue, Jun 21, 2011 at 12:38 PM, Ben Finney
> > wrote:
> > > The *binding* is scoped.
>
> > And the binding follows the exact same rules as anything else would.
> > It has scope and visibility. In terms of the OP, the binding IS
Chris Angelico writes:
> On Tue, Jun 21, 2011 at 12:38 PM, Ben Finney
> wrote:
> > The *binding* is scoped.
>
> And the binding follows the exact same rules as anything else would.
> It has scope and visibility. In terms of the OP, the binding IS like a
> variable.
Yes. So let's stop behaving
On Tue, Jun 21, 2011 at 12:38 PM, Ben Finney wrote:
> The *binding* is scoped.
>
And the binding follows the exact same rules as anything else would.
It has scope and visibility. In terms of the OP, the binding IS like a
variable.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Chris Angelico writes:
> On Tue, Jun 21, 2011 at 10:39 AM, Ben Finney
> wrote:
> > Instead, Python has objects, and references to those objects so you
> > can get at them. The Python documentation, much to my frustration,
> > calls these references “variables” even though that gives exactly
>
On Mon, 20 Jun 2011 15:35:35 -0700, gervaz wrote:
> Hi all, can you explain me why this simple function works well (i.e. I
> can call the print function using txt) in py
>
def test(value):
> ... if value%5: txt = "hello"
> ... else: txt = "test"
> ... print(txt)
>
> while in oth
On Tue, Jun 21, 2011 at 10:39 AM, Ben Finney wrote:
> gervaz writes:
> Python doesn't have variables the way C or many other languages have
> them.
>
> Instead, Python has objects, and references to those objects so you can
> get at them. The Python documentation, much to my frustration, calls
>
gervaz writes:
> Hi all, can you explain me why this simple function works well (i.e. I
> can call the print function using txt) in py
>
> >>> def test(value):
> ... if value%5: txt = "hello"
> ... else: txt = "test"
> ... print(txt)
>
> while in other languages like C the txt identif
On Tue, Jun 21, 2011 at 8:35 AM, gervaz wrote:
> Hi all, can you explain me why this simple function works well (i.e. I
> can call the print function using txt) in py
>
def test(value):
> ... if value%5: txt = "hello"
> ... else: txt = "test"
> ... print(txt)
It's as though you h
Hi all, can you explain me why this simple function works well (i.e. I
can call the print function using txt) in py
>>> def test(value):
... if value%5: txt = "hello"
... else: txt = "test"
... print(txt)
while in other languages like C the txt identifier would be undefined?
Is there
In Ethan Furman
writes:
>kj wrote:
>> Miles Kaufmann writes:
>>>...because the suite
>>>namespace and the class namespace would get out of sync when different
>>>objects were assigned to the class namespace:
>>
>>
>>>class C:
>>> x = 1
>>> def foo(self):
>>> print x
>>> print
kj wrote:
Miles Kaufmann writes:
...because the suite
namespace and the class namespace would get out of sync when different
objects were assigned to the class namespace:
class C:
x = 1
def foo(self):
print x
print self.x
o = C()
o.foo()
1
1
o.x = 2
o.foo()
1
2
B
kj a écrit :
In <4a967b2f$0$19301$426a7...@news.free.fr> Bruno Desthuilliers
writes:
The only thing one is entitled to expect when learning a new language is
that the language's implementation follows the language specs.
In fact, the official docs, when they discuss scopes, are off to
a bad
On Fri, Aug 28, 2009 at 1:48 PM, Xavier Ho wrote:
>
> Class already provides some kind of scoping/namespace, that is the locals()
> method for the class. What is pypothetical about this, if you could
> elaborate?
>
Obviously that was supposed to be "hypothetical". Oops.
--
http://mail.python.or
On Fri, Aug 28, 2009 at 1:27 PM, Miles Kaufmann wrote:
> You're right, of course. If I had been thinking properly, I would have
> posted this:
>
> ... the suite namespace and the class namespace would get out of sync when
> different objects were assigned to the class namespace:
I'm not an exp
On Aug 27, 2009, at 4:49 PM, kj wrote:
Miles Kaufmann writes:
Guido's design justifications:
http://mail.python.org/pipermail/python-dev/2000-November/010598.html
Ah! Clarity! Thanks! How did you find this? Did you know of
this post already? Or is there some special way to search Guido'
kj wrote:
> But this unfortunate situation is already possible, because one
> can already define
>
> class C:
> x = 1
> def foo(self):
> print C.x
> print self.x
How is this a problem? There is no ambiguity between the global scope and
the local from within foo.
>From wi
On Fri, Aug 28, 2009 at 9:49 AM, kj wrote:
>
> Miles Kaufmann writes:
>
> >...because the suite
> >namespace and the class namespace would get out of sync when different
> >objects were assigned to the class namespace:
>
> >class C:
> > x = 1
> > def foo(self):
> > print x
> > pr
Miles Kaufmann writes:
>On Aug 26, 2009, at 1:11 PM, kj wrote:
>> I think I understand the answers well enough. What I *really*
>> don't understand is why this particular "feature" of Python (i.e.
>> that functions defined within a class statement are forbidden from
>> "seeing" other identifier
> kj (k) wrote:
>k> No, the fact() function here represents an internal "helper"
>k> function. It is meant to be called only once to help initialize
>k> a class variable that would be inconvenient to initialize otherwise;
>k> this helper function is not meant to be called from outside the
>k
On Aug 26, 2009, at 1:11 PM, kj wrote:
I think I understand the answers well enough. What I *really*
don't understand is why this particular "feature" of Python (i.e.
that functions defined within a class statement are forbidden from
"seeing" other identifiers defined within the class statement)
14:17:15 Steven D'Aprano wrote:
The class is a scope, and inside the class scope, you can access local
names. What you can't do is access the class scope from inside nested
functions.
s/from inside nested functions/from inside nested scopes
Besides that detail, I fully agree.
*j
--
Jan Kal
In <4a967b2f$0$19301$426a7...@news.free.fr> Bruno Desthuilliers
writes:
>The only thing one is entitled to expect when learning a new language is
>that the language's implementation follows the language specs.
In fact, the official docs, when they discuss scopes, are off to
a bad start:
Nam
On Thursday 27 August 2009 11:31:41 Steven D'Aprano wrote:
>
> What you are calculating might actually be quite complicated to enter as
> a literal. You might have something like:
8< -- Complicated Table Example ---
Me? - never! I am just an assembler program
On Thursday 27 August 2009 11:14:41 Steven D'Aprano wrote:
> On Thu, 27 Aug 2009 08:38:29 +0200, Hendrik van Rooyen wrote:
> > On Wednesday 26 August 2009 17:14:27 kj wrote:
> >> As I described at length in another reply, the function in question is
> >> not intended to be "callable outside the cla
On Thu, 27 Aug 2009 09:10:46 +0100
Stephen Fairchild wrote:
> So why didn't you delete it after you were done with it?
>
> Class Demo(object):
That should be "class".
> _classvar = fact(5)
> del fact()
I suppose you mean "del fact".
--
D'Arcy J.M. Cain | Democracy is three
Jean-Michel Pichavant a écrit :
kj wrote:
I think I understand the answers well enough. What I *really*
don't understand is why this particular "feature" of Python (i.e.
that functions defined within a class statement are forbidden from
"seeing" other identifiers defined within the class statem
In <02a6427a$0$15633$c3e8...@news.astraweb.com> Steven D'Aprano
writes:
>On Thu, 27 Aug 2009 09:09:21 +0200, Hendrik van Rooyen wrote:
>> On Wednesday 26 August 2009 17:45:54 kj wrote:
>>> In <02a54597$0$20629$c3e8...@news.astraweb.com> Steven D'Aprano
>> writes:
>>
>>> >Why are you defining
In Jean-Michel Pichavant
writes:
>in foo.py:
>a = 5
>b = a # works fine
>
>def foo(self):
> e = 5
> f = e #works fine
>It may be solved by creating the class upon the "class" statement. If
>the class A object is created, then c is added as a property of that
>object, th
On Thu, 27 Aug 2009 13:45:00 +0200, Jean-Michel Pichavant wrote:
> in foo.py:
>
> a = 5
> b = a # works fine
>
> class A:
> c = 5
> d = c # broken
Incorrect. That works fine.
>>> class A:
... c = 5
... d = c # not actually broken
...
>>> A.c
5
>>> A.d
5
The class is a scope, a
In Jean-Michel Pichavant
writes:
>kj wrote:
>> I think I understand the answers well enough. What I *really*
>> don't understand is why this particular "feature" of Python (i.e.
>> that functions defined within a class statement are forbidden from
>> "seeing" other identifiers defined within t
kj wrote:
I think I understand the answers well enough. What I *really*
don't understand is why this particular "feature" of Python (i.e.
that functions defined within a class statement are forbidden from
"seeing" other identifiers defined within the class statement) is
generally considered to b
Ulrich Eckhardt wrote:
Ulrich Eckhardt wrote:
Jean-Michel Pichavant wrote:
class Color:
def __init__(self, r, g,b):
pass
BLACK = Color(0,0,0)
It make sens from a design point of view to put BLACK in the Color
namespace. But I don't think it's possible with python.
kj wrote:
No, the fact() function here represents an internal "helper"
function. It is meant to be called only once to help initialize
a class variable that would be inconvenient to initialize otherwise;
this helper function is not meant to be called from outside the
class statement.
That, to
On Thu, 27 Aug 2009 09:09:21 +0200, Hendrik van Rooyen wrote:
> On Wednesday 26 August 2009 17:45:54 kj wrote:
>> In <02a54597$0$20629$c3e8...@news.astraweb.com> Steven D'Aprano
> writes:
>
>> >Why are you defining a method without a self parameter?
>>
>> Because, as I've explained elsewhere, it
On Thu, 27 Aug 2009 08:38:29 +0200, Hendrik van Rooyen wrote:
> On Wednesday 26 August 2009 17:14:27 kj wrote:
>
>> As I described at length in another reply, the function in question is
>> not intended to be "callable outside the class". And yes,
>
> I think this might go to nub of your proble
kj a écrit :
In "Martin P. Hellwig"
writes:
kj wrote:
First, one of the goals of OO is encapsulation, not only at the
level of instances, but also at the level of classes.
Who says?
Python itself: it already offers a limited form of class encapsulation
(e.g. class variables).
"class
kj a écrit :
In <1bf83a7e-f9eb-46ff-84fe-cf42d9608...@j21g2000yqe.googlegroups.com> Carl Banks
writes:
Yeah, it's a little surprising that you can't access class scope from
a function, but that has nothing to do with encapsulation.
It does: it thwarts encapsulation. The helper function in
kj a écrit :
(snip)
I fully agree that this case is rather vexing to my (and obviously your)
biased brain. I wouldn't call this a bug before fully understanding why
e.g. you can not access a class before its definition is finished.
I understand this, what I don't understand is why do it this
kj wrote:
> Because, as I've explained elsewhere, it is not a method: it's a
> "helper" function, meant to be called only once, within the class
> statement itself.
So why didn't you delete it after you were done with it?
Class Demo(object):
def fact(x):
...
_classvar = fact(5)
Ulrich Eckhardt a écrit :
(snip)
Now, what actually causes problems is that 'fact_rec' is not universally
accessible until class 'Demo' is fully defined, but you need this in order
to fully define it. Here comes a drawback of the dynamic nature of Python,
that the declaration phase (compiling) i
kj wrote:
I think I understand the answers well enough. What I *really*
don't understand is why this particular "feature" of Python (i.e.
that functions defined within a class statement are forbidden from
"seeing" other identifiers defined within the class statement) is
generally considered to
On Wednesday 26 August 2009 17:45:54 kj wrote:
> In <02a54597$0$20629$c3e8...@news.astraweb.com> Steven D'Aprano
writes:
> >Why are you defining a method without a self parameter?
>
> Because, as I've explained elsewhere, it is not a method: it's a
> "helper" function, meant to be called only on
On Wednesday 26 August 2009 17:14:27 kj wrote:
> As I described at length in another reply, the function in question
> is not intended to be "callable outside the class". And yes,
I think this might go to nub of your problem - It might help you to think as
follows:
A Python class, even after
26-08-2009 o 17:45:54 kj wrote:
In <02a54597$0$20629$c3e8...@news.astraweb.com> Steven D'Aprano
writes:
On Wed, 26 Aug 2009 10:57:32 +, kj wrote:
Recursion! One of the central concepts in the theory of
functions! This is shown most clearly by the following elaboration of
my origin
kj wrote:
I think I understand the answers well enough. What I *really*
don't understand is why this particular "feature" of Python (i.e.
that functions defined within a class statement are forbidden from
"seeing" other identifiers defined within the class statement) is
generally considered to b
26-08-2009 o 09:03:27 Ulrich Eckhardt wrote:
Jean-Michel Pichavant wrote:
class Color:
def __init__(self, r, g,b):
pass
BLACK = Color(0,0,0)
It make sens from a design point of view to put BLACK in the Color
namespace. But I don't think it's possible with python.
class Col
In <2a7gm6-9h@satorlaser.homedns.org> Ulrich Eckhardt
writes:
>kj wrote:
>> class Demo(object):
>> def fact_iter(n):
>> ret = 1
>> for i in range(1, n + 1):
>> ret *= i
>> return ret
>>
>> def fact_rec(n):
>> if n < 2:
>> retur
In <7figv3f2m3p0...@mid.uni-berlin.de> "Diez B. Roggisch"
writes:
>But if you insist on the above methodology, you can do this:
>class Demo(object):
>def fact(n):
>def inner(n):
>if n < 2:
>return 1
>else:
>return n * inner(n
In Ethan Furman
writes:
>Going back through the archives I found Arnaud's post with this decorator:
>def bindfunc(f):
> def boundf(*args, **kwargs):
> return f(boundf, *args, **kwargs)
> return boundf
>If you use it on your fact function like so...
>class Demo(object):
>
Carl Banks wrote:
On Aug 26, 8:13 am, Dave Angel wrote:
You can probably work around this by replacing the staticmethod
decorator with an equivalent function call:.
class Demo9(object):
def fact(n):
if n < 2:
return 1
else:
return n * Demo.fact(n
In <02a54597$0$20629$c3e8...@news.astraweb.com> Steven D'Aprano
writes:
>http://docs.python.org/reference/executionmodel.html
>It is also discussed in the PEP introducing nested scopes to Python:
>http://www.python.org/dev/peps/pep-0227/
>It's even eluded to in the tutorial:
>http://docs.pyt
kj wrote:
I have many years of programming experience, and a few languages,
under my belt, but still Python scoping rules remain mysterious to
me. (In fact, Python's scoping behavior is the main reason I gave
up several earlier attempts to learn Python.)
Here's a toy example il
kj wrote:
In <7figv3f2m3p0...@mid.uni-berlin.de> "Diez B. Roggisch"
writes:
Classes are not scopes.
Classes are objects. In particular, they are (by default) instances of
class 'type'. Unless 'scopes' were instances of some other metaclass,
the statement has to be true. I understand 'sco
kj wrote:
> class Demo(object):
> def fact_iter(n):
> ret = 1
> for i in range(1, n + 1):
> ret *= i
> return ret
>
> def fact_rec(n):
> if n < 2:
> return 1
> else:
> return n * fact_rec(n - 1)
>
> classvar1
On Wed, 26 Aug 2009 15:36:35 +, kj wrote:
> In <1bf83a7e-f9eb-46ff-84fe-cf42d9608...@j21g2000yqe.googlegroups.com>
> Carl Banks writes:
>
>>Yeah, it's a little surprising that you can't access class scope from a
>>function, but that has nothing to do with encapsulation.
>
> It does: it thwa
On Aug 26, 8:36 am, kj wrote:
> In <1bf83a7e-f9eb-46ff-84fe-cf42d9608...@j21g2000yqe.googlegroups.com> Carl
> Banks writes:
>
> >Yeah, it's a little surprising that you can't access class scope from
> >a function, but that has nothing to do with encapsulation.
>
> It does: it thwarts encapsulati
On Wed, 26 Aug 2009 14:09:57 +, kj wrote:
>>1. One of the key aspects of Python's design is that attributes must be
>>accessed explicitly with dot notation. Accessing class scopes from
>>nested functions would (seemingly) allow access to class attributes
>>without the dotted notation. Theref
In <02a54597$0$20629$c3e8...@news.astraweb.com> Steven D'Aprano
writes:
>On Wed, 26 Aug 2009 10:57:32 +, kj wrote:
>> Recursion! One of the central concepts in the theory of
>> functions! This is shown most clearly by the following elaboration of
>> my original example:
>>
>> class Demo(
kj wrote:
>
> Needless to say, I'm pretty beat by this point. Any help would be
> appreciated.
>
> Thanks,
Based on your statement above, and the fact that multiple people have
now explained *exactly* why your attempt at recursion hasn't worked, it
might be a good idea to step back, accept the a
On Wed, 26 Aug 2009 13:57:23 +, kj wrote:
> In "Martin P. Hellwig"
> writes:
>
>>kj wrote:
>>
>>> First, one of the goals of OO is encapsulation, not only at the level
>>> of instances, but also at the level of classes.
>>Who says?
>
> Python itself: it already offers a limited form of cla
In <1bf83a7e-f9eb-46ff-84fe-cf42d9608...@j21g2000yqe.googlegroups.com> Carl
Banks writes:
>Yeah, it's a little surprising that you can't access class scope from
>a function, but that has nothing to do with encapsulation.
It does: it thwarts encapsulation. The helper function in my
example is o
On Wed, 26 Aug 2009 10:57:32 +, kj wrote:
> In <7figv3f2m3p0...@mid.uni-berlin.de> "Diez B. Roggisch"
> writes:
>
>>Classes are not scopes.
>
> This looks to me like a major wart, on two counts.
>
> First, one of the goals of OO is encapsulation, not only at the level of
> instances, but a
On Aug 26, 8:13 am, Dave Angel wrote:
> You can probably work around this by replacing the staticmethod
> decorator with an equivalent function call:.
>
> class Demo9(object):
> def fact(n):
> if n < 2:
> return 1
> else:
> return n * Demo.fact(n - 1)
>
In <1bf83a7e-f9eb-46ff-84fe-cf42d9608...@j21g2000yqe.googlegroups.com> Carl
Banks writes:
>On Aug 26, 7:09=A0am, kj wrote:
>> In <16b72319-8023-471c-ba40-8025aa6d4...@a26g2000yqn.googlegroups.com> Ca=
>rl Banks writes:
>>
>> >> First, one of the goals of OO is encapsulation, not only at the
>>
In Dave Angel
writes:
>Thanks for diluting my point. The OP is chasing the wrong problem. Who
>cares whether a class initializer can call a method, if the method
>doesn't meet its original requirements, to be callable outside the class?
>And the arguments about how recursion is restricted
kj wrote:
In <7figv3f2m3p0...@mid.uni-berlin.de> "Diez B. Roggisch"
writes:
Classes are not scopes.
This looks to me like a major wart, on two counts.
First, one of the goals of OO is encapsulation, not only at the
level of instances, but also at the level of classes. Your comment
In Dave Angel
writes:
>Stephen Fairchild wrote:
>> You are trying to run code in a class that does not exist yet.
>>
>> def Demo():
>> def fact(n):
>> if n < 2:
>> return 1
>> else:
>> return n * fact(n - 1)
>> return type("Demo", (object,), {"fa
On Aug 26, 7:09 am, kj wrote:
> In <16b72319-8023-471c-ba40-8025aa6d4...@a26g2000yqn.googlegroups.com> Carl
> Banks writes:
>
> >> First, one of the goals of OO is encapsulation, not only at the
> >> level of instances, but also at the level of classes. =A0Your comment
> >> suggests that Python
kj wrote:
> Is there any good reason (from the point of view of Python's overall
> design) for not fixing this?
Python is not a compiled language, in the sense that a compiler can go back
and forth over the program, filling in the details that make the program
runnable. Python is an interprete
7stud wrote:
On Aug 25, 7:26 pm, Dave Angel wrote:
Stephen Fairchild wrote:
You are trying to run code in a class that does not exist yet.
def Demo():
def fact(n):
if n < 2:
return 1
else:
return n * fact(n - 1)
return type("Demo"
In <16b72319-8023-471c-ba40-8025aa6d4...@a26g2000yqn.googlegroups.com> Carl
Banks writes:
>> First, one of the goals of OO is encapsulation, not only at the
>> level of instances, but also at the level of classes. =A0Your comment
>> suggests that Python does not fully support class-level encaps
In "Martin P. Hellwig"
writes:
>kj wrote:
>
>> First, one of the goals of OO is encapsulation, not only at the
>> level of instances, but also at the level of classes.
>Who says?
Python itself: it already offers a limited form of class encapsulation
(e.g. class variables). It would be nice if
On Aug 25, 7:26 pm, Dave Angel wrote:
> Stephen Fairchild wrote:
> > You are trying to run code in a class that does not exist yet.
>
> > def Demo():
> > def fact(n):
> > if n < 2:
> > return 1
> > else:
> > return n * fact(n - 1)
> > return type("De
kj wrote:
First, one of the goals of OO is encapsulation, not only at the
level of instances, but also at the level of classes.
Who says?
Anyway, you could be right (I am not capable to judge it) and Python
should change on this issue but from what I gathered, Pythons OO is
inspired by the fo
Ulrich Eckhardt wrote:
Jean-Michel Pichavant wrote:
class Color:
def __init__(self, r, g,b):
pass
BLACK = Color(0,0,0)
It make sens from a design point of view to put BLACK in the Color
namespace. But I don't think it's possible with python.
class Color:
...
set
On Aug 26, 3:57 am, kj wrote:
> In <7figv3f2m3p0...@mid.uni-berlin.de> "Diez B. Roggisch"
> writes:
>
> >Classes are not scopes.
>
> This looks to me like a major wart, on two counts.
Class statements *are* scopes, they are just not accessible from
scopes nested within them.
> First, one of t
Ulrich Eckhardt wrote:
> Jean-Michel Pichavant wrote:
>> class Color:
>> def __init__(self, r, g,b):
>> pass
>> BLACK = Color(0,0,0)
>>
>> It make sens from a design point of view to put BLACK in the Color
>> namespace. But I don't think it's possible with python.
>
> class Colo
In <7figv3f2m3p0...@mid.uni-berlin.de> "Diez B. Roggisch"
writes:
>Classes are not scopes.
This looks to me like a major wart, on two counts.
First, one of the goals of OO is encapsulation, not only at the
level of instances, but also at the level of classes. Your comment
suggests that Python
In John Posner
writes:
>Stephen Hansen said:
>> This sounds like a fundamental confusion -- a namespace is not
>> equivalent to a scope, really, I think.
>> ...
Hmm. I can't find Stephen Hansen's original post anywhere. Where
did you come across it?
Is there an *official* write-up where th
Jean-Michel Pichavant wrote:
> class Color:
> def __init__(self, r, g,b):
> pass
> BLACK = Color(0,0,0)
>
> It make sens from a design point of view to put BLACK in the Color
> namespace. But I don't think it's possible with python.
class Color:
...
setattrib(Color, "BLACK"
Stephen Fairchild wrote:
You are trying to run code in a class that does not exist yet.
def Demo():
def fact(n):
if n < 2:
return 1
else:
return n * fact(n - 1)
return type("Demo", (object,), {"fact": staticmethod(fact), "_classvar":
fact(5)})
De
You are trying to run code in a class that does not exist yet.
def Demo():
def fact(n):
if n < 2:
return 1
else:
return n * fact(n - 1)
return type("Demo", (object,), {"fact": staticmethod(fact), "_classvar":
fact(5)})
Demo = Demo()
d = Demo()
pri
25-08-2009 o 22:16:24 Stephen Hansen wrote:
The OP's probably is that during the execution of the class body, the
class
doesn't exist... so the 'def fact' -can't- use Classname.fact to address
itself explicitly, and within fact the locals don't contain a reference
to
the function itself, an
Stephen Hansen said:
But http://docs.python.org/tutorial/classes.html says, in Section
9.3 "A First Look at Classes":
When a class definition is entered, a new namespace is created,
and used as the local scope — thus, all assignments to local variables
go into this new name
>
>
> But http://docs.python.org/tutorial/classes.html says, in Section 9.3 "A
> First Look at Classes":
>
> When a class definition is entered, a new namespace is created,
> and used as the local scope — thus, all assignments to local variables
> go into this new namespace. In particular, function
John Posner schrieb:
Diez said:
Classes are not scopes.
So the above doesn't work because name resolution inside
functions/methods
looks for local variables first, then for the *global* scope. There is no
class-scope-lookup.
But http://docs.python.org/tutorial/classes.html says, in Section
7stud said:
python ignores the names inside a function when it creates the
function. This "program" will not produce an error:
def f():
print x
python parses the file and creates the function object and assigns the
function object to the variable f. It's not until you execute the
functio
On Aug 25, 12:11 pm, John Posner wrote:
> Diez said:
>
>
>
> > Classes are not scopes.
>
> > So the above doesn't work because name resolution inside functions/methods
> > looks for local variables first, then for the *global* scope. There is no
> > class-scope-lookup.
>
> Buthttp://docs.python.or
Diez said:
Classes are not scopes.
So the above doesn't work because name resolution inside functions/methods
looks for local variables first, then for the *global* scope. There is no
class-scope-lookup.
But http://docs.python.org/tutorial/classes.html says, in Section 9.3 "A
First Look at
Jean-Michel Pichavant wrote:
> Diez B. Roggisch wrote
>> Classes are not scopes.
>>
>>
> Too bad, could have been handy.
Nope. Because then a lot of people would write something like this:
class Foo(object):
def bar(self):
bar() # note the missing self.
And this would lead to e
On Wed, Aug 26, 2009 at 2:14 AM, Diez B. Roggisch wrote:
>
> Classes are not scopes.
>
> So the above doesn't work because name resolution inside functions/methods
> looks for local variables first, then for the *global* scope. There is no
> class-scope-lookup.
Sorry, I'm coming here with sincer
1 - 100 of 106 matches
Mail list logo
