Why do Perl programmers make more money than Python programmers

[jmfauth]

On 6 mai, 09:49, Fábio Santos <fabiosantos... at gmail.com> wrote:
> On 6 May 2013 08:34, "Chris Angelico" <ros... at gmail.com> wrote:
>
> > Well you see, it was 70 bytes back in the Python 2 days (I'll defer to
> > Steven for data points earlier than that), but with Python 3, there
> > were two versions: one was 140 bytes representing 70 characters, the
> > other 280 bytes representing 70 characters. In Python 3.3, they were
> > merged, and a trivial amount of overhead added, so now it's 80 bytes
> > representing 70 characters. But you have an absolute guarantee that
> > it's correct now.
>
> > Of course, the entire code can be represented as a single int now. You
> > used to have to use a long.
>
> > ChrisA
> > --
>
> Thanks. You have made my day.
>
> I may rise the average pay of a Python programmer in Portugal. I have asked
> for a raise back in December, and was told that it wouldn't happen before
> this year. I have done well. I think I deserve better pay than a
> supermarket employee now. I am sure that my efforts were appreciated and I
> will be rewarded. I am being sarcastic.
>
> The above paragraph wouldn't be true if I programmed in perl, c++ or lisp.


-----


1) The memory gain for many of us (usually non ascii users)
just become irrelevant.

>>> sys.getsizeof('maçã')
41
>>> sys.getsizeof('abcd')
29

2) More critical, Py 3.3, just becomes non unicode compliant,
(eg European languages or "ascii" typographers !)

>>> import timeit
>>> timeit.timeit("'abcd'*1000 + 'a'")
2.186670111428325
>>> timeit.timeit("'abcd'*1000 + '€'")
2.9951699820528432
>>> timeit.timeit("'abcd'*1000 + 'œ'")
3.0036780444886233
>>> timeit.timeit("'abcd'*1000 + 'ẞ'")
3.004992278824048
>>> timeit.timeit("'maçã'*1000 + 'œ'")
3.231025618708202
>>> timeit.timeit("'maçã'*1000 + '€'")
3.215894398100758
>>> timeit.timeit("'maçã'*1000 + 'œ'")
3.224407974255655
>>> timeit.timeit("'maçã'*1000 + '’'")
3.2206342273566406
>>> timeit.timeit("'abcd'*1000 + '’'")
2.9914403449067777

3) Python is "pround" to cover the whole unicode range,
unfortunately it "breaks" the BMP range.
Small GvR exemple (ascii) from the the bug list,
but with non ascii characters.

# Py 3.2, all chars

>>> timeit.repeat("a = 'hundred'; 'x' in a")
[0.09087790617297742, 0.07456871885972305, 0.07449940353376405]
>>> timeit.repeat("a = 'maçãé€ẞ'; 'x' in a")
[0.10088136800095526, 0.07488497003487282, 0.07497594640028638]


# Py 3.3 ascii and non ascii chars
>>> timeit.repeat("a = 'hundred'; 'x' in a")
[0.11426985953005442, 0.10040049292649655, 0.09920834808588097]
>>> timeit.repeat("a = 'maçãé€ẞ'; 'é' in a")
[0.2345595188256766, 0.21637172864154763, 0.2179096624382737]


There are plenty of good reasons to use Python. There are
also plenty of good reasons to not use (or now to drop)
Python and to realize that if you wish to process text
seriously, you are better served by using "corporate
products" or tools using Unicode properly.

jmf