Is a "real" C-Python possible?

[Bruno Desthuilliers]

Re: Is a "real&quot ; C-Python possible?

sturlamolden a écrit :

On 12 Des, 17:00, "Chris Mellon" <arka...@gmail. comwrote:
>

>Python has not become what it is, and achieved the success it has,
>because a bunch of people really wanted to use Lisp but didn't think
>other people could handle it.
>>
>The goal of these sorts of discussions should be to make Python a
>better Python.

>
I do not want to use Lisp. The syntax is awkward and strange, and does
not fit in my brain. I cannot read Lisp code and get a mental image of
what it does. Readability is what sets Python apart.

Part of this readability comes from opiniated choices wrt/ syntax.
Letting anyone invent it's own syntax could well ruin this.

[Patrick Mullen]

Re: Is a &quot;real&quot ; C-Python possible?

Kay Schluehr wrote:

Python 2.6 and 3.0 have a more Pythonic way for the problem:
class A(object):
@property
def foo(self):
return self._foo
@foo.setter
def foo(self, value)
self._foo = value
@foo.deletter
def foo(self)
del self._foo
class B(A):
# one can even overwrite the getter in a subclass
@foo.getter
def foo(self):
return self._foo * 2
Christian

On Dec 12, 2007 12:57 PM, George Sakkis <george.sakkis@ gmail.comwrote:

1. The property name ('foo') is repeated *5* times for a single class.
Talk about DRY.
2. Total inconsistency: @property for the getter when it is defined
for the first time, @foo.setter/@foo.deletter for the setter/deletter,
@foo.getter when the getter is redefined. WTF ?!

Eww, I agree with George here, with respect to these two points. When
I looked at this my first wtf was the @property and then @foo.getter
business. I really don't mind the current way of doing things: attr =
property(get,se t). Other mechanisms can be created with getattr
routines. I don't really like this new syntax at all. Too many @
marks, inconsistancies , and too many foos everywhere. Not to mention
how long it reads. For only getters, it's not bad though, and a
little better than property().

Decorators really don't feel pythonic to me at all, mostly due to the
@ symbol, but it looks really awful in this instance.

What about this, somewhat similar but not ugly syntax:

class A:
foo = property()
def foo.get():
return self._foo
def foo.delete():
del self._foo
def foo.set(val):
self._foo = val

Defining something with a dot is currently a syntax error. Ok, so
it's still too many foos. At least it's consistent. I'm not really
proposing this btw. I'd rather not introduce more specialized syntax.

How about abusing with:

class A:
with property("foo") :
def get
def set...

There's your thunk, and I really like with, but am saddened that it
has such limited use at the moment. Of course this isn't really what
with is for...

Can anyone tell me what's wrong about the current property() syntax,
besides namespace polution?

[Chris Mellon]

Re: Is a &quot;real&quot ; C-Python possible?

On Dec 13, 2007 12:04 PM, Patrick Mullen <saluk64007@gma il.comwrote:

Kay Schluehr wrote:
Python 2.6 and 3.0 have a more Pythonic way for the problem:
class A(object):
@property
def foo(self):
return self._foo
@foo.setter
def foo(self, value)
self._foo = value
@foo.deletter
def foo(self)
del self._foo
class B(A):
# one can even overwrite the getter in a subclass
@foo.getter
def foo(self):
return self._foo * 2
Christian

>
On Dec 12, 2007 12:57 PM, George Sakkis <george.sakkis@ gmail.comwrote:

1. The property name ('foo') is repeated *5* times for a single class.
Talk about DRY.
2. Total inconsistency: @property for the getter when it is defined
for the first time, @foo.setter/@foo.deletter for the setter/deletter,
@foo.getter when the getter is redefined. WTF ?!

>
Eww, I agree with George here, with respect to these two points. When
I looked at this my first wtf was the @property and then @foo.getter
business. I really don't mind the current way of doing things: attr =
property(get,se t). Other mechanisms can be created with getattr
routines. I don't really like this new syntax at all.

For the record, this is not new syntax. It's implemented this way
specifically to avoid the creation of new syntax for properties.

>Too many @
marks, inconsistancies , and too many foos everywhere. Not to mention
how long it reads. For only getters, it's not bad though, and a
little better than property().
>

I don't feel that it's especially inconsistent, and I like decorators.
Having to write foo everywhere isn't that nice, but it's only mildly
worse than C# to me - I find the extra block levels really atrocious.

Decorators really don't feel pythonic to me at all, mostly due to the
@ symbol, but it looks really awful in this instance.
>
What about this, somewhat similar but not ugly syntax:
>
class A:
foo = property()
def foo.get():
return self._foo
def foo.delete():
del self._foo
def foo.set(val):
self._foo = val
>
Defining something with a dot is currently a syntax error. Ok, so
it's still too many foos. At least it's consistent. I'm not really
proposing this btw. I'd rather not introduce more specialized syntax.
>
How about abusing with:
>
class A:
with property("foo") :
def get
def set...
>
There's your thunk, and I really like with, but am saddened that it
has such limited use at the moment. Of course this isn't really what
with is for...
>
Can anyone tell me what's wrong about the current property() syntax,
besides namespace polution?
>

Nothing, except that people prefer decorators and they don't like the
namespace pollution. foo = property() isn't going away and if you
prefer it (I don't) you're free to use it. If you don't like
decorators in general it's fairly obvious that you won't be partial to
a decorator based feature.

It's not that big a deal anyway, of course, the use case for
properties in Python has a much smaller scope than in C#, and
getter-only properties (which you can create with just @property) are
the majority of those.

[Duncan Booth]

Re: Is a &quot;real&quot ; C-Python possible?

Christian Heimes <lists@cheimes. dewrote:

Python 2.6 and 3.0 have a more Pythonic way for the problem:
>
class A(object):
@property
def foo(self):
return self._foo
>
@foo.setter
def foo(self, value)
self._foo = value
>
@foo.deletter
def foo(self)
del self._foo
>
class B(A):
# one can even overwrite the getter in a subclass
@foo.getter
def foo(self):
return self._foo * 2
>

That would be great if it worked, but it doesn't.

Fixing your typos (missing colons, spelling of deleter, and in B the
decorator needs to refer to A.foo.getter):

Python 3.0a2 (r30a2:59405M, Dec 7 2007, 15:23:28) [MSC v.1500 32 bit
(Intel)] on win32
Type "copyright" , "credits" or "license()" for more information.

*************** *************** *************** *************** ****
Personal firewall software may warn about the connection IDLE
makes to its subprocess using this computer's internal loopback
interface. This connection is not visible on any external
interface and no data is sent to or received from the Internet.
*************** *************** *************** *************** ****

IDLE 3.0a1

>>class A(object):

@property
def foo(self):
return self._foo

@foo.setter
def foo(self, value):
self._foo = value

@foo.deleter
def foo(self):
del self._foo

>>class B(A):

# one can even overwrite the getter in a subclass
@A.foo.getter
def foo(self):
return self._foo * 2

>>a = A()
>>a.foo = 5
>>a.foo

10

>>A.__dict__['foo']

<property object at 0x01261F80>

>>B.__dict__['foo']

<property object at 0x01261F80>

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.

[sturlamolden]

Re: Is a &quot;real&quot ; C-Python possible?

On 13 Des, 19:16, "Chris Mellon" <arka...@gmail. comwrote:

I don't feel that it's especially inconsistent, and I like decorators.
Having to write foo everywhere isn't that nice, but it's only mildly
worse than C# to me - I find the extra block levels really atrocious.

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,'ba r',2)?

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.

[Christian Heimes]

Re: Is a &quot;real&quot ; C-Python possible?

Duncan Booth wrote:

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]

Re: Is a &quot;real&quot ; C-Python possible?

Duncan Booth wrote:

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]

Re: Is a &quot;real&quot ; C-Python possible?

On Thu, 13 Dec 2007 13:35:24 -0800, sturlamolden wrote:

On 13 Des, 19:16, "Chris Mellon" <arka...@gmail. comwrote:
>

>I don't feel that it's especially inconsistent, and I like decorators.
>Having to write foo everywhere isn't that nice, but it's only mildly
>worse than C# to me - I find the extra block levels really atrocious.

>
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,'ba r',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.



--
Steven

[Christian Heimes]

Re: Is a &quot;real&quot ; C-Python possible?

Steven D'Aprano wrote:

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]

Re: Is a &quot;real&quot ; C-Python possible?

Steven D'Aprano wrote:

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]

Re: Is a &quot;real&quot ; C-Python possible?

In article <mailman.2374.1 197592941.13605 .python-list@python.org >,
Christian Heimes <lists@cheimes. dewrote:

>Steven D'Aprano wrote:

>>
>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__

[....]

Naw, I'll skip the rant this time. ;-)
--
Aahz (aahz@pythoncra ft.com) <* http://www.pythoncraft.com/

"Typing is cheap. Thinking is expensive." --Roy Smith

[Bruno Desthuilliers]

Re: Is a &quot;real&quot ; C-Python possible?

sturlamolden a écrit :

On 13 Des, 19:16, "Chris Mellon" <arka...@gmail. comwrote:
>
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,'ba r',2)?

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

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.