469,343 Members | 5,388 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,343 developers. It's quick & easy.

Is a "real" C-Python possible?

I understand that the standard Python distribution is considered
the C-Python. Howerver, the current C-Python is really a combination
of C and Python implementation. There are about 2000 Python files
included in the Windows version of Python distribution. I'm not sure
how much of the C-Python is implemented in C but I think the more
modules implemented in C, the better performance and lower memory
footprint it will get.

I wonder if it's possible to have a Python that's completely (or at
least for the most part) implemented in C, just like PHP - I think
this is where PHP gets its performance advantage. Or maybe I'm wrong
because the core modules that matter are already in C and those Python
files are really a think wrapper. Anyhow, if would be ideal if Python
has performance similar to Java, with both being interpreted languages.

Jack
Dec 9 '07
71 2809
Kay Schluehr wrote:
class A(object):
foo = property:
def fget(self):
return self._foo
def fset(self, value):
self._foo = value

which was translated as follows:

class A(object):
def thunk():
def fget(self):
return self._foo
def fset(self, value):
self._foo = value
return vars()
foo = propery(**thunk())
del thunk
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

Dec 12 '07 #51
On Dec 12, 4:09 am, Kay Schluehr <kay.schlu...@gmx.netwrote:
I vaguely remember a discussion a few years ago, where someone made
the quite reasonable suggestion of introducing some kind of
thunk_statement:

class A(object):
foo = property:
def fget(self):
return self._foo
def fset(self, value):
self._foo = value
That's almost identical to a recipe I had written once upon a time,
without requiring a syntax change: http://aspn.activestate.com/ASPN/Coo.../Recipe/410698

George
Dec 12 '07 #52
On Dec 12, 1:12 pm, Christian Heimes <li...@cheimes.dewrote:
Kay Schluehr wrote:
class A(object):
foo = property:
def fget(self):
return self._foo
def fset(self, value):
self._foo = value
which was translated as follows:
class A(object):
def thunk():
def fget(self):
return self._foo
def fset(self, value):
self._foo = value
return vars()
foo = propery(**thunk())
del thunk

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
This is by definition Pythonic since it was conceived by the BDFL.It
is also certainly an improvement over the current common practice of
polluting the class namespace with private getters and setters. Still
it's a kludge compared to languages with builtin support for
properties.

George
Dec 12 '07 #53
On Dec 12, 3:36 pm, sturlamolden <sturlamol...@yahoo.nowrote:
On 12 Des, 12:56, George Sakkis <george.sak...@gmail.comwrote:
Ah, the 'make' statement.. I liked (and still do) that PEP, I think it
would have an impact comparable to the decorator syntax sugar, if not
more.

I think it is one step closer to Lisp. I believe that it would be
worth considering adding defmacro statement. Any syntax, including if,
else, for, while, class, lambda, try, except, etc. would be
implemented with defmacros. We would only need a minimalistic syntax,
that would bootstrap a full Python syntax on startup. And as for
speed, we all know how Lisp compares to Python.
It would be great if Python could be speeded up to SBCL Lisp by just
transforming one parse tree into another one. But since Python is
compiled to bytecodes I dare to say that surface syntax is not the key
factor ;)

Kay
Dec 12 '07 #54
On Dec 12, 2007 12:53 PM, George Sakkis <ge***********@gmail.comwrote:
On Dec 12, 1:12 pm, Christian Heimes <li...@cheimes.dewrote:
Kay Schluehr wrote:
class A(object):
foo = property:
def fget(self):
return self._foo
def fset(self, value):
self._foo = value
which was translated as follows:
class A(object):
def thunk():
def fget(self):
return self._foo
def fset(self, value):
self._foo = value
return vars()
foo = propery(**thunk())
del thunk
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

This is by definition Pythonic since it was conceived by the BDFL.It
is also certainly an improvement over the current common practice of
polluting the class namespace with private getters and setters. Still
it's a kludge compared to languages with builtin support for
properties.

How exactly is this a kludge? This is almost identical syntax (but
with less indentation) to a C# property declaration. The only thing
that's simpler is auto-generation of trivial accessors via a
decoration, but those are useless in Python so only the case of
getters and setters that actually do something needs to be addressed.

If the only thing that's not a "kludge" is direct syntax support for a
feature, you've set a pretty high and uselessly arbitrary bar.
Dec 12 '07 #55
On Dec 12, 2:23 pm, "Chris Mellon" <arka...@gmail.comwrote:
On Dec 12, 2007 12:53 PM, George Sakkis <george.sak...@gmail.comwrote:
On Dec 12, 1:12 pm, Christian Heimes <li...@cheimes.dewrote:
Kay Schluehr wrote:
class A(object):
foo = property:
def fget(self):
return self._foo
def fset(self, value):
self._foo = value
which was translated as follows:
class A(object):
def thunk():
def fget(self):
return self._foo
def fset(self, value):
self._foo = value
return vars()
foo = propery(**thunk())
del thunk
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
This is by definition Pythonic since it was conceived by the BDFL.It
is also certainly an improvement over the current common practice of
polluting the class namespace with private getters and setters. Still
it's a kludge compared to languages with builtin support for
properties.

How exactly is this a kludge?
In three (at least) ways:

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 ?!
This is almost identical syntax (but with less indentation) to a C# property declaration.
3. Less indentation is not an advantage here; typically ones wants all
two or three related functions that define the property to stand out
as a separate group, not be mixed with regular public methods.

Sorry, C# wins hands down on this.

George
Dec 12 '07 #56
In article <87************@rudin.co.uk>,
Paul Rudin <pa*********@rudin.co.ukwrote:
>Christian Heimes <li***@cheimes.dewrites:
>>
We are happy and glad for every improvement regarding speed, memory
usage or features if and only if: ...

... platform independent / supported on all platforms. Python runs
on machines from mobile phones to large main frames.

JOOI - there are things in the standard library that are not supported
on all platforms. Why would that be a basis for excluding some
psyco-like package?
As a stand-alone package (even shipping with Python), that's not a
problem; my understanding is that other issues have prevented including
Psyco. However, Christian was talking specifically about changes to the
CPython core for performance purposes.
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"Typing is cheap. Thinking is expensive." --Roy Smith
Dec 12 '07 #57
On Dec 12, 8:23 pm, "Chris Mellon" <arka...@gmail.comwrote:
On Dec 12, 2007 12:53 PM, George Sakkis <george.sak...@gmail.comwrote:
On Dec 12, 1:12 pm, Christian Heimes <li...@cheimes.dewrote:
Kay Schluehr wrote:
class A(object):
foo = property:
def fget(self):
return self._foo
def fset(self, value):
self._foo = value
which was translated as follows:
class A(object):
def thunk():
def fget(self):
return self._foo
def fset(self, value):
self._foo = value
return vars()
foo = propery(**thunk())
del thunk
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
This is by definition Pythonic since it was conceived by the BDFL.It
is also certainly an improvement over the current common practice of
polluting the class namespace with private getters and setters. Still
it's a kludge compared to languages with builtin support for
properties.

How exactly is this a kludge? This is almost identical syntax (but
with less indentation) to a C# property declaration.
C# properties are thunk statements:

private Object _foo = null;

public Object foo {
get { return this._foo; }
set { this._foo = value; }
}

In Python pseudo code this would translate to

foo:
def get(self): return self._foo
def set(self, value): self._foo = value

omitting the reference to a property constructor. This is the pure
essence: assign methods not to objects but object attributes, for
which certain protocols are defined. It could be generalized for GUI
applications using triggers or other dataflow related bindings. The
"pythonic" solution being mentioned is a rather obscure and convoluted
decorator hack. "Executable pseudocode" reads different and for the
latter assertion one doesn't need a BDFL stamped license. It
demonstrates the cleverness of the programmer more than it clarifies
the issue.

Kay
Dec 12 '07 #58
Paul Boddie wrote:
Then you haven't been reading the right IRC channel recently. ;-)
What's the right channel? I'm on #python and #python-dev
Indeed, but there's arguably a certain amount of deadlock around
making unpatched, released versions of Python available in all these
places, unless there's been some activity below the surface in the
python-dev community on things like cross-compilation and not running
distutils using the newly built Python executable (which, as I
remember, was but one of the problems). Your point stands, naturally,
but if there's potential for some real movement on some
uncontroversial issues, and yet we see no movement, one remains
skeptical about getting even slightly controversial improvements into
vanilla CPython.
I don't get your point, especially when you talk about distutils. Please
elaborate.

(C)Python has a well known process to get new features or changes into
the language: Write a PEP, convince enough core developers and/or Guido,
implement the feature. I don't see a PEP about JIT in the list at
abouthttp://www.python.org/dev/peps/, do you? :]

Besides nobody is going to stop you from creating a fork. Christian
Tismer forked of stackless years ago. It's a successful branch with
useful additions to the language. It got never merged back because
Christian didn't feel right about it.
Perhaps, but what would people prefer: yet more language bolt-ons or
better performance?
I prefer a fast, stable and maintainable Python over a faster but unstable.
It will be interesting to see what happens with recent work on
improving threading within CPython. As for Psyco (which perhaps offers
concurrency benefits only through instruction-level parallelism, if we
briefly consider that topic), I can understand that just-in-time
compilation can bring certain penalties in terms of memory usage and
initialisation times (as Java virtual machines have demonstrated), but
there's a compelling argument for trying to make such technologies
available to CPython if they can be switched off and won't then incur
such penalties. But we presumably return to the point of people not
wanting to touch code that has anything to do with such features: a
combination of social factors and the priorities of the group.
Rhamph is working on a GIL-less Python version. It may become a compile
time option someday in the future. Others have worked hard to speed up
other parts of Python. We have multiple pending patches which speed up
small parts of Python. Some are related to peephole (byte code
optimizations), other patches speed up attribute access on classes or
globals. The global lookup patch makes globals as fast as locals.

I've done my share for the poor Windows souls when I created the VS 2008
PCbuild9 directory and enabled PGO builds. PGO builds are about 10%
faster than ordinary VS 2008 builds. VS 2008 should be slightly faster
than VS 2003 but I can bench mark it on my machine.

In my opinion an optional JIT as compile time or startup option has good
chances to become part of the CPython implementation. You "only" have to
replace ceval.c ... :]

Christian

Dec 13 '07 #59
Paul Boddie wrote:
Then you haven't been reading the right IRC channel recently. ;-)
What's the right channel? I'm on #python and #python-dev
Indeed, but there's arguably a certain amount of deadlock around
making unpatched, released versions of Python available in all these
places, unless there's been some activity below the surface in the
python-dev community on things like cross-compilation and not running
distutils using the newly built Python executable (which, as I
remember, was but one of the problems). Your point stands, naturally,
but if there's potential for some real movement on some
uncontroversial issues, and yet we see no movement, one remains
skeptical about getting even slightly controversial improvements into
vanilla CPython.
I don't get your point, especially when you talk about distutils. Please
elaborate.

(C)Python has a well known process to get new features or changes into
the language: Write a PEP, convince enough core developers and/or Guido,
implement the feature. I don't see a PEP about JIT in the list at
abouthttp://www.python.org/dev/peps/, do you? :]

Besides nobody is going to stop you from creating a fork. Christian
Tismer forked of stackless years ago. It's a successful branch with
useful additions to the language. It got never merged back because
Christian didn't feel right about it.
Perhaps, but what would people prefer: yet more language bolt-ons or
better performance?
I prefer a fast, stable and maintainable Python over a faster but unstable.
It will be interesting to see what happens with recent work on
improving threading within CPython. As for Psyco (which perhaps offers
concurrency benefits only through instruction-level parallelism, if we
briefly consider that topic), I can understand that just-in-time
compilation can bring certain penalties in terms of memory usage and
initialisation times (as Java virtual machines have demonstrated), but
there's a compelling argument for trying to make such technologies
available to CPython if they can be switched off and won't then incur
such penalties. But we presumably return to the point of people not
wanting to touch code that has anything to do with such features: a
combination of social factors and the priorities of the group.
Rhamph is working on a GIL-less Python version. It may become a compile
time option someday in the future. Others have worked hard to speed up
other parts of Python. We have multiple pending patches which speed up
small parts of Python. Some are related to peephole (byte code
optimizations), other patches speed up attribute access on classes or
globals. The global lookup patch makes globals as fast as locals.

I've done my share for the poor Windows souls when I created the VS 2008
PCbuild9 directory and enabled PGO builds. PGO builds are about 10%
faster than ordinary VS 2008 builds. VS 2008 should be slightly faster
than VS 2003 but I can bench mark it on my machine.

In my opinion an optional JIT as compile time or startup option has good
chances to become part of the CPython implementation. You "only" have to
replace ceval.c ... :]

Christian

Dec 13 '07 #60
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.

Dec 13 '07 #61
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 <ge***********@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,set). 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?
Dec 13 '07 #62
On Dec 13, 2007 12:04 PM, Patrick Mullen <sa********@gmail.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 <ge***********@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,set). 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.
Dec 13 '07 #63
Christian Heimes <li***@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.
Dec 13 '07 #64
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,'bar',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.





Dec 13 '07 #65
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

Dec 14 '07 #66
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

Dec 14 '07 #67
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,'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.

--
Steven
Dec 14 '07 #68
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
Dec 14 '07 #69
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

Dec 14 '07 #70
In article <ma***************************************@python. org>,
Christian Heimes <li***@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 (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"Typing is cheap. Thinking is expensive." --Roy Smith
Dec 14 '07 #71
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,'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.
Dec 14 '07 #72

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Ira Baxter | last post: by
7 posts views Thread by Aryeh M. Friedman | last post: by
11 posts views Thread by Nobody | last post: by
reply views Thread by Simon Verona | last post: by
reply views Thread by David Garamond | last post: by
reply views Thread by Ignacio Machin ( .NET/ C# MVP ) | last post: by
1 post views Thread by CARIGAR | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.