3 ms·

> I was shooting for the most concise syntax I could get. Yes, but default arguments are simply not intended for that. Decorators are. You wouldn't use default

> I was shooting for the most concise syntax I could get. Yes, but default arguments are simply not intended for that. Decorators are. You wouldn't use default arguments as method metadata in Ruby, would you? Going for the "most concise syntax" in all cases gets you Perl, and Python is most definitely not Perl.

jrockway 15y ago
In Perl, all arguments are undef (similar to None) by default, which is pretty much the only thing you should be defaulting things to in Python. So actually, Perl makes it hard to shoot yourself in the foot, while Python has syntax for making it easy. (We have an internal library at work that does something like: def __init__(self, ..., foo={}): self.foo = foo Guess what happens when you change some_instance.foo. Yup, all the other instances change too!)
- LeafStorm 15y ago
  That's really not the point I was going for. I mean, we can debate which language's style is better all day, but regardless of which approach to default arguments is better Mr. Coe is still using the ones in Python improperly.
  - BenjaminCoe 15y ago
    I attempted to make amends one comment below this. I will switch the library to using a decorator based approach -- it's as clean, and there's no reason for me to break convention (I'll lash myself a few times to be safe too ;) With regards to instance variables: On a request, the main process forks and a new instance of the route object is instantiated. Trust me, instance variables won't leak between requests: This is what happens when a request comes in, the parameters to process_message are described here: http://docs.python.org/library/smtpd.html http://docs.python.org/library/smtpd.html @pytoad_decorator() def process_message(self, peer, mailfrom, rcpttos, message_data): for RouteClass in self.routes: route = RouteClass(peer_ip=peer[0]) route.route(message_data)
- fakeempire 15y ago
  Excuse my ignorance, but why would that change all the instances in this case? I don't understand. Would you mind explaining more?
  - pyre 15y ago
    def __init__(self, ..., foo={}): self.foo = foo In this case, 'foo={}' is evaluated once, and returns a pointer to a dict(). After that, foo is always pointing to the same dict, not to a newly created empty dict. Run this in a Python interpreter: class PhoneBook(object): def __init__(self, names={}): self.names = names phonebook1 = PhoneBook() phonebook2 = PhoneBook() phonebook1.names['Bob'] = '+1 555 5555' print phonebook2.names['Bob'] The only thing that is really safe to put in the defaults are immutable values.
BenjaminCoe 15y ago
You could definitely twist my arm and get me to change the approach, mentally substitute: def subscribe(self, route=r'subscribe-(?P<name>[^@])@.'): with: @route('subscribe-(?P<name>[^@])@.'') def subscribe(self): and we can stop arguing. I'm sticking to my guns on the instance variables, it's cleaner.

jrockway 15y ago

In Perl, all arguments are undef (similar to None) by default, which is pretty much the only thing you should be defaulting things to in Python. So actually, Perl makes it hard to shoot yourself in the foot, while Python has syntax for making it easy. (We have an internal library at work that does something like: def __init__(self, ..., foo={}): self.foo = foo Guess what happens when you change some_instance.foo. Yup, all the other instances change too!)

LeafStorm 15y ago
That's really not the point I was going for. I mean, we can debate which language's style is better all day, but regardless of which approach to default arguments is better Mr. Coe is still using the ones in Python improperly.
- BenjaminCoe 15y ago
  I attempted to make amends one comment below this. I will switch the library to using a decorator based approach -- it's as clean, and there's no reason for me to break convention (I'll lash myself a few times to be safe too ;) With regards to instance variables: On a request, the main process forks and a new instance of the route object is instantiated. Trust me, instance variables won't leak between requests: This is what happens when a request comes in, the parameters to process_message are described here: http://docs.python.org/library/smtpd.html http://docs.python.org/library/smtpd.html @pytoad_decorator() def process_message(self, peer, mailfrom, rcpttos, message_data): for RouteClass in self.routes: route = RouteClass(peer_ip=peer[0]) route.route(message_data)
fakeempire 15y ago
Excuse my ignorance, but why would that change all the instances in this case? I don't understand. Would you mind explaining more?
- pyre 15y ago
  def __init__(self, ..., foo={}): self.foo = foo In this case, 'foo={}' is evaluated once, and returns a pointer to a dict(). After that, foo is always pointing to the same dict, not to a newly created empty dict. Run this in a Python interpreter: class PhoneBook(object): def __init__(self, names={}): self.names = names phonebook1 = PhoneBook() phonebook2 = PhoneBook() phonebook1.names['Bob'] = '+1 555 5555' print phonebook2.names['Bob'] The only thing that is really safe to put in the defaults are immutable values.

BenjaminCoe 15y ago

You could definitely twist my arm and get me to change the approach, mentally substitute: def subscribe(self, route=r'subscribe-(?P<name>[^@])@.'): with: @route('subscribe-(?P<name>[^@])@.'') def subscribe(self): and we can stop arguing. I'm sticking to my guns on the instance variables, it's cleaner.