Switch to lower_case names for methods (PEP 8) and maintain backwards compatibility with aliases

[McSinyx]

I am aware that this is quite up to personal preference, but many modules I have used followed that naming convention, which IMHO makes code more recognizable, i.e. one can easily distinguish between module/class/method/function. threading has went smoothly through this kind of migration by aliasing deprecated names to ensure backward compatibility.

Happy lunar new year!

[chr15m]

@McSinyx probably a good idea. Will merge a PR that implements this change with the aliasing you suggest.

[byronsharman]

Would this be a good newcomer bug? I'm interested in helping.

[chr15m]

@nonoesimposible indeed! The criteria for success are:

• Callbacks and methods are available via lower_case style names.
• The tests pass.

[byronsharman]

So here is something interesting. In Channel.py (will eventually be called channel.py), the send method (previously Send) looks like this:

class Channel(asynchat.async_chat):
    ...
    def send(self, data):
        """Returns the number of bytes sent after encoding."""
        outgoing = dumps(data) + self.endchars.encode()
        self.sendqueue.append(outgoing)
        return len(outgoing)

This actually ends up recursively calling send() until my computer runs out of memory. Since the aysnchat.async_chat already has a send() method, I think Channel.send is overriding it and messing things up. Previously, this wasn't happening because Python is case-sensitive, so Send() and send() were two different methods.

Is there a way to get around this without completely renaming Channel.send to something else?
Edit: I suppose what I really wanted to ask is whether it would be OK to rename Channel.send to something else, or whether that would break a bunch of stuff.

The exception looks like this:

Server launched
connection
New Player('127.0.0.1', 44950)
players [<__main__.ClientChannel connected 127.0.0.1:44950 at 0x7fb703bfa668>]
Traceback (most recent call last):
  File "ChatServer.py", line 72, in <module>
    s.launch()
  File "ChatServer.py", line 62, in launch
    self.pump()
  File "/usr/lib/python3.7/site-packages/PodSixNet/Server.py", line 38, in pump
    [c.pump() for c in self.channels]
  File "/usr/lib/python3.7/site-packages/PodSixNet/Server.py", line 38, in <listcomp>
    [c.pump() for c in self.channels]
  File "/usr/lib/python3.7/site-packages/PodSixNet/Channel.py", line 30, in pump
    [asynchat.async_chat.push(self, d) for d in self.sendqueue]
  File "/usr/lib/python3.7/site-packages/PodSixNet/Channel.py", line 30, in <listcomp>
    [asynchat.async_chat.push(self, d) for d in self.sendqueue]
  File "/usr/lib/python3.7/asynchat.py", line 202, in push
    self.initiate_send()
  File "/usr/lib/python3.7/asynchat.py", line 251, in initiate_send
    num_sent = self.send(data)
  File "/usr/lib/python3.7/site-packages/PodSixNet/Channel.py", line 35, in send
    outgoing = dumps(data) + self.endchars.encode()
MemoryError

[chr15m]

@nonoesimposible thanks for making progress on this. Yes using .Send() to avoid overriding .send() was not a great hack. I'm not sure what the best solution to fix this is. Some different options:

• Stop subclassing asynchat and instead compose it in under a new class property.
• Monkey-patch the class and rename .send to something else before overriding it (may cause other errors but tests will probably reveal them).
• Change the name of the new method to some other verb entirely.

I suppose if the old .Send() is still available to code which uses it then whatever we do is ok for existing users so it's more about what's best for future users.

I'll have a think about it, but don't let me stop you from moving ahead.

[byronsharman]

Hmm, it looks like this is not the only thing that interferes with asyncore's variable names. Some possible instances are:

• EndPoint.close() calls itself recursively
• Channel.handle_connect() has trouble because connected is now a variable instead of a method of EndPoint (perhaps this could be easily taken care of by replacing the name connected with something more specific)

Should we handle these (and possibly more undiscovered) cases individually, or should we come up with one solution that tackles them all?

[chr15m]

A solution that tackles them all sounds pretty good if you can work one out.

[pauliyobo]

You could try by storing the async_chat's instance into a class property instead of inheriting from it. That way send should not conflict with the parent class.

[pauliyobo]

sorry if I sound spammy.
Is someone currently working on this issue?

[byronsharman]

To be honest, I did get stuck a while back with the namespace thing but your recent activity has reminded me of this issue and I'd be happy to give it another try. =)

This is my fault for not communicating well/being honest; if you want to take a shot at fixing this, go ahead.

[pauliyobo]

alright. I'll be starting this in a new branch and see what I can come up with.