On 5/31/06, Ronald Oussoren <[EMAIL PROTECTED]> wrote:

On 31-mei-2006, at 19:19, Antoine Pitrou wrote:

> Le mercredi 31 mai 2006 à 09:57 -0700, Brett Cannon a écrit :
>>
>> That might be true of http, but what about modules with a more
>> ambiguous name?
>
> Then perhaps the name can be made less ambiguous ;)
> For example "ElementTree" could be named "xmltree", or whatever.
>
>> 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?
>
> No, but it still would be additional baggage to remember.
> It is clear a "deque" is a collection and a "heapq" is a specific kind
> of data structure, so why try to categorize them whereas the
> categorization does not bring any additional information or
> functionality to the programmer?

And what would a more hierarchical namespace mean for 3th-party code?
If there were to be a toplevel package "gui" that contains gui code
such as tkinter it would be very natural to assume that wxWidgets or
gtk are also in the gui namespace, even if they aren't part of the
standard library. I haven't thought enough about this to know which
option I'd hate more, requiring 3th-party libraries to pick unobvious
names or not knowing if net.jabber is a standard library package I
didn't use yet or something that is was installed sepereately.

Why would a 3rd-party module be installed into the stdlib namespace?  net.jabber wouldn't exist unless it was in the stdlib or the module's author decided to be snarky and inject their module into the stdlib namespace.

And this ambiguity issue exists now.  If a module author choose some generic name, how are you supposed to know where it is in the stdlib or not?

And I really don't think the gui example is an issue anyway.  wxWidgets names itself wx to prevent these problems to begin with.  I really don't think users are going to be confused by not finding third-party code in stdlib packages.

-Brett

_______________________________________________
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

Reply via email to