Re: should self be changed?
On Wednesday 03 June 2015 03:19, Marko Rauhamaa wrote: Steven D'Aprano st...@pearwood.info: On Fri, 29 May 2015 12:00 pm, Steven D'Aprano wrote: [...] in a language where classes are themselves values, there is no reason why a class must be instantiated, particularly if you're only using a single instance of the class. Anyone ever come across a named design pattern that involves using classes directly without instantiating them? I'm basically looking for a less inelegant term for instanceless class -- not so much a singleton as a zeroton. C# has these, and calls them static classes. I guess Python has them, too, and calls them modules. Modules play a similar role -- after all, modules and classes are both namespaces. But: - you can't (easily) use inheritance on a module to make a new module, but you can use inheritance on a class; although I think C# prohibits that. - you can't (easily) include more than one module in a single file. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Tue, Jun 2, 2015 at 11:19 AM, Marko Rauhamaa ma...@pacujo.net wrote: Steven D'Aprano st...@pearwood.info: On Fri, 29 May 2015 12:00 pm, Steven D'Aprano wrote: [...] in a language where classes are themselves values, there is no reason why a class must be instantiated, particularly if you're only using a single instance of the class. Anyone ever come across a named design pattern that involves using classes directly without instantiating them? I'm basically looking for a less inelegant term for instanceless class -- not so much a singleton as a zeroton. C# has these, and calls them static classes. I guess Python has them, too, and calls them modules. Indeed. I find it amusing that C# has special syntax to work around what is ostensibly a design feature -- that all code must be contained in a class (or struct). But then, the same practice also exists in Java, where there is no specific syntax for it. -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Fri, 29 May 2015 12:00 pm, Steven D'Aprano wrote: [...] in a language where classes are themselves values, there is no reason why a class must be instantiated, particularly if you're only using a single instance of the class. Anyone ever come across a named design pattern that involves using classes directly without instantiating them? I'm basically looking for a less inelegant term for instanceless class -- not so much a singleton as a zeroton. C# has these, and calls them static classes. https://msdn.microsoft.com/en-us/library/79b3xss3%28v=vs.100%29.aspx -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
Steven D'Aprano st...@pearwood.info: On Fri, 29 May 2015 12:00 pm, Steven D'Aprano wrote: [...] in a language where classes are themselves values, there is no reason why a class must be instantiated, particularly if you're only using a single instance of the class. Anyone ever come across a named design pattern that involves using classes directly without instantiating them? I'm basically looking for a less inelegant term for instanceless class -- not so much a singleton as a zeroton. C# has these, and calls them static classes. I guess Python has them, too, and calls them modules. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Wednesday, May 27, 2015 at 8:00:49 AM UTC-5, Todd wrote: On Wed, May 27, 2015 at 2:40 PM, zipher dreamin...@gmail.com wrote: On Wednesday, May 27, 2015 at 6:30:16 AM UTC-5, Ben Finney wrote: Steven D'Aprano steve+comp@pearwood.info writes: On Wednesday 27 May 2015 14:39, Ben Finney wrote: That kind of homophobic slur is inappropriate from anyone in this community. Kindly cut it out altogether. I look forward to the day when people would read the earlier insult and be perplexed as to why it is a slur at all. In the same way as your mother wears army boots has become a joke slur, not taken seriously. Yes, let's all work toward an end to the use of gender, sexuality, ethnicity, and other inborn traits as the punchline of insults or jokes. Oh God, you people are being idiots. It's poop. And shall we all so look forward to the day, when people who eat poop are also welcome into the circle of humanity? If your goal is to get people to stop calling you a troll, you are going about it the wrong way. If it isn't, why are you even here? Please remember the first rule of holes: if you find yourself in a hole, stop digging. Dude, I stopped digging into holes a long time ago, but then that was the issue wasn't it? And since my goal isn't that, let's go back to discussing the ins and outs (ahem) of creating a more complete lexical specification of the language, which would provide many other worthy side benefits, besides saving on typing characters. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Wednesday, May 27, 2015 at 2:39:21 AM UTC-5, Marko Rauhamaa wrote: Chris Angelico ros...@gmail.com: Using some other name in place of self should definitely remain *possible*, but not commonly done. You are effectively making the argument that Python has made a mistake by not giving self a special, language-level status. I'm making that claim. Guido's arguments are based on a simple lexical definition of the language. If the lexical definition were sophisticated enough to feed into GCC as a front-end, for example, then it wouldn't have to be so abnormal. It's a short-cut for a less mature language. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Wednesday, May 27, 2015 at 12:48:02 AM UTC-5, Steven D'Aprano wrote: On Wednesday 27 May 2015 14:39, Ben Finney wrote: zipher dreamingforw...@gmail.com writes: Arrgh. Sorry, that was meant privately... I'm glad we saw it publicly, so that we get more of an idea how you treat people. That kind of homophobic slur is inappropriate from anyone in this community. Kindly cut it out altogether. I look forward to the day when people would read the earlier insult and be perplexed as to why it is a slur at all. In the same way as your mother wears army boots has become a joke slur, not taken seriously. Yes, and I look forward to the day when you *bend over* freely to take it all in without complaint. When such offerings are natural and aren't seen as an insult at all. You first. Mark So long as it does nobody any harm, and all participants have consented, what one adult chooses to take into their mouth is nobody else's business and certainly no reason to look down on them. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Tuesday, May 26, 2015 at 11:40:20 PM UTC-5, Ben Finney wrote: zipher dreamingforw...@gmail.com writes: Arrgh. Sorry, that was meant privately... I'm glad we saw it publicly, so that we get more of an idea how you treat people. Ben, he asked for it. Stop assuming. That kind of homophobic slur is inappropriate from anyone in this community. Kindly cut it out altogether. Ben that is so presumtuous of you! He and my acts were completely homo positive. I assure you. Perhaps you are hiding something? Mark P.S. You can respond privately. -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Thursday, May 28, 2015 at 11:59:36 AM UTC-5, Marko Rauhamaa wrote: Ian Kelly ian.g.ke...@gmail.com: I think I would be more inclined to use enums. This has the advantages of not creating a new set of state classes for every connection instance and that each state is a singleton instance, allowing things like if self.state is SMTPConnectionState.IDLE. It could look something like this: class SMTPConnectionState(Enum): class IDLE: @classmethod def handle_command(cls, conn, cmd): # ... class SPF_HELO: @classmethod def terminate(cls, conn): # ... Really, the main expressive choice is whether you use an inner class (and get the advantages of a closure) or an outer class (and get potential performance advantages). Can you tell me: What is the advantage of a closure here? Also: why wouldn't you simply put your state classes at the outer scope (i.e. module-level) of your module so that they are clear to anyone else who want to use the module? Presumably these classes are for making your SMTPServerConnection object more useable, not to hide these state-classes from the users. MarkJ -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Fri, May 29, 2015 at 2:59 AM, Marko Rauhamaa ma...@pacujo.net wrote: When I have coded state machines for C or Java, I have noticed that nothing beats enums and switch statements performance-wise, and expressively, they're not that bad, either. Python doesn't have a switch statement, so the natural thing is to ride on method dispatching (whether via inner or outer classes). However, I must say the exception idiom someone mentioned on this forum way back has its lure: try: raise self.state except IDLE: #... except SPF_HELO: #... I take exception to that idiom. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Fri, 29 May 2015 01:01 am, Marko Rauhamaa wrote:
Anssi Saari a...@sci.fi:
Do you have an example of state pattern using nested classes and
python? With a quick look I didn't happen to find one in any language.
Here's an sampling from my mail server:
I haven't studied this in close detail, but first impressions is that this
is not well-written Python code. The obvious problems that come to mind:
class SMTPServerConnection(ServerConnection):
#: : :
#: : :
def __init__(self, server, sock, domain, peer):
super().__init__(server, sock)
conn = self
client_ip = peer[0]
class STATE:
def __str__(self):
return self.__class__.__name__
A minor criticism: each time you instantiate a new SMTP server connection,
it creates new STATE, IDLE etc. classes. That's wasteful and inefficient
unless you have a good reason for it, although you may not care if you only
have a single connection at a time.
More serious problem: by nesting the state classes, it is much harder to
test the state classes in isolation from a connection.
def handle_command(self, cmd):
conn.log(handle_command (unexpected): {}.format(cmd))
assert False
At first glance, this appears to be an abuse of `assert` and risks breaking
your code when running under -O which turns debugging (and hence asserts)
off. Since the intent is to make these abstract methods which must be
overridden, I'd prefer to define an AbstractMethodError, then:
raise AbstractMethodError(unexpected %s % cmd)
then do the logging elsewhere.
This has the advantage(?) of eliminating the need to refer to conn, which
means that the methods are no longer closures and the entire inner class
can be moved out of the SMTPServerConnection body.
[...]
class IDLE(STATE):
def handle_command(self, cmd):
conn.log(handle_command: {}.format(cmd))
Using a closure for information hiding is a solid functional equivalent to
using private fields in an OOP context. However, private should be
considered an anti-testing idiom. I would seriously consider this entire
design to be an anti-pattern, and would prefer to one of two alternate
designs:
(1) Pull the state classes out of the SMTPServerConnection class. On
initialisation, each state takes a conn argument. All references to conn
are replaced by self.conn. That's basically the conventional OOP
approach.
(2) Again, pull the state classes out of the SMTPServerConnection class,
except this time there is no need to instantiate the state classes at all!
Decorate all the methods with @classmethod, and have them take the
connection as an explicit argument. The caller (namely the
SMTPServerConnection instance) provides itself as argument to the state
methods, like so:
self.state = IDLE # No need to instantiate.
self.state.process_ehlo_or_helo(self, other, args, go, here)
This reduces implicit coupling, makes it explicit that the state methods
depend on the connection, avoids reference loops, and enables easy mocking
for testing.
The only downsides are that people coming from a conventional (e.g. Java)
OOP background will freak at seeing you using a class as a first class
value (pun intended), and it will be ever-so-slightly tiresome to have to
decorate each and every method with classmethod.
(Perhaps a class decorator is the solution to that second issue?)
The design pattern community is dominated by Java, where classes are not
values, so this idiom is impossible in Java and unlikely to have a DP name.
But it really should have one -- in a language where classes are themselves
values, there is no reason why a class *must* be instantiated, particularly
if you're only using a single instance of the class. Anyone ever come
across a named design pattern that involves using classes directly without
instantiating them?
I'm basically looking for a less inelegant term for instanceless class --
not so much a singleton as a zeroton.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Fri, 29 May 2015 12:00 pm, Steven D'Aprano wrote: I haven't studied this in close detail, but first impressions is that this is not well-written Python code. The obvious problems that come to mind: Well, first impressions can be misleading... I wrote the above, thinking that there were more problems with the code than there actually are. (Specifically, I didn't notice that the inner classes used closures for their methods, then forgot to go back and revise that sentence.) So the code actually was not as bad as I first thought, not withstanding the issues that I described in my previous post. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
Marko Rauhamaa ma...@pacujo.net writes: Ned Batchelder n...@nedbatchelder.com: I would find it much clearer to not use a nested class at all, and instead to pass the object into the constructor: Nested classes are excellent and expressing the state pattern URL: http://en.wikipedia.org/wiki/State_pattern. Do you have an example of state pattern using nested classes and python? With a quick look I didn't happen to find one in any language. -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
Anssi Saari a...@sci.fi:
Do you have an example of state pattern using nested classes and
python? With a quick look I didn't happen to find one in any language.
Here's an sampling from my mail server:
class SMTPServerConnection(ServerConnection):
#: : :
#: : :
def __init__(self, server, sock, domain, peer):
super().__init__(server, sock)
conn = self
client_ip = peer[0]
class STATE:
def __str__(self):
return self.__class__.__name__
def handle_command(self, cmd):
conn.log(handle_command (unexpected): {}.format(cmd))
assert False
def handle_bad_command(self, reason):
conn.log(handle_bad_command (unexpected): {}.format(reason))
assert False
def handle_eof(self):
conn.log(eof (unexpected))
assert False
def terminate(self):
assert False
class IDLE(STATE):
def handle_command(self, cmd):
conn.log(handle_command: {}.format(cmd))
verb, args = conn.split_cmd(cmd)
if verb == b'EHLO':
self.process_ehlo_or_helo(
args,
PIPELINING,
SIZE {:d}.format(conn.MAX_MSG_SIZE),
VRFY,
EXPN,
8BITMIME)
elif verb == b'HELO':
self.process_ehlo_or_helo(args)
elif verb in [ b'NOOP', b'RSET' ]:
conn.respond(250, OK)
elif verb == b'HELP':
conn.respond(214, No help available)
elif verb in [ b'VRFY', b'EXPN' ]:
conn.respond(550, Access denied to you)
elif verb == b'QUIT':
conn.respond(221, {} Closing channel.format(
server.domain))
conn.shut_down()
conn.set_state(QUITTING)
elif verb == b'MAIL':
self.handle_mail(args)
elif verb in [ b'RCPT', b'DATA' ]:
conn.respond(503, Bad sequence of commands)
else:
conn.respond(500, Command unrecognized)
def process_ehlo_or_helo(self, args, *capabilities):
if not args:
conn.respond(501, Missing parameter)
return
try:
# may be an IP address
conn.helo_domain_name = args[0].decode()
except UnicodeError:
conn.respond(501, Bad encoding in parameter)
return
if conn.local_client:
conn.respond(250, server.domain, *capabilities)
conn.set_state(IDLE)
return
## todo: remove the suspend concept from mux
conn.suspend()
conn.log(authorize helo {} from {}.format(
conn.helo_domain_name, client_ip))
conn.set_state(SPF_HELO)
def callback(verdict, reason):
conn.state.handle_spf_verdict(
verdict, reason, *capabilities)
conn.spf_query = server.spf_client.authorize_helo(
server.host, conn.helo_domain_name, server.family,
client_ip, callback, xid = id(conn))
#: : :
#: : :
class SPF_HELO(STATE):
def terminate(self):
conn.resume()
conn.spf_query.cancel()
conn.close()
if conn.timer is not None:
conn.timer.cancel()
conn.timer = None
conn.set_state(ZOMBIE)
def handle_spf_verdict(self, verdict, reason, *capabilities):
conn.resume()
conn.log(verdict {} reason {}.format(verdict, reason))
# RFC 4408 §2.5.5 calls for leniency for SoftFail
#if verdict in [ SPFClient.FAIL, SPFClient.SOFT_FAIL ]:
if verdict in [ SPFClient.FAIL ]:
conn.respond(550, SPF check failed: {}.format(reason))
conn.set_state(IDLE)
return
conn.respond(250, server.domain, *capabilities)
conn.set_state(IDLE)
class SPF_SENDER(STATE):
def terminate(self):
conn.resume()
conn.spf_query.cancel()
conn.close()
if conn.timer is not None:
conn.timer.cancel()
conn.timer = None
conn.set_state(ZOMBIE)
def
Re: should self be changed?
On Thu, May 28, 2015 at 9:01 AM, Marko Rauhamaa ma...@pacujo.net wrote: Anssi Saari a...@sci.fi: Do you have an example of state pattern using nested classes and python? With a quick look I didn't happen to find one in any language. Here's an sampling from my mail server: I think I would be more inclined to use enums. This has the advantages of not creating a new set of state classes for every connection instance and that each state is a singleton instance, allowing things like if self.state is SMTPConnectionState.IDLE. It could look something like this: class SMTPConnectionState(Enum): class IDLE: @classmethod def handle_command(cls, conn, cmd): # ... class SPF_HELO: @classmethod def terminate(cls, conn): # ... -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
Ian Kelly ian.g.ke...@gmail.com: On Thu, May 28, 2015 at 9:01 AM, Marko Rauhamaa ma...@pacujo.net wrote: Anssi Saari a...@sci.fi: Do you have an example of state pattern using nested classes and python? With a quick look I didn't happen to find one in any language. Here's an sampling from my mail server: I think I would be more inclined to use enums. This has the advantages of not creating a new set of state classes for every connection instance and that each state is a singleton instance, allowing things like if self.state is SMTPConnectionState.IDLE. It could look something like this: class SMTPConnectionState(Enum): class IDLE: @classmethod def handle_command(cls, conn, cmd): # ... class SPF_HELO: @classmethod def terminate(cls, conn): # ... Really, the main expressive choice is whether you use an inner class (and get the advantages of a closure) or an outer class (and get potential performance advantages). When I have coded state machines for C or Java, I have noticed that nothing beats enums and switch statements performance-wise, and expressively, they're not that bad, either. Python doesn't have a switch statement, so the natural thing is to ride on method dispatching (whether via inner or outer classes). However, I must say the exception idiom someone mentioned on this forum way back has its lure: try: raise self.state except IDLE: #... except SPF_HELO: #... Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Wed, May 27, 2015 at 5:39 PM, Marko Rauhamaa ma...@pacujo.net wrote: Chris Angelico ros...@gmail.com: Using some other name in place of self should definitely remain *possible*, but not commonly done. You are effectively making the argument that Python has made a mistake by not giving self a special, language-level status. Uhh... no I'm not. I'm saying it should be possible to use some other name instead of self, which means that Python got it right by not making it special. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: On Wednesday 27 May 2015 14:39, Ben Finney wrote: That kind of homophobic slur is inappropriate from anyone in this community. Kindly cut it out altogether. I look forward to the day when people would read the earlier insult and be perplexed as to why it is a slur at all. In the same way as your mother wears army boots has become a joke slur, not taken seriously. Yes, let's all work toward an end to the use of gender, sexuality, ethnicity, and other inborn traits as the punchline of insults or jokes. Until that happy day, let's work to improve the lot of those who are made the butt of such slurs. Part of that work must be to call foul when someone invokes an entire class of people as an insult. -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\Brain, but why would anyone want to see Snow White and the | _o__) Seven Samurai?” —_Pinky and The Brain_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Wed, May 27, 2015 at 2:40 PM, zipher dreamingforw...@gmail.com wrote: On Wednesday, May 27, 2015 at 6:30:16 AM UTC-5, Ben Finney wrote: Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: On Wednesday 27 May 2015 14:39, Ben Finney wrote: That kind of homophobic slur is inappropriate from anyone in this community. Kindly cut it out altogether. I look forward to the day when people would read the earlier insult and be perplexed as to why it is a slur at all. In the same way as your mother wears army boots has become a joke slur, not taken seriously. Yes, let's all work toward an end to the use of gender, sexuality, ethnicity, and other inborn traits as the punchline of insults or jokes. Oh God, you people are being idiots. It's poop. And shall we all so look forward to the day, when people who eat poop are also welcome into the circle of humanity? Everyday, you let atrocity happen, and you're fighting for oppressed feltchers? If so, you dumbasses don't deserve much of a future. If your goal is to get people to stop calling you a troll, you are going about it the wrong way. If it isn't, why are you even here? Please remember the first rule of holes: if you find yourself in a hole, stop digging. -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Wednesday, May 27, 2015 at 6:30:16 AM UTC-5, Ben Finney wrote: Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: On Wednesday 27 May 2015 14:39, Ben Finney wrote: That kind of homophobic slur is inappropriate from anyone in this community. Kindly cut it out altogether. I look forward to the day when people would read the earlier insult and be perplexed as to why it is a slur at all. In the same way as your mother wears army boots has become a joke slur, not taken seriously. Yes, let's all work toward an end to the use of gender, sexuality, ethnicity, and other inborn traits as the punchline of insults or jokes. Oh God, you people are being idiots. It's poop. And shall we all so look forward to the day, when people who eat poop are also welcome into the circle of humanity? Everyday, you let atrocity happen, and you're fighting for oppressed feltchers? If so, you dumbasses don't deserve much of a future. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On 2015-05-27, Todd toddr...@gmail.com wrote: On Wed, May 27, 2015 at 2:40 PM, zipher dreamingforw...@gmail.com wrote: [some stupid crap] If your goal is to get people to stop calling you a troll, you are going about it the wrong way. If it isn't, why are you even here? Please remember the first rule of holes: if you find yourself in a hole, stop digging. And thanks to everybody who keeps replying to zipher's posts so that those of use who's newsreaders are configured to filter him out get to see them anyway. -- Grant Edwards grant.b.edwardsYow! I need to discuss at BUY-BACK PROVISIONS gmail.comwith at least six studio SLEAZEBALLS!! -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Wed, May 27, 2015 at 3:23 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Wednesday 27 May 2015 06:45, Mark Lawrence wrote: Apart from breaking all the tools that rely on self being spelt self this looks like an excellent idea. Tools which rely on self being spelled self are already broken. It's a convention, nothing more, and there are various good reasons for breaking the convention: - metaclasses - classmethods - custom descriptors - nested classes If it truly relies on it, yes. But if I see a function that has self as its first parameter, I'm going to read it as a (probable) method rather than a stand-alone function, and it wouldn't surprise me if introspection and/or source code parsing made the same assumption. It's as strong a convention as don't touch the ones that begin with an underscore, which is broken by the namedtuple due to namespacing requirements, but otherwise is fairly dependable (eg if tab completion skipped the underscore attributes, it'd be a bit less useful on namedtuples, but probably more practical overall). Using some other name in place of self should definitely remain *possible*, but not commonly done. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On 5/27/2015 2:32 AM, Chris Angelico wrote: On Wed, May 27, 2015 at 3:23 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Wednesday 27 May 2015 06:45, Mark Lawrence wrote: Apart from breaking all the tools that rely on self being spelt self this looks like an excellent idea. Tools which rely on self being spelled self are already broken. It's a convention, nothing more, and there are various good reasons for breaking the convention: - metaclasses - classmethods - custom descriptors - nested classes If it truly relies on it, yes. But if I see a function that has self as its first parameter, I'm going to read it as a (probable) method rather than a stand-alone function, and it wouldn't surprise me if introspection and/or source code parsing made the same assumption. The Idlelib calltips function does not look at names. It leaves the signature of functions as is and removes the first name, whatever it is, of bound methods, including bound class methods. See idlelib.CallTips.get_argspec for details. To make sure there is no name assumption, test_calltips.py tests that the first name, not 'self', is the name removed. One test method, Tc.t6, has function signature (no, self), which makes the bound method signature (self). -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
Chris Angelico ros...@gmail.com: Using some other name in place of self should definitely remain *possible*, but not commonly done. You are effectively making the argument that Python has made a mistake by not giving self a special, language-level status. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Tuesday, May 26, 2015 at 12:28:31 PM UTC-5, Mark Lawrence wrote: On 26/05/2015 17:37, zipher wrote: Would it be prudent to rid the long-standing argument (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name? Yes, how about you taking a permanent holiday rather than bother this list with more of your nonsense? Mark Lawrence Mr. Lawrence, could you calm down with your sadism on the list. Our session last time ended with a lot of semen on your floor instead of in your mouth. Your bosom buddy, Mark Janssen -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Tuesday, May 26, 2015 at 11:57:44 AM UTC-5, Laura Creighton wrote: In a message of Tue, 26 May 2015 09:37:29 -0700, zipher writes: Would it be prudent to rid the long-standing argument (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name? class MyClass(object): def __init__(@): @.dummy = None OR, even better, getting *rid of it* in the parameter list, so it stops confusing people about how many parameters a method needs, and transform it into a true *operator*. class MyClass(object): def __init__(): #takes no arguments! @.dummy = None #the @ invokes the class object's dictionary That would seem to be a nice solution to the problem, really. It doesn't become PERLish because you've made it into a genuine operator -- self was always a non-variable that looked like a variable and hence created an itch that couldn't be scratched. Guido did. :) http://neopythonic.blogspot.se/2008/10/why-explicit-self-has-to-stay.html Sweet link. I see now that my confusion surrounds the mistaken notion that Python is lexing python source into *abstract syntax trees* (wikipedia describes nicely), so that code inside a method knows what class it's in. But GvR hasn't defined his language to the extent where the notion of object even exists. He's only set aside a keyword called class. So of course he has to treat the method code, practically, like a [C] function. But that limits the language, not to define what an object is inside the lexical structure: object ::= class identifier ( inheritence_list ) : inheritence_list ::= [[et cetera]] If he did this, then code inside the class could already know what class they're in and all the objections in Laura's link would be moot. Mark J -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Wednesday 27 May 2015 05:46, Marko Rauhamaa wrote: Python's practice works. However, a small problem is presented by nested classes: class Connection: def __init__(self): class Idle: def signal_start(self): # how to refer to the outer self : : The best solution is not to use nested classes, but if you really must: class Connection: def __init__(self): class Idle: def signal_start(this): # this is the Idle instance; # self is the Connection instance -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Tuesday, May 26, 2015 at 11:57:44 AM UTC-5, Laura Creighton wrote: In a message of Tue, 26 May 2015 09:37:29 -0700, zipher writes: Would it be prudent to rid the long-standing argument (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name? Something like: class MyClass(object): def __init__(@): @.dummy = None OR, even better, getting *rid of it* in the parameter list, so it stops confusing people about how many parameters a method needs, and transform it into a true *operator*. class MyClass(object): def __init__(): #takes no arguments! @.dummy = None #the @ invokes the class object's dictionary That would seem to be a nice solution to the problem, really. It doesn't become PERLish because you've made it into a genuine operator -- self was always a non-variable that looked like a variable and hence created an itch that couldn't be scratched. Anyone else have any thoughts? Guido did. :) http://neopythonic.blogspot.se/2008/10/why-explicit-self-has-to-stay.html Nice link, thanks. I see the problem. I was under the false impression that Python's lexer built an *abstract syntax tree* (see wikipedia for a nice description) like C does so that lexical items like functions and objects are defined. As it stands now, Python doesn't even seem to know what an *expression* is. Guido hasn't defined his language so that an object is defined lexically, so he's cheating a little by requiring self to be passed in. If Python were to be defined more completely, all his points in reference to Bruce Eckel's suggestion would be moot. A method would automatically (not auto*magically*) know what class they are in. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Tuesday, May 26, 2015 at 9:48:25 PM UTC-5, zipher wrote: On Tuesday, May 26, 2015 at 12:28:31 PM UTC-5, Mark Lawrence wrote: On 26/05/2015 17:37, zipher wrote: Would it be prudent to rid the long-standing argument (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name? Yes, how about you taking a permanent holiday rather than bother this list with more of your nonsense? Mark Lawrence Mr. Lawrence, could you calm down with your sadism on the list. Our session last time ended with a lot of semen on your floor instead of in your mouth. Your bosom buddy, Mark Janssen Arrgh. Sorry, that was meant privately... -m -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
zipher dreamingforw...@gmail.com writes: Arrgh. Sorry, that was meant privately... I'm glad we saw it publicly, so that we get more of an idea how you treat people. That kind of homophobic slur is inappropriate from anyone in this community. Kindly cut it out altogether. -- \ “Always do right. This will gratify some people, and astonish | `\the rest.” —Mark Twain | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Wednesday 27 May 2015 02:37, zipher wrote: Would it be prudent to rid the long-standing argument (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name? No. Something like: class MyClass(object): def __init__(@): @.dummy = None OR, even better, getting *rid of it* in the parameter list, so it stops confusing people about how many parameters a method needs, and transform it into a true *operator*. I think you misspelled a word. There's no be, tt or er in worse :-) All joking aside, I cannot imagine why you think that the first argument to a method should be considered an operator. It's an argument, a named variable, not an operator. class MyClass(object): def __init__(): #takes no arguments! But that is completely wrong. __init__ DOES take a single argument -- the instance. Methods, it can be either bound to the instance or unbound: py str.upper(hello world) # unbound method, self provided explicitly 'HELLO WORLD' py hello world.upper() # bound method, self provided automatically 'HELLO WORLD' I suggest you study these two examples carefully. @.dummy = None #the @ invokes the class object's dictionary It certainly shouldn't do that. It should invoke the full attribute lookup machinery, which does far more than invoke the class __dict__. In fact, if it invoked the class __dict__, that would *completely* break the object oriented paradigm. Writing to the class __dict__ means that all instances share the same value. That would seem to be a nice solution to the problem, really. It doesn't become PERLish because you've made it into a genuine operator -- self was always a non-variable that looked like a variable and hence created an itch that couldn't be scratched. That is completely wrong. self is, and always has been, a real variable. That's why you can call it anything you like -- self is just the convention, nothing more. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Wednesday 27 May 2015 06:45, Mark Lawrence wrote: Apart from breaking all the tools that rely on self being spelt self this looks like an excellent idea. Tools which rely on self being spelled self are already broken. It's a convention, nothing more, and there are various good reasons for breaking the convention: - metaclasses - classmethods - custom descriptors - nested classes -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Wednesday 27 May 2015 14:39, Ben Finney wrote: zipher dreamingforw...@gmail.com writes: Arrgh. Sorry, that was meant privately... I'm glad we saw it publicly, so that we get more of an idea how you treat people. That kind of homophobic slur is inappropriate from anyone in this community. Kindly cut it out altogether. I look forward to the day when people would read the earlier insult and be perplexed as to why it is a slur at all. In the same way as your mother wears army boots has become a joke slur, not taken seriously. So long as it does nobody any harm, and all participants have consented, what one adult chooses to take into their mouth is nobody else's business and certainly no reason to look down on them. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Tue, May 26, 2015, at 12:57, Laura Creighton wrote: Guido did. :) http://neopythonic.blogspot.se/2008/10/why-explicit-self-has-to-stay.html It's worth noting that the dynamically modify a class argument (and to some extent the decorator argument) misses Javascript's solution - _any_ function may refer to this (which is not in the argument list), which will be the global scope object (the browser window for browser-hosted javascript - presumably the current module for a hypothetical equivalent python feature, though it might be more prudent to simply make it None.) if the function is called without an object reference. Of course, Javascript also lacks bound methods, which makes it much more likely to happen by accident. I can't really think of anything that you can do with decorators, either, in the current model, that you _couldn't_ do in a JS-alike function call model... but I doubt it would be possible to implement backwards-compatibly. In principle, if you added a class keyword (hey, technically, isn't there one already?) you wouldn't need decorators at all for the staticmethod/classmethod/instance method case. -- https://mail.python.org/mailman/listinfo/python-list
should self be changed?
Would it be prudent to rid the long-standing argument (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name? Something like: class MyClass(object): def __init__(@): @.dummy = None OR, even better, getting *rid of it* in the parameter list, so it stops confusing people about how many parameters a method needs, and transform it into a true *operator*. class MyClass(object): def __init__(): #takes no arguments! @.dummy = None #the @ invokes the class object's dictionary That would seem to be a nice solution to the problem, really. It doesn't become PERLish because you've made it into a genuine operator -- self was always a non-variable that looked like a variable and hence created an itch that couldn't be scratched. Anyone else have any thoughts? --mark -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Tuesday, May 26, 2015 at 3:47:20 PM UTC-4, Marko Rauhamaa wrote: zipher dreamingforw...@gmail.com: Would it be prudent to rid the long-standing argument (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name? Something like: class MyClass(object): def __init__(@): @.dummy = None OR, even better, getting *rid of it* in the parameter list, so it stops confusing people about how many parameters a method needs, and transform it into a true *operator*. Python's practice works. However, a small problem is presented by nested classes: class Connection: def __init__(self): class Idle: def signal_start(self): # how to refer to the outer self : : Solutions include: ... class Connection: def __init__(self): conn = self class Idle: def signal_start(self): conn.set_state(Ready) : I have used the latter method recently. I would find it much clearer to not use a nested class at all, and instead to pass the object into the constructor: class Idle: def __init__(self, conn): self.conn = conn def signal_start(self): self.conn.set_state(Ready) class Connection: def __init__(self): something(Idle(self)) --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
zipher dreamingforw...@gmail.com wrote: Would it be prudent to rid the long-standing argument (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name? Something like: class MyClass(object): def __init__(@): @.dummy = None Believe or not, python3 (via Guido's time machine) already anticipated this suggestion and you can indeed use a symbol instead of 'self': class MyClass(object): def __init__(ስ): ስ.dummy = None -- --- | Radovan Garabík http://kassiopeia.juls.savba.sk/~garabik/ | | __..--^^^--..__garabik @ kassiopeia.juls.savba.sk | --- Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus! Copy me into your signature file to help me spread! -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
Ned Batchelder n...@nedbatchelder.com: I would find it much clearer to not use a nested class at all, and instead to pass the object into the constructor: Nested classes are excellent and expressing the state pattern URL: http://en.wikipedia.org/wiki/State_pattern. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
zipher dreamingforw...@gmail.com: Would it be prudent to rid the long-standing argument (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name? Something like: class MyClass(object): def __init__(@): @.dummy = None OR, even better, getting *rid of it* in the parameter list, so it stops confusing people about how many parameters a method needs, and transform it into a true *operator*. Python's practice works. However, a small problem is presented by nested classes: class Connection: def __init__(self): class Idle: def signal_start(self): # how to refer to the outer self : : Solutions include: class Connection: def __init__(self): class Idle: def signal_start(_): self.set_state(Ready) : class Connection: def __init__(self): conn = self class Idle: def signal_start(self): conn.set_state(Ready) : I have used the latter method recently. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On 26/05/2015 21:26, garabik-news-2005...@kassiopeia.juls.savba.sk wrote: zipher dreamingforw...@gmail.com wrote: Would it be prudent to rid the long-standing argument (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name? Something like: class MyClass(object): def __init__(@): @.dummy = None Believe or not, python3 (via Guido's time machine) already anticipated this suggestion and you can indeed use a symbol instead of 'self': class MyClass(object): def __init__(ስ): ስ.dummy = None Apart from breaking all the tools that rely on self being spelt self this looks like an excellent idea. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
Mark Lawrence wrote: def __init__(ስ): ስ.dummy = None Apart from breaking all the tools that rely on self being spelt self this looks like an excellent idea. too bad for the tools: using the name self is just a convention, not a rule. -- By ZeD -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On 2015-05-26 21:45, Mark Lawrence wrote: class MyClass(object): def __init__(ስ): ስ.dummy = None Apart from breaking all the tools that rely on self being spelt self this looks like an excellent idea. Though to be fair, they *are* broken tools if they rely on self since there's nothing in the Python specs that require that. It's just a convention[1]. -tkc [1] https://docs.python.org/2/tutorial/classes.html#random-remarks Often, the first argument of a method is called self. This is nothing more than a convention: the name self has absolutely no special meaning to Python. Note, however, that by not following the convention your code may be less readable to other Python programmers, and it is also conceivable that a class browser program might be written that relies upon such a convention. It does give fair warning, but I'd consider that a warning to authors of class browser program[s] as much as to developers. -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
zipher wrote: Would it be prudent to rid the long-standing argument (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name? Something like: class MyClass(object): def __init__(@): @.dummy = None Just seeing the Python3.5 announce with @ used as matrix multiplication operator ;-) OR, even better, getting *rid of it* in the parameter list, so it stops confusing people about how many parameters a method needs, and transform it into a true *operator*. Self is not an operator, its the target object as first parameter. And with Python you can call some methods directly using theclass.themethod(objet, param1, param2). class MyClass(object): def __init__(): #takes no arguments! @.dummy = None #the @ invokes the class object's dictionary That would seem to be a nice solution to the problem, really. It doesn't become PERLish because you've made it into a genuine operator -- self was always a non-variable that looked like a variable and hence created an itch that couldn't be scratched. «Explicit is better than implicit» I think that googling for that idea you will find other people already proposing it (I've seen propositions to directly remove part before the dot like this: .dummy = None). Just read it. Anyone else have any thoughts? IMHO Zero chance that it be adopted. A+ Laurent. -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On Wed, May 27, 2015 at 3:28 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: Yes, how about you taking a permanent holiday rather than bother this list with more of your nonsense? No need to be nasty about it. The suggestion is a plausible one, it just happens to not fit Python's philosophy. The best response is to quote Guido's statement on the subject... which is exactly what Laura already did. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
In a message of Tue, 26 May 2015 09:37:29 -0700, zipher writes: Would it be prudent to rid the long-standing argument (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name? Something like: class MyClass(object): def __init__(@): @.dummy = None OR, even better, getting *rid of it* in the parameter list, so it stops confusing people about how many parameters a method needs, and transform it into a true *operator*. class MyClass(object): def __init__(): #takes no arguments! @.dummy = None #the @ invokes the class object's dictionary That would seem to be a nice solution to the problem, really. It doesn't become PERLish because you've made it into a genuine operator -- self was always a non-variable that looked like a variable and hence created an itch that couldn't be scratched. Anyone else have any thoughts? Guido did. :) http://neopythonic.blogspot.se/2008/10/why-explicit-self-has-to-stay.html Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: should self be changed?
On 26/05/2015 17:37, zipher wrote: Would it be prudent to rid the long-standing argument (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name? Something like: class MyClass(object): def __init__(@): @.dummy = None OR, even better, getting *rid of it* in the parameter list, so it stops confusing people about how many parameters a method needs, and transform it into a true *operator*. class MyClass(object): def __init__(): #takes no arguments! @.dummy = None #the @ invokes the class object's dictionary That would seem to be a nice solution to the problem, really. It doesn't become PERLish because you've made it into a genuine operator -- self was always a non-variable that looked like a variable and hence created an itch that couldn't be scratched. Anyone else have any thoughts? --mark Yes, how about you taking a permanent holiday rather than bother this list with more of your nonsense? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
