Stack Overflow moderator “animusonâ€

[Ian Kelly]

I haven't provided a "real-world" example, since I expect you Python
Einsteins to be able do an A/B test between Python and Perl yourselves
(provided you know Perl, of course, which I'm afraid is not always the
case). And why would I use any "custom" version of Python, when I don't
have to do that with Perl?

Well, I'm certainly not about to do the comparison myself. I only
have so much time, and presently I am not sufficiently motivated about
this topic to invest any time in it. A suggestion: *you* brought up
the subject, so if you want us to pay attention to your claims, then
*you* had better be prepared to get your hands dirty and do the actual
work to support it.

 

[Steven D'Aprano]

Not a troll. It's just hard to convince Python users that their beloved
language would have inferior regular expression performance to Perl.

I can't speak for others, but I've known for many years that Python's
regex implementation was slower than Perl's. So what? Do you have a patch?

 

[Ethan Furman]

I hate to sound like this but do you realise that this is exactly what
you're arguing for when saying that sum() shouldn't use "+="?

my_obj = SomeKoolClass()
my_obj.modify_in_some_kool_way()
new_result = sum([SKC1, SKC2, SKC3], my_obj)

Guess what? You've just changed my_obj.

 

[Joel Goldstick]

call your mom

I hate to sound like this but do you realise that this is exactly what
you're arguing for when saying that sum() shouldn't use "+="?

my_obj = SomeKoolClass()
my_obj.modify_in_some_kool_**way()
new_result = sum([SKC1, SKC2, SKC3], my_obj)

Guess what? You've just changed my_obj.

 

[Steven D'Aprano]

I hate to sound like this but do you realise that this is exactly what
you're arguing for when saying that sum() shouldn't use "+="?

You're referencing an off-list conversation, which will probably confuse
most others reading this.

I don't agree with that. Apart from one throw-away comment where I said
that sometimes it is handy to have a trivial example of an O(N**2)
algorithm for teaching purposes, I have never made any suggestion that
having sum(lists) be slow was a good thing in and of itself. My argument
has always been that there are costs as well as benefits to changing sum
of lists to use += instead of + and I'm not convinced that the benefits
outweigh those costs.

Quite frankly, looking at the pure-Python version of sum that Sergey has
posted, I *really* hope he is a better C programmer than Python
programmer, because his pure-Python version is so full of bugs it is
ridiculous. But now I'm also referring to posts off-list

 

[Joshua Landau]

You're referencing an off-list conversation, which will probably confuse
most others reading this.

I don't agree with that. Apart from one throw-away comment where I said
that sometimes it is handy to have a trivial example of an O(N**2)
algorithm for teaching purposes, I have never made any suggestion that
having sum(lists) be slow was a good thing in and of itself.

I might be misattributing posts then. Or... YOU'RE IN DENIAL!

Who wins? You decide!

 

[Joshua Landau]

I hate to sound like this but do you realise that this is exactly what
you're arguing for when saying that sum() shouldn't use "+="?

my_obj = SomeKoolClass()
my_obj.modify_in_some_kool_way()
new_result = sum([SKC1, SKC2, SKC3], my_obj)

Guess what? You've just changed my_obj.

You're extrapolating too quickly. The first "+" is a copying "+", the
rest add in-place to the new object. Thus, no unexpected side effect.

 

[Terry Reedy]

A moderator who calls himself “animuson†on Stack Overflow doesn’t
want to face the truth. He has deleted all my postings regarding Python
regular expression matching being extremely slow compared to Perl.
Additionally my account has been suspended for 7 days. Such a dickwad.

Your opinion of "animuson" is off-topic for this list.

StackOverflow is explicitly for technical questions with technical
answers. I believe opinions, languages comparisions, and flamebaits in
general are explicitly banned and subject to removal and possible
banning. So are subterfuges like phrasing banned topics as questions.

Given your behavior here, I am 90+% sure animuson's action was appropriate.

 

[Steven D'Aprano]

I might be misattributing posts then. Or... YOU'RE IN DENIAL!

Ranting Rick? Is that you?

Who wins? You decide!

Ah, definitely not RR

 

[alex23]

You're obviously trying hard to be funny. It fails miserably.

It's obvious that you are quite familiar with miserableness.

Also obvious is that animuson did the world of StackOverflow quite the
favour. If only e moderated this list...

 

[alex23]

Op Wed, 10 Jul 2013 12:06:06 +0000, schreef Mats Peterson:

If you're able to do that with Perl, and Perl is faster that Python,
why would you want to bother with Python?

The OP has no interest in using Python, this is simply a perfect example
of the effect of Dunbar's number.

 

[Michael Torrie]

I fear you don’t even know what a regular expression is. Then this will
of course not affect you.

Hmm, and your stack exchange posts had a similar tone, hmm?

I for one have never ready any of your posts on this forum before, so it
looks like you've come here solely to troll. Perhaps your time would be
better spent contributing a faster regex engine to the Python standard
library.

 

[Michael Torrie]

You're showing by these examples what regular expressions mean to you.

Chris is showing no such thing. And you are simply trolling. What do
you want us to do, fall down and worship you and admit that Python is a
horrible language and we should all use Perl? What is your point? Are
you looking for an admission of Python's slowness compared to Perl? If
so, then yes it's slower. For what I need it for, it does not matter.
Maybe you could write a better regex engine for python. Then we'd have
the best of both worlds.

 

[Michael Torrie]

I haven't provided a "real-world" example, since I expect you Python
Einsteins to be able do an A/B test between Python and Perl yourselves
(provided you know Perl, of course, which I'm afraid is not always the
case). And why would I use any "custom" version of Python, when I don't
have to do that with Perl?

Oh wow. You really do sound like Ranting Rick. Always wanting someone
else to do the work and carry the burden of proof.

Since you don't use Python, don't like Python, and don't promote Python,
why are you here on this list? Are you evangelizing Perl?

Apologies to the list; I hope I'm done.

 

[CM]

Mats, I fear you have misunderstood. If the Python Secret Underground
existed, which it most certainly does not, it would absolutely not have
the power to censor people's emails or cut them off in the middle of

*That's* the Python Secret Underground's special power? That's it?! Cutting people off in the middle of an email? I mean how lame can

 

[Antoon Pardon]

Op 10-07-13 13:56, Benedict Verheyen schreef:

Op Wed, 10 Jul 2013 12:12:10 +0100, schreef Joshua Landau:



Indeed, as Joshua says, instead of going through all the effort to talk
about it, why don't you show us that Python is slower in regexs than perl.
That's at least relevant bandwdith.

Next, if Python is slower, there might be ways to improve the performance.

Last, if there is a SPU (Secret Python Underground), I want to j

Heretic, it is the

 

[Antoine Pitrou]

And for good damn reason too. They're ruining our language, á mon avis.

We do!
<off to buy wine>

Regards

Antoine.

 

[Jake Angulo]

A moderator who calls himself “animuson” on Stack Overflow doesn’t
want to face the truth. He has deleted all my postings regarding Python
regular expression matching being extremely slow compared to Perl.
Additionally my account has been suspended for 7 days. Such a dickwad.

The OP meant to post:

A moderator who calls himself MatsDtroll on Stack Overflow doesn’t want to
face the truth. He has deleted all my postings regarding Perl regular
expression matching being extremely slow compared to Bash regex.
Additionally my account has been suspended for 7 days. Such a dickwad.

 

[wxjmfauth]

Le mercredi 10 juillet 2013 11:00:23 UTC+2, Steven D'Aprano a écrit :

That's by design. We don't want to make the same mistake as Perl, where

every problem is solved by a regular expression:



http://neilk.net/blog/2000/06/01/abigails-regex-to-test-for-prime-numbers/



so we deliberately make regexes as slow as possible so that programmers

will look for a better way to solve their problem. If you check the

source code for the re engine, you'll find that for certain regexes, it

busy-waits for anything up to 30 seconds at a time, deliberately wasting

cycles.



The same with Unicode. We hate French people, you see, and so in an

effort to drive everyone back to ASCII-only text, Python 3.3 introduces

some memory optimizations that ensures that Unicode strings work

correctly and are up to four times smaller than they used to be. You

should get together with jmfauth, who has discovered our dastardly plot

and keeps posting benchmarks showing how on carefully contrived micro-

benchmarks using a beta version of Python 3.3, non-ASCII string

operations can be marginally slower than in 3.2.








I cannot imagine why he would have done that.

This Flexible String Representation is a dream case study.
Attempting to optimize a subset of character is a non sense.

If you are a non-ascii user, such a mechanism is irrelevant,
because per definition you do not need it. Not only it useless,
it is penalizing, just by the fact of its existence. [*]

Conversely (or identically), if you are an ascii user, same situation,
it is irrelevant, useless and penalizing.

Practically, and today, all coding schemes we have
(including the endorsed Unicode utf transformers) work
with a unique set of of encoded code points. If you
wish to take the problem from the other side, it is
because one can only work properly with a unique set
of code points that so many coding schemes exist!

Question: does this FSR use internally three coding
schemes because it splits Unicode in three groups or
does it split Unicode in three subsets to have the joyce
to use three coding schemes?

About "micro benchmarks". What to say, they appear
practivally every time you use non ascii.

And do not forget memory. The €uro just become expensive.
40

I do not know. When an €uro char need 14 bytes more that
a dollar, I belong to those who thing there is a problem
somewhere.

This FSR is a royal gift for those who wish to teach Unicode
and the coding of characters.

jmf

 

[Chris Angelico]

And do not forget memory. The €uro just become expensive.

40

I do not know. When an €uro char need 14 bytes more that
a dollar, I belong to those who thing there is a problem
somewhere.

Oh, I totally agree. But it's not just the Euro symbol that's
expensive. Look how much I have to pay for a couple of square
brackets!

sys.getsizeof((1)) 14
sys.getsizeof([1])

40

ChrisA