By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,952 Members | 1,693 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,952 IT Pros & Developers. It's quick & easy.

How to best explain a "subtle" difference between Python and Perl ?

P: n/a
Hi everyone !

I'd like to apologize in advance for my bad english, it's not my
mother tongue...

My girlfriend (who is a newbie in Python, but knows Perl quite well)
asked me this morning why the following code snippets didn't give the
same result :

### Python ###

liste = [1,2,3]

def foo( my_list ):
my_list = []

foo(liste)

print liste# she expected liste to be an empty list

### Perl ###

@lst =(1,2,3);
$liste =\@lst;
foo($liste);
print "@lst\n";

sub foo {
my($my_list)=@_;
@{$my_list}=()
}

I have to admit that I don't know how to clearly explain to her the
differences between these results.
Could someone please help us understand these difference between
Python and Perl ?

Thanks in advance,
P4|1ndr0m
Aug 12 '08 #1
Share this Question
Share on Google+
8 Replies


P: n/a
In article
<42**********************************@s50g2000hsb. googlegroups.com>,
Palindrom <de*******@gmail.comwrote:
Hi everyone !

I'd like to apologize in advance for my bad english, it's not my
mother tongue...

My girlfriend (who is a newbie in Python, but knows Perl quite well)
asked me this morning why the following code snippets didn't give the
same result :

### Python ###

liste = [1,2,3]

def foo( my_list ):
Right now my_list is a local variable - since you
called foo(liste), the name my_list is bound to the
object liste
my_list = []
But this line doesn't modify liste, instead it
binds the name my_list to a different object.

If you want to modify the list that my_List points
to you could do it in either of two ways:

def foo1(my_liste):
del my_liste[:]

def foo2(my_liste):
my_liste[:] = []
foo(liste)

print liste# she expected liste to be an empty list

### Perl ###

@lst =(1,2,3);
$liste =\@lst;
foo($liste);
print "@lst\n";

sub foo {
my($my_list)=@_;
@{$my_list}=()
}

I have to admit that I don't know how to clearly explain to her the
differences between these results.
Could someone please help us understand these difference between
Python and Perl ?

Thanks in advance,
P4|1ndr0m
--
David C. Ullrich
Aug 12 '08 #2

P: n/a
Palindrom wrote:
### Python ###

liste = [1,2,3]

def foo( my_list ):
my_list = []
The above points the my_list reference at a different object. In this
case a newly created list. It does not modify the liste object, it
points my_list to a completely different object.
### Perl ###

@lst =(1,2,3);
$liste =\@lst;
foo($liste);
print "@lst\n";

sub foo {
my($my_list)=@_;
@{$my_list}=()
}
The above code *de-references* $my_list and assigns an empty list to its
referant (@lst).

The two code examples are not equivalent.

An equivalent perl example would be as follows:

### Perl ###

@lst =(1,2,3);
$liste =\@lst;
foo($liste);
print "@lst\n";

sub foo {
my($my_list)=@_;
$my_list = [];
}

The above code does just what the python code does. It assigns a newly
created list object to the $my_list reference. Any changes to this now
have no effect on @lst because $my_list no longer points there.

n
Aug 12 '08 #3

P: n/a
Thank you Nigel, it's clearer for both of us now.
I think wat confused her is the fact that :

L = [1,2,3]
def foo(my_list):
my_list.append(4)

will modify L, while the following:

L = [1,2,3]
def foo(my_list):
my_list = [1,2,3,4]

will not.

On Tue, Aug 12, 2008 at 6:46 PM, Nigel Rantor <wi****@wiggly.orgwrote:
Palindrom wrote:
>>
### Python ###

liste = [1,2,3]

def foo( my_list ):
my_list = []

The above points the my_list reference at a different object. In this case a
newly created list. It does not modify the liste object, it points my_list
to a completely different object.
>### Perl ###

@lst =(1,2,3);
$liste =\@lst;
foo($liste);
print "@lst\n";

sub foo {
my($my_list)=@_;
@{$my_list}=()
}

The above code *de-references* $my_list and assigns an empty list to its
referant (@lst).

The two code examples are not equivalent.

An equivalent perl example would be as follows:

### Perl ###

@lst =(1,2,3);
$liste =\@lst;
foo($liste);
print "@lst\n";

sub foo {
my($my_list)=@_;
$my_list = [];
}

The above code does just what the python code does. It assigns a newly
created list object to the $my_list reference. Any changes to this now have
no effect on @lst because $my_list no longer points there.

n
Aug 12 '08 #4

P: n/a
Thank you both for your reply !

On Tue, Aug 12, 2008 at 8:52 PM, Demarche Bruno <de*******@gmail.comwrote:
Thank you Nigel, it's clearer for both of us now.
I think wat confused her is the fact that :

L = [1,2,3]
def foo(my_list):
my_list.append(4)

will modify L, while the following:

L = [1,2,3]
def foo(my_list):
my_list = [1,2,3,4]

will not.

On Tue, Aug 12, 2008 at 6:46 PM, Nigel Rantor <wi****@wiggly.orgwrote:
>Palindrom wrote:
>>>
### Python ###

liste = [1,2,3]

def foo( my_list ):
my_list = []

The above points the my_list reference at a different object. In this case a
newly created list. It does not modify the liste object, it points my_list
to a completely different object.
>>### Perl ###

@lst =(1,2,3);
$liste =\@lst;
foo($liste);
print "@lst\n";

sub foo {
my($my_list)=@_;
@{$my_list}=()
}

The above code *de-references* $my_list and assigns an empty list to its
referant (@lst).

The two code examples are not equivalent.

An equivalent perl example would be as follows:

### Perl ###

@lst =(1,2,3);
$liste =\@lst;
foo($liste);
print "@lst\n";

sub foo {
my($my_list)=@_;
$my_list = [];
}

The above code does just what the python code does. It assigns a newly
created list object to the $my_list reference. Any changes to this now have
no effect on @lst because $my_list no longer points there.

n
Aug 12 '08 #5

P: n/a
On Aug 12, 9:17*am, Palindrom <demarc...@gmail.comwrote:
Hi everyone !

I'd like to apologize in advance for my bad english, it's not my
mother tongue...

My girlfriend (who is a newbie in Python, but knows Perl quite well)
asked me this morning why the following code snippets didn't give the
same result :

### Python ###

liste = [1,2,3]

def foo( my_list ):
* * my_list = []

foo(liste)

print liste# she expected liste to be an empty list

### Perl ###

@lst =(1,2,3);
$liste =\@lst;
foo($liste);
print "@lst\n";

sub foo {
*my($my_list)=@_;
*@{$my_list}=()

}

I have to admit that I don't know how to clearly explain to her the
differences between these results.
Could someone please help us understand these difference between
Python and Perl ?
David Ullrich gives a great and complete answer. I want to focus on
some of the subtleties.

Perl and C share a lot in common. There are "direct" variables, things
like numbers and arrays. These aren't references to object, but the
object is itself stored in the variable. That is, you can't talk about
the thing that is '@lst' without creating a reference to it.

Python, on the other hand, doesn't have direct variables. Well, it
does, it is just that all of the direct variables are really pointers
or references to the values they reference.

Imagine a perl where you are only allowed to use scalars, and
specifically, scalars that are references to object but not references
to references. That is the Python variable system.

To be more concrete...

This statement cannot be expressed in Python:

@lst = (1, 2, 3); # perl
However, you can create an arrayref (perl) / list (Python) and assign
a scalar (perl) / variable (Python) to reference it:

$liste = [1, 2, 3]; # perl
liste = [1, 2, 3] # Python
Likewise, this statement cannot be expressed in Python:

$refref = \$ref; # perl
Although you can cheat in both perl and Python to get a similar
result:

$refref = [$ref] # perl
refref = [ref] # python
As far as the functions, the Python version and the perl version are
doing two completely different things. David explains how to write a
Python version that does what the perl version is doing. If you wanted
a perl version that did what your python version did, it would look
like this:

sub foo {
my ($my_list) = @_;
$my_list = [];
return undef;
}
Is Python's variable system better than perl's? It depends on which
way you prefer. As for me, being a long-time veteran of perl and
Python, I don't think having a complicated variable system such as
perl's adds anything to the language. Python's simplicity in this
regard is not only sufficient, but preferable.
Aug 13 '08 #6

P: n/a
On Aug 13, 2:12*am, Jonathan Gardner <jgard...@jonathangardner.net>
wrote:
On Aug 12, 9:17*am, Palindrom <demarc...@gmail.comwrote:
Hi everyone !
I'd like to apologize in advance for my bad english, it's not my
mother tongue...
My girlfriend (who is a newbie in Python, but knows Perl quite well)
asked me this morning why the following code snippets didn't give the
same result :
### Python ###
liste = [1,2,3]
def foo( my_list ):
* * my_list = []
foo(liste)
print liste# she expected liste to be an empty list
### Perl ###
@lst =(1,2,3);
$liste =\@lst;
foo($liste);
print "@lst\n";
sub foo {
*my($my_list)=@_;
*@{$my_list}=()
}
I have to admit that I don't know how to clearlyexplainto her the
differences between these results.
Could someone please help us understand these difference between
Python and Perl ?

David Ullrich gives a great and complete answer. I want to focus on
some of the subtleties.

Perl and C share a lot in common. There are "direct" variables, things
like numbers and arrays. These aren't references to object, but the
object is itself stored in the variable. That is, you can't talk about
the thing that is '@lst' without creating a reference to it.

Python, on the other hand, doesn't have direct variables. Well, it
does, it is just that all of the direct variables are really pointers
or references to the values they reference.

Imagine a perl where you are only allowed to use scalars, and
specifically, scalars that are references to object but not references
to references. That is the Python variable system.

To be more concrete...

This statement cannot be expressed in Python:

*@lst = (1, 2, 3); * *# perl

However, you can create an arrayref (perl) / list (Python) and assign
a scalar (perl) / variable (Python) to reference it:

*$liste = [1, 2, 3]; *# perl
*liste = [1, 2, 3] * *# Python

Likewise, this statement cannot be expressed in Python:

*$refref = \$ref; * * # perl

Although you can cheat in both perl and Python to get a similar
result:

*$refref = [$ref] * * # perl
*refref = [ref] * * * # python

As far as the functions, the Python version and the perl version are
doing two completely different things. David explains how to write a
Python version that does what the perl version is doing. If you wanted
a perl version that did what your python version did, it would look
like this:

*sub foo {
* *my ($my_list) = *@_;
* *$my_list = [];
* *return undef;
*}

Is Python's variable system better than perl's? It depends on which
way you prefer. As for me, being a long-time veteran of perl and
Python, I don't think having a complicated variable system such as
perl's adds anything to the language. Python's simplicity in this
regard is not only sufficient, but preferable.
Thank you Jonathan for your extensive and clear response !

I agree with you, Python's variable system is eazier to understand.
Regards.
Aug 13 '08 #7

P: n/a
Jonathan Gardner wrote:
[...eloquent and interesting discussion of variable system snipped...]
>
Is Python's variable system better than perl's? It depends on which
way you prefer. As for me, being a long-time veteran of perl and
Python, I don't think having a complicated variable system such as
perl's adds anything to the language. Python's simplicity in this
regard is not only sufficient, but preferable.
Very well put.

I am not however sure I agree with your very final thought.

I ma a long time C/C++/Java/Perl developer. I know some python too.

The Python system is the same as the Java system, apart from Java's
primitive types, which is a completely different discussion that I
really don't want to get into right now.

So, everything is by reference.

I understand, and agree that a simple system is good. And maybe even
preferable. But it isn't always sufficient.

Some algorithms are much easier to write if you know that your
parameters are going to be copied and that the function may use them as
local variables without having to explicitly create copies.

You can also reason more easily about what side-effects the function
could have if you know it cannot possibly modify your parameters.

Other systems out there require pointer-like semantics (for example
CORBA out and inout parameters) which have to be kludged in languages
like Java to pass in wrapper objects/boxes that can be assigned values.

Whilst it may be easier to learn a system like python/java, in the end
the amount of time spent learning the system is normally dwarfed by the
time spent using the system to build software. I would rather have a
type system that is as expressive as possible.

Also, note that it is entirely possible to create many, many, many
interesting and useful things in Perl without having to resort to
references. They are a relatively new feature after all.

Just my 0.02p

n
Aug 13 '08 #8

P: n/a
Nigel Rantor wrote:
The Python system is the same as the Java system, apart from Java's
primitive types, which is a completely different discussion that I
really don't want to get into right now.

So, everything is by reference.
I am not too familiar with Java's system.
I understand, and agree that a simple system is good. And maybe even
preferable. But it isn't always sufficient.

Some algorithms are much easier to write if you know that your
parameters are going to be copied and that the function may use them as
local variables without having to explicitly create copies.
If you could provide some specific examples, I would appreciate that.

As for me, using Python (and perl, which doesn't make copies when you
are passing references around) extensively for large projects, I've
never run into a case where that's bitten me. If I need to make a copy
of any object, it's a one-line statement in Python. It's pretty rare
that you do need to make copies of stuff, and it's pretty obvious where
it needs to be done. I'm glad that it's very explicit.
You can also reason more easily about what side-effects the function
could have if you know it cannot possibly modify your parameters.
We can all keep track of where our hands are by wearing straitjackets as
well.

As for me, I'd rather make vague promises and use my best judgment with
complete freedom to deliver the best result.
Other systems out there require pointer-like semantics (for example
CORBA out and inout parameters) which have to be kludged in languages
like Java to pass in wrapper objects/boxes that can be assigned values.

Whilst it may be easier to learn a system like python/java, in the end
the amount of time spent learning the system is normally dwarfed by the
time spent using the system to build software.
I disagree with this. I find myself many factors more productive in
Python than expert Java developers. I also find that I think about the
problem while the Java developers are always thinking about how they can
express themselves in Java properly.

You may want to spend some more time in Python. Once you abandon all of
your Java-isms and perl-isms, then you'll find it quite relaxing. Most
of my ramp up time in Python was leaving behind old ideas that were
specific to the languages I already knew. It takes a while for one to
realize that programming isn't supposed to be hard.
I would rather have a type system that is as expressive as possible.
Then you really should look at Haskell.
Also, note that it is entirely possible to create many, many, many
interesting and useful things in Perl without having to resort to
references. They are a relatively new feature after all
It's true that Perl's reference system is relatively new, but I can't
imagine writing even trivial scripts without references. (How do you do
getopt without references?) The hacks people had to do in the past were
horrifying. Yes, it's possible. No, it's not preferable.
Aug 13 '08 #9

This discussion thread is closed

Replies have been disabled for this discussion.