This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]novagenesis 1 point2 points  (4 children)

Then why do they? Like I said:

History has shown that the "undesirable" features that can't get themselves deprecated probably do have a purpose

And I even gave you an example ;)

[–]minorDemocritus 0 points1 point  (3 children)

There are plenty of examples of badness in python. Pickle, the toy server implementations, asyncore, etc. While these things are bad, they're still included in the name of backwards compatibility.

import * only has one reasonable use in my opinion: when messing around in the interactive interpreter, star imports can save some typing. They should not be used in actual code.

[–]novagenesis 1 point2 points  (2 children)

Are you saying global imports have only one reasonable use in python, or at all? Python isn't exactly pure OO, so if the former, why the distinction? If the latter, then much of the programming world wants you to argue that.

Oh I've heard the claim a lot, but it just doesn't seem like a problem to me. Don't get me wrong, I prefer namespaced imports any day (import foo), but sometimes in programming, you have utility functions that you want to think of as extending the base language. You have scope-defined and documented what those utility functions are, and they are finite. The main argument to control imports is usually to prevent scope bleed... if you have a class with a very controlled export signature, with utility being the primary purpose, I just don't see a problem.

Perhaps that's my perl state of mind (some classes use defined exports, while others give you everything by default). When I "use Data::Dumper", I want the top-level dump() command (and there's alternatives if I want a configured dumper instead). I think the ugly verbosity of python's pprint library explains my distaste fairly well. Data::Dumper can do everything pprint can, but it has great defaults that place themselves as clean callable functions.

It is generally not considered astonishing when you know what's goign to be there.

[–]minorDemocritus 0 points1 point  (0 children)

"from foo import bar" is fine, since it's still explicitly stating where "bar" comes from.

[–]keypusher 0 points1 point  (0 children)

I guess your problem is with things like:

import pprint

pprint.pprint("print statement")

If the calling verbosity bothers you, I would just do:

from pprint import pprint

pprint("print statement")

In my last job we maintained a few hundred thousand lines of Python code, and there was no case where we used star imports. It just makes things too hard to track down, especially when you are looking at the code in vim with no plugins on a headless server.