Re: sobering observation, python vs. perl

On Thu, 17 Mar 2016 21:18:43 +0530, srinivas devaki wrote: > please upload the log file, Sorry, it's work stuff, can't do that, but just take any big set of files and change the strings appropriately and the numbers should be equivalent. > > and global variables in python are slow, so just ke

Re: sobering observation, python vs. perl

On 03/17/2016 09:08 AM, Charles T. Smith wrote: On Thu, 17 Mar 2016 10:52:30 -0500, Tim Chase wrote: Not saying this will make a great deal of difference, but these two items jumped out at me. I'd even be tempted to just use string manipulations for the isready aspect as well. Something like

Re: sobering observation, python vs. perl

On Thu, 17 Mar 2016 15:29:47 +, Charles T. Smith wrote: And for completeness, and also surprising: time sed -n -e '/ is ready/{s///;h}' -e '/release_req/{g;p}' *.out | sort -u TestCase_F_00_P TestCase_F_00_S TestCase_F_01_S TestCase_F_02_M real0m10.998s user0m10.885s sys 0m0.108

Re: sobering observation, python vs. perl

On Thu, 17 Mar 2016 19:08:58 +0200, Marko Rauhamaa wrote: > "Charles T. Smith" : > > > Compare Perl (http://www.perlmonks.org/?node_id=98357>): > >my $str = "I have a dream"; >my $find = "have"; >my $replace = "had"; >$find = quotemeta $find; # escape regex metachars if present

Re: sobering observation, python vs. perl

"Charles T. Smith" : > I need the second check to also be a RE because it's not > separate tokens. The string "in" check doesn't care about tokens. Marko -- https://mail.python.org/mailman/listinfo/python-list

Re: sobering observation, python vs. perl

On 17/03/2016 18:53, Marko Rauhamaa wrote: BartC : sub replacewith{ $s = $_[0]; $t = $_[1]; $u = $_[2]; $s =~ s/$t/$u/; return $s; } Although once done, the original task now looks a proper language: print (replacewith("I have a dream","have","had")); Now try your funct

Re: sobering observation, python vs. perl

On Thu, 17 Mar 2016 10:52:30 -0500, Tim Chase wrote: >> Not saying this will make a great deal of difference, but these two > items jumped out at me. I'd even be tempted to just use string > manipulations for the isready aspect as well. Something like > (untested) well, I don't want to forgo RE

Re: sobering observation, python vs. perl

"Charles T. Smith" : > well, I don't want to forgo REs in order to have python's numbers be > better http://stackoverflow.com/questions/12793562/text-processing-pytho n-vs-perl-performance> Marko -- https://mail.python.org/mailman/listinfo/python-list

Re: sobering observation, python vs. perl

"Charles T. Smith" : > Here's the programs: > > #!/usr/bin/env python > # vim: tw=0 > import sys > import re > > isready = re.compile ("(.*) is ready") > relreq = re.compile (".*release_req") > for fn in sys.argv[1:]: # logfile name > tn = None > with open (

Re: sobering observation, python vs. perl

On Thu, 17 Mar 2016 18:30:29 +0200, Marko Rauhamaa wrote: > "Charles T. Smith" : > >> I need the second check to also be a RE because it's not >> separate tokens. > > The string "in" check doesn't care about tokens. > > > Marko Ah, yes. Okay. -- https://mail.python.org/mailman/listinfo/pyt

Re: sobering observation, python vs. perl

BartC : > On 17/03/2016 18:53, Marko Rauhamaa wrote: >> BartC : > >>> sub replacewith{ >>> $s = $_[0]; >>> $t = $_[1]; >>> $u = $_[2]; >>> $s =~ s/$t/$u/; >>> return $s; >>> } >>> >>> Although once done, the original task now looks a proper language: >>> >>> print (replacewith(

Re: sobering observation, python vs. perl

On Fri, 18 Mar 2016 03:08 am, Charles T. Smith wrote: > On Thu, 17 Mar 2016 10:52:30 -0500, Tim Chase wrote: > >>> Not saying this will make a great deal of difference, but these two >> items jumped out at me. I'd even be tempted to just use string >> manipulations for the isready aspect as well

Re: sobering observation, python vs. perl

BartC : > I was going to suggest just using a function. But never having coded in > Perl before, I wasn't expecting something this ugly: > > sub replacewith{ >$s = $_[0]; >$t = $_[1]; >$u = $_[2]; >$s =~ s/$t/$u/; >return $s; > } > > Although once done, the original task now lo

Re: sobering observation, python vs. perl

On Thu, 17 Mar 2016 10:26:12 -0700, Ethan Furman wrote: > On 03/17/2016 09:36 AM, Charles T. Smith wrote: > >> Yes, your point was to forgo REs despite that they are useful. >> I could have thought the search would have been better as: >> >> 'release[-.:][Rr]eq' >> >> or something else ... y

Re: sobering observation, python vs. perl

On 17/03/2016 17:25, Charles T. Smith wrote: On Thu, 17 Mar 2016 19:08:58 +0200, Marko Rauhamaa wrote: my $str = "I have a dream"; my $find = "have"; my $replace = "had"; $find = quotemeta $find; # escape regex metachars if present $str =~ s/$find/$replace/g; print $str

Re: sobering observation, python vs. perl

On Thu, 17 Mar 2016 18:07:12 +0200, Marko Rauhamaa wrote: > "Charles T. Smith" : > Ok. The LANG=C setting has a tremendous effect on the performance of > textutils. > > > Marko Good to know, thank you... -- https://mail.python.org/mailman/listinfo/python-list

Re: sobering observation, python vs. perl

On Thu, 17 Mar 2016 17:48:54 +0200, Marko Rauhamaa wrote: > "Charles T. Smith" : > >> On Thu, 17 Mar 2016 15:29:47 +, Charles T. Smith wrote: >> >> And for completeness, and also surprising: >> >> time sed -n -e '/ is ready/{s///;h}' -e '/release_req/{g;p}' *.out | sort -u >> TestCase_F_00_P

Re: sobering observation, python vs. perl

On 2016-03-17 15:29, Charles T. Smith wrote: > isready = re.compile ("(.*) is ready") > relreq = re.compile (".*release_req") > for fn in sys.argv[1:]: # logfile > name tn = None > with open (fn) as fd: > for line in fd: > #match = re.match ("

Re: sobering observation, python vs. perl

"Charles T. Smith" : > On Thu, 17 Mar 2016 17:48:54 +0200, Marko Rauhamaa wrote: >> Try running the sed command again after setting: >> >> export LANG=C > > Hmmm. Interesting thought. But... > > $ locale > LANG=C Ok. The LANG=C setting has a tremendous effect on the performance of textutils.

Re: sobering observation, python vs. perl

On Thu, 17 Mar 2016 09:21:51 -0700, Ethan Furman wrote: >> well, I don't want to forgo REs in order to have python's numbers be >> better > > The issue is not avoiding REs, but using Python's strengths and idioms. > Write the code in Python's style, get the same results, then compare > t

Re: sobering observation, python vs. perl

Charles T. Smith wrote: > On Thu, 17 Mar 2016 10:52:30 -0500, Tim Chase wrote: > >>> Not saying this will make a great deal of difference, but these two >> items jumped out at me. I'd even be tempted to just use string >> manipulations for the isready aspect as well. Something like >> (untested

Re: sobering observation, python vs. perl

On Thu, 17 Mar 2016 17:47:55 +0200, Marko Rauhamaa wrote: > Can't comment on the numbers but the code segments are not quite > analogous. What about this one: > > #!/usr/bin/env python > # vim: tw=0 > import sys > import re > > isready = re.compile("(.*) is ready") > for

Re: sobering observation, python vs. perl

On Thu, 17 Mar 2016 18:34:06 +0200, Marko Rauhamaa wrote: > n-vs-perl-performance Okay, that was interesting. Actually, I saw a study some years ago that concluded that python could be both slower and faster than perl, but that perl had much less deviation than python. I took that and accepted

Re: sobering observation, python vs. perl

On 03/17/2016 09:36 AM, Charles T. Smith wrote: Yes, your point was to forgo REs despite that they are useful. I could have thought the search would have been better as: 'release[-.:][Rr]eq' or something else ... you're in a "defend python at all costs!" mode. No, I'm in the "don't try

Re: sobering observation, python vs. perl

Charles T. Smith: I've really learned to love working with python, but it's too soon to pack perl away. I was amazed at how long a simple file search took so I ran some statistics: Write Python in pythonic style instead of translated-from-Perl style, and the tables are turned: $ cat find-re

Re: sobering observation, python vs. perl

On Thursday, March 17, 2016 at 11:24:00 PM UTC+5:30, BartC wrote: > On 17/03/2016 17:25, Charles T. Smith wrote: > > On Thu, 17 Mar 2016 19:08:58 +0200, Marko Rauhamaa wrote: > > >> my $str = "I have a dream"; > >> my $find = "have"; > >> my $replace = "had"; > >> $find = quotemeta

Re: sobering observation, python vs. perl

"Charles T. Smith" : > On Thu, 17 Mar 2016 15:29:47 +, Charles T. Smith wrote: > > And for completeness, and also surprising: > > time sed -n -e '/ is ready/{s///;h}' -e '/release_req/{g;p}' *.out | sort -u > TestCase_F_00_P > TestCase_F_00_S > TestCase_F_01_S > TestCase_F_02_M > > real0m

Re: sobering observation, python vs. perl

Marko Rauhamaa writes: > "Charles T. Smith" : > >> Actually, I saw a study some years ago that concluded that python >> could be both slower and faster than perl, but that perl had much less >> deviation than python. I took that and accepted it, but was surprised >> now that in exactly the field

Re: sobering observation, python vs. perl

On 03/17/2016 10:35 AM, Charles T. Smith wrote: On Thu, 17 Mar 2016 10:26:12 -0700, Ethan Furman wrote: On 03/17/2016 09:36 AM, Charles T. Smith wrote: Yes, your point was to forgo REs despite that they are useful. I could have thought the search would have been better as: 'release[-.:

sobering observation, python vs. perl

I've really learned to love working with python, but it's too soon to pack perl away. I was amazed at how long a simple file search took so I ran some statistics: $ time python find-rel.py ./find-relreq *.out | sort -u TestCase_F_00_P TestCase_F_00_S TestCase_F_01_S TestCa

Re: sobering observation, python vs. perl

On 17/03/2016 16:36, Charles T. Smith wrote: On Thu, 17 Mar 2016 09:21:51 -0700, Ethan Furman wrote: well, I don't want to forgo REs in order to have python's numbers be better The issue is not avoiding REs, but using Python's strengths and idioms. Write the code in Python's style, get

Re: sobering observation, python vs. perl

please upload the log file, and global variables in python are slow, so just keep all that in a function and try again. generally i get 20-30% time improvement by doin that. On Thu, Mar 17, 2016 at 8:59 PM, Charles T. Smith wrote: > I've really learned to love working with python, but it's too

Re: sobering observation, python vs. perl

"Charles T. Smith" : > Actually, I saw a study some years ago that concluded that python > could be both slower and faster than perl, but that perl had much less > deviation than python. I took that and accepted it, but was surprised > now that in exactly the field of application that I've traditi

Python vs. Perl, which is better to learn?

4332951-- http://mail.python.org/mailman/listinfo/python-list

Re: python vs perl performance test

[EMAIL PROTECTED] wrote: > ... When I first translated it to Python verbatim, > the Python script took almost 30 secs to run. > So far, the best I can do is 11.2 secs using this: > > from random import randrange > from itertools import imap, repeat > from operator import getitem, add, getslice >

Re: python vs perl performance test

On Dec 13, 1:23 pm, Jakub Stolarski <[EMAIL PROTECTED]> wrote: > If all you need is the result here's simpler and more efficient code: > > from random import randrange > sum = 100 * randrange(128) > print "Sum is ", sum > > And the same in perl: > > my $sum = 100 * int(rand(128)); > print "Sum is $

Re: python vs perl performance test

On 13 Gru, 19:11, [EMAIL PROTECTED] wrote: > There's got to be a simpler and more efficient way to do this. > Can you help? > > Thanks, > igor If all you need is the result here's simpler and more efficient code: from random import randrange sum = 100 * randrange(128) print "Sum is ", sum And t

Re: python vs perl performance test

On Dec 13, 6:11 pm, [EMAIL PROTECTED] wrote: > from random import randrange > from itertools import imap, repeat > from operator import getitem, add, getslice > > result = 0 > zeros = [0]*100 > for i in xrange (10): > s = [chr(randrange(128))] * 1024 > starts = repeat(randrange(900), 1

Re: python vs perl performance test

On Dec 13, 2007 12:11 PM, <[EMAIL PROTECTED]> wrote: > First, let me admit that the test is pretty dumb (someone else > suggested it :) but since I am new to Python, I am using it to learn > how to write efficient code. > > my $sum = 0; > foreach (1..10) { > my $str = chr(rand(128)) x 1024

python vs perl performance test

First, let me admit that the test is pretty dumb (someone else suggested it :) but since I am new to Python, I am using it to learn how to write efficient code. my $sum = 0; foreach (1..10) { my $str = chr(rand(128)) x 1024; foreach (1..100) { my $substr = substr($str, rand(900

Re: japanese encoding iso-2022-jp in python vs. perl

Thanks Leo, and everyone else, these were very helpful replies. The issue was exactly as Leo described, and I apologize for not being aware of it, and thus not quite reporting it correctly. At the moment I don't care about round-tripping between half-width and full-width kana, rather I need only

Re: japanese encoding iso-2022-jp in python vs. perl

On Oct 23, 3:37 am, kettle <[EMAIL PROTECTED]> wrote: > Hi, >   I am rather new to python, and am currently struggling with some > encoding issues.  I have some utf-8-encoded text which I need to > encode as iso-2022-jp before sending it out to the world. I am using > python's encode functions: > -

Re: japanese encoding iso-2022-jp in python vs. perl

> var = var.encode("iso-2022-jp", "replace") > print var [...] > ↓東京メトロ日比谷線・北千住行 > > So, what's the deal? Why can't python properly encode some of these > characters? It's not clear. As Ryan says, it works just fine (and so it does for me with Python 2.4.4 on Debian). What Python version are

RE: japanese encoding iso-2022-jp in python vs. perl

> On Behalf Of kettle > I am rather new to python, and am currently struggling with some > encoding issues. I have some utf-8-encoded text which I need to > encode as iso-2022-jp before sending it out to the world. I am using > python's encode functions: > -- > var = var.encode("iso-2022-jp", "

japanese encoding iso-2022-jp in python vs. perl

Hi, I am rather new to python, and am currently struggling with some encoding issues. I have some utf-8-encoded text which I need to encode as iso-2022-jp before sending it out to the world. I am using python's encode functions: -- var = var.encode("iso-2022-jp", "replace") print var -- I am

Re: Random passwords generation (Python vs Perl) =)

NoName wrote: > Perl: > @char=("A".."Z","a".."z",0..9); > do{print join("",@char[map{rand @char}(1..8)])}while(<>); If you generate passwords like that to normal computer users, you'll end up with a lot of "my password doesn't work" tickets. You should skip the symbols that are easy to mistake for

Re: Random passwords generation (Python vs Perl) =)

In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > And can anyone explain why this is so? while 1: input(__import__('os').urandom(6).encode('base64')) > ... > BgiWdv// > > Traceback (most recent call last): > File "", line 1, in > File "", line 0 > > ^ > SyntaxError: unexpected EOF

Re: Random passwords generation (Python vs Perl) =)

En Wed, 31 Jan 2007 01:08:28 -0300, [EMAIL PROTECTED] <[EMAIL PROTECTED]> escribió: > raw_input can do the job of print > while 1: raw_input(__import__('os').urandom(6).encode('base64')) > > And can anyone explain why this is so? while 1: input(__import__('os').urandom(6).encode('base64'))

Re: Random passwords generation (Python vs Perl) =)

On Jan 30, 5:07 am, "NoName" <[EMAIL PROTECTED]> wrote: > WOW! :shock: > > in this case: > > while 1:i=__import__;print > i('binascii').b2a_base64(i('os').urandom(6)),;raw_input() > > > :) raw_input can do the job of print while 1: raw_input(__import__('os').urandom(6).encode('base64')) And can a

Re: Random passwords generation (Python vs Perl) =)

En Mon, 29 Jan 2007 01:58:39 -0300, NoName <[EMAIL PROTECTED]> escribió: > Perl: > @char=("A".."Z","a".."z",0..9); > do{print join("",@char[map{rand @char}(1..8)])}while(<>); > > !!generate passwords untill U press ctrl-z > > > > Python (from CookBook): > > from random import choice > import strin

Re: Random passwords generation (Python vs Perl) =)

On Mon, 29 Jan 2007 08:38:13 -0800, Szabolcs Nagy wrote: >>> why use xrange? range is faster and simpler for small ranges That is not true. >>> import timeit >>> timeit.Timer("range(50)", "").repeat() [2.8599629402160645, 2.8296849727630615, 2.8609859943389893] >>> timeit.Timer("xrange(50)", "")

Re: Random passwords generation (Python vs Perl) =)

On Mon, 29 Jan 2007 16:24:18 +0100, Laszlo Nagy wrote: > NoName írta: >> Hmmm.. >> In the Perl example password generates after user hit ENTER not >> continously like in Python you wrote... :) >> >> i want see various ways to generate passwords even if they some >> indirect like using BASE64 >>

Re: Random passwords generation (Python vs Perl) =)

WOW! :shock: in this case: while 1:i=__import__;print i('binascii').b2a_base64(i('os').urandom(6)),;raw_input() On 30 Янв., 04:06, "Szabolcs Nagy" <[EMAIL PROTECTED]> wrote: > > while > > 1:i=__import__;print''.join(i('random').choice(i('string').letters > > +'1234567890')for x in range(8)),;r

Re: Random passwords generation (Python vs Perl) =)

> while > 1:i=__import__;print''.join(i('random').choice(i('string').letters > +'1234567890')for x in range(8)),;raw_input() > while 1:i=__import__;r='random';print''.join(i(r).choice(i('string').letters +'1234567890')for x in`r`),;raw_input() even shorter: range -> `'random'` :) -- http://m

Re: Random passwords generation (Python vs Perl) =)

> If you really want a hack, here it is: > > while 1:print > ''.join(__import__('random').choice(__import__('string').letters+'1234567890') > for x in xrange(8)),;n=raw_input() > > This is a one-liner (though mail transmission may split it up), no > import statements. If someone can come up with an

Re: Random passwords generation (Python vs Perl) =)

NoName schrieb: > Perl: > @char=("A".."Z","a".."z",0..9); > do{print join("",@char[map{rand @char}(1..8)])}while(<>); > > !!generate passwords untill U press ctrl-z > > > > Python (from CookBook): > > from random import choice > import string > print ''.join([choice(string.letters+string.digit

Re: Random passwords generation (Python vs Perl) =)

> Is os.urandom cryptographically strong on all platforms? http://docs.python.org/lib/os-miscfunc.html "The returned data should be unpredictable enough for cryptographic applications, though its exact quality depends on the OS implementation." -- http://mail.python.org/mailman/listinfo/pyth

Re: Random passwords generation (Python vs Perl) =)

NoName írta: > Hmmm.. > In the Perl example password generates after user hit ENTER not > continously like in Python you wrote... :) > > i want see various ways to generate passwords even if they some > indirect like using BASE64 > I copied this from a recipe, I do not remember which one. I li

Re: Random passwords generation (Python vs Perl) =)

On Jan 29, 4:08 pm, Paul Rubin wrote: > "Szabolcs Nagy" <[EMAIL PROTECTED]> writes: > > file('/dev/urandom').read(6).encode('base64') > > (oneliner and without import sa op requested)Nice, though Un*x dependent > > (os.urandom is supposed to be portable). Is os.urando

Re: Random passwords generation (Python vs Perl) =)

"Szabolcs Nagy" <[EMAIL PROTECTED]> writes: > file('/dev/urandom').read(6).encode('base64') > (oneliner and without import sa op requested) Nice, though Un*x dependent (os.urandom is supposed to be portable). -- http://mail.python.org/mailman/listinfo/python-list

Re: Random passwords generation (Python vs Perl) =)

> If you don't mind possibly getting a few nonalphanumeric characters: > > import os,binascii > print binascii.b2a_base64(os.urandom(6)) what about file('/dev/urandom').read(6).encode('base64') (oneliner and without import as op requested) -- http://mail.python.org/mailman/listinfo/python-list

Re: Random passwords generation (Python vs Perl) =)

> If you don't mind possibly getting a few nonalphanumeric characters: > > import os,binascii > print binascii.b2a_base64(os.urandom(6)) what about file('/dev/urandom').read(6).encode('base64') (oneliner and without import sa op requested) -- http://mail.python.org/mailman/listinfo/python-list

Re: Random passwords generation (Python vs Perl) =)

Hmmm.. In the Perl example password generates after user hit ENTER not continously like in Python you wrote... :) i want see various ways to generate passwords even if they some indirect like using BASE64 thanks all p.s. sorry for my eng ;) -- http://mail.python.org/mailman/listinfo/python-

Re: Random passwords generation (Python vs Perl) =)

"Paul McGuire" <[EMAIL PROTECTED]> writes: > from random import choice Security note: if you're trying to generate real passwords this way, you're better off using os.urandom instead of the random module to generate the random numbers. The random module's results are supposed to be statistically

Re: Random passwords generation (Python vs Perl) =)

NoName wrote: > Perl: > @char=("A".."Z","a".."z",0..9); > do{print join("",@char[map{rand @char}(1..8)])}while(<>); > > !!generate passwords untill U press ctrl-z > > > > Python (from CookBook): > > from random import choice > import string > print ''.join([choice(string.letters+string.digits)

Re: Random passwords generation (Python vs Perl) =)

On Jan 28, 10:58 pm, "NoName" <[EMAIL PROTECTED]> wrote: > Perl: > @char=("A".."Z","a".."z",0..9); > do{print join("",@char[map{rand @char}(1..8)])}while(<>); > > !!generate passwords untill U press ctrl-z > > Python (from CookBook): > > from random import choice > import string > print ''.join([ch

Re: Random passwords generation (Python vs Perl) =)

"NoName" <[EMAIL PROTECTED]> writes: > from random import choice > import string > print ''.join([choice(string.letters+string.digits) for i in > range(1,8)]) > > !!generate password once :( > > who can write this smaller or without 'import'? If you don't mind possibly getting a few nonalphanum

Re: Random passwords generation (Python vs Perl) =)

2007/1/29, Leif K-Brooks <[EMAIL PROTECTED]>: NoName wrote: > from random import choice > import string > print ''.join([choice(string.letters+string.digits) for i in > range(1,8)]) > > !!generate password once :( So add a while true: line. > who can write this smaller or without 'import'?

Re: Random passwords generation (Python vs Perl) =)

NoName wrote: > from random import choice > import string > print ''.join([choice(string.letters+string.digits) for i in > range(1,8)]) > > !!generate password once :( So add a while true: line. > who can write this smaller or without 'import'? Why are those your goals? -- http://mail.python.

Random passwords generation (Python vs Perl) =)

Perl: @char=("A".."Z","a".."z",0..9); do{print join("",@char[map{rand @char}(1..8)])}while(<>); !!generate passwords untill U press ctrl-z Python (from CookBook): from random import choice import string print ''.join([choice(string.letters+string.digits) for i in range(1,8)]) !!generate pass

Re: python vs perl lines of code

on Friday, May 19, 2006 11:26 PM [EMAIL PROTECTED] wrote: | All I would ask is what objective evidence does either of actually | have? How can you know? What is a fair way to even count line | numbers? From there how do we begin to objectively measure software | quality? That's why this discu

Re: python vs perl lines of code

"George Sakkis" <[EMAIL PROTECTED]> wrote: > Oh, I think I get it now. Spamvertizing _one_ site is worth your > host's subscription; doing it for _four_ sites at your signature is > perfectly ok though. Do yourself and many others a favour before you post again, educate yourself on Usenet. It mi

Re: python vs perl lines of code

John Bokma wrote: > Funny though, how you have a problem with a thread that side steps to Perl > only for 4 or 5 postings, but have no problem with a hit & run post in 5 > groups to spamvertize a site. > > Have fun with the pondering btw. > > -- > John MexIT: http://

Re: python vs perl lines of code

"George Sakkis" <[EMAIL PROTECTED]> wrote: > John Bokma wrote: >> "George Sakkis" <[EMAIL PROTECTED]> wrote: [ Xah Lee ] >> [1] He is looking for another hoster btw. > > This must feel really empowering huh ? I am sure I've had quite some help. Also, you made quite a mistake. I have 0 power,

Re: python vs perl lines of code

John Bokma wrote: > "George Sakkis" <[EMAIL PROTECTED]> wrote: > > > John Bokma wrote: > > > >> "George Sakkis" <[EMAIL PROTECTED]> wrote: > >> > >> > Not trying to be as ass, but can you take this offline or at least in > >> > a perl newsgroup ? Arguing on a particular fact or speculation about >

Re: python vs perl lines of code

"George Sakkis" <[EMAIL PROTECTED]> wrote: > John Bokma wrote: > >> "George Sakkis" <[EMAIL PROTECTED]> wrote: >> >> > Not trying to be as ass, but can you take this offline or at least in >> > a perl newsgroup ? Arguing on a particular fact or speculation about >> > the perl community is rather

Re: python vs perl lines of code

John Bokma wrote: > "George Sakkis" <[EMAIL PROTECTED]> wrote: > > > Not trying to be as ass, but can you take this offline or at least in > > a perl newsgroup ? Arguing on a particular fact or speculation about > > the perl community is rather unproductive and offtopic for a python > > newsgroup.

Re: python vs perl lines of code

Larry Bates wrote: > Sorry, I don't buy this. I can write REALLY short programs that don't > handle exceptions, don't provide for logging for debugging purposes, don't > allow > for future growth, etc. I find that 60% of my code has nothing to do with > the actual algorithm or function I'm tryin

Re: python vs perl lines of code

George Sakkis wrote: > Not trying to be as ass, but can you take this offline or at least in a > perl newsgroup ? Arguing on a particular fact or speculation about the > perl community is rather unproductive and offtopic for a python > newsgroup. No offense taken. It's definitely OT. I left it

Re: python vs perl lines of code

"George Sakkis" <[EMAIL PROTECTED]> wrote: > Not trying to be as ass, but can you take this offline or at least in > a perl newsgroup ? Arguing on a particular fact or speculation about > the perl community is rather unproductive and offtopic for a python > newsgroup. Use a real Usenet client, an

Re: python vs perl lines of code

Edward Elliott <[EMAIL PROTECTED]> wrote: > You lecturing people on pissing contests, that's rich. Nice way to > duck the issue and sound like a winner. Then you've missed what a discussion really is. It's not about winning, it's about learning. Sadly you missed that point. > Wake me when you

Re: python vs perl lines of code

Edward Elliott wrote: > This is just anecdotal, but I still find it interesting. Take it for what > it's worth. I'm interested in hearing others' perspectives, just please > don't turn this into a pissing contest. > > I'm in the process of converting some old perl programs to python. These > pr

Re: python vs perl lines of code

Edward Elliott wrote: > John Bokma wrote: > > > Edward Elliott <[EMAIL PROTECTED]> wrote: > > > >> A little out-of-order execution seems useful here. ;) > > > > No, not interested in a pissing contest. Your statement that the Perl > > community encourages importing is *encouraged* (over using OO w

Re: python vs perl lines of code

John Bokma wrote: > Edward Elliott <[EMAIL PROTECTED]> wrote: > >> A little out-of-order execution seems useful here. ;) > > No, not interested in a pissing contest. Your statement that the Perl > community encourages importing is *encouraged* (over using OO without > importing) is false. The c

Re: python vs perl lines of code

Edward Elliott <[EMAIL PROTECTED]> wrote: > A little out-of-order execution seems useful here. ;) No, not interested in a pissing contest. Your statement that the Perl community encourages importing is *encouraged* (over using OO without importing) is false. -- John

Re: python vs perl lines of code

A little out-of-order execution seems useful here. ;) John Bokma wrote: > Edward Elliott <[EMAIL PROTECTED]> wrote: >> I can readily believe that the "community" frequenting the newsgroups, >> mailing lists, and blogs don't encourage it anymore. But that's a >> tiny fraction of all perl programm

Re: python vs perl lines of code

Edward Elliott <[EMAIL PROTECTED]> wrote: > John Bokma wrote: > >> Edward Elliott <[EMAIL PROTECTED]> wrote: >> > like "from X import *" which are generally frowned on in python > while 'use MOD qw(id)' is encouraged in perl. Not by me, and I doubt it is in general. >>> >>> W

Re: python vs perl lines of code

John Bokma wrote: > Edward Elliott <[EMAIL PROTECTED]> wrote: > like "from X import *" which are generally frowned on in python while 'use MOD qw(id)' is encouraged in perl. >>> >>> Not by me, and I doubt it is in general. >> >> Well it's all over the Perl Cookbook. > > Yeah, sure, a

Re: python vs perl lines of code

Edward Elliott <[EMAIL PROTECTED]> wrote: > John Bokma wrote: > >> Edward Elliott <[EMAIL PROTECTED]> wrote: >> >>> The question is how to count explicit names like module.class.func; >>> should that be 1 identifier or 3? Counting as 3 would reward things >>> like "from X import *" which are ge

Re: python vs perl lines of code

John Bokma wrote: > Edward Elliott <[EMAIL PROTECTED]> wrote: > >> The question is how to count explicit names like module.class.func; >> should that be 1 identifier or 3? Counting as 3 would reward things >> like "from X import *" which are generally frowned on in python while >> 'use MOD qw(id

Re: python vs perl lines of code

Edward Elliott <[EMAIL PROTECTED]> wrote: > The question is how to count explicit names like module.class.func; > should that be 1 identifier or 3? Counting as 3 would reward things > like "from X import *" which are generally frowned on in python while > 'use MOD qw(id)' is encouraged in perl.

Re: python vs perl lines of code

[EMAIL PROTECTED] wrote: > But first things first... and this one I think is solvable - their has > got to be an equitable way to count how much code was written - maybe > it isn't lines maybe it is > ANd that's it - not can we make a qualitative > statement beyond that. But simply can we q

Re: python vs perl lines of code

> Yes, like the shorter version might be overlooking many real world > situations and is naive code. As for generalization, if you bet that the > shorter one is later written, that's to me a generalization. I agree that > there is a change that after reexamining the code, and algorithm can be > wr

Re: python vs perl lines of code

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > John Bokma wrote: >> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: >> >> > But if a 1 person, using 1 language, with the same set of tools >> > withing a 3 month period implements the same algo without bugs - >> > I'll bet you the shorter one was t

Re: python vs perl lines of code

John Bokma wrote: > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > But if a 1 person, using 1 language, with the same set of tools withing > > a 3 month period implements the same algo without bugs - I'll bet you > > the shorter one was theone written second. > > You might lose that bet very

Re: Quoting relevant material for response (was: Re: python vs perl lines of code)

OT, sort of, but... [EMAIL PROTECTED] wrote: >If that > quoting mechanism is available on the web interface and I haven't found > it - I'd love to know how to use it. Click "show options" and THEN hit "reply". It's a bit counterintuitive, but the entire message to which you reply is then shown.

Re: python vs perl lines of code

Terry Hancock wrote: > Edward Elliott wrote: > >>For inquiries into real-world code, it's enough to >>believe that I'm not lying >> > So I don't make assumptions about people without some kind > of evidence. There *are* plenty of "bad guys" out there, so > one learns both to have a thick skin and

Re: python vs perl lines of code

Edward Elliott wrote: >For inquiries into real-world code, it's enough to >believe that I'm not lying > Yeah, well, this is the internet -- I've gotten emails trying to sell me ex-soviet rocket-launchers and child porn.* So I don't make assumptions about people without some kind of evidence. Ther

Re: python vs perl lines of code

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > But if a 1 person, using 1 language, with the same set of tools withing > a 3 month period implements the same algo without bugs - I'll bet you > the shorter one was theone written second. You might lose that bet very often. I see often that additi

Re: Quoting relevant material for response (was: Re: python vs perl lines of code)

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > quoting mechanism is available on the web interface and I haven't found > it - I'd love to know how to use it. http://groups.google.com/support/bin/answer.py?answer=14213 > Also i use the threaded view on > the web client, so I have little trouble

  1   2   >