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
-~----------~----~----~----~------~----~------~--~---
