[Python-il] Perl Vs. Python on Various Points

Tal Einat taleinat at gmail.com
Mon Jul 13 15:12:16 IDT 2009

On Mon, Jul 13, 2009 at 12:57 PM, Shlomi Fish wrote:
> On Monday 13 July 2009 12:00:23 Tal Einat wrote:

>> > 1. Syntax as an Indicative of What the Language is Doing:
>> > ---------------------------------------------------------
>> > I said I happen to like it because the extra characters convey meaning.
>> Perl has very few built-in types; I recall numbers, strings, arrays,
>> hashes and functions. When you need to use anything else you are
>> forced to use references, which are indistinguishable from numbers and
>> require "casting" their targets' values back to their actual type.
> References are not numbers. They are different types of scalars. You can tell
> them apart using perldoc -f ref . You may be able to add a reference to a
> number, without a lot of meaning, or perform other arithmetic operations, but
> it's not encouraged.

My point here was that because references are scalars like numbers and
strings, and references are used quite often, knowing that something
is a scalar means that it is either a "simple" scalar (number, string,
undef) or a reference (which can point to anything), so it isn't
obvious what type of underlying data it represents. My experience with
Perl found me using references very often, which made the sigils less
informative and more of a burden.

>> In Python every class defines its own
>> comparison methods (if relevant), which Python uses when evaluating
>> "==" and friends. I can use "==" and ">=" and ">" to compare various
>> types of containers, such as lists, sets, tuples and dicts, and these
>> comparisons are simple and obvious. Besides making the code clean and
>> readable, things like this make learning Python less tedious.
> Can I also overload the meaning of these for my own containers? This may cause
> unexpected results. This is also the case for Perl with overloading.

Yes, you can. However, doing so for non-trivial comparisons is highly

The main point is that the comparison operators simply work for all of
the built-in classes as well as those in the standard library.
Normally you doesn't really have to think about such issues at all
since the normal comparison operators just do what you would expect.

>> > 4. Hiding Code
>> Usually you just don't want someone to have your original version of
>> the code, so they don't copy/paste and develop their own product based
>> on your code.
> Well, Richard M. Stallman and other free software zealots will disagree with
> you on this. ;-) Even Python itself is distributed along with the original
> version of the code, so other people can copy/paste and develop their own
> product based on the code. Its licence even permits changing the licence of
> the code, including making it proprietary.

I should have added "excluding open-source software" or something
before that... :)

>> For this purpose obfuscation and/or compiling to
>> byte-code are enough.
> You may be right. However, I was under the impression that my conversation
> partner wanted even better protection.

That is hard to achieve with any language! There are many decompilers
for C/C++ which do a pretty good job even on highly optimized code,
not just Java. The only way to ensure someone doesn't know what your
software is doing is to not have the software run on his computer.

>> (Obligatory: Writing in Perl is all the obfuscation one would ever need ;)
> That's an old joke and was never particularly funny or true.

Actually I was trying to have a serious conversation, and just
mentioned the usual trolling with a wink to show that I'm not like
that. No hard feelings I hope?

- Tal

More information about the Python-il mailing list