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  3221 
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
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
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
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
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.
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
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
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
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
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
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.
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?
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.
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.
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.
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
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
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
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
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
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
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Ira Baxter |
last post by:
My understanding is that Zend are the folks behind the one and only
PHP implementation. Now that PHP5 is released, I'm quite interested
in using it.
However, the documentation avialable at...
|
by: Aryeh M. Friedman |
last post by:
If have something like the following declartion:
enum foo {One,Two,....,Ten};
How do I determine how many elements (enumerations)... in this case it is
obviously 10 but I don't want to hard...
|
by: Nobody |
last post by:
Heres the deal... I have an application where I have a list (as in a Windows
list control, but thats not important) displayed to the user. I sort this
list based on the list controls sort function...
|
by: Silas |
last post by:
Hi,
I use view to join difference table together for some function. However,
when the "real" table fields changed (e.g. add/delete/change field). The
view table still use the "old fields".
...
|
by: Simon Verona |
last post by:
I have some Windows Forms software that I'm developing that uses a remote
server (called using remoting) to provide the business rules and dataaccess.
For development purposes the client and...
|
by: David Garamond |
last post by:
I want to know how functional indexes are used "in the real world". Here
are the common uses:
* non-unique index on the first parts of a longish text field
(SUBSTRING(field)) to save disk space,...
|
by: playagain |
last post by:
Please help me to build a list of examples of stack and queue in real life situation...
Conditions:
The object concerned must only one object.
And the object must be tangible.
Example:
Queue...
|
by: Tyno Gendo |
last post by:
Hi everyone
I need to move on a step in my PHP...
I know what classes are, both in PHP4 and 5 and I'm aware of "patterns"
existing, but what I'm looking for are some real world projects eg....
|
by: jamesicus |
last post by:
.......... just for curiosity?
"real" XHTML served as content (MIME) type application/xhtml+xml will display in MSIE 6.0 release 2900 and 7.0 but they will not render xml content. However, MSIE...
|
by: Ignacio Machin ( .NET/ C# MVP ) |
last post by:
The difference between compile & runtime. CreateInstance works at
runtime, you can pass ANY string to it (even an incorrect one like
"123123123123") and it will compile
Only at runtime you will...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
