LinuxQuestions.org - [SOLVED] Perl or Python

Page 3 of 4

Show 50 post(s) from this thread on one page

LinuxQuestions.org (/questions/)

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - Perl or Python (https://www.linuxquestions.org/questions/programming-9/perl-or-python-4175451226/)

Sergei Steshenko

02-25-2013 11:16 PM

Quote:

Originally Posted by mina86 (Post 4899707)

My second translation does what you want. ...

Where is that second translation ?

devUnix

02-26-2013 12:04 AM

Quote:

Originally Posted by sundialsvcs (Post 4899422)

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."

There are various articles such as http://www.norvig.com/python-lisp.html and http://openbookproject.net/py4fun/lisp/lisp.html which are much better than I am at discussing the etymology of the various programming languages (and, mind you, they definitely do each have one).

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 :jawa:" 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.

Thanks for sharing your insight!

mina86

02-26-2013 08:30 AM

Quote:

Originally Posted by Sergei Steshenko (Post 4899812)

Where is that second translation ?

#28, read after “UPDATE”.

Sergei Steshenko

02-26-2013 09:25 AM

Quote:

Originally Posted by mina86 (Post 4900077)

#28, read after “UPDATE”.

OK, so could you separate your code into two files ? Doing that will hopefully show yet another inherent problem.

mina86

02-26-2013 11:41 AM

Quote:

Originally Posted by Sergei Steshenko (Post 4900105)

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.

Sergei Steshenko

02-26-2013 09:55 PM

Quote:

Originally Posted by mina86 (Post 4900223)

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.

mina86

02-27-2013 08:02 AM

Quote:

Originally Posted by Sergei Steshenko (Post 4900543)

For crying out loud, here you are:

Code:

$ cat car.py



def createCar(color, power):

    …

$ cat main.py

import car



fancy_car = car.createCar(…)

humble_car = car.createCar(…)



…

Sergei Steshenko

02-27-2013 08:55 AM

Quote:

Originally Posted by mina86 (Post 4900813)

For crying out loud, here you are:

Code:

$ cat car.py



def createCar(color, power):

    …

$ cat main.py

import car



fancy_car = car.createCar(…)

humble_car = car.createCar(…)



…

So, again, namespace pollution ?

I.e. the 'car' name pollutes top level namespace, correct ? ... Was it, by the way, 'Car' rather than 'car' ?

If yes, you see yet another source of potential errors ?

You need to know the class name, don't you ? You probably need the files to follow <class_name>'py naming convention ?

mina86

02-27-2013 10:41 AM

Quote:

Originally Posted by Sergei Steshenko (Post 4900852)

So, again, namespace pollution ?

No.

Quote:

Originally Posted by Sergei Steshenko (Post 4900852)

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 (Post 4900852)

If yes, you see yet another source of potential errors ?

No, so no.

Quote:

Originally Posted by Sergei Steshenko (Post 4900852)

You need to know the class name, don't you ?

I do, so?

Quote:

Originally Posted by Sergei Steshenko (Post 4900852)

You probably need the files to follow <class_name>'py naming convention ?

No.

So, have we established already that your argument is invalid?

Sergei Steshenko

02-27-2013 11:12 AM

Quote:

Originally Posted by mina86 (Post 4900920)

No.

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.

mina86

02-27-2013 12:01 PM

I'm seriously getting tired of this argument. Granted, in

Code:

my $foo = require 'file.prl';

consumer decides on the name of $foo but that's also true in case of:

Code:

import file as foo

Now, can we finally agree that your argument has no merit?

Sergei Steshenko

02-27-2013 12:25 PM

Quote:

Originally Posted by mina86 (Post 4900980)

I'm seriously getting tired of this argument. Granted, in

Code:

my $foo = require 'file.prl';

consumer decides on the name of $foo but that's also true in case of:

Code:

import file as foo

Now, can we finally agree that your argument has no merit?

Then we have another problem - we need to make sure that 'file' module has 'file.py' file name.

I am saying that

give_name_to_anonymous foo_name

is simpler than

rename foo bar
.

Or in yet other words - why to have a name if it is to be discarded anyway ?

And AFAIR, in ( http://docs.python.org/release/2.5.2/ref/import.html )

Quote:

import_stmt ::= "import" module ["as" name] ( "," module ["as" name] )*

the "as" part wasn't originally there, but I'm not sure - I seriously looked into Python in year 2000.

mina86

02-27-2013 12:33 PM

Quote:

Originally Posted by Sergei Steshenko (Post 4900996)

rename foo bar

You don't have to rename files. You just import it under a different name.

Quote:

Originally Posted by Sergei Steshenko (Post 4900996)

Or in yet other words - why to have a name if it is to be discarded anyway ?

Because files have names… I'm sorry, I don't know how to answer that. It's like asking why the Perl file has “car.prl” name if you are discarding it.

Quote:

Originally Posted by Sergei Steshenko (Post 4900996)

the "as" part wasn't originally there,

So?

Sergei Steshenko

02-27-2013 01:23 PM

Quote:

Originally Posted by mina86 (Post 4901006)

You don't have to rename files. You just import it under a different name.

Because files have names… I'm sorry, I don't know how to answer that. It's like asking why the Perl file has “car.prl” name if you are discarding it.

So?

I didn't mean renaming files.

I meant that when writing first the producer gives a name, and then the consumer renames that name in

Quote:

import_stmt ::= "import" module ["as" name] ( "," module ["as" name] )*

construct.

So why giving name in the first place ?

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:

- 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.

ntubski

02-27-2013 02:08 PM

Quote:

Originally Posted by Sergei Steshenko (Post 4901041)

I didn't mean renaming files.

I meant that when writing first the producer gives a name, and then the consumer renames that name in

Code:

import_stmt ::= "import" module ["as" name] ( "," module ["as" name] )*

construct.

So why giving name in the first place ?

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'>

All times are GMT -5. The time now is 02:59 AM.

Page 3 of 4

Show 50 post(s) from this thread on one page