Do pythons like sugar?
Afanasiy
But it's ugly as sin. With all those self's I consider
it much less readable than it could be...
A few languages provide syntax sugar for dealing with
this by allowing you to localize the class scope.
Does Python? eg. `with self do:`
def format( self, width=80 ):
self.lines = ['']
i = 0
for word in self.text.split():
if self.textwidth(self.lines[i]) + self.textwidth(word) <= width:
if self.textwidth(self.lines[i]) > 0:
self.lines[i] += ' '
self.lines[i] += word
else:
i += 1
self.lines.append(word)
Andrew Dalke
> I've written this method for a text formatting class...
> But it's ugly as sin. With all those self's I consider
> it much less readable than it could be...
> Does Python? eg. `with self do:`
>
> def format( self, width=80 ):
> self.lines = ['']
> i = 0
> for word in self.text.split():
> if self.textwidth(self.lines[i]) + self.textwidth(word) <= width:
> if self.textwidth(self.lines[i]) > 0:
> self.lines[i] += ' '
> self.lines[i] += word
> else:
> i += 1
> self.lines.append(word)
>
Do you really need all those self references? This looks like it should
be a function, as in
def format(text, width = 80):
lines = []
line = ''
for word in text.split():
if len(line) + len(word) <= width:
if line:
line += ' '
line += word
else:
if not line:
raise TypeError("The word %r is more than %d colums!" % \
(word, width))
lines.append(line)
line = ''
return lines
class ...
def ...
self.lines = format(text, 132)
(Note -- I'm using 'len' instead of your 'self.textwidth'. You
could pass in the length function as a parameter if you want.)
If using Python 2.3, see the 'textwrap' module.
Andrew
da...@dalkescientific.com
Simon Wittber (Maptek)
Nope. However, you could perhaps rewrite this function to be slighty
more readable and faster. (See below)
> def format( self, width=80 ):
> self.lines = ['']
> i = 0
> for word in self.text.split():
> if self.textwidth(self.lines[i]) + self.textwidth(word) <= width:
> if self.textwidth(self.lines[i]) > 0:
> self.lines[i] += ' '
> self.lines[i] += word
> else:
> i += 1
> self.lines.append(word)
def format(self, width=80):
lines = ['']
i = 0
for word in self.text.split():
if self.textwidth(lines[i]) + self.textwidth(word) <= width:
if self.textwidth(lines[i]) > 0:
lines[i] += ' '
lines[i] += word
else:
i += 1
lines.append(word)
self.lines = lines
This avoids a few references to self, which looks better, and is slighty
faster too!
Simon.
Afanasiy
So the answer is a definitive no? I want to do things as I have them,
I don't want to change my design just to be able to type 'self' less.
Is there any tricky one-liner that brings object members in scope?
P.S. The specific implementation above should be considered irrelevant.
Max M
No. But a little imagination takes you a long part of the way:
def format( self, width=80 ):
twidth = self.textwidth
lines = ['']
i = 0
for word in self.text.split():
if twidth(lines[i]) + twidth(word) <= width:
if twidth(lines[i]) > 0:
lines[i] += ' '
lines[i] += word
else:
i += 1
lines.append(word)
self.lines = lines
regards Max M
--
hilsen/regards Max M
http://www.futureport.dk/
Fremtiden, videnskab, skeptiscisme og transhumanisme
Andrew Dalke
>>A few languages provide syntax sugar for dealing with
>>this by allowing you to localize the class scope.
>>
>>Does Python? eg. `with self do:`
> So the answer is a definitive no? I want to do things as I have them,
> I don't want to change my design just to be able to type 'self' less.
It's a definite no. From previous accounts, said sugar is hiding
rat poison. It's advantages are slight to its disadvantages. Eg,
for your case it would have hid a poor implementation rather than
yield a better one.
When I do a lot of "self." references it's mostly with a set of
initializations. In that case I just leave "self." in my paste
buffer.
> Is there any tricky one-liner that brings object members in scope?
Yes but I won't tell. You shouldn't use it.
> P.S. The specific implementation above should be considered irrelevant.
In order to add a new feature, especially one which affect the
language like that, then you'll need to come up with a pressing example.
If there isn't one, then there's no need for a change, eh?
Andrew
da...@dalkescientific.com
Afanasiy
>Afanasiy wrote:
>>>A few languages provide syntax sugar for dealing with
>>>this by allowing you to localize the class scope.
>>>
>>>Does Python? eg. `with self do:`
>
>> So the answer is a definitive no? I want to do things as I have them,
>> I don't want to change my design just to be able to type 'self' less.
>
>It's a definite no. From previous accounts, said sugar is hiding
>rat poison. It's advantages are slight to its disadvantages. Eg,
>for your case it would have hid a poor implementation rather than
>yield a better one.
You don't know what I am doing. My design is perfect.
In my situation, your way is wrong. I am not looking to
hide a poor implementation. That's a rude assumption.
>> Is there any tricky one-liner that brings object members in scope?
>
>Yes but I won't tell. You shouldn't use it.
Excellent, thanks.
Afanasiy
>No. But a little imagination takes you a long part of the way:
>
>def format( self, width=80 ):
> twidth = self.textwidth
> lines = ['']
> i = 0
> for word in self.text.split():
> if twidth(lines[i]) + twidth(word) <= width:
> if twidth(lines[i]) > 0:
> lines[i] += ' '
> lines[i] += word
> else:
> i += 1
> lines.append(word)
> self.lines = lines
I already knew I could make aliases/references or 'macros' (as the
documentation calls them) to members I wish to access more easily.
I am not arguing for some addition to the language, I just asked a
question and the answer is apparently no, except for the knowledge
Dalke is withholding of course. But I can find that one my own...
I just thought this would be a little better than some irc channel.
Andrew Bennetts
> On Thu, 09 Jan 2003 03:25:41 -0700, some Dalke wrote:
>
> >Afanasiy wrote:
> >>>A few languages provide syntax sugar for dealing with
> >>>this by allowing you to localize the class scope.
> >>>
> >>>Does Python? eg. `with self do:`
> >
> >> So the answer is a definitive no? I want to do things as I have them,
> >> I don't want to change my design just to be able to type 'self' less.
> >
> >It's a definite no. From previous accounts, said sugar is hiding
> >rat poison. It's advantages are slight to its disadvantages. Eg,
> >for your case it would have hid a poor implementation rather than
> >yield a better one.
>
> You don't know what I am doing. My design is perfect.
What is good design for one language isn't necessarily good design for
another. Python offers different features to, say, C++, and is best used in
different ways. I would recommend that you try to understand the pythonic
world-view better, rather than insisting on imposing your preconceptions on
us... my experience agrees with Andrew Dalke's; explicit self is much better
than the alternatives.
Not to mention that the code you have shown us doesn't give me any confidence
that your code is what you claim it to be.
> In my situation, your way is wrong. I am not looking to
> hide a poor implementation. That's a rude assumption.
What is your situation? You're refusing to say what it actually is, so it's
reasonable for people to refuse to try help you -- its hard to know what the
answer is if you won't tell us the question!
Show us your code, and let us help you.
-Andrew.
Afanasiy
<andrew-p...@puzzling.org> wrote:
>What is good design for one language isn't necessarily good design for
>another. Python offers different features to, say, C++, and is best used in
>different ways. I would recommend that you try to understand the pythonic
>world-view better, rather than insisting on imposing your preconceptions on
>us... my experience agrees with Andrew Dalke's; explicit self is much better
>than the alternatives.
The design is simple and normal. Dalke's code in response to mine made
changes which would break my design. My design for my project is right.
It also just happens to be of a very traditional and common methodology.
>Not to mention that the code you have shown us doesn't give me any confidence
>that your code is what you claim it to be.
You cannot see what the rest of the class is doing or meant to do.
>What is your situation? You're refusing to say what it actually is, so it's
>reasonable for people to refuse to try help you -- its hard to know what the
>answer is if you won't tell us the question!
It is not relevant. I just wanted to know about the possibility of
implicit self. I suppose this is a sore spot. I'll look elsewhere,
but will continue to react to people saying I am doing it wrong
when all I was asking about what the possibility of implicit self.
Afanasiy
<andrew-p...@puzzling.org> wrote:
>On Thu, Jan 09, 2003 at 10:47:13AM +0000, Afanasiy wrote:
>> On Thu, 09 Jan 2003 03:25:41 -0700, some Dalke wrote:
>>
>> >Afanasiy wrote:
>> >>>A few languages provide syntax sugar for dealing with
>> >>>this by allowing you to localize the class scope.
>> >>>
>> >>>Does Python? eg. `with self do:`
>> >
>> >> So the answer is a definitive no? I want to do things as I have them,
>> >> I don't want to change my design just to be able to type 'self' less.
>> >
>> >It's a definite no. From previous accounts, said sugar is hiding
>> >rat poison. It's advantages are slight to its disadvantages. Eg,
>> >for your case it would have hid a poor implementation rather than
>> >yield a better one.
>>
>> You don't know what I am doing. My design is perfect.
>
>What is good design for one language isn't necessarily good design for
>another. Python offers different features to, say, C++, and is best used in
>different ways. I would recommend that you try to understand the pythonic
>world-view better, rather than insisting on imposing your preconceptions on
>us... my experience agrees with Andrew Dalke's; explicit self is much better
>than the alternatives.
If the "pythonic world-view" is that code which would look better with
implicit self is "poor implementation", then no, I do not agree with it.
Please note I am not complaining out about the lack of this possibility.
I only have a problem with the condescending tones. I guess it's normal.
Andrew Bennetts
The pythonic world-view on this particular issue is that "Explicit is better
than implicit", yes.
> Please note I am not complaining out about the lack of this possibility.
> I only have a problem with the condescending tones. I guess it's normal.
In my experience, people who find this sort of thing about Python annoying
aren't using Python optimally. My recommendation is to trust us, show us
your whole class, and invite constructive criticism on its design. This may
sound condescending, but this newsgroup is filled with experienced Python
programmers, and I would be very surprised if you considered yourself better
at writing Python than them.
-Andrew.
holger krekel
They probably stem from strong oppinions about the "virtues" of implicit
instance references. I guess i can understand the intentions of
both sides.
Sometimes you are doing lots of accesses to instance attributes
in a specific (e.g. algorithmic) part of a method. It makes sense
to have a mechanism which lets you specify that certain
(otherwise local) names refer in fact to instance attributes.
Good news is that i am currently implementing something
along these lines which allows to 'connect' local names with
instance attributes. You have to explicitely specify these
names, though. hopefully this will appeal to both sides.
cheers,
holger
Andrew Bennetts
> On Thu, 9 Jan 2003 22:29:33 +1100, Andrew Bennetts
> <andrew-p...@puzzling.org> wrote:
>
> >What is good design for one language isn't necessarily good design for
> >another. Python offers different features to, say, C++, and is best used in
> >different ways. I would recommend that you try to understand the pythonic
> >world-view better, rather than insisting on imposing your preconceptions on
> >us... my experience agrees with Andrew Dalke's; explicit self is much better
> >than the alternatives.
>
> The design is simple and normal. Dalke's code in response to mine made
> changes which would break my design. My design for my project is right.
> It also just happens to be of a very traditional and common methodology.
It also just happens that your design is not of a common methodology for
Python code. To my eyes, it looks needlessly complex, but it is hard to
tell without the surrounding context.
> >Not to mention that the code you have shown us doesn't give me any confidence
> >that your code is what you claim it to be.
>
> You cannot see what the rest of the class is doing or meant to do.
Indeed. I am extrapolating based on what little information I have... if
you would show us the whole class, I could have a more informed opinion.
Until then, I will work with what data I have.
> >What is your situation? You're refusing to say what it actually is, so it's
> >reasonable for people to refuse to try help you -- its hard to know what the
> >answer is if you won't tell us the question!
>
> It is not relevant. I just wanted to know about the possibility of
> implicit self. I suppose this is a sore spot. I'll look elsewhere,
> but will continue to react to people saying I am doing it wrong
> when all I was asking about what the possibility of implicit self.
The answer is "no, and you don't really need it". The fact that you are
asking the question suggests that you don't fully appreciate the pythonic
way of doing things, hence the condescening replies you complain about in
another post. That's not to say the idea is entirely without merit; but it
has been debated often in the past -- as a quick search through the archives
would show -- and the vast majority seem to be in agreement that it is a bad
idea.
-Andrew.
Steve Holden
news:6u6q1vk7dgjps43t0...@4ax.com...
regards
-----------------------------------------------------------------------
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/
Bring your musical instrument to PyCon! http://www.python.org/pycon/
-----------------------------------------------------------------------
Andrew Koenig
Afanasiy> def format( self, width=80 ):
Afanasiy> self.lines = ['']
Afanasiy> i = 0
Afanasiy> for word in self.text.split():
Afanasiy> if self.textwidth(self.lines[i]) + self.textwidth(word) <= width:
Afanasiy> if self.textwidth(self.lines[i]) > 0:
Afanasiy> self.lines[i] += ' '
Afanasiy> self.lines[i] += word
Afanasiy> else:
Afanasiy> i += 1
Afanasiy> self.lines.append(word)
def format( self, width=80 ):
lines = self.lines = ['']
textwidth = self.textwidth
i = 0
for word in self.text.split():
if textwidth(lines[i]) + textwidth(word) <= width:
if textwidth(lines[i]) > 0:
lines[i] += ' '
lines[i] += word
else:
i += 1
lines.append(word)
--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark
Nick Vargish
> You don't know what I am doing. My design is perfect.
c.f. 'hubris'.
Nick
--
#include<stdio.h> /* SigMask 0.3 (sig.c) 19990429 PUBLIC DOMAIN "Compile Me" */
int main(c,v)char *v;{return !c?putchar(*v-1)&&main(0,v+ /* Tweaks welcomed. */
1):main(0,"Ojdl!Wbshjti!=obwAqbusjpu/ofu?\v\1");} /* build: cc -o sig sig.c */
Steve Holden
news:mailman.1042118119...@python.org...
I wouldn't be at all surprised if he considered himself better at writing
Python. I'd be surprised if he were right, though.
Afanasiy: to write '''If the "pythonic world-view" is that code which would
look better with implicit self is "poor implementation"''' and '''My design
is perfect.''', and then complain about condescending attitudes strikes me
as the pot calling the kettle black. You asked a question, and you got
answers. You may not have liked the tone, but since you can only *interpret*
its meaning it usually doesn't do you much good to complain about newsgroup
modes of expression. Or, more shortly: "get over it!".
This is actually quite a friendly group (certainly there are many others
where you would experience much greater hostility). Try not to interpret
comments as condescending: they usually aren't. I guess you may wish to make
an exception of this message :-), though I am actually trying to pur oil on
troubled waters.
Afanasiy
<andrew-p...@puzzling.org> wrote:
>On Thu, Jan 09, 2003 at 12:54:24PM +0000, Afanasiy wrote:
>> On Thu, 9 Jan 2003 22:29:33 +1100, Andrew Bennetts
>> <andrew-p...@puzzling.org> wrote:
>> >>
>> >> You don't know what I am doing. My design is perfect.
>> >
>> >What is good design for one language isn't necessarily good design for
>> >another. Python offers different features to, say, C++, and is best used in
>> >different ways. I would recommend that you try to understand the pythonic
>> >world-view better, rather than insisting on imposing your preconceptions on
>> >us... my experience agrees with Andrew Dalke's; explicit self is much better
>> >than the alternatives.
>>
>> If the "pythonic world-view" is that code which would look better with
>> implicit self is "poor implementation", then no, I do not agree with it.
>
>The pythonic world-view on this particular issue is that "Explicit is better
>than implicit", yes.
Except that is entirely not my point. Thinking so causes friction.
And this friction is only bad for me, because you create the two
sided argument from your side so that it looks like I am somehow
anti-Python or anti-implicit. It's a disgusting way of communicating.
>> Please note I am not complaining out about the lack of this possibility.
>> I only have a problem with the condescending tones. I guess it's normal.
>
>In my experience, people who find this sort of thing about Python annoying
>aren't using Python optimally. My recommendation is to trust us, show us
>your whole class, and invite constructive criticism on its design. This may
>sound condescending, but this newsgroup is filled with experienced Python
>programmers, and I would be very surprised if you considered yourself better
>at writing Python than them.
I would rather not have people to tell me how to design basic classes.
Thanks for the offer. I will surely ask if I need the assistance there.
Afanasiy
wrote:
>Afanasiy <abeli...@hotmail.com> writes:
>
>> You don't know what I am doing. My design is perfect.
>
>c.f. 'hubris'.
And the same to those who would say it is wrong.
They can say it is wrong, I can say it is right.
Afanasiy
wrote:
>Afanasiy> Does Python? eg. `with self do:`
>
> def format( self, width=80 ):
> lines = self.lines = ['']
> textwidth = self.textwidth
> i = 0
> for word in self.text.split():
> if textwidth(lines[i]) + textwidth(word) <= width:
> if textwidth(lines[i]) > 0:
> lines[i] += ' '
> lines[i] += word
> else:
> i += 1
> lines.append(word)
Thank you, I did know that, and wrote it as such before ever asking my
question here. I did not like the thought of having to do that for all
future methods I would be writing. But I now see I have to. Thanks.
Afanasiy
<sho...@holdenweb.com> wrote:
>"Andrew Bennetts" <andrew-p...@puzzling.org> wrote in message
>news:mailman.1042118119...@python.org...
>Afanasiy: to write '''If the "pythonic world-view" is that code which would
>look better with implicit self is "poor implementation"''' and '''My design
>is perfect.''', and then complain about condescending attitudes strikes me
>as the pot calling the kettle black. You asked a question, and you got
>answers. You may not have liked the tone, but since you can only *interpret*
>its meaning it usually doesn't do you much good to complain about newsgroup
>modes of expression. Or, more shortly: "get over it!".
I have the same desire to defend myself with a reply as you or others.
Except that I was the original victim and my double quoting remark was
a purely logical rephrasing of what they were telling me. The fact that
it spurred such a reply when *I* rephrashed what they said says much.
>This is actually quite a friendly group (certainly there are many others
>where you would experience much greater hostility). Try not to interpret
>comments as condescending: they usually aren't. I guess you may wish to make
>an exception of this message :-), though I am actually trying to pur oil on
>troubled waters.
When someone like Dalke trolls I will always react.
Afanasiy
wrote:
It should not be common practice to slander someone who asks this.
I'm going to attempt to ignore this thread now. Have a nice life.
Afanasiy
wrote:
>I've written this method for a text formatting class...
Just had to have one more reply. I did say "try"... anyway...
I stumbled onto the fact that Peter Norvig agrees with me. ;)
Mike Meyer
> I would rather not have people to tell me how to design basic classes.
> Thanks for the offer. I will surely ask if I need the assistance there.
I don't think anyone wants to tell you how to design basic
classes. We'd just like to point out where you may have missed a trick
because you're not familiar with Python.
For instance, you test for "self.textwidth(self.lines[i]) > 0". Surely
that test can just be "self.lines[i]"? Or are there characters with
zero width?
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Michele Simionato
I have posted few days ago a solution involving metaclasses which allows
Python to recognize _x as a shortcut for self.x. For instance your code
would read
from noself import Noself
class D(Noself):
text='Hello world!' #put here your text
def textwidth(self,x): #put here your textwidth function
return len(x)
def format( self, width=80 ):
_lines = ['']
i = 0
for word in _text.split():
if _textwidth(_lines[i]) + _textwidth(word) <= width:
if _textwidth(_lines[i]) > 0:
_lines[i] += ' '
_lines[i] += word
else:
i += 1
_lines.append(word)
d=D()
d.format()
print d.lines
I don't know if this is elegant enough for you. It works with Python 2.2,
but it has some limitations (for instance you cannot use methods
defined trough lambda functions). Moreover, in the present form,
_x is replaced with self.x even inside strings, which is bad.
Finally, you will break pre-existing code using variables of
kind "_x".
Nevertheless, I send the script to you to show that a solution is possible,
but not recommended, since you would confused all Pythonistas if
you use that instead of self.
--- begin noself.py ---
import re,inspect
def selfexpand(cls):
"""Given a class, looks in its methods and expands identifiers starting
with _ to self. For instance, _x --> self.x. Identifiers starting with
__ are expanded as __x --> self._classname__x. Identifiers of the
form __something__ are ignored. This first version is very stupid and
does the replacement in comments (no big harm) and strings
(potentially big harm!) too."""
__id__=r'(\b__\w+?__\b)' #first, look at this kind of identifier
__id =r'\b__(\w*)' #then, at this kind
_id =r'\b_([a-zA-Z_]\w*)' #then, at this kind
regexp=re.compile('|'.join([__id__,__id,_id]))
def sub(match):
i=match.lastindex; g=match.group(i)
if i==1: return g # do nothing
elif i==2: return 'self._%s__%s' % (cls.__name__,g)
elif i==3: return 'self.%s' % g
def kill_initial_spaces(text):
lines=text.splitlines(); firstline=lines[0]
spaces=len(firstline)-len(firstline.lstrip())
if not spaces: return text
else: return '\n'.join([line[spaces:] for line in lines])
def modify(method):
source=kill_initial_spaces(inspect.getsource(method))
code=regexp.sub(sub,source) # print code
d={}; exec code+'\n' in d
setattr(cls,method.__name__,d[method.__name__])
for key,val in cls.__dict__.items():
if inspect.isroutine(val): modify(val)
class Noself:
class __metaclass__(type):
"Classes who inherit from Noself automagically call selfexpand"
def __init__(cls,name,bases,dic): selfexpand(cls)
--- end noself.py ---
Laura Creighton
Ben Leslie wanted to know the difference between 'clever' and 'wise'.
Andrew Dalke wrote:
> Afanasiy wrote:
> >>A few languages provide syntax sugar for dealing with
> >>this by allowing you to localize the class scope.
> >>
> >>Does Python? eg. `with self do:`
>
> > So the answer is a definitive no? I want to do things as I have them,
> > I don't want to change my design just to be able to type 'self' less.
>
> It's a definite no. From previous accounts, said sugar is hiding
> rat poison. It's advantages are slight to its disadvantages. Eg,
> for your case it would have hid a poor implementation rather than
> yield a better one.
>
> When I do a lot of "self." references it's mostly with a set of
> initializations. In that case I just leave "self." in my paste
> buffer.
>
> > Is there any tricky one-liner that brings object members in scope?
>
> Yes but I won't tell. You shouldn't use it.
Afanasiy is looking to be clever here. Andrew Dalke doesn't think that
it is wise.
<snip>
Laura Creighton
Andrew Dalke
> You don't know what I am doing. My design is perfect.
> hide a poor implementation. That's a rude assumption.
I didn't say your design was imperfect, I said your
implementation was. Though upon review, what I though
was an error in your code (regarding long word lengths)
is not. That error of mine is not germane to the rest
of this thread.
> When someone like Dalke trolls I will always react.
Me? Trolling? That's the first time in 12+ years of
newsgroups that I've been accused of that. You're
pretty thin skinned or hot headed if you believe this
to be the case.
> I just asked a question and the answer is apparently no,
> except for the knowledge Dalke is withholding of course.
> But I can find that one my own...
Unlikely that you can find it, but hey, it's little
skin off my nose and it's cute in an evil sort of way
But if you or anyone uses this in your code, you should
be rightly chastised by everyone else in a code review.
In other words "DO NOT USE IN REAL CODE - I WILL NOT BE
HELD RESPONSIBLE IF YOU DEPLOY WITH THIS. FOR NOVELTY
USE ONLY."
>>> class Foo:
... eggs = 1
... def doit(self):
... self.spam = 5
... self.tomato = 3
... for x in dir(self): exec "%s = self.%s" % (x,x)
... for k, v in locals().items():
... print k, "==", v
... print
... print "the calculation yields", tomato ** spam
...
>>> Foo().doit()
doit == <bound method Foo.doit of <__main__.Foo instance at 0x815a284>>
tomato == 3
__module__ == __main__
spam == 5
x == tomato
self == <__main__.Foo instance at 0x815a284>
eggs == 1
__doc__ == None
the calculation yields 243
>>>
Andrew
da...@dalkescientific.com
Carl Banks
> Afanasiy <abeli...@hotmail.com> writes:
>
>> You don't know what I am doing. My design is perfect.
>
> c.f. 'hubris'.
I hope everyone else realizes he (Afanasiy) was being ironic. I
realize using sublte irony in a computer programming chat room is not
the smartest thing to do, as programmers tend not to be the most
metaphorical people in the world.
--
CARL BANKS
Carl Banks
> I wouldn't be at all surprised if he considered himself better at writing
> Python. I'd be surprised if he were right, though.
>
> Afanasiy: to write '''If the "pythonic world-view" is that code which would
> look better with implicit self is "poor implementation"''' and '''My design
> is perfect.''', and then complain about condescending attitudes strikes me
> as the pot calling the kettle black.
I really don't see it.
If I asked a question about how to get rid of self, and was told that
self is necessary because code without self makes a poor
implementation, I would say the same thing, because it's a damn petty
excuse to refuse to answer the question. That's not why Python uses
self, and it's flatly wrong.
And when he said, "My design is perfect," he was being sarcastic, and
was mocking Andrew Dalke's attitude.
What I do see is a presumptuous attitude from some of the reponders;
maybe not condescending, but definitely presumptuous.
> You asked a question, and you got answers.
He got unwanted answers to a question he didn't ask.
I understand this happens, and that a lot of people appreciate it. I
do it myself. But what I didn't like at all was the way some of the
posters continued to try to answer the question Afanasiy didn't ask,
even when it was clear he wasn't interested in the answer (e.g. Andrew
Bennett's "why don't you post some more code so we can help you
realize why you don't need self" attitude).
> You may not have liked the tone, but since you can only *interpret*
> its meaning it usually doesn't do you much good to complain about newsgroup
> modes of expression. Or, more shortly: "get over it!".
I agree, it is better to ignore well-meaning but presumptuous people.
Afanasiy could have avoided this whole mess just by ignoring the first
responder.
> This is actually quite a friendly group (certainly there are many others
> where you would experience much greater hostility). Try not to interpret
> comments as condescending: they usually aren't. I guess you may wish to make
> an exception of this message :-), though I am actually trying to pur oil on
> troubled waters.
I agree this is a friendly newsgroup, and this kind of thing happens a
lot less than it happens elsewhere. I had an experience similar to
Afanasiy's on another newsgroup. I understand that responders will
sometimes will sometimes be presumptuous, however, one particular
poster reeked of it so bad that I lost my cool and let him know it
curtly. I regret the way I handled it today; I could and should have
been politer, and probably should have used email.
So I sympathize with Afanasiy here. It can be quite irritating to ask
a question, and have someone second guess you for even asking. And it
can be very nauseating when that person treats you as if you actually
did ask the question you didn't ask.
Because of this, I try very hard to avoid a presumptuous attitude when
answering questions, and I would like to request others try to as
well. Specifically, I would request that everyone always respect the
poster's original question. Replies like, "why are you doing it that
way, you should do it this way," without any regard to the actual
question, I find very rude.
Whenever I want to offer alternatives, I'll usually answer the
original question, if I know the answer, and then offer alternatives.
If I don't know the answer, I'll say I don't know it. Sometimes, if
it's really a bad idea, I'll offer to answer it if the poster really
wants, but highly suggest a something else. (And if the poster comes
back saying, "thanks but no thanks," I'll give him the answer.) But,
no matter what, I try to always acknowledge the question.
I think this newsgroup mostly does a good job of that.
--
CARL BANKS
Nick Vargish
> I hope everyone else realizes he (Afanasiy) was being ironic.
I believe your irony detector is yielding false positives.
> I realize using sublte irony in a computer programming chat room is
> not the smartest thing to do, as programmers tend not to be the most
> metaphorical people in the world.
Actually, programmers have to be fairly agile with metaphors and other
methods of abstraction, or was this further irony that I'm just not
getting?
Nick
--
# sigmask.py || version 0.2 || 2003-01-07 || Feed this to your Python.
print reduce(lambda x,y:x+chr(ord(y)-1),'Ojdl!Wbshjti!=obwAqbusjpu/ofu?','')
Andrew Dalke
> If I asked a question about how to get rid of self, and was told that
> self is necessary because code without self makes a poor
> implementation, I would say the same thing, because it's a damn petty
> excuse to refuse to answer the question. That's not why Python uses
> self, and it's flatly wrong.
That's not what happened, IMO. He asked two questions, one implicit
and one explicit. The implicit one was "my code is ugly because of
all the self. references, [what can I do to improve it?]" The explicit
one was a refinement of the original question, being "does Python
have a 'with self do' construct, which some other language use to
solve similar problems?"
Here's Afanasiy' OP so you don't need to find it.
] I've written this method for a text formatting class...
] But it's ugly as sin. With all those self's I consider
] it much less readable than it could be...
]
] A few languages provide syntax sugar for dealing with
] this by allowing you to localize the class scope.
]
] Does Python? eg. `with self do:`
First paragraph is the problem he's trying to solve. That's
the one he wants really wants answered.
Second paragraph thoughts about how other language solve it.
Third is a question asking if the second paragraph presents
a solution which is available in Python.
We answered his more fundamental question of how to make the code
less ugly. We "refused" to answer his second question because it
wasn't relevant to answering the first question.
When he asked for clarification on the second (explicit) question,
I said no, "with .. do" isn't available, there were other threads
on this topic, that the contruct turns out not being helpful (with
the implication he could Google for the other threads to see why),
and pointed out that it wouldn't help the code example he gave.
I then suggested a way to make it slightly easier for the cases
when a lot of self are needed.
I said there's a tricky one-liner which does what he explicitly
asked for in his second post, but that it shouldn't be used. It
shouldn't, and I made a judgement that if I posted it it would
be detrimental to his code and any others which read it.
I also pointed out that if he wants that feature added to Python
then he needs a good justification for it, which means specific
examples, as in code.
> And when he said, "My design is perfect," he was being sarcastic, and
> was mocking Andrew Dalke's attitude.
Th OP said my attitude was brusque, or some such. I've been reviewing
my post and I still don't see that. Yes, I said his implementation
(not his design) was poor. It is. Five other people agreed with me.
Was it wrong to point that out? It wasn't like I said it sucks or
other harshly disparaging terms. It's poor code, and any code review
would point it out. Not only that, I suggested how to improve it.
Since you agree with him (he having stopped responding to this thread),
perhaps you can clarify. Was it that I wouldn't give him the rope to
hang himself by posting the exec trick? His clarification was "object
members in scope?" and the exec trick does just that. However, it will
only do what he expects for in-place modifications of mutable objects,
since it doesn't put locals back into module scope.
Or should I have explained all that too?
> What I do see is a presumptuous attitude from some of the reponders;
> maybe not condescending, but definitely presumptuous.
Presumptuous? Because I made assumptions about his level of
Python knowledge based on the code he presented?
> He got unwanted answers to a question he didn't ask.
But he did ask it. Just not with a question mark.
> So I sympathize with Afanasiy here. It can be quite irritating to ask
> a question, and have someone second guess you for even asking. And it
> can be very nauseating when that person treats you as if you actually
> did ask the question you didn't ask.
Hence herein I described exactly my interpretation of the OP, to
show exactly why I saw two questions.
> Replies like, "why are you doing it that
> way, you should do it this way," without any regard to the actual
> question, I find very rude.
There are other ways to have constructed the OP to make it more
explicit on what was requested. The actual explicit question is
Does Python provide syntax sugar for dealing with many self
references by allowing you to localize the class scope?
That restated question is pieced together from across three different
paragraphs. Had it been written that way, it would have had an
explicit answer. It wasn't, hence the responses given.
> Whenever I want to offer alternatives, I'll usually answer the
> original question, if I know the answer, and then offer alternatives.
Hmm. And here I thought I did. 1) rewrite the code, 2) put 'self.'
in the paste buffer. I should also have offered 3) use local variables
instead of instance variables, but Simon Wittber already did that.
Yes, there was a solution I wasn't going to post, tough. I
wasn't going to lie and say no when the solution wasn't a proper
answer to the question. Nor did I want the obligation of explaining
how it worked, how it could go wrong, and why it shouldn't be used.
Perhaps I should stop posting then?
Andrew
da...@dalkescientific.com
Bengt Richter
[...]
>
>When someone like Dalke trolls I will always react.
Whether your perception is correct or not, "I will always react"
is delegating to others a lot of power over your life ;-)
If you find a suitable match, you will have infinite recursion.
Consider the pitiable madness in the Middle East and elsewhere,
where people helplessly "always react" ;-/
Regards,
Bengt Richter
Bengt Richter
I am sorry to read that you felt slandered. I may have missed a post or two.
There is certainly no license to slander in this newsgroup, and I think archives
fortunately will show that most disagreements do not end in huffy standoffs.
That said, I understand the feeling of being mistaken for something I'm not
and getting a response that is both socially and technically off mark.
Join the club ;-) It's bound to happen from time to time.
A point relating to your question is optimization. The 'self' name is not
treated specially, so it is looked up just like any other local name in the
method function. With an alternate indication of default self attribute
references, presumably one step could be removed from the code stream,
using a suitable new byte code instruction.
A possibility is keeping the '.' and leaving out the 'self' when the current
object is being referred to. That would make your code above look like:
(with 4-space indentation ;-)
def format( self, width=80 ):
.lines = ['']
i = 0
for word in .text.split():
if .textwidth(.lines[i]) + .textwidth(word) <= width:
if .textwidth(.lines[i]) > 0:
.lines[i] += ' '
.lines[i] += word
else:
i += 1
.lines.append(word)
How does that look to you?
Regards,
Bengt Richter
Cliff Wells
> On Thu, 09 Jan 2003 03:25:41 -0700, some Dalke wrote:
>
> >Afanasiy wrote:
> >>>this by allowing you to localize the class scope.
> >>>
> >>>Does Python? eg. `with self do:`
> >
> >> I don't want to change my design just to be able to type 'self' less.
> >
> >It's a definite no. From previous accounts, said sugar is hiding
> >rat poison. It's advantages are slight to its disadvantages. Eg,
> >for your case it would have hid a poor implementation rather than
> >yield a better one.
>
"My design is perfect?". I'll just let that speak for itself.
> In my situation, your way is wrong. I am not looking to
> hide a poor implementation. That's a rude assumption.
No, it's a fair assumption. A *silly* assumption would be to assume
that someone who clearly isn't that familiar with Python would have a
*correct* implementation.
> >> Is there any tricky one-liner that brings object members in scope?
> >
> >Yes but I won't tell. You shouldn't use it.
>
> Excellent, thanks.
Although I too am a bit curious what Andrew's trick is, I'm guessing it
involves manipulating namespaces in an "interesting" way. Not the sort
of thing to be encouraged. He knows that if he told you, you'd probably
use it and then regret it later on when you realized its implications,
or that using it would prevent you seeing a better solution.
I can understand that you are perhaps irritated that you didn't get the
answer you were looking for. If you had gotten a single reply that
simply read "No" would that have really made you happier? You asked a
question to which that was a valid reply, but you also implicitly
presented a problem that you thought "with self do:" was an answer for.
Rather than simply telling you "No" and letting you wonder, people were
trying to provide you with *alternative* methods that perhaps you would
find more palatable. It seems that with your "perfect" design
(something I personally haven't seen in almost 20 years of programming
and that, of course, you won't reveal) that you are above criticism or
even suggestions. If you dump a piece of code on a public forum, you
can expect it to be criticised. That's *why* you put it there.
Regards,
--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308
Cliff Wells
> Just had to have one more reply. I did say "try"... anyway...
> I stumbled onto the fact that Peter Norvig agrees with me. ;)
Damn, what is up with the mail<->news gateway? I have no idea which
post he is referring to. I also haven't seen my own posts for some time
(probably no big loss ;)
Steven D. Arnold
> Because of this, I try very hard to avoid a presumptuous attitude when
> answering questions, and I would like to request others try to as
> well. Specifically, I would request that everyone always respect the
> poster's original question. Replies like, "why are you doing it that
> way, you should do it this way," without any regard to the actual
> question, I find very rude.
>
> Whenever I want to offer alternatives, I'll usually answer the
> original question, if I know the answer, and then offer alternatives.
> If I don't know the answer, I'll say I don't know it. Sometimes, if
> it's really a bad idea, I'll offer to answer it if the poster really
> wants, but highly suggest a something else. (And if the poster comes
> back saying, "thanks but no thanks," I'll give him the answer.) But,
> no matter what, I try to always acknowledge the question.
If all you're saying is "answer the original question in addition to asking
about the overall intent" then I think we're in agreement. I only disagree
if "respecting the original question" means not asking about the overall
intent. I agree it's polite to answer the original question as best one
can, but experience shows that posters are often on the wrong track entirely
and would do better to change their approach.
I think the suggestion that a new approach was needed was a stab to
Afanasiy's vain picture of himself as master programmer, and that, not the
responses to his question, is what caused this thread to be more than four
posts long.
steve
--
Cliff Wells
I somehow missed the slander. Perhaps there are language/cultural
problems showing themselves, but all I've seen in this thread are people
trying to help you and you getting bent out of shape about it. Saying
that you stole something you didn't is _slander_. Suggesting that your
code might be improved isn't. It's called "constructive criticism", or
"help" for short.
You might have better luck in comp.lang.lisp.
Chad Netzer
> What I do see is a presumptuous attitude from some of the reponders;
> maybe not condescending, but definitely presumptuous.
>
> > You asked a question, and you got answers.
>
> He got unwanted answers to a question he didn't ask.
And as was pointed out, this is solely because we wanted to understand
his motivations for writing the code itself, and wanted a better
example of what he was trying to accomplish. That happens ALL the
time on this group, and is an indication of people taking the time to
try to be helpful.
In fact, whenever I see a class method posted, without ANY further
context to the class itself, I get very suspicious (from long
experience). How do I know what is going on in the class, or that the
poster even understands the distinction between methods and functions?
I found Afanasiy's responses to be the presumptuous ones, like he is
*entitled* to a helpful response to a poorly posed question? Should
the answer have been a simple and curt "no", without any further
inquiry? I'll bet that wouldn't have garnered an "okay, thank you"
response.
--
Bay Area Python Interest Group - http://www.baypiggies.net/
Chad Netzer
cne...@mail.arc.nasa.gov
Cliff Wells
I had a difficult time telling and I've never made a mistake.
Carl Banks
> Carl Banks wrote:
>> If I asked a question about how to get rid of self, and was told that
>> self is necessary because code without self makes a poor
>> implementation, I would say the same thing, because it's a damn petty
>> excuse to refuse to answer the question. That's not why Python uses
>> self, and it's flatly wrong.
>
> That's not what happened, IMO. He asked two questions, one implicit
> and one explicit. The implicit one was "my code is ugly because of
> all the self. references, [what can I do to improve it?]" The explicit
> one was a refinement of the original question, being "does Python
> have a 'with self do' construct, which some other language use to
> solve similar problems?"
>
> Here's Afanasiy' OP so you don't need to find it.
> ] I've written this method for a text formatting class...
> ] But it's ugly as sin. With all those self's I consider
> ] it much less readable than it could be...
> ]
> ] A few languages provide syntax sugar for dealing with
> ] this by allowing you to localize the class scope.
> ]
> ] Does Python? eg. `with self do:`
>
> First paragraph is the problem he's trying to solve. That's
> the one he wants really wants answered.
Well, I'm accusing responders of being presumptuous, and you've just
demonstrated it. <shrug> What made you so sure that's what he really
wanted answered? I'm surprised you would say this after he made it
clear he wasn't interested in anyone helping him rewrite his classes.
It's clear now you made the wrong assumption.
Personally, I don't think the assumption was warranted, even before he
made it clear that it wasn't what he was asking. I see the first
paragraph as background information, not a question to be answered.
For the record, I was (and am) playing devil's advocate--trying to put
the other side into perspective. He certainly hasn't displayed the
best tact, and I'm sure that has gone a long way into bringing out the
worst in the responders.
[snip]
>> And when he said, "My design is perfect," he was being sarcastic, and
>> was mocking Andrew Dalke's attitude.
>
> Th OP said my attitude was brusque, or some such. I've been reviewing
> my post and I still don't see that. Yes, I said his implementation
> (not his design) was poor. It is. Five other people agreed with me.
> Was it wrong to point that out? It wasn't like I said it sucks or
> other harshly disparaging terms. It's poor code, and any code review
> would point it out. Not only that, I suggested how to improve it.
Rereading it, I don't think you were brusque at all. He definitely
overreacted. However, he was definitely being sarcastic when he said
his design was perfect; not trying to say he was a better coder (which
was the point I was trying to make).
> Since you agree with him (he having stopped responding to this thread),
> perhaps you can clarify. Was it that I wouldn't give him the rope to
> hang himself by posting the exec trick? His clarification was "object
> members in scope?" and the exec trick does just that. However, it will
> only do what he expects for in-place modifications of mutable objects,
> since it doesn't put locals back into module scope.
>
> Or should I have explained all that too?
Well, I would have responded differently than you. You said, "You
don't need it," which was a little rude. He probably was asking for
it, but it was still a little rude.
If I had felt like you did, I would have said something like, "There
is a way. I highly recommend you not use it; many Pythonistas
consider it bad style, it makes code harder to understand, and it has
some hidden dangers on top of that. But if you insist, I'll tell
you."
And if he had insisted, I would have told him, with a "use at your own
risk" disclaimer.
Sometimes it's best to just let them learn the hard way.
Of course, what I really would have done is not answered it at all. I
just don't think it's nice to give someone alternate answers without
being prepared to answer (or help answer) the actual question.
>> What I do see is a presumptuous attitude from some of the reponders;
>> maybe not condescending, but definitely presumptuous.
>
> Presumptuous? Because I made assumptions about his level of
> Python knowledge based on the code he presented?
No, because you made an assumption about what he wanted answered.
(Bennetts did that more brazenly than you, though.)
[snip]
>> Whenever I want to offer alternatives, I'll usually answer the
>> original question, if I know the answer, and then offer alternatives.
>
> Hmm. And here I thought I did. 1) rewrite the code, 2) put 'self.'
> in the paste buffer. I should also have offered 3) use local variables
> instead of instance variables, but Simon Wittber already did that.
Look, I'm sorry, but I don't see it. His original question was
explicit and specific, even if was a tad more wordy than it had to be.
He asked whether Python had syntax sugar for self; nothing more. I
don't think it was warranted to assume he was asking anything other
than that.
You did not answer the question he asked. (Ok, technically you did:
he asked, "Is there a way?" I hope you agree that it's not an invalid
assumption that he also wanted to know how to do it.)
> Yes, there was a solution I wasn't going to post, tough. I
> wasn't going to lie and say no when the solution wasn't a proper
> answer to the question. Nor did I want the obligation of explaining
> how it worked, how it could go wrong, and why it shouldn't be used.
>
> Perhaps I should stop posting then?
Might have been a good idea. It was a tough situation, I'll cut you
some slack, ok? I was more bothered by Andrew Bennetts' attitude
anyways.
--
CARL BANKS
Carl Banks
> Carl Banks <imb...@vt.edu> writes:
>
>> I hope everyone else realizes he (Afanasiy) was being ironic.
>
> I believe your irony detector is yielding false positives.
I believe your irony detector is broken.
He perceived (wrongly, it appears) an arrogant attitude from Dalke,
who was trying to point out problems with Afanasiy's code, and it's
very obvious his statement, "My code is perfect," was in mockery of
the attitude he perceived. It was not hubris.
As for whether programmers are metaphorical, I'll say only this:
abstract is not the same as figurative.
--
CARL BANKS
Erik Max Francis
> I believe your irony detector is yielding false positives.
Yeah, I'd have to agree. His subsequent response suggests that either
he's laying it on _really_ thick or he's not being deliberately ironic.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ The great floodgates of the wonder-world swung open.
\__/ Herman Melville
CatCam / http://www.catcam.com/
What do your pets do all day while you're at work? Find out.
Carl Banks
> You might have better luck in comp.lang.lisp.
Talk about "out of the frying pan and into the fire."
--
CARL BANKS
Carl Banks
> I think the suggestion that a new approach was needed was a stab to
> Afanasiy's vain picture of himself as master programmer, and that, not the
> responses to his question, is what caused this thread to be more than four
> posts long.
I agree Afanasiy brought out the worst in people.
--
CARL BANKS
Carl Banks
> On Thu, 2003-01-09 at 11:14, Carl Banks wrote:
>> Nick Vargish wrote:
>> > Afanasiy <abeli...@hotmail.com> writes:
>> >
>> >> You don't know what I am doing. My design is perfect.
>> >
>> > c.f. 'hubris'.
>>
>> I hope everyone else realizes he (Afanasiy) was being ironic. I
>> realize using sublte irony in a computer programming chat room is not
>> the smartest thing to do, as programmers tend not to be the most
>> metaphorical people in the world.
>
> I had a difficult time telling and I've never made a mistake.
:-)
--
CARL BANKS
andy
> In other words "DO NOT USE IN REAL CODE - I WILL NOT BE
> HELD RESPONSIBLE IF YOU DEPLOY WITH THIS. FOR NOVELTY
> USE ONLY."
Oooh.
>
> >>> class Foo:
>
> ... eggs = 1
> ... def doit(self):
> ... self.spam = 5
> ... self.tomato = 3
> ... for x in dir(self): exec "%s = self.%s" % (x,x)
> ... for k, v in locals().items():
> ... print k, "==", v
> ... print
> ... print "the calculation yields", tomato ** spam
> ...
Ahhh.
> >>> Foo().doit()
>
> doit == <bound method Foo.doit of <__main__.Foo instance at 0x815a284>>
> tomato == 3
> __module__ == __main__
> spam == 5
> x == tomato
> self == <__main__.Foo instance at 0x815a284>
> eggs == 1
> __doc__ == None
>
> the calculation yields 243
I can see why one shouldn't use this... kind of 'implementation' and 'version'
specific!
Maybe a candidate for the next PEP... not?
Anyway, I sort of like the explicit self reference - makes things clearer in
the long run.
-andyj
Andrew Dalke
> involves manipulating namespaces in an "interesting" way. Not the sort
> of thing to be encouraged. He knows that if he told you, you'd probably
> use it and then regret it later on when you realized its implications,
> or that using it would prevent you seeing a better solution.
I posted it elsewhere.
=====================
In other words "DO NOT USE IN REAL CODE - I WILL NOT BE
HELD RESPONSIBLE IF YOU DEPLOY WITH THIS. FOR NOVELTY
USE ONLY."
>>> class Foo:
.... eggs = 1
.... def doit(self):
.... self.spam = 5
.... self.tomato = 3
.... for x in dir(self): exec "%s = self.%s" % (x,x)
.... for k, v in locals().items():
.... print k, "==", v
.... print
.... print "the calculation yields", tomato ** spam
....
>>> Foo().doit()
doit == <bound method Foo.doit of <__main__.Foo instance at 0x815a284>>
tomato == 3
__module__ == __main__
spam == 5
x == tomato
self == <__main__.Foo instance at 0x815a284>
eggs == 1
__doc__ == None
the calculation yields 243
>>>
===============================
Andrew
Cliff Wells
> I posted it elsewhere.
Yes, yes. I posted most of these comments between 7 and 8 this morning
(that'd be almost 12 hours ago), but they didn't come through until just
now. Didn't you see me whining earlier?
--
Cliff Wells <cliffor...@attbi.com>
Geoff Gerrietts
>
> In other words "DO NOT USE IN REAL CODE - I WILL NOT BE
> HELD RESPONSIBLE IF YOU DEPLOY WITH THIS. FOR NOVELTY
> USE ONLY."
Another disclaimer we might like to add is "does not work under
pythons earlier than 2.2", since it doesn't. dir(self) won't return
attributes on the class or base classes prior to 2.2.
--
Geoff Gerrietts "I don't think it's immoral to want to
<geoff at gerrietts net> make money." -- Guido van Rossum
Bengt Richter
>Nick Vargish wrote:
>> Carl Banks <imb...@vt.edu> writes:
>>
>>> I hope everyone else realizes he (Afanasiy) was being ironic.
>>
>> I believe your irony detector is yielding false positives.
>
>I believe your irony detector is broken.
>
>He perceived (wrongly, it appears) an arrogant attitude from Dalke,
>who was trying to point out problems with Afanasiy's code, and it's
>very obvious his statement, "My code is perfect," was in mockery of
>the attitude he perceived. It was not hubris.
>
OTOH, it might have been neither. It could have been short for,
[Please assume for the sake of argument that] my code is perfect [ because
whatever flaws it may have are irrelevant to the question I'm trying to pose].
I don't know where the OP is from, but it could be that there, making a blunt
statement as if of fact merely proposes that it be taken as a given without
further encumbering the discussion about it. If people take the signal that
way, it can work in English too. The thing is, depending on locale-sensitive
conventions of dialog is risky on the internet, so smileys and <meta signals>
can help avoid misinterpretations. And explicit is less likely to be misunderstood.
>As for whether programmers are metaphorical, I'll say only this:
>abstract is not the same as figurative.
IME programmers are varied ;-)
Regards,
Bengt Richter
Andrew Dalke
> Another disclaimer we might like to add is "does not work under
> pythons earlier than 2.2", since it doesn't. dir(self) won't return
> attributes on the class or base classes prior to 2.2.
True. I was thinking about that later, since the spec (as I
recall) says the behaviour of dir() is undefined. I should
have used self.__dict__.keys().
However, my actual code would have worked since I was only
referencing instance variables.
Andrew
da...@dalkescientific.com
Nick Vargish
> Yeah, I'd have to agree. His subsequent response suggests that either
> he's laying it on _really_ thick or he's not being deliberately ironic.
I actually read ahead a few posts to see some of his responses to
other people who made suggestions before posting my "hubris"
comment. I feel it was justified, but don't care to argue it with
people who want to defend him.
Ah well, I probably should have known better and just stayed
out. Maybe I never _will_ learn...
Tim Cargile
So ... the big question to me is when are Dalke and Afanasiy
going to get hitched. It would be a 'selfless' relationship,
I'm sure.
Max M
> Look, I'm sorry, but I don't see it. His original question was
> explicit and specific, even if was a tad more wordy than it had to be.
> He asked whether Python had syntax sugar for self; nothing more. I
> don't think it was warranted to assume he was asking anything other
> than that.
But sometimes you have to answer something else to give a meaningfull reply.
I the example certianly belive it to be relevant to show that you can
use pythons dynamic features, and rename a local member to get the same
effect::
aList = self.aList
Which basically solves the problem he was having. Though not in the way
he asked for. There are many examples of this in Python, when people
with different backgrounds gives it a try.
So second guessing is nessecary.
regards Max M
--
hilsen/regards Max M
http://www.futureport.dk/
Fremtiden, videnskab, skeptiscisme og transhumanisme
Travis Beaty
previous 12 hours I've gotten a half done responses *before* the
original post. Maybe one of the servers have some new quantum chips or
something. Makes for an interesting sequencial read, since everything
more mixed up than a fart in a whirlwind.
I'll check for a response to this particular post before I send it.
Just to be efficient.
Travis Beaty
Mason City, Iowa.
COMP.LANG.PYTHON. We're so efficent, we deliver the answer before you
can ask the question.
Travis Beaty
> I'd have to agree where these recent posts are concerned. During the
That should have read half dozen. I'm just half awake.
Steve Holden
news:odoT9.36428$xb....@nwrddc02.gnilink.net...
> Cliff Wells wrote:
> > You might have better luck in comp.lang.lisp.
>
> Talk about "out of the frying pan and into the fire."
>
Actually I'd say that would be more like "out of the frying pan and into the
heart of a 10-kiloton nuclear explosion", but then I'm (mostly)
rudeness-averse.
which-is-one-reason-why-i-like-c.l.py-ly y'rs - steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/
Bring your musical instrument to PyCon! http://www.python.org/pycon/
Steve Holden
news:QKzT9.632582$WL3.196381@rwcrnsc54...
> Travis Beaty wrote:
> > I'd have to agree where these recent posts are concerned. During the
> > previous 12 hours I've gotten a half done ...
>
> That should have read half dozen. I'm just half awake.
>
A pity you didn't post that before your original - it would have made your
point nicely :-)
regards
Christopher A. Craig
> I found Afanasiy's responses to be the presumptuous ones, like he is
> *entitled* to a helpful response to a poorly posed question? Should
> the answer have been a simple and curt "no", without any further
> inquiry? I'll bet that wouldn't have garnered an "okay, thank you"
> response.
This is something I wondered about too. And if that were the answer,
is it really anyone's opinion that the newsgroup would be more
polite/helpful because of it?
I once had a friend who doesn't do much computational theory ask me "I
have this linked list that I have to search a lot, but it's real slow.
Is there any way to search a linked list faster?" I could have just
said no, but it seems to me to be more helpful to suggest that if he
is going to search a lot a hash table, avl tree, or even just a sorted
array, might be a much better data type.
--
Christopher A. Craig <list-...@ccraig.org>
It was never really an Internet company, AOL was based on the idea that
people needed to live in a halfway house while they became accustomed
to the Net. -- Salon Magazine
Martijn Faassen
> def format( self, width=80 ):
> self.lines = ['']
> i = 0
> for word in self.text.split():
> if self.textwidth(self.lines[i]) + self.textwidth(word) <= width:
> if self.textwidth(self.lines[i]) > 0:
> self.lines[i] += ' '
> self.lines[i] += word
> else:
> i += 1
> self.lines.append(word)
If I see too many 'self.' I rewrite method to something like:
def format(self, width=80):
lines = [''] # could write lines = self.lines = [''] instead
textwidth = self.textwidth
i = 0
for word in self.text.split():
if textwidth(lines[i]) + textwidth(word) <= width:
if textwidth(lines[i]) > 0:
lines[i] += ' '
lines[i] += word
else:
i += 1
lines.append(word)
self.lines = lines # could skip this if wrote lines = self.lines = ['']
This may actually be more efficient too, as there are less attribute
lookups. If a method is really needing to get a whole host of attributes
as local variables I'd doubt the method or class is well written; usually
you only have to pull in one or two.
Regards,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?
Martijn Faassen
> I already knew I could make aliases/references or 'macros' (as the
> documentation calls them) to members I wish to access more easily.
I'm curious. What documentation calls this 'macros'? Why are the people
who wrote that documentation still alive? They'd have been eaten by hoardes
of screaming lisp masses by now, right?
Anyway, what's wrong with this technique? I like it, and there's actually
a different in behavior (less attribute lookups) which is explicitly visible.
It should be clear enough by now that there's no pythonic way to do what
you're asking. :)