Argh, wrong list again... Christopher Arndt schrieb: > Tim Lesher schrieb: >> On Nov 7, 2007 8:50 AM, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: >>> One special case are the imports from sqlobject, sqlalchemy and elixir >>> in model.py. In this case, importing * makes some sense. >> I disagree on model. It's one thing to say, "Yes, these well-known, >> supported, redistributable modules support the __all__ convention, and we >> know they will in the future." But it's another thing to say, "we're going >> to quickstart your application in a way that says you are hereby ordered to >> use the __all__ convention in your internal code and keep it up-to-date". > > Good point. > >> Sure, that issue would be solved by using >> __all__, but I think it's asking too much to force every user to keep an >> __all__ up-to-date for a file that isn't necessarily intended for reuse. > > Why isn't model.py intended for re-use? Not within another application, > perhaps, but even if you only import it within your own application it's > still good practice to use __all__. > > If we generated an '__all__ = [...]' statement for all generated > database classes in model.py, the user would be either required to keep > it up-to-date by adding his own model classes or delete the whole statement. > > Something like: > > # List of symbols exported by this module > # Add the names of your own model classes to the list to export them > # or remove the __all__ assignment completely (not recommended). > __all__ = [ > 'User', > 'Group', > 'Permission' > ... > ] > > > Chris
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
