Is a "real" C-Python possible?

[Christian Heimes]

Unfortunately as currently implemented, getter setter and deleter just
update the existing property, so the getter defined in B changes how the
property works in A as well. I think the intention may have been that they
should create a new property each time, but this isn't what has been
implemented.

Thanks for the information! I've talked to Guido and we both agree that
it is a bug. I've a pending fix for it at my hands.

Christian

 

[Christian Heimes]

Unfortunately as currently implemented, getter setter and deleter just
update the existing property, so the getter defined in B changes how the
property works in A as well. I think the intention may have been that they
should create a new property each time, but this isn't what has been
implemented.

Thanks for the information! I've talked to Guido and we both agree that
it is a bug. I've a pending fix for it at my hands.

Christian

 

[Steven D'Aprano]

Personally I find properties atrocious and unsafe. One cannot
distinguish between a function call and binding an attribute in a
statement like:

foo.bar = 2 # Does this call a function or bind an attribute?
# Is this foo.setBar(2) or setattr(foo,'bar',2)?

Why do you care?

As the class *creator*, you care, but as the class *user*, you shouldn't
need to -- at least assuming it is a well-written class. (You might care
if the class' setter has harmful side-effects, but that's no difference
from a class with a __setattr__ method with harmful side-effects.)

Even worse: if we make a typo, the error will not be detected as the
syntax is still valid. Properties and dynamic binding do not mix.

I'm not quite sure I understand that criticism. How is that different
from things which are not properties?

foo.baz = 2 # oops, I meant bar

will succeed regardless of whether foo.bar is an attribute or a property.

 

[Christian Heimes]

I'm not quite sure I understand that criticism. How is that different
from things which are not properties?

foo.baz = 2 # oops, I meant bar

will succeed regardless of whether foo.bar is an attribute or a property.

Unless it's a new style class with __slots__

Christian

 

[Christian Heimes]

I'm not quite sure I understand that criticism. How is that different
from things which are not properties?

foo.baz = 2 # oops, I meant bar

will succeed regardless of whether foo.bar is an attribute or a property.

Unless it's a new style class with __slots__

Christian

 

[Aahz]

Unless it's a new style class with __slots__

[....]

Naw, I'll skip the rant this time. ;-)

 

[Bruno Desthuilliers]

sturlamolden a écrit :

Personally I find properties atrocious and unsafe.

What a strange observation from someone wanting to introduce defmacros
and customizable syntax in Python....

One cannot
distinguish between a function call and binding an attribute in a
statement like:

FWIW, "binding an attribute" will *alway* require some function call...
Properties - or any other computed attributes - are just hooks into the
default __setattr__ implementation so you can customize it.

foo.bar = 2 # Does this call a function or bind an attribute?

From the client code POV, it binds an attribute - whatever the
implementation is.

From the implementation POV, it will always call a couple functions.

What's you point, exactly ?

# Is this foo.setBar(2) or setattr(foo,'bar',2)?

Why do you care ? Ever heard about the concept of "encapsulation" ?

Even worse: if we make a typo, the error will not be detected as the
syntax is still valid.

So what ? This has nothing to do with properties.

Properties and dynamic binding do not mix.

Sorry, but IMVHO, this is total bullshit.