ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Personally, I use Perl and Python (and... and...) pretty much interchangeably in my line of work, so I honestly don't think too much about them and certainly don't try to debate philosophies or to suggest that one is "better than" another. It also simply isn't the point of "what can one do that the other cannot."
In my view, you can definitely see a Lisp influence in Python, with its use of tail-recursion, S-expressions and a bunch of other funky ideas. Not so much in Perl, which was inspired by Awk.
There are always multiple "levels of " in every programming language. There's a friendly, approachable front-room that you can spend a lot of time in, perhaps an entire career in. But, over there in the corner, not drawing attention to itself in any particular way, there is a little Door. If you choose to open that door, a strange and intoxicating odor will waft out. You can follow it, exploring the first Hall of Mysteries. At the far end of that room, also not drawing attention to itself, is another little Door ...
You will generally not find the differences between various languages in that friendly, approachable front room.
Every programming language, without exception, started in the mind of some person (or, eecch! committee) who had a problem to solve and who envisioned an "–er" tool to solve that problem and others like it. Then, a whole bunch of other people whacked on it over the years, and wrote a lot of code in it which paid for their research-grants and salaries. And, so it goes.
OK, so could you separate your code into two files ? Doing that will hopefully show yet another inherent problem.
Spare me, and just tell my what you think is an inherent problem.
If the problem is that the main module will be able to overwrite createCar from the second module, than this is not a problem, no matter how much you'd like it to be. In fact, it's a feature which makes testing possible. Your Perl code is untestable since unit tests cannot substitute the car creation routine with some other routine which returns a mock object.
Spare me, and just tell my what you think is an inherent problem.
If the problem is that the main module will be able to overwrite createCar from the second module, than this is not a problem, no matter how much you'd like it to be. In fact, it's a feature which makes testing possible. Your Perl code is untestable since unit tests cannot substitute the car creation routine with some other routine which returns a mock object.
I know Python very superficially, that's why I only suspect what the problem is. If and when those who know it well implement the task according to their understanding of Python, and if the problem I suspect is indeed there, we'll discuss it. If not - I am wrong in my suspicions.
I know Python very superficially, that's why I only suspect what the problem is. If and when those who know it well implement the task according to their understanding of Python, and if the problem I suspect is indeed there, we'll discuss it. If not - I am wrong in my suspicions.
I.e. the 'car' name pollutes top level namespace, correct ? ... Was it, by the way, 'Car' rather than 'car' ?
No. It's “car” as in the name of the module defined in car.py file. It does not pollute top level namespace any more than $create_car = require 'create_car.pl'; does. All variables defined in separate files reside in their own namespaces. import is not include.
By the way, either of the below will work as well:
Code:
import car as blah
fancy_car = blah.createCar(…)
Code:
from car import createCar
fancy_car = createCar(…)
Code:
from car import createCar as blah
fancy_car = blah(…)
Quote:
Originally Posted by Sergei Steshenko
If yes, you see yet another source of potential errors ?
No, so no.
Quote:
Originally Posted by Sergei Steshenko
You need to know the class name, don't you ?
I do, so?
Quote:
Originally Posted by Sergei Steshenko
You probably need the files to follow <class_name>'py naming convention ?
No.
So, have we established already that your argument is invalid?
No. It's “car” as in the name of the module defined in car.py file. It does not pollute top level namespace any more than $create_car = require 'create_car.pl'; does. ...
Of course, yes.
Module names are in global namespace in both Perl and Pyhton, while top level lexical variables are not.
Furthermore, and I think it's the fundamental issue Python proponents do not understand, with anonymous export -> named import, i.e. with
Code:
my $foo = require 'some_file.prl';
idiom it is the consumer (the human) who decides on in this case '$foo' name; in other words, it's the consumer who performs name binding as late as possible, and because the producer of 'some_file.prl' exports just an anonymous reference, no namespace pollution occurs - by construction.
With
Code:
my $foo = require 'some_file.prl';
idiom provided neither side uses global namespace neither consumer can pollute 'some_file.prl', nor producer can pollute 'main.pl'. The interpreter simply doesn't present such a possibility - by construction.
...
Maybe I'll prepare a shorter example showing lack of protection of variables in producer. And maybe even in consumer - I have to check Python documentation and maybe even write some code myself.
And, overall, this example shows that in order to imitate block scope classes are used, and classes require names, and the name is then discarded.
Readable ? Logical ?
By the way, in Java scopes also used to suck, and the workaround was also to use classes, and classes could be anonymous, but 'class' keyword was needed.
I suspect Java designers wanted to make Java as different from C++ as possible, and Python designers wanted to make Python as different from Perl as possible.
Ironically, both Java and Python designers in the end had to introduce closures.
...
Quote:
So
- first Python designers introduce a problem by not having anonymous export, then they compensate for the problem introducing 'import module as name'. So you see, how much activity ? In Russian we say "имитация кипучей деятельности" - aka ИКД - "imitation of boiling activity" - "boiling" means intensive.
The module name before the "as" is really in the filesystem namespace (like 'foo.pl' except that it can look for "foo.py" or "foo.pyc"), it doesn't go in the consumer's namespace:
Code:
>>> import foo as bar
>>> foo
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'foo' is not defined
>>> bar
<module 'foo' from 'foo.py'>
Last edited by ntubski; 02-27-2013 at 02:13 PM.
Reason: module name isn't actually a filename, per se
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.