Lawrence D'Oliveiro wrote:
“Dynamically” is when that “future” becomes the present, so you can see it
right in front of you, here, now.
But raising an "UnboundAttributeError" when attempting to
read a class attribute that *could*, but hasn't yet, been
shadowed by an instance attribute requires
In message <8hl2jvfb1...@mid.individual.net>, Gregory Ewing wrote:
> Lawrence D'Oliveiro wrote:
>
>> If you can’t do it statically, do it dynamically.
>
> But how can that be done without seeing into the future?
“Dynamically” is when that “future” becomes the present, so you can see it
right i
Lawrence D'Oliveiro wrote:
If you can’t do it statically, do it dynamically.
But how can that be done without seeing into the future?
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 10, 12:07 pm, John Nagle wrote:
> (If you want default values for an instance, you define them
> in __init__, not as class-level attributes.)
>
I beg to differ. I've seen plenty of code where defaults are set at
the class level. It makes for some rather nice code.
I'm thinking of lxm
In message <8hhm9afbl...@mid.individual.net>, Gregory Ewing wrote:
> Lawrence D'Oliveiro wrote:
>
>> In message <8hfq23fet...@mid.individual.net>, Gregory Ewing wrote:
>>
>>>How would you intend to enforce such a restriction?
>>
>> The same way it’s already enforced.
>
> I don't see how that's
Lawrence D'Oliveiro wrote:
In message <8hfq23fet...@mid.individual.net>, Gregory Ewing wrote:
How would you intend to enforce such a restriction?
The same way it’s already enforced.
I don't see how that's possible, except in a very limited and
unreliable way. The compiler would have to be a
On 10/9/10 10:30 PM, John Nagle wrote:
> Python protects global variables from similar confusion
> by making them read-only when referenced from an inner scope
> without a "global" statement.
No. It doesn't. Assignments simply always apply to local variables,
unless you explicitly indicate oth
On Mon, Oct 11, 2010 at 9:44 AM, Dennis Lee Bieber
wrote:
> On Mon, 11 Oct 2010 10:43:04 -0400, John Posner
> declaimed the following in gmane.comp.python.general:
>> No surprising behavior, just a surprising look:
>>
>> self.EGGS = ...
>>
>> ... which might remind the programmer what's going
On 10/10/2010 7:02 PM, Steven D'Aprano wrote:
On Sun, 10 Oct 2010 18:14:33 -0400, John Posner wrote:
Class attributes are often used as "class constants", so how about
naming them with UPPERCASE names, like other constants? When you choose
to override one of these constants, like this:
se
John Nagle wrote:
Here's an obscure bit of Python semantics which
is close to being a bug:
>>> class t(object) :
... classvar = 1
...
... def fn1(self) :
... print("fn1: classvar = %d" % (self.classvar,))
... self.classvar = 2
... print("fn1: classvar = %d" % (
In message <8hfq23fet...@mid.individual.net>, Gregory Ewing wrote:
> Lawrence D'Oliveiro wrote:
>
>> It seems to me the same principle, that of disallowing implicit
>> overriding of a name from an outer scope with that from an inner one
>> after the former has already been referenced, should be a
Lawrence D'Oliveiro wrote:
It seems to me the same principle, that of disallowing implicit overriding
of a name from an outer scope with that from an inner one after the former
has already been referenced, should be applied here as well.
How would you intend to enforce such a restriction?
--
John Nagle wrote:
On 10/10/2010 12:53 AM, Lawrence D'Oliveiro wrote:
In message<4cb14f8c$0$1627$742ec...@news.sonic.net>, John Nagle wrote:
Within "fn1", the first reference to "self.classvar" references the
class-
level version of "classvar". The assignment overrides that and
creates an
o
In message <4cb23ac9.70...@optimum.net>, John Posner wrote:
> Since it's unlikely that the language will change ...
Python 4000, anybody? :)
--
http://mail.python.org/mailman/listinfo/python-list
On Sun, 10 Oct 2010 18:14:33 -0400, John Posner wrote:
> Class attributes are often used as "class constants", so how about
> naming them with UPPERCASE names, like other constants? When you choose
> to override one of these constants, like this:
>
> self.EGGS = 4
Er what?
If self.EGGS is m
On 10/10/2010 3:07 PM, John Nagle wrote:
I understand how the current semantics fall out of the obvious
implementation. But I don't see those semantics as particularly
desirable. The obvious semantics for globals are similar, but
that case is so error-prone that it was made an error.
Nicely st
On 10/10/2010 12:53 AM, Lawrence D'Oliveiro wrote:
In message<4cb14f8c$0$1627$742ec...@news.sonic.net>, John Nagle wrote:
Within "fn1", the first reference to "self.classvar" references the class-
level version of "classvar". The assignment overrides that and creates an
object-level instance o
In article <4cb14f8c$0$1627$742ec...@news.sonic.net>
John Nagle wrote:
>Here's an obscure bit of Python semantics which
>is close to being a bug:
[assigning to instance of class creates an attribute within
the instance, thus obscuring the class-level version of the
attribute]
This is sort o
In message <4cb14f8c$0$1627$742ec...@news.sonic.net>, John Nagle wrote:
> Within "fn1", the first reference to "self.classvar" references the class-
> level version of "classvar". The assignment overrides that and creates an
> object-level instance of "self.classvar". Further references to
> self
On Oct 9, 10:30 pm, John Nagle wrote:
> Here's an obscure bit of Python semantics which
> is close to being a bug:
>
> >>> class t(object) :
> ... classvar = 1
> ...
> ... def fn1(self) :
> ... print("fn1: classvar = %d" % (self.classvar,))
> ... self.classvar = 2
> ..
On Sat, 09 Oct 2010 22:30:43 -0700, John Nagle wrote:
> Here's an obscure bit of Python semantics which is close to being a bug:
"Obscure"? It's possibly the most fundamental aspect of Python's object
model. Setting instance.attr assigns to the instance attribute, creating
it if it doesn't exis
Here's an obscure bit of Python semantics which
is close to being a bug:
>>> class t(object) :
... classvar = 1
...
... def fn1(self) :
... print("fn1: classvar = %d" % (self.classvar,))
... self.classvar = 2
... print("fn1: classvar = %d" % (self.classvar,))
..
22 matches
Mail list logo
