Hacker News new | ask | show | jobs
by NoahTheDuke 1622 days ago
> Another one is having to import everything you use.

The alternative is what exactly? Have the entire standard library exposed at once? Make all modules create non-conflicting names for exported objects, so that the json parse function has to be called json_parse and the csv parse function has to be called csv_parse?

Seems less than ideal to me.

1 comments

That's one way.

If these things are classes in a plain old single-dispatch oop system, you can havec a json-parser and csv-parser which have parse methods.

There could be packages/namespaces. So csv:parse and json:parse. These packages are standard and so they just exist; nothing to import.

In Python, you cannot use anything without an import! The top-level modules (which serve as de facto namespaces) themselves are not visible.

Say there is a csv module with a parse. You cannot just do:

  csv.parse(...)
you have to first say

  import csv
This jaw-droppingly moronic.
It lets you debug. E.g. if they have made a file called cvs.py in the same directory, then print (cvs.__file__) will show you this. If they have some weirdly screwed up paths with multiple pythons installed and multiple copies of the modules etc., same.

I will not Go lang has the same feature carried forward from C. It helps a lot in the reading code side of the code lifecycle. And Go compiler makes you keep the imports up to date, which is good.

> It lets you debug.

It lets you debug Python problems which the system created in the first place.

> If they have some weirdly screwed up paths with multiple pythons installed and multiple copies of the modules etc., same.

Doesn't happen in a sane language. Or, even not a sanely defined language/implementation.

I can easily have multiple different GCC copies (possibly for different processor targets) on the same machine. Each one knows where its own files are; an #include <stdio.h> compiled with your /path/to/arm-linux-eabi-gcc will positively not use your /usr/include/stdio.h, unless you explicitly do stupid things, like -I/usr/include on the command line.

You might like [Hissp's][1] import system. It does compile down to Python.

[1]: https://github.com/gilch/hissp

> This jaw-droppingly moronic.

It can be slightly inconvenient but doesn’t feel moronic to me. It means that except for the built-in functions, everything can be traced to either a definition or an import. Makes tracking code much easier.

Why not import the built-in functions too? The only thing not requiring import can be import.

  from python import def  # now you can def
That should be even easier to track things; now you don't have to deal with the difficulty of def not being defined anywhere in your code. It's traced to an import, which is telling you that def comes from python, liberating you from having to know that and remember it.
"def" is not a function. It's not even an identifier.
This exercise requires you to imagine a somewhat different Python in which you can (and must) do from python import def if you are to use def.
I mean, that would be Lisp, and in that context I wouldn't really have a problem with it.