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 met
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 d
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 va
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
> >
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 +
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 t
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 Desth
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
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
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:
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 FunctionT
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 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 'meth
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.
>
>
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
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
j
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 e
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 = "dingali
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 v
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...
--
http
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:
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
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
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
>
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 + oldLoc
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 --
> 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 thos
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
"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
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?
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
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
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
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 [sel
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.
--
G
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))
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. :
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 menti
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 = self.
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
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 th
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,
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 wi
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 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:
>>>
>>
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
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
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
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)
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 be
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
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():
> g
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 inst
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 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 do begin
> a = ...
> b = ...
> en
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 wa
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
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 ab
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)
>
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 ea
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
>
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 i
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 opi
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 Vect
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
> retu
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
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 co
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 explicit"ation
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.
>
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
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
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
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 byt
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 poss
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 @
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 w
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-
> looki
[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 will use it.
>
> Bye,
>
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
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
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
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
--
http://mail.python.org/ma
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 prog
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 writ
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 i
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-
> lookin
87 matches
Mail list logo
