Is there a conflict of libraries here?

[Chris Angelico]

On Mon, Nov 9, 2020 at 3:32 PM Terry Reedy <tjreedy at udel.edu> wrote:
>
> On 11/8/2020 9:56 AM, Chris Angelico wrote:
> > On Mon, Nov 9, 2020 at 1:11 AM Terry Reedy <tjreedy at udel.edu> wrote:
>
> >> A module containing an object with the same name as the module is a real
> >> pain, a constant mental papercut.  I consider datetime.datetime to be a
> >> design mistake*.  You are the 2nd person in about a month to post the
> >> same resulting code problem.
> >>
> >> * Either the class should have been 'Datetime', capitalized like classes
> >> in modules other that builtins generally should be, or the module should
> >> have been given a different name.  I personally would always rename the
> >> module when imported.
> >>
> >
> > Yes, it's annoying, but it's only annoying when code on the internet
> > suggests "from datetime import *",
>
> I agree that the latter is annoying, but I disagree about 'only'.  Names
> pointing to two different objects (or people ;-) are ambiguous without
> additional disambiguation.  If I write 'datetime has an off-by-one bug'
> or 'datetime is great', which datetime do I mean?

Perhaps, but certainly the confusion is far less when the module is
always imported as itself, and then the class is "datetime.datetime"
which nicely parallels "datetime.date" and "datetime.time".

If we could abuse Guido's time machine and have them as
"datetime.DateTime" etc, I would definitely be in favour of it. I
don't know that it'd be worth actually changing, though, and even
adding aliases doesn't really seem worthwhile IMO.

> idlelib once had multiple name.name pairs, such as Debugger.Debugger,
> and to me, the nuisance of fixing them (as per PEP 434 and subsequent
> decision by the BDFL-delegate) has now been outweighed by the continuing
> benefit.

Yes, but the nuisance of fixing internal idlelib details isn't nearly
as strong as renaming a public class :)

ChrisA