LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
LinkBack Search this Thread
Old 02-25-2013, 11:16 PM   #31
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 451Reputation: 451Reputation: 451Reputation: 451Reputation: 451

Quote:
Originally Posted by mina86 View Post
My second translation does what you want. ...
Where is that second translation ?
 
Old 02-26-2013, 12:04 AM   #32
devUnix
Member
 
Registered: Oct 2010
Location: Bengaluru, India
Distribution: RHEL 5.1 on My PC, & SunOS / Sun Solaris, RHEL, SuSe, Debian, FreeBSD and other Linux flavors @ Work
Posts: 533

Original Poster
Rep: Reputation: 46
Quote:
Originally Posted by sundialsvcs View Post
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 " 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!
 
Old 02-26-2013, 08:30 AM   #33
mina86
Member
 
Registered: Aug 2008
Distribution: Slackware
Posts: 311

Rep: Reputation: 120Reputation: 120
Quote:
Originally Posted by Sergei Steshenko View Post
Where is that second translation ?
#28, read after “UPDATE”.
 
Old 02-26-2013, 09:25 AM   #34
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 451Reputation: 451Reputation: 451Reputation: 451Reputation: 451
Quote:
Originally Posted by mina86 View Post
#28, read after “UPDATE”.

OK, so could you separate your code into two files ? Doing that will hopefully show yet another inherent problem.
 
Old 02-26-2013, 11:41 AM   #35
mina86
Member
 
Registered: Aug 2008
Distribution: Slackware
Posts: 311

Rep: Reputation: 120Reputation: 120
Quote:
Originally Posted by Sergei Steshenko View Post
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.
 
Old 02-26-2013, 09:55 PM   #36
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 451Reputation: 451Reputation: 451Reputation: 451Reputation: 451
Quote:
Originally Posted by mina86 View Post
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.
 
Old 02-27-2013, 08:02 AM   #37
mina86
Member
 
Registered: Aug 2008
Distribution: Slackware
Posts: 311

Rep: Reputation: 120Reputation: 120
Quote:
Originally Posted by Sergei Steshenko View Post
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.
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(…)

…
 
Old 02-27-2013, 08:55 AM   #38
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 451Reputation: 451Reputation: 451Reputation: 451Reputation: 451
Quote:
Originally Posted by mina86 View Post
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 ?
 
Old 02-27-2013, 10:41 AM   #39
mina86
Member
 
Registered: Aug 2008
Distribution: Slackware
Posts: 311

Rep: Reputation: 120Reputation: 120
Quote:
Originally Posted by Sergei Steshenko View Post
So, again, namespace pollution ?
No.

Quote:
Originally Posted by Sergei Steshenko View Post
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 View Post
If yes, you see yet another source of potential errors ?
No, so no.

Quote:
Originally Posted by Sergei Steshenko View Post
You need to know the class name, don't you ?
I do, so?

Quote:
Originally Posted by Sergei Steshenko View Post
You probably need the files to follow <class_name>'py naming convention ?
No.

So, have we established already that your argument is invalid?
 
Old 02-27-2013, 11:12 AM   #40
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 451Reputation: 451Reputation: 451Reputation: 451Reputation: 451
Quote:
Originally Posted by mina86 View Post
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.
 
Old 02-27-2013, 12:01 PM   #41
mina86
Member
 
Registered: Aug 2008
Distribution: Slackware
Posts: 311

Rep: Reputation: 120Reputation: 120
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?
 
Old 02-27-2013, 12:25 PM   #42
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 451Reputation: 451Reputation: 451Reputation: 451Reputation: 451
Quote:
Originally Posted by mina86 View Post
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.
 
Old 02-27-2013, 12:33 PM   #43
mina86
Member
 
Registered: Aug 2008
Distribution: Slackware
Posts: 311

Rep: Reputation: 120Reputation: 120
Quote:
Originally Posted by Sergei Steshenko View Post
rename foo bar
You don't have to rename files. You just import it under a different name.

Quote:
Originally Posted by Sergei Steshenko View Post
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 View Post
the "as" part wasn't originally there,
So?
 
Old 02-27-2013, 01:23 PM   #44
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 451Reputation: 451Reputation: 451Reputation: 451Reputation: 451
Quote:
Originally Posted by mina86 View Post
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:
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.
 
Old 02-27-2013, 02:08 PM   #45
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian
Posts: 2,307

Rep: Reputation: 767Reputation: 767Reputation: 767Reputation: 767Reputation: 767Reputation: 767Reputation: 767
Quote:
Originally Posted by Sergei Steshenko View Post
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'>

Last edited by ntubski; 02-27-2013 at 02:13 PM. Reason: module name isn't actually a filename, per se
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Python related: How to access a Perl script behind a firewall from Python? vxc69 Programming 8 12-14-2010 07:32 AM
Perl Vs python knockout_artist Linux - Newbie 6 10-15-2008 11:06 AM
My needs: Perl vs. Python dave201 Programming 25 08-11-2007 11:13 PM
perl vs python yenonn Programming 6 08-01-2006 05:44 AM
Perl or Python ! linuxlover1 Programming 13 04-19-2004 07:33 AM


All times are GMT -5. The time now is 02:14 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration