[31311] in Perl-Users-Digest
Perl-Users Digest, Issue: 2556 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 17 03:09:44 2009
Date: Mon, 17 Aug 2009 00:09:08 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 17 Aug 2009 Volume: 11 Number: 2556
Today's topics:
Re: end-of-line conventions <willem@stack.nl>
Re: end-of-line conventions sln@netherlands.com
Re: end-of-line conventions <jurgenex@hotmail.com>
Re: end-of-line conventions <hjp-usenet2@hjp.at>
Re: end-of-line conventions <ben@morrow.me.uk>
Re: end-of-line conventions <ben@morrow.me.uk>
FDA Issues Rules for Early Access to Experimental Drugs <asim.ssat@gmail.com>
IOI 2009 <rvtol+usenet@xs4all.nl>
Multithreaded Perl application crash with cURL and HTTP <jagathishp@gmail.com>
Re: Multithreaded Perl application crash with cURL and <jagathishp@gmail.com>
Re: Multithreaded Perl application crash with cURL and <xhoster@gmail.com>
python doc available in emacs info format? <xahlee@gmail.com>
Re: revisiting web development in Perl...where to start <nat.k@gm.ml>
Re: revisiting web development in Perl...where to start <thegist@nospam.net>
Re: Searching for the first komma in a sentence <massion@gmx.de>
Re: simple socket client-server interaction works on C, <mark_galeck_spam_magnet@yahoo.com>
simple socket client-server interaction works on C, but <mark_galeck_spam_magnet@yahoo.com>
Re: simple socket client-server interaction works on C, <alexander.bartolich@gmx.at>
Re: simple socket client-server interaction works on C, <hjp-usenet2@hjp.at>
Re: Social problems of Python doc [was Re: Python docs <xahlee@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 16 Aug 2009 07:59:33 +0000 (UTC)
From: Willem <willem@stack.nl>
Subject: Re: end-of-line conventions
Message-Id: <slrnh8ff35.16nq.willem@turtle.stack.nl>
Jürgen Exner wrote:
) But then how come that the file created by this little program
)
) open FOO, ">" , "foo";
) print FOO "k\n" x 20;
) close FOO;
)
) is 60 bytes long instead of 40 as would to be expected if the 'k' and
) the "\n" each were only one byte long?
Because the I/O routine translates the newlines. Just like in C.
Perl probably even uses the C I/O library to write to the file.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Sun, 16 Aug 2009 02:06:22 -0700
From: sln@netherlands.com
Subject: Re: end-of-line conventions
Message-Id: <luif859lddgpqkeht8k062a099qm4e3jeg@4ax.com>
On Sun, 16 Aug 2009 07:59:33 +0000 (UTC), Willem <willem@stack.nl> wrote:
>Jürgen Exner wrote:
>) But then how come that the file created by this little program
>)
>) open FOO, ">" , "foo";
>) print FOO "k\n" x 20;
>) close FOO;
>)
>) is 60 bytes long instead of 40 as would to be expected if the 'k' and
>) the "\n" each were only one byte long?
>
>Because the I/O routine translates the newlines. Just like in C.
>Perl probably even uses the C I/O library to write to the file.
>
>
>SaSW, Willem
There are heuristics in Windows programs. Just look at Word, a Microsoft
offering.
-sln
------------------------------
Date: Sun, 16 Aug 2009 09:24:12 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: end-of-line conventions
Message-Id: <ufcg85lmd08us56ifsifptvlvd2og90qha@4ax.com>
Willem <willem@stack.nl> wrote:
>Jürgen Exner wrote:
>) But then how come that the file created by this little program
>)
>) open FOO, ">" , "foo";
>) print FOO "k\n" x 20;
>) close FOO;
>)
>) is 60 bytes long instead of 40 as would to be expected if the 'k' and
>) the "\n" each were only one byte long?
>
>Because the I/O routine translates the newlines.
So, I guess you are saying that there is a context where "\n" does mean
two characters, contrary to Ben's statement:
"\n" can *never* mean "\015\012"
jue
------------------------------
Date: Sun, 16 Aug 2009 19:15:56 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: end-of-line conventions
Message-Id: <slrnh8gfmc.1jr.hjp-usenet2@hrunkner.hjp.at>
On 2009-08-16 16:24, Jürgen Exner <jurgenex@hotmail.com> wrote:
> Willem <willem@stack.nl> wrote:
>>Jürgen Exner wrote:
>>) But then how come that the file created by this little program
>>)
>>) open FOO, ">" , "foo";
>>) print FOO "k\n" x 20;
>>) close FOO;
>>)
>>) is 60 bytes long instead of 40 as would to be expected if the 'k' and
>>) the "\n" each were only one byte long?
>>
>>Because the I/O routine translates the newlines.
>
> So, I guess you are saying that there is a context where "\n" does mean
> two characters, contrary to Ben's statement:
> "\n" can *never* mean "\015\012"
"\n" is *always* a string containing one character (\x{000A} on most
platforms including Windows). However, when this character is written to
a file handle, an I/O layer may convert this in any way it pleases. It
may just pass it through unchanged, it may convert it into a sequence of
two bytes (e.g. "\x0D\x0A"), or it might even pad all lines to a fixed
length with spaces and not write any new line characters at all.
On input the reverse transformation should be performed.
hp
------------------------------
Date: Sun, 16 Aug 2009 18:18:42 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: end-of-line conventions
Message-Id: <ikrll6-112.ln1@osiris.mauzo.dyndns.org>
Quoth Jürgen Exner <jurgenex@hotmail.com>:
> Willem <willem@stack.nl> wrote:
> >Jürgen Exner wrote:
> >) But then how come that the file created by this little program
> >)
> >) open FOO, ">" , "foo";
> >) print FOO "k\n" x 20;
> >) close FOO;
> >)
> >) is 60 bytes long instead of 40 as would to be expected if the 'k' and
> >) the "\n" each were only one byte long?
> >
> >Because the I/O routine translates the newlines.
>
> So, I guess you are saying that there is a context where "\n" does mean
> two characters, contrary to Ben's statement:
> "\n" can *never* mean "\015\012"
No. "\n" means "\012". Your FOO filehandle has a :crlf layer on it,
which translates "\012" to "\015\012" on output. You will get exactly
the same result if you run
open FOO, ">", "foo";
print FOO "k\012" x 20;
close FOO;
so the CRLF newlines have nothing to do with your use of "\n".
Ben
------------------------------
Date: Sun, 16 Aug 2009 18:24:22 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: end-of-line conventions
Message-Id: <6vrll6-112.ln1@osiris.mauzo.dyndns.org>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <h2qjl6-4ht2.ln1@osiris.mauzo.dyndns.org>, on 08/15/2009
> at 11:39 PM, Ben Morrow <ben@morrow.me.uk> said:
>
> >"\n" can *never* mean "\015\012":
>
> Are you a betting man.
Not usually :).
> >"\n" can *never* mean "\015\012": on Win32 it means "\012", just as on
> >Unix. If "\n" was more than one byte/character (take your pick) long,
> >practically everything would break.
>
> Wrong; \n is two bytes on DOS and OS/2, and AFAIK nothing breaks except
> cgi.pm.
No it's not, at least not as far as Perl is concerned. Files have CRLF
line endings, but they are (by default) translated into LF line endings
when the file is read. If you have a file containing
fooCRLF
and you read a line with
open my $FOO, "<", "foo";
my $foo = <$FOO>;
then $foo will be four bytes long, not five.
> >AFAIK the only platforms where "\n" ne "\012" are Mac OS Classic and
> >the EBCDIC platforms, both of which are obsolete as far as Perl is
> >concerned.
>
> When there's ongoing maintenance then it's a rather lively corpse.
Perl is no longer maintained for Mac OS Classic or the EBCDIC platforms.
I did not mean to imply they were obsolete for other purposes.
Ben
------------------------------
Date: Sun, 16 Aug 2009 07:03:04 -0700 (PDT)
From: asim malik <asim.ssat@gmail.com>
Subject: FDA Issues Rules for Early Access to Experimental Drugs
Message-Id: <ed8cab1c-b802-4c8b-951c-4bc2982e7836@g10g2000yqh.googlegroups.com>
Patients who suffer from serious and fatal illnesses may be granted
early access to drugs that are still in the experimental stage. By
clarifying the rules for granting patients www.hn786.blogspot.com
------------------------------
Date: Sun, 16 Aug 2009 12:53:28 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: IOI 2009
Message-Id: <4a87e529$0$188$e4fe514c@news.xs4all.nl>
Nice set of Perl golf exercises:
http://www.ioi2009.org/GetResource?id=1969
Idea: Get Perl accepted as one of the allowed languages for these contests.
--
Ruud
------------------------------
Date: Sun, 16 Aug 2009 09:41:15 -0700 (PDT)
From: Jag <jagathishp@gmail.com>
Subject: Multithreaded Perl application crash with cURL and HTTPS
Message-Id: <562e2544-4633-4058-9c2e-42cff6d9cde7@f37g2000yqn.googlegroups.com>
Hi,
I use WWW::Curl::Easy module to use cURL in my perl application.
My application has a lot of threads and each of them request pages
through HTTPS.
After some time of running, the application crashes.
Looking at the "multithreading" hints in the curl website, I need to
set some
callbacks to get it work correctly.
http://curl.haxx.se/libcurl/c/libcurl-tutorial.html#Multi-threading
Has anyone done such a thing for perl?
Thanks.
UNT,
Jag
------------------------------
Date: Sun, 16 Aug 2009 09:43:04 -0700 (PDT)
From: Jag <jagathishp@gmail.com>
Subject: Re: Multithreaded Perl application crash with cURL and HTTPS
Message-Id: <e3958388-80f2-4dc6-98df-97eefa2b2e91@c1g2000yqi.googlegroups.com>
Oh. I am using OpenSSL for handling HTTPS.
UNT,
Jag
------------------------------
Date: Sun, 16 Aug 2009 10:24:42 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: Multithreaded Perl application crash with cURL and HTTPS
Message-Id: <4a884023$0$30307$ed362ca5@nr5-q3a.newsreader.com>
Jag wrote:
> Hi,
>
> I use WWW::Curl::Easy module to use cURL in my perl application.
> My application has a lot of threads and each of them request pages
> through HTTPS.
Why not use WWW::Curl::Multi instead of doing your own threading with on
top of WWW::Curl::Easy?
Xho
------------------------------
Date: Sun, 16 Aug 2009 21:43:48 -0700 (PDT)
From: Xah Lee <xahlee@gmail.com>
Subject: python doc available in emacs info format?
Message-Id: <dd8f5914-ba06-45c2-b773-7d25914e0ea9@c2g2000yqi.googlegroups.com>
btw, is there still info format for python doc?
i feel kinda sad that emacs info format has pretty much been
deprecated over the past decade. About a decade ago, you still will
see now and then people asking for emacs info format of docs (was the
days of perl). Today, one don't hear of it.
Part of this is due to emacs cult problem. See:
=E2=80=A2 Emacs Modernization
http://xahlee.org/emacs/emacs_modernization.html
=E2=80=A2 Emacs Should Adopt HTML To Replace Texinfo
http://xahlee.org/emacs/modernization_html_vs_info.html
=E2=80=A2 Language, Purity, Cult, and Deception
http://xahlee.org/UnixResource_dir/writ/lang_purity_cult_deception.html
Xah
=E2=88=91 http://xahlee.org/
=E2=98=84
On Dec 11 2008, 6:56 am, Matthias <oron...@gmail.com> wrote:
> Xah Lee <xah...@gmail.com> writes:
> > in programing elisp in emacs, i can press =E2=80=9CCtrl+h f=E2=80=9D to=
lookup
> > the doc for the function under cursor. is there such facility
> > when coding in perl, python, php?
>
> Yes, try C-h S (or similarly <f1> S):
>
> (info-lookup-symbol SYMBOL &optional MODE) Display the
> definition of SYMBOL, as found in the relevant manual. When this
> command is called interactively, it reads SYMBOL from the
> minibuffer.
>
> Note that `the relevant manual' means an info file. With recent
> emacsen on an Ubuntu distro, python arrives with info files and
> everything is well configured. It also works with bash, latex, perl,
> scheme, elisp, awk, texinfo, makefile, libc, or any info file with an
> index.
> --
> Matthias
------------------------------
Date: Sun, 16 Aug 2009 12:55:04 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: revisiting web development in Perl...where to start?
Message-Id: <suZhm.143562$Qg6.137507@newsfe14.iad>
sln@netherlands.com wrote:
> On Fri, 14 Aug 2009 07:09:43 -0700, merlyn@stonehenge.com (Randal L.
> Schwartz) wrote:
>
>>>>>>> "TheGist" == TheGist <thegist@nospam.net> writes:
>>
>>TheGist> Surely CGIs are no longer widely used, right?
>>
>>Please don't confuse the CGI technology with the use of Perl.
>>
>>CGI technology (which can be used with many different languages) is
>>still perfectly fine for websites needing under a dozen dynamic pages
>>a minute, which is 95% of the market.
>
> You lost me.
That's not difficult.
> Its got to be the CGI interface to a perl script that
> apparently slows the pace to what 12 dynamic pages/minute? Because I
> could easily generate 100's per second dynamic pages in Perl.
>
> The cgi modules to perl are pretty standard, no? Its not perl that
> would slow page generation, must be the cgi.
>
> Glad to give any demonstrations on page generation/sec in a perl
> program.
>
> -sln
Yes, CGI spawns overhead, not Perl, and CGI is slow (compared to dso or
core modules), but it's not so slow that it's really that big of a
deal, unless you have a massive amount of traffic. Good code in any
language for CGI is still better than using a web server module like
mod_perl if the code is bad or has memory leaks. But, in mod_perl, it's
going to handle more traffic if the code is good. Yes, you should be
able to have a more than 12 dynamic page requests per minute, maybe he
meant per second.
------------------------------
Date: Mon, 17 Aug 2009 00:08:50 -0400
From: TheGist <thegist@nospam.net>
Subject: Re: revisiting web development in Perl...where to start?
Message-Id: <27311$4a88d7d4$48fb6746$15378@news.eurofeeds.com>
Randal L. Schwartz wrote:
>>>>>> "TheGist" == TheGist <thegist@nospam.net> writes:
>
> TheGist> Surely CGIs are no longer widely used, right?
>
> Please don't confuse the CGI technology with the use of Perl.
>
> CGI technology (which can be used with many different languages) is still
> perfectly fine for websites needing under a dozen dynamic pages a minute, which
> is 95% of the market.
>
> Perl is most often these days used with mod_perl (Perl inside Apache), for
> both large legacy apps and even some "green shoots" that I'm aware of.
>
> It's far from dead, or outdated. It's the mainstream web. In fact, dynamic
> languages are seeing a resurgence these days, as the promises made by the Java
> Server folks are coming up a bit hollow, and people want to get back to rapid
> (and sane :) development models.
I think it is pretty awesome that one of the people
responding to my CGI thread is the author of one of the
books I
used to write my first CGI scripts!
Chapter 19 of the Second Edition of Learning Perl
helped me immensely when I was trying this stuff out
ten years ago.
Anyway, I think now is a good time to look into Catalyst
and Mason.
Based on this thread and other readings I do now
see how plain CGI scripts are still perfectly fine. ;)
------------------------------
Date: Sun, 16 Aug 2009 09:58:05 -0700 (PDT)
From: Francois Massion <massion@gmx.de>
Subject: Re: Searching for the first komma in a sentence
Message-Id: <d7d07276-4ce6-403b-8484-12b6a6f345fe@b15g2000yqd.googlegroups.com>
On 15 Aug., 22:09, Tad J McClellan <ta...@seesig.invalid> wrote:
> Francois Massion <mass...@gmx.de> wrote:
>
> > I am trying to modify the pattern of a sentence with a komma
> > separating different sections of the sentence. I would like to put at
> > the end of the sentence what is at the beginning of the sentence.
>
> > Current pattern: word1 word2 word3, word4, word5 word6
> > Expected pattern: word4, word5 word6, word1 word2 word3
>
> > Replacement expression:
>
> > $sentence =3D~ s/(.*)(,)(.*)/$3$2$1/;
>
> > Actual result: =A0word5 word6,word1 word2 word3, word4
>
> > Apparently Perl doesn't start at the beginning of the sentence but
> > searches backwards.
>
> No, perl _does_ start at the beginning, but it has 2 possible
> matches for the first .*
>
> =A0 =A0 word1 word2 word3, word4, word5 word6
> =A0 =A0 ^^^^^^^^^^^^^^^^^
> =A0 =A0 ^^^^^^^^^^^^^^^^^^^^^^^^
>
> It must choose one. By default it chooses the longest one (it is greedy).
>
> > This would be the reason for this result.
>
> Greed would be the reason for result you are getting.
>
> > tell Perl to start searching for the first komma in the sentence. How
> > can I do it?
>
> =A0 =A0 perldoc -q greedy
>
> =A0 =A0 =A0 =A0 What does it mean that regexes are greedy? =A0How can I g=
et around it?
>
> --
> Tad McClellan
> email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"- Zit=
ierten Text ausblenden -
>
> - Zitierten Text anzeigen -
It was as simple as that! Thanks for the help. It works perfectly.
$sentence =3D~ s/(.*?)(,)(.*)/$3$2$1/;
------------------------------
Date: Sun, 16 Aug 2009 11:59:54 -0700 (PDT)
From: Mark_Galeck <mark_galeck_spam_magnet@yahoo.com>
Subject: Re: simple socket client-server interaction works on C, but the analogous code does not work with Perl
Message-Id: <213c1904-aa19-4d7d-bfee-0d3038258472@32g2000yqj.googlegroups.com>
thank you Peter and Alexander, this makes perfect sense
------------------------------
Date: Sun, 16 Aug 2009 07:50:46 -0700 (PDT)
From: Mark_Galeck <mark_galeck_spam_magnet@yahoo.com>
Subject: simple socket client-server interaction works on C, but the analogous code does not work with Perl
Message-Id: <dfd4c3e8-86f5-4c08-a1ac-113b1b9bdaae@a26g2000yqn.googlegroups.com>
Hello,
here is a simplest possible (I think), socket client-server code in
Perl. You start the server first, it listens, client starts, sends
the server a message, server replies back, that's it. The exact
analogous code to this, written in C, works as expected, but here in
Perl, not (both run under the latest Ubuntu). So I think, I
understand how the sockets work, I just don't understand how Perl
works.
Under Perl, the server just prints "accepted", but never gets any
messages from the client. Curiously, if I comment out the client
reading from server after sending, then everything else is fine, the
server gets the message and both exit.
What is going on?? Thank you for your insights! Mark
serv.pl:
use Socket;
socket(SERVER, PF_INET, SOCK_STREAM, getprotobyname('tcp'));
bind(SERVER, sockaddr_in(3000, inet_aton("127.0.0.1")));
listen(SERVER, 1);
accept(CLIENT, SERVER);
print "accepted\n";
$_ = <CLIENT>;
print "read from client:\n";
print ;
print CLIENT "foobar\n";
close(CLIENT);
close(SERVER);
client.pl:
use Socket;
socket(SERVER, PF_INET, SOCK_STREAM, getprotobyname('tcp'));
connect(SERVER, sockaddr_in(3000, inet_aton("127.0.0.1")))
or die "WHOA! could not connect";
print SERVER "foo\n";
$_ = <SERVER>; #only if I comment this line out, does the server get
the above message!!
print "read from server:\n";
print ;
close(SERVER);
------------------------------
Date: Sun, 16 Aug 2009 15:16:58 +0000 (UTC)
From: Alexander Bartolich <alexander.bartolich@gmx.at>
Subject: Re: simple socket client-server interaction works on C, but the analogous code does not work with Perl
Message-Id: <h697ta$smh$1@news.albasani.net>
Mark_Galeck wrote:
> [...]
> Under Perl, the server just prints "accepted", but never gets any
> messages from the client. Curiously, if I comment out the client
> reading from server after sending, then everything else is fine, the
> server gets the message and both exit.
>
> What is going on?? Thank you for your insights! Mark
You are using buffered I/O without explicit flush.
http://perldoc.perl.org/perlfaq5.html#How-do-I-flush/unbuffer-an-output-filehandle?--Why-must-I-do-this?
The simplies fix of your program (measured in lines of code) is
this line:
binmode(SERVER, ":unix");
--
Brüder, in die Tonne die Freiheit,
Brüder, ein Stoppschild davor.
Egal was die Schwarzen Verlangen
Rufen wir: Ja! Brav im Chor.
------------------------------
Date: Sun, 16 Aug 2009 17:26:06 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: simple socket client-server interaction works on C, but the analogous code does not work with Perl
Message-Id: <slrnh8g98f.gd.hjp-usenet2@hrunkner.hjp.at>
On 2009-08-16 14:50, Mark_Galeck <mark_galeck_spam_magnet@yahoo.com> wrote:
> here is a simplest possible (I think), socket client-server code in
> Perl. You start the server first, it listens, client starts, sends
> the server a message, server replies back, that's it. The exact
> analogous code to this, written in C, works as expected, but here in
> Perl, not (both run under the latest Ubuntu). So I think, I
> understand how the sockets work, I just don't understand how Perl
> works.
>
> Under Perl, the server just prints "accepted", but never gets any
> messages from the client. Curiously, if I comment out the client
> reading from server after sending, then everything else is fine, the
> server gets the message and both exit.
>
> What is going on?? Thank you for your insights! Mark
>
[...]
> client.pl:
>
> use Socket;
>
>
>
> socket(SERVER, PF_INET, SOCK_STREAM, getprotobyname('tcp'));
>
>
> connect(SERVER, sockaddr_in(3000, inet_aton("127.0.0.1")))
>
> or die "WHOA! could not connect";
At this point, the file handle SERVER is buffered, so ...
> print SERVER "foo\n";
This will *not* send "foo\n" to the server, it will only put it into the
buffer.
> $_ = <SERVER>; #only if I comment this line out, does the server get
> the above message!!
Now you wait for a message from the server. But you haven't sent a
message to the server yet, so the server is waiting for the client, too.
This is called a deadlock.
> print "read from server:\n";
>
> print ;
>
>
> close(SERVER);
The close would flush the buffer (and send everything in it to the
server), but that line is never reached.
See the question "How do I flush/unbuffer an output filehandle? Why
must I do this?" in the FAQ for a solution.
Or just use IO::Socket objects instead of plain file handles. They have
autoflush turned on by default (the FAQ is out-of-date in this respect).
hp
------------------------------
Date: Sun, 16 Aug 2009 23:50:27 -0700 (PDT)
From: Xah Lee <xahlee@gmail.com>
Subject: Re: Social problems of Python doc [was Re: Python docs disappointing]
Message-Id: <a8d7ce5b-184b-4b01-ac19-3f6a481dd882@e27g2000yqm.googlegroups.com>
On Aug 12, 12:15 pm, Raymond Hettinger <pyt...@rcn.com> wrote:
> [Xah Lee]
>
> > i've wrote several articles about this issue, total time spend on this
> > is probably more than 2 months full-time work. See:
>
> > =E2=80=A2 Python Documentation Problems
> > http://xahlee.org/perl-python/python_doc_index.html
>
> I just read you post. You did devote a substantial amount of time
> to the project. Some of your criticisms are valid. Wish you had
> posted patches, I think many of them would have been accepted.
>
> Since you wrote this a few years ago, many examples have
> been added to the docs and more are forthcoming.
>
> > I often receive thank you emails for 2 particular articles, which are
> > most frequently google searched as indicated by my weblog:
>
> > =E2=80=A2 Python Doc Problem Example: gzip
> > http://xahlee.org/perl-python/python_doc_gzip.html
>
> > =E2=80=A2 Python Doc Problem Example: sort()
> > http://xahlee.org/perl-python/python_doc_sort.html
>
> > =E2=80=A2 Sorting in Python and Perl
> > http://xahlee.org/perl-python/sort_list.html
>
> Some are the criticisms are valid; others seem off-base.
>
> Here are a few thoughts on list.sort() for those who are interested:
>
> * The key=3D and reversed=3D parameters are not intended for special
> cases, leaving cmp=3D for the general case. They were intended to
> be full replacements. In Python3.x, the cmp function is gone.
>
> * The interaction of the key=3D and cmp=3D functions can be made to
> interact (the key function is first applied to every element and
> the cmp function then gets applied to the results of the key
> function). This isn't a normal or intended use case, so the docs
> don't delve into the subject.
>
> * The reversed parameter does more than list.sort() followed by
> list.reverse(). It also preserves stability in the event of equal
> keys:
>
> >>> sorted([(1,2), (1,3)], key=3Ditemgetter(0), reverse=3DTrue)
> [(1,2), (1,3)]
>
> So it was not correct to say that the following are equivalent:
>
> li.sort(lambda x, y: cmp(x[1],y[1]), reverse=3DTrue)
> li.sort(lambda x, y: cmp(y[1],x[1]))
>
> * We should link the sorted() and list.sort() docs to the
> sorting how-to (with a fuller discussion on the art of sorting
> including a discussion of operator.itemgetter() and
> operator.attrgetter() which were designed to work with the key=3D
> parameter.
> > Here are a few thoughts on list.sort() for those who are interested:
>
> After one more reading of Xah Lee's posts on the documentation for
> sort,
> here are couple more thoughts:
>
> * The reason that list.sort() allows None for the cmp parameter is not
> so that you can write list.sort(None). It was put there to make it
> easier for people writing function definitions where the cmp function
> is a possible argument:
>
> def sort_and_chop(seq, maxlen, cmp=3DNone):
> s =3D seq[:]
> s.sort(cmp) # needs to accept None as a possible
> argument
> return s[:maxlen]
>
> * The reason for implementing the key=3D parameter had nothing to do
> with limitations of Python's compiler. Instead, it was inspired by
> the
> decorate-sort-undecorate pattern.
Hi Raymond,
thanks for the many points. They are informative, some i disagree, but
it's getting into detail. I don't know python 3.0, will have to look
into its sort in the future.
This part i don't particular agree:
> * The reason for implementing the key=3D parameter had nothing to do
> with limitations of Python's compiler. Instead, it was inspired by
> the
> decorate-sort-undecorate pattern.
The decorate-sort-undecorate pattern is a compiler limitation, for
most of today's langs. I'm not sure, but i think some of the fancy
functional langs automatically detect such and optimize it away, to
various degrees.
... my criticism is usually written in a style catered to irritate a
particular class of coder i call tech geekers (they think of themselfs
with their idiotic term =E2=80=9Chackers=E2=80=9D). So, parts are exaggerat=
ed. It'd be
more clear to say, that the reason for python's =E2=80=9Ckey=E2=80=9D, and =
as a
=E2=80=9Csolution=E2=80=9D or need of the decorate-sort-undecorate issue, c=
an be
attributed to the current state of the art of popular imperative
language's compilers (induced by such lang's semantics).
again, i haven't studied python 3.0 to see what it has changed with
sort, and thanks for the informative post. I find it intriguing that
it doesn't have =E2=80=9Ccmp=E2=80=9D anymore as you say.... maybe when i a=
ctually
study it and i'll come away with rage and rants. LOL.
Xah
=E2=88=91 http://xahlee.org/
=E2=98=84
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2556
***************************************
