And thank you gentlemen for turning my somewhat banale question into a
worthwhile discussion. :-)
I shall not forget self ever again!
--
http://mail.python.org/mailman/listinfo/python-list
Edward Elliott wrote:
bruno at modulix wrote:
Edward Elliott wrote:
Ah, well then, there's no need for a full-blown parser. It should
suffice to recognize a class definition and modify the parameter list of
every def indented one level further than that.
won't do :
class
Ben Finney wrote:
Bruno Desthuilliers [EMAIL PROTECTED] writes:
Ben Finney a écrit :
So now you're proposing that this be a special case when a
function is declared by that particular syntax, and it should be
different to when a function is created outside the class
definition and added as a
Edward Elliott wrote:
Ben Finney wrote:
As I understand it, the point was not what the code does, but to give
a sample input (a Python program) for the simple text processor you
described to wade through.
Ah, well then, there's no need for a full-blown parser. It should suffice
to
bruno at modulix wrote:
Edward Elliott wrote:
Ah, well then, there's no need for a full-blown parser. It should
suffice to recognize a class definition and modify the parameter list of
every def indented one level further than that.
won't do :
class CounterExample(object):
if
Bruno Desthuilliers wrote:
(snip)
Since Python 3K is supposed to be the 'clean the warts and don't bother
breaking compat' rewrite of Python, you may as well propose a PEP on
this. You'll have to really prove it doesn't break anything else in the
object model, have strong and articulate
Bruno Desthuilliers wrote:
IOW, let's give Edward some time to come up with enough rope so we can
hang him to the nearest (AS) Tree !-)
That's all I ask. ;)
--
http://mail.python.org/mailman/listinfo/python-list
Bruno Desthuilliers wrote:
But then, constructs like:
class Obj(object):
def method(...): ...
method = staticmethod(method)
or it's newer syntactic-sugar-version would become somewhat more
difficult to parse properly - but I admit that this is beyond my
knowledge.
Hmm, that'll
bruno at modulix wrote:
And of course propose an implementation - perhaps the compiler.ast could
be useful ?
Ugh. Just when I thought I'd seen my last abstract syntax tree, one rears
its ugly head.
--
http://mail.python.org/mailman/listinfo/python-list
Edward Elliott wrote:
Bruno Desthuilliers wrote:
But then, constructs like:
class Obj(object):
def method(...): ...
method = staticmethod(method)
or it's newer syntactic-sugar-version would become somewhat more
difficult to parse properly - but I admit that this is beyond my
knowledge.
bruno at modulix wrote:
Technically, they are still function objects. They are later wrapped
into method descriptor objects (at lookup time IIRC, but ask a guru or
read the doc to know for sure). And don't forget the case of nested
functions...
I don't see how nested functions change
Edward Elliott a écrit :
bruno at modulix wrote:
Technically, they are still function objects. They are later wrapped
into method descriptor objects (at lookup time IIRC, but ask a guru or
read the doc to know for sure). And don't forget the case of nested
functions...
I don't see how
In [EMAIL PROTECTED], Edward Elliott
wrote:
I can prove that assertion too: make a simple text processor that reads
Python source code and outputs the same source code with only one change:
insert the string 'self as the first parameter of every def somemethod.
Next run the output source
Marc 'BlackJack' Rintsch a écrit :
(snip)
Okay, let's start with writing a simple text processor for this little
mess::
def b(c):
def d(r, *s, **t):
print '***'
c(r, *s, **t)
return d
What a nice, readable, highly pythonic code...
Edward Elliott [EMAIL PROTECTED] writes:
As long as we're trotting out aphorisms
The ones I quoted were from Python.
import this
how about DRY: Don't Repeat Yourself. The rule couldn't be clearer:
don't repeat your SELF. ;) Yet that's exactly what explicitly
declaring self does,
Bruno Desthuilliers [EMAIL PROTECTED] writes:
Ben Finney a écrit :
So now you're proposing that this be a special case when a
function is declared by that particular syntax, and it should be
different to when a function is created outside the class
definition and added as a method to the
Ben Finney wrote:
Edward Elliott [EMAIL PROTECTED] writes:
As long as we're trotting out aphorisms
The ones I quoted were from Python.
import this
Yes I know where it's from.
You've misunderstood don't repeat yourself. It advocates *one*
definition of any given thing in the code.
Ben Finney wrote:
My basis for rejecting the proposal is that it claims to offer net
simplicity, yet it breaks at least two of the admonishments that
simplify Python.
As do other features of Python. Or did you forget the follow-up to the
special cases rule?
Special cases aren't special
Marc 'BlackJack' Rintsch wrote:
Edward Elliott wrote:
I can prove that assertion too: make a simple text processor that reads
Python source code and outputs the same source code with only one change:
insert the string 'self as the first parameter of every def
somemethod. Next run the output
Edward Elliott [EMAIL PROTECTED] writes:
Marc 'BlackJack' Rintsch wrote:
Edward Elliott wrote:
I can prove that assertion too: make a simple text processor that
reads Python source code and outputs the same source code with
only one change: insert the string 'self as the first parameter
Ben Finney wrote:
As I understand it, the point was not what the code does, but to give
a sample input (a Python program) for the simple text processor you
described to wade through.
Ah, well then, there's no need for a full-blown parser. It should suffice
to recognize a class definition and
Just my opinion, but I think the Guido tutorial on Classes is
unintelligible unless you're coming from another OO language.
But I found something else that looks promising that you may want to
peek at:
http://pytut.infogami.com/node11-baseline.html
rd
--
No way. You didn't deserve it. Unless you came from another OO
language, the Guido tutorial on Classes is unintelligible. It assumes
way too much knowledge.
But I found something else that looks promising that you may want to
peek at:
http://pytut.infogami.com/node11-baseline.html
rd
Reply
--
Steve Holden wrote:
Objects don't actually pass references to themselves. The interpreter
adds the bound instance as the first argument to a call on a bound method.
Sure, if you want to get technical For that matter, objects don't actually
call their methods either -- the interpreter looks up
Edward Elliott wrote:
Holger wrote:
oops, that was kinda embarrassing.
It's really not. You got a completely unhelpful error message saying you
passed 2 args when you only passed one explicitly. The fact the b is also
an argument to b.addfile(f) is totally nonobvious until you know
Edward Elliott a écrit :
bruno at modulix wrote:
(snip)
You skipped the interesting part, so I repost it and ask again: how
could the following code work without the instance being an explicit
parameter of the function to be used as a method ?
def someFunc(obj):
try:
print obj.name
Bruno Desthuilliers wrote:
Edward, I know I told you so at least three times, but really,
seriously, do *yourself* a favor : take time to read about descriptors
and metaclasses - and if possible to experiment a bit - so you can get a
better understanding of Python's object model. Then I'll be
Edward Elliott [EMAIL PROTECTED] writes:
bruno at modulix wrote:
class MyObj(object):
def __init__(self, name):
self.name = name
class MyObj(object):
def __init__(name):
self.name = name
So the tradeoff you propose is:
- Honour explicit is better than implicit, but
Edward Elliott [EMAIL PROTECTED] writes:
Compiler, interpreter, magic-codey-runny-thingy, whatever, at some point
something has to translate this source code
def method (self, a, b): something
into a function object (or whatever you're calling the runnable code this
week). Call this
Edward Elliott a écrit :
Bruno Desthuilliers wrote:
Edward, I know I told you so at least three times, but really,
seriously, do *yourself* a favor : take time to read about descriptors
and metaclasses - and if possible to experiment a bit - so you can get a
better understanding of Python's
Ben Finney wrote:
So now you're proposing that this be a special case when a function is
declared by that particular syntax, and it should be different to when
a function is created outside the class definition and added as a
method to the object at run-time.
Thus breaking not only explicit
Ben Finney wrote:
So the tradeoff you propose is:
- Honour explicit is better than implicit, but users are confused
over why do I need to declare the instance in the method
signature?
against
- Break explicit is better than implicit, take away some of the
flexibility
Hi guys
Tried searching for a solution to this, but the error message is so
generic, that I could not get any meaningfull results.
Anyways - errormessage:
TypeError: addFile() takes exactly 1 argument (2 given)
Holger wrote:
Tried searching for a solution to this, but the error message is so
generic, that I could not get any meaningfull results.
Anyways - errormessage:
TypeError: addFile() takes exactly 1 argument (2 given)
oops, that was kinda embarrassing.
But thx anyway :-)
--
http://mail.python.org/mailman/listinfo/python-list
Holger [EMAIL PROTECTED] writes:
TypeError: addFile() takes exactly 1 argument (2 given)
import sys
class KeyBase:
def
Holger wrote:
oops, that was kinda embarrassing.
It's really not. You got a completely unhelpful error message saying you
passed 2 args when you only passed one explicitly. The fact the b is also
an argument to b.addfile(f) is totally nonobvious until you know that 1) b
is an object not a
Edward Elliott wrote:
Holger wrote:
oops, that was kinda embarrassing.
It's really not. You got a completely unhelpful error message saying you
passed 2 args when you only passed one explicitly. The fact the b is also
an argument to b.addfile(f) is totally nonobvious until you know
38 matches
Mail list logo
