On 5/31/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
That might be true of http, but what about modules with a more ambiguous name?
But with Java (don't have much .NET experience) the issue is they put data structures in java.util which doesn't explain anything. But if it had been named datastruct or something more meaningful would it be so bad?
We are adults, but doesn't that mean we can also be organized? We are past the point of keeping our toys in one big basket and instead have organized shelves where we separate our Transformers from our Tonka trucks.
We will be fixing the names on top of categorizing, so that will be addressed.
The magic importation is an implementation artifact from os being around before packages existed. If it was done today that wouldn't work that way.
And I would never want to flatten os completely. Knowing that path manipulating code is in os.path is handy when you are looking for a function in the documentation, and especially at the interpreter prompt. We all know searching a tree over a list is better! =)
-Brett
Le mardi 30 mai 2006 à 09:25 -0700, Brett Cannon a écrit :
>
> I think what needs to happen is decide if we want to group modules
> into packages (but no deeper than a single depth), and then how to
> handle general naming ( e.g., net.http, net.httplib, http, or
> httplib?).
I don't see the point of grouping modules into packages.
It is obvious what "http" is (a network protocol), so why have to write
"net.http " instead of simply "http" ? It's more things to type and more
things to remember, without any clear advantage.
That might be true of http, but what about modules with a more ambiguous name?
The current flat namespace for the standard library is one *very*
pleasant feature of Python. You only have to remember the module name
itself, not its position in the hierarchy. Compare this with Java
or .Net...
But with Java (don't have much .NET experience) the issue is they put data structures in java.util which doesn't explain anything. But if it had been named datastruct or something more meaningful would it be so bad?
Moreover, as someone wrote in another post, if you introduce packages,
people will write "from gui import wx", so why not just let it be
"import wx"? We are adults.
We are adults, but doesn't that mean we can also be organized? We are past the point of keeping our toys in one big basket and instead have organized shelves where we separate our Transformers from our Tonka trucks.
The problem with the current naming IMO is the fact it is inconsistent
and sometimes confusing. I don't think introducing a level of nesting is
an answer to this problem. Actually, flattening the current nested
modules would be a good think.
We will be fixing the names on top of categorizing, so that will be addressed.
(for example, I don't like the way "os.path" is magically imported when
importing "os". Some functions are in "os", others in "os.path", without
any clear logical reason. They should all belong in "os" - or any other
name for that matter).
The magic importation is an implementation artifact from os being around before packages existed. If it was done today that wouldn't work that way.
And I would never want to flatten os completely. Knowing that path manipulating code is in os.path is handy when you are looking for a function in the documentation, and especially at the interpreter prompt. We all know searching a tree over a list is better! =)
-Brett
Regards
Antoine.
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: http://mail.python.org/mailman/options/python-3000/brett%40python.org
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
