Florent Aide wrote: > On Nov 7, 2007 8:31 PM, Christopher Arndt <[EMAIL PROTECTED]> wrote: > > [...] > >> 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' >> ... >> ] >> > > I must admit that I would prefer to *not* impose the __all__ usage on > the end-users (thus not impose it in quickstarted model/controllers). > But why not impose it in our TG code.
I think that what Chris has proposed (put __all__ and a comment explaining why) is a great idea. I personally have learned much (and got some bad habits on the way too) from the layout given to me by frameworks when I was a noob. Showing "good practices" by-example never hurts IMO. > The usage of __all__ in a nearly empty model.py could lead to strange > questions in the ML when people try to import something and forgot to > declare it in __all__. We would have too much questions around this > and I feel it would be an irritation/frustration to beginners more > than a help for them. A well-worded comment can help mitigate this. Alberto --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
