Steven D'Aprano a écrit :
On Tue, 27 Nov 2007 10:11:48 +0100, Bruno Desthuilliers wrote:
Fine. Now since Python let you define your own callable types and your
own descriptors, you can as well have an attribute that behave just like
a method without being an instance of any of the method
On Mon, 26 Nov 2007 21:48:36 +0100, Ton van Vliet wrote:
On Mon, 26 Nov 2007 20:14:50 +0100, Bruno Desthuilliers
[EMAIL PROTECTED] wrote:
However, I was more thinking in terms of attributes only
Too bad : in Python, everything's an object, so 'methods' are attributes
too.
Right, but I'm
Steven D'Aprano a écrit :
On Mon, 26 Nov 2007 21:48:36 +0100, Ton van Vliet wrote:
On Mon, 26 Nov 2007 20:14:50 +0100, Bruno Desthuilliers
[EMAIL PROTECTED] wrote:
However, I was more thinking in terms of attributes only
Too bad : in Python, everything's an object, so 'methods' are
In article [EMAIL PROTECTED],
Bruno Desthuilliers [EMAIL PROTECTED]
wrote:
Steven D'Aprano a écrit :
On Mon, 26 Nov 2007 21:48:36 +0100, Ton van Vliet wrote:
On Mon, 26 Nov 2007 20:14:50 +0100, Bruno Desthuilliers
[EMAIL PROTECTED] wrote:
However, I was more thinking in terms of
On Nov 27, 3:20 am, Roy Smith [EMAIL PROTECTED] wrote:
If you want to have a little fun:
class peverse:
def __call__(self):
raise AttributeError (peverse instance has no __call__ method)
x = peverse()
x()
That is peverse, but still...
from types import FunctionType
type(x)
Colin J. Williams a écrit :
Bruno Desthuilliers wrote:
[snip]
Too bad : in Python, everything's an object, so 'methods' are
attributes too.
What do you see as a problem here?
You snipped too much... Tony wrote However, I was more thinking in
terms of attributes only (implying: attributes
MonkeeSage a écrit :
On Nov 27, 3:20 am, Roy Smith [EMAIL PROTECTED] wrote:
If you want to have a little fun:
class peverse:
def __call__(self):
raise AttributeError (peverse instance has no __call__ method)
x = peverse()
x()
print callable(x)
= True
That is peverse, but
On Nov 27, 4:22 am, Bruno Desthuilliers
You don't have to subclass function to define a callable type that
implements the descriptor protocol so it behaves just like a function in
the context of an attribute lookup.
I'm aware, and I understand that python's types (as with other duck-
typed
On Nov 27, 9:20 am, Roy Smith [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED],
Bruno Desthuilliers [EMAIL PROTECTED]
wrote:
Steven D'Aprano a écrit :
On Mon, 26 Nov 2007 21:48:36 +0100, Ton van Vliet wrote:
On Mon, 26 Nov 2007 20:14:50 +0100, Bruno Desthuilliers
[EMAIL
MonkeeSage a écrit :
On Nov 27, 4:22 am, Bruno Desthuilliers
You don't have to subclass function to define a callable type that
implements the descriptor protocol so it behaves just like a function in
the context of an attribute lookup.
I'm aware, and I understand that python's types (as
Iain King [EMAIL PROTECTED] wrote:
FTR, I won't be using this :) I do like this syntax though:
class Vector:
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
def abs(self):
using self:
return math.sqrt(.x*.x + .y*.y +
On Nov 27, 12:03 pm, Duncan Booth [EMAIL PROTECTED]
wrote:
Iain King [EMAIL PROTECTED] wrote:
FTR, I won't be using this :) I do like this syntax though:
class Vector:
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
def abs(self):
On 2007-11-26, Bruno Desthuilliers [EMAIL PROTECTED] wrote:
Patrick Mullen a écrit :
(snip)
Still an unnecessary lookup on tmp though :) And it would be useless
to use it for one assignment, the idea is to eliminate all the typing
with this:
self.var1 = 5
self.var2 = a value
self.var3 =
On Tue, 27 Nov 2007 10:11:48 +0100, Bruno Desthuilliers wrote:
Fine. Now since Python let you define your own callable types and your
own descriptors, you can as well have an attribute that behave just like
a method without being an instance of any of the method types - so the
above test
On Nov 24, 2007 11:55 AM, jakub silar [EMAIL PROTECTED] wrote:
Below is my coding standard - I'm lazy, even lazy to persuade
comutinties into strange (imho) language syntax extensions.
class Vector:
def __init__(s, x, y, z):
s.x = x
s.y = y
Ton van Vliet a écrit :
On 24 Nov 2007 13:56:37 GMT, Marc 'BlackJack' Rintsch [EMAIL PROTECTED]
wrote:
(snip)
So::
def meth(self):
using self:
tmp = raw_input('Enter age: ')
age = int(tmp)
becomes::
def meth(self):
using self:
self.tmp =
samwyse a écrit :
(snip)
Besides Pascal, Visual Basic also offers a 'with' statement that
behaves almost in this way. That in itself should be an indication
that the whole thing is a bad idea. ;-)
FWIW, Javascript has it too - and it's considered a BadPractice(tm) to
use it...
--
Ton van Vliet a écrit :
On 24 Nov 2007 16:07:18 GMT, Duncan Booth
[EMAIL PROTECTED] wrote:
Ton van Vliet [EMAIL PROTECTED] wrote:
It would boil down to choice: explicit/speed vs implicit/readability
No, it would boil down to explicit+speed+readability+maintainability vs
implicit+error
Patrick Mullen a écrit :
(snip)
Still an unnecessary lookup on tmp though :) And it would be useless
to use it for one assignment, the idea is to eliminate all the typing
with this:
self.var1 = 5
self.var2 = a value
self.var3 = stuff
self.var4 = [2,54,7,7]
self.var5 = dingaling
samwyse a écrit :
(snip)
Actually, the chained dots are solving a completely different problem,
that of refactoring a collection of functions that use global vars
into a class.
Using globals to maintain state between functions being bad practice in
most cases, I don't see any reason to
On Mon, 26 Nov 2007 20:14:50 +0100, Bruno Desthuilliers
[EMAIL PROTECTED] wrote:
However, I was more thinking in terms of attributes only
Too bad : in Python, everything's an object, so 'methods' are attributes
too.
Right, but I'm sure *you* know a way to distinguish between them (I'm
just a
Bruno Desthuilliers wrote:
[snip]
Too bad : in Python, everything's an object, so 'methods' are attributes
too.
What do you see as a problem here?
Surely it gives useful flexibility.
Colin W.
--
http://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano wrote:
On Fri, 23 Nov 2007 23:38:24 +, BJörn Lindqvist
wrote:
I like that a lot. This saves 12 characters for the original example and
removes the need to wrap it.
7return math.sqrt(.x * .x + .y * .y + .z * .z)
+1 Readability counts, even on small
Kay Schluehr wrote:
Colin J. Williams schrieb:
Kay Schluehr wrote:
On Nov 22, 8:43 pm, Bruno Desthuilliers
[EMAIL PROTECTED] wrote:
Colin J. Williams a écrit :
[EMAIL PROTECTED] wrote:
Alexy:
Sometimes I
avoid OO just not to deal with its verbosity. In fact, I try to use
Ruby
I like the explicit self, personally. It helps distinguish class
methods from functions. When I see a self I think A-ha, a class
method. Of course, I could tell that from just the indentation and
following that back to the class declaration, but as a quick reference
I find it helpful. Besides,
On Nov 24, 1:10 pm, Patrick Mullen [EMAIL PROTECTED] wrote:
If there were a using or if the with statement would handle
something like this, I wouldn't use it. s. is only 2 characters. I
saw chained dots mentioned. Chained dots are 2 characters. Why are
we still discussing this? s. is the
Colin J. Williams [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Alternatively, as someone else suggested, an analogue of the Pascal with
could be used:
def abs(self):
with self:
return math.sqrt(x**2 + y**2 + z**2)
How does your suggested with statement know to transform
Andrew Koenig wrote:
Colin J. Williams [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Alternatively, as someone else suggested, an analogue of the Pascal with
could be used:
def abs(self):
with self:
return math.sqrt(x**2 + y**2 + z**2)
How does your suggested with
I am not advocating this, but this could be:
def abs(self):
with self:
with math:
return sqrt(x**2 + y**2 + z**2)
The idea being that with self use
creates a new namespace:
newGlobal= oldGlobal + oldLocal
newLocal= names from self
You don't know what those names
The issue of lexical scope still looms large on the horizon. How does
one distinguish between attributes (as scoped by the with clause),
local/global variables, and function/method calls? There doesn't seem
to be an easy way. You'd need multiple passes over the data to
determine various scopes --
Andrew Koenig wrote:
I am not advocating this, but this could be:
def abs(self):
with self:
with math:
return sqrt(x**2 + y**2 + z**2)
The idea being that "with self" use
creates a new namespace:
newGlobal= oldGlobal +
MonkeeSage wrote:
The issue of lexical scope still looms large on the horizon. How does
one distinguish between attributes (as scoped by the with clause),
local/global variables, and function/method calls? There doesn't seem
to be an easy way. You'd need multiple passes over the data to
On Nov 24, 10:55 am, jakub silar [EMAIL PROTECTED] wrote:
BJörn Lindqvist wrote:
On Nov 22, 2007 2:08 PM, Colin J. Williams [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Alexy:
Sometimes I
avoid OO just not to deal with its verbosity. In fact, I try to use
Ruby anywhere speed is
On Fri, 23 Nov 2007 17:16:25 -0800, Patrick Mullen
[EMAIL PROTECTED] wrote:
Most of the time self doesn't bother me in the slightest. The one
time it does bother me however, is when I am turning a function into a
method. In this case, often I have many local variables which I
actually want to
On Sat, 24 Nov 2007 09:12:34 +0100, Ton van Vliet wrote:
Just bringing up something I sometimes miss from good-old Turbo-Pascal
here, which has the WITH statement to reduce the typing overhead with
(long) record/struct prefixes, used like:
with prefix do begin
a = ...
b = ...
Ton Van Vliet:
[... using/with ...]
This looks like a really nice little construct, and solves my small
quirk issue (which has popped up maybe twice in my python experience).
It could also be a solution to the OP's problem. The issue of course
is disambiguation. Is EVERY name looked up in the
On Nov 23, 7:16 pm, Patrick Mullen [EMAIL PROTECTED] wrote:
Most of the time self doesn't bother me in the slightest. The one
time it does bother me however, is when I am turning a function into a
method. In this case, often I have many local variables which I
actually want to be instance
On Sat, 24 Nov 2007 01:55:38 -0800, samwyse wrote:
I've had the same thought, along with another. You see, on of my pet
peeves about all OO languages that that when creating new code, I
generally begin by writing something like this:
cat = 'felix'
dog = 'rover'
def example():
global
On Nov 24, 4:07 am, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
On Sat, 24 Nov 2007 01:55:38 -0800, samwyse wrote:
I've had the same thought, along with another. You see, on of my pet
peeves about all OO languages that that when creating new code, I
generally begin by writing
BJörn Lindqvist wrote:
On Nov 22, 2007 2:08 PM, Colin J. Williams [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Alexy:
Sometimes I
avoid OO just not to deal with its verbosity. In fact, I try to use
Ruby anywhere speed is not crucial especially for @ prefix is better-
looking than self.
On 24 Nov 2007 08:48:30 GMT, Marc 'BlackJack' Rintsch [EMAIL PROTECTED]
wrote:
On Sat, 24 Nov 2007 09:12:34 +0100, Ton van Vliet wrote:
Just bringing up something I sometimes miss from good-old Turbo-Pascal
here, which has the WITH statement to reduce the typing overhead with
(long)
Kay Schluehr wrote:
Colin J. Williams schrieb:
Kay Schluehr wrote:
On Nov 22, 8:43 pm, Bruno Desthuilliers
[EMAIL PROTECTED] wrote:
Colin J. Williams a écrit :
[EMAIL PROTECTED] wrote:
Alexy:
Sometimes I
avoid OO just not to deal with its verbosity. In fact, I try to
use
Ruby
On Sat, 24 Nov 2007 02:54:27 -0800, samwyse wrote:
On Nov 24, 4:07 am, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
On Sat, 24 Nov 2007 01:55:38 -0800, samwyse wrote:
I've had the same thought, along with another. You see, on of my pet
peeves about all OO languages that that when
On Sat, 24 Nov 2007 14:09:04 +0100, Ton van Vliet wrote:
On 24 Nov 2007 08:48:30 GMT, Marc 'BlackJack' Rintsch [EMAIL PROTECTED]
wrote:
On Sat, 24 Nov 2007 09:12:34 +0100, Ton van Vliet wrote:
Just bringing up something I sometimes miss from good-old Turbo-Pascal
here, which has the WITH
On 24 Nov 2007 13:56:37 GMT, Marc 'BlackJack' Rintsch [EMAIL PROTECTED]
wrote:
On Sat, 24 Nov 2007 14:09:04 +0100, Ton van Vliet wrote:
On 24 Nov 2007 08:48:30 GMT, Marc 'BlackJack' Rintsch [EMAIL PROTECTED]
wrote:
On Sat, 24 Nov 2007 09:12:34 +0100, Ton van Vliet wrote:
Just bringing up
Ton van Vliet [EMAIL PROTECTED] wrote:
It would boil down to choice: explicit/speed vs implicit/readability
No, it would boil down to explicit+speed+readability+maintainability vs
implicit+error prone.
It would mean that as well as the interpreter having to search the
instance to work out
On Nov 24, 7:50 am, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
On Sat, 24 Nov 2007 02:54:27 -0800, samwyse wrote:
On Nov 24, 4:07 am, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
On Sat, 24 Nov 2007 01:55:38 -0800, samwyse wrote:
I've had the same thought, along with another.
On Nov 24, 10:07 am, Duncan Booth [EMAIL PROTECTED]
wrote:
Ton van Vliet [EMAIL PROTECTED] wrote:
It would boil down to choice: explicit/speed vs implicit/readability
No, it would boil down to explicit+speed+readability+maintainability vs
implicit+error prone.
It would mean that as well
On Sat, 24 Nov 2007 08:27:56 -0800, samwyse wrote:
On Nov 24, 7:50 am, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
On Sat, 24 Nov 2007 02:54:27 -0800, samwyse wrote:
On Nov 24, 4:07 am, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
On Sat, 24 Nov 2007 01:55:38 -0800, samwyse
On 24 Nov 2007 16:07:18 GMT, Duncan Booth
[EMAIL PROTECTED] wrote:
Ton van Vliet [EMAIL PROTECTED] wrote:
It would boil down to choice: explicit/speed vs implicit/readability
No, it would boil down to explicit+speed+readability+maintainability vs
implicit+error prone.
It would not be a full
On 24 Nov 2007 13:56:37 GMT, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
So::
def meth(self):
using self:
tmp = raw_input('Enter age: ')
age = int(tmp)
becomes::
def meth(self):
using self:
self.tmp =
On 24 Nov, 20:10, Patrick Mullen [EMAIL PROTECTED] wrote:
Yes, that's no good. So you would write it like so:
def meth(self,*args):
tmp = int(raw_input('Enter age:'))
using self:
age = tmp
Still an unnecessary lookup on tmp though :)
Indeed. As has been mentioned, it's
samwyse wrote:
so you might instead
add 'as' clauses as an alternate way to reduce confusion:
using myclass.new() as p:
p.do_something()
p.something_else()
or even
p = myclass.new()
p.do_something()
p.something_else()
Doesn't even need any new syntax. :-)
--
Patrick Mullen wrote:
Sometimes I actually use a dictionary, but typing all of the quotes
for the keys gets old.
If the keys are all identifiers, you can use keyword
args to the dict constructor. So you could write
self.__dict__.update(dict(var1 = 5,
var2 = a value, var3 = stuff))
if
samwyse wrote:
Later, I inevitably decide to encapsulate it inside a class, which
means lots of source changes to change my function into a method
You'd be better off changing your design habits to make
things into classes from the beginning if you suspect
you may want it that way later.
--
For these localized initialization blocks, I don't see anything wrong
with:
_ = self
_.var1 = 5
_.var2 = a value
_.var3 = stuff
_.var4 = [2,54,7,7]
_.var5 = dingaling
_.var6 = 6.4
_.var7 = 1
_.var8 = False
_.var9 = True
Or if you wanted to simulate something like using or with:
for _ in [self]:
On Nov 23, 2007 11:54 PM, Steven D'Aprano
[EMAIL PROTECTED] wrote:
On Fri, 23 Nov 2007 23:38:24 +, BJörn Lindqvist
wrote:
I like that a lot. This saves 12 characters for the original example and
removes the need to wrap it.
7return math.sqrt(.x * .x + .y * .y + .z * .z)
On Nov 24, 10:54 am, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
[snip]
The correct solution to your example is to get rid of the attribute
lookups from the expression completely:
correct in what sense?
def abs(self):
x, y, z = self.x, self.y, self.z
return
On Nov 23, 7:21 pm, BJörn Lindqvist [EMAIL PROTECTED] wrote:
On Nov 23, 2007 11:54 PM, Steven D'Aprano
The correct solution to your example is to get rid of the attribute
lookups from the expression completely:
No it is not. The solution is nothing more than a silly band-aid
thrown out by
Most of the time self doesn't bother me in the slightest. The one
time it does bother me however, is when I am turning a function into a
method. In this case, often I have many local variables which I
actually want to be instance variables, so I have to add self to all
of them. Of course, this
Hi,
Python uses self (and textual notation when possible) because its
designers consider that symbols reduce readability. Self won't go
away. :-P
The issue is related to the first and seventh lines in The Zen of
Python,
1. Beautiful is better than ugly
7. Readability counts.
My opinion
On 2007-11-23, BJörn Lindqvist [EMAIL PROTECTED] wrote:
The big deal is that self. occupies important horizontal
screen real estate. That is, it is usually not self in itself
that is problematic, but the overflowing lines is. Take this
silly vector class for example:
1class Vector:
2
On Fri, 23 Nov 2007 23:38:24 +, BJörn Lindqvist
wrote:
I like that a lot. This saves 12 characters for the original example and
removes the need to wrap it.
7return math.sqrt(.x * .x + .y * .y + .z * .z)
+1 Readability counts, even on small screens.
-2 Readability counts,
On Nov 22, 2007 2:08 PM, Colin J. Williams [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Alexy:
Sometimes I
avoid OO just not to deal with its verbosity. In fact, I try to use
Ruby anywhere speed is not crucial especially for @ prefix is better-
looking than self.
Ruby speed
On Nov 24, 2:38 am, BJörn Lindqvist [EMAIL PROTECTED] wrote:
The big deal is that self. occupies important horizontal screen real
estate. That is, it is usually not self in itself that is problematic,
Exactly. I understand and appreciate all the scoping qualification
and explicitation needs,
Colin J. Williams schrieb:
Kay Schluehr wrote:
On Nov 22, 8:43 pm, Bruno Desthuilliers
[EMAIL PROTECTED] wrote:
Colin J. Williams a écrit :
[EMAIL PROTECTED] wrote:
Alexy:
Sometimes I
avoid OO just not to deal with its verbosity. In fact, I try to use
Ruby anywhere speed is not
On Nov 24, 12:54 am, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
The correct solution to your example is to get rid of the attribute
lookups from the expression completely:
def abs(self):
x, y, z = self.x, self.y, self.z
return math.sqrt(x**2 + y**2 + z**2)
It's
BJörn Lindqvist wrote:
6def abs(self):
7return math.sqrt(self.x * self.x + self.y * self.y +
self.z * self.z)
I would write that as
def abs(self):
x = self.x
y = self.y
z = self.z
return math.sqrt(x * x + y * y + z * z)
Not only is it
On Fri, 23 Nov 2007 20:48:06 -0800, Kay Schluehr wrote:
I like this pattern but less much I like the boilerplate. What about
an explicit unpacking protocol and appropriate syntax?
def abs(self):
x, y, z by self
return math.sqrt(x**2 + y**2 + z**2)
expands to
def abs(self):
On 24 Nov., 07:29, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
On Fri, 23 Nov 2007 20:48:06 -0800, Kay Schluehr wrote:
I like this pattern but less much I like the boilerplate. What about
an explicit unpacking protocol and appropriate syntax?
def abs(self):
x, y, z by self
On 2007-11-22, Steven D'Aprano [EMAIL PROTECTED] wrote:
On Wed, 21 Nov 2007 15:51:56 -0800, braver wrote:
Is there any trick to get rid of having to type the annoying,
character-eating self. prefix everywhere in a class?
You got this highly flexible language, very good for rapid programming,
Alexy:
Sometimes I
avoid OO just not to deal with its verbosity. In fact, I try to use
Ruby anywhere speed is not crucial especially for @ prefix is better-
looking than self.
Ruby speed will increase, don't worry, as more people will use it.
Bye,
bearophile
--
On 22 Nov., 00:51, braver [EMAIL PROTECTED] wrote:
But things grow -- is there any metaprogramming tricks or whatnot we
can throw on the self?
http://docs.python.org/lib/compiler.html
--
http://mail.python.org/mailman/listinfo/python-list
On Nov 22, 4:34 pm, Kay Schluehr [EMAIL PROTECTED] wrote:
On 22 Nov., 00:51, braver [EMAIL PROTECTED] wrote:
But things grow -- is there any metaprogramming tricks or whatnot we
can throw on the self?
http://docs.python.org/lib/compiler.html
Indeed. Well, my current solution is to bow to
On Thu, Nov 22, 2007 at 10:13:46AM +0100, A.T.Hofkamp wrote regarding Re: the
annoying, verbose self:
On 2007-11-22, Steven D'Aprano [EMAIL PROTECTED] wrote:
On Wed, 21 Nov 2007 15:51:56 -0800, braver wrote:
Is there any trick to get rid of having to type the annoying,
character-eating
braver wrote:
Is there any trick to get rid of having to type the annoying,
character-eating self. prefix everywhere in a class? Sometimes I
avoid OO just not to deal with its verbosity. In fact, I try to use
Ruby anywhere speed is not crucial especially for @ prefix is better-
looking
Colin J. Williams a écrit :
[EMAIL PROTECTED] wrote:
Alexy:
Sometimes I
avoid OO just not to deal with its verbosity. In fact, I try to use
Ruby anywhere speed is not crucial especially for @ prefix is better-
looking than self.
Ruby speed will increase, don't worry, as more people
On Nov 22, 8:43 pm, Bruno Desthuilliers
[EMAIL PROTECTED] wrote:
Colin J. Williams a écrit :
[EMAIL PROTECTED] wrote:
Alexy:
Sometimes I
avoid OO just not to deal with its verbosity. In fact, I try to use
Ruby anywhere speed is not crucial especially for @ prefix is better-
On 22 Nov, 20:24, Ayaz Ahmed Khan [EMAIL PROTECTED] wrote:
I've never really understood why some people find that annoying to do. I
make it a point to use, for example, the `this` operator when writing C++
code to avoid implicilty calling/accessing attributes of objects as much
as possible.
On Nov 23, 1:15 am, Paul Boddie [EMAIL PROTECTED] wrote:
One wonders whether the people complaining so vehemently
about self have ever encountered coding style guides.
Dude, I'm also programming in Ada, 83 to 95 to 2005. Beautiful
language, a living style guide. I love typing names dozens of
Paul Boddie a écrit :
On 22 Nov, 20:24, Ayaz Ahmed Khan [EMAIL PROTECTED] wrote:
I've never really understood why some people find that annoying to do. I
make it a point to use, for example, the `this` operator when writing C++
code to avoid implicilty calling/accessing attributes of objects
Kay Schluehr a écrit :
(snip)
The object model is irrelevant here. The substitution is purely
syntactical and gets resolved at compile time:
def foo(first, ...):
.bar = ...
is always equivalent with:
def foo(first, ...):
first.bar = ...
and generates the same bytecode.
On 23 Nov, 01:41, braver [EMAIL PROTECTED] wrote:
On Nov 23, 1:15 am, Paul Boddie [EMAIL PROTECTED] wrote:
One wonders whether the people complaining so vehemently
about self have ever encountered coding style guides.
Dude, I'm also programming in Ada, 83 to 95 to 2005.
It's not often that
braver wrote:
Is there any trick to get rid of having to type the annoying,
character-eating self. prefix everywhere in a class? Sometimes I
avoid OO just not to deal with its verbosity. In fact, I try to use
Ruby anywhere speed is not crucial especially for @ prefix is better-
looking than
There are always tricks. If 5 characters is really too much to type,
how about 2 characters s.. Though I would recommend against that
since
it violates standard Python convention.
def foo( self ):
becomes
def foo( s ):
Otherwise, if you happen to be using self.something a lot, just
assign it
On Wed, 21 Nov 2007 15:51:56 -0800, braver wrote:
Is there any trick to get rid of having to type the annoying,
character-eating self. prefix everywhere in a class?
Oh I know! It' uch a pain. Sinc writing a hug cla lat wk, I'v had a
trribl hortag o lowrca S E L and F charactr. It mak writing
86 matches
Mail list logo
