On Sat, 2007-09-22 at 20:12 +0800, Russell Keith-Magee wrote: > So my question becomes 'how do we accomodate the 1% case'. I would > suggest the best approach here would be to check for name clashes when > a new command is registered. If a clash is identified, we can either: > 1) Raise an error, stopping manage.py > 2) Raise a warning, and > a) adopt the new command > b) ignore the new command > 3) Register the duplicate command with an auto-aliased name - the > appname.command syntax you proposed is probably a good option here. >
OK. But there are some points from the Zen of Python that are, I think, appropriate here: * Explicit is better than implicit. * Special cases aren't special enough to break the rules. * In the face of ambiguity, refuse the temptation to guess. * Namespaces are one honking great idea -- let's do more of those! My point is that my original patch only requires you to put app_name.command instead of just command. If someone wants to provide a syncdb command, it would be clear that dbmigrations.syncdb is different from syncdb in that the former is provided by that app and the latter is provided by Django itself. If, on the other hand, dbmigrations also provides migratedb, then, based on the "if a conflict occurs, append the app_name" you'd have migratedb and dbmigrations.syncdb, both provided by the same app. What's more, if two apps provide the same command, which one will get the app_name in front of it depends on which order the two appear in INSTALLED_APPS. If we both have app alpha and beta installed, but the order is different, I might have to use alpha.run_something and runsomething as commands, while you would use run_something and beta.run_something. This creates ambiguities, breaks rules with special cases, and causing problems with implicitness. All of which just is not Pythonic, at least according to my reading. In short, we can avoid all these potential problems if we just make people put the app_module in front of commands. It's one little extra bit with a period, it's something they should be aware of anyway (because you shouldn't be using a command unless you know where it's coming from), and it avoids that 1% of problems without making things 99% more complicated. Furthermore, sometimes worrying about the 1% of the cases before they've caused a problem is worth it. http://www.joelonsoftware.com/articles/Craftsmanship.html Here's a case where fixing the problems *before* they occur doesn't take any more effort than not fixing them, so why don't we fix them? Todd P.S. Sorry to be such a pain about this. But, as I said, I've been bitten by the global namespace problem for templates one too many times. I mentioned it in the high school class I teach and the four students who've spent a decent amount of time with Django have also been bitten by it. If we can avoid having the same name refer ambiguously to multiple things in the command domain, I think that's a good thing. I will, however, defer to BDFL fiat, but will have an "I told you so" email ready and waiting for the first time someone gets bitten by this issue. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
