Perl 5 Porters Weekly: October 22-October 28, 2012

Welcome to Perl 5 Porters Weekly, a summary of the email traffic of the perl5-porters email list. I'd hoped to get this published earlier, but it didn't happen.

In the US, we just switched back to "standard" time on Saturday. Rah, rah energy savings, but toddlers don't adapt well to legalistic time changes, so I was up and at 'em at the butt crack of dawn this morning.

Enough complaining, let's get to this week's topics. I hope you wanted a week full of discussion(?) around subroutine signatures, because that's what we got.

  • perl-5.16.2-RC1 is now available
  • 5.12.5 last call for patches
  • Consider Forbidding Developer Releases in Production Perls
  • No-taint support in Perl
  • What happened to the whole "small core" idea?
  • sub signatures
    • too many arguments
    • function to return the signature
    • too few arguments
    • status - I'm going quiet for a while ...

perl-5.16.2-RC1 is now available

Ricardo Signes announced that perl-5.16.2-RC1 is now available at CPAN mirror near you.

Read the announcement

5.12.5 last call for patches

Dominic Hargreaves is asking for any patches that should be applied to a new 5.12.5 maintenance release.

Read the announcement

Follow on RT

Consider Forbidding Developer Releases in Production Perls

Jeffrey Thalhammer (author of Perl Critic and Pinto among others), and Miyagawa (author of Plack among others) were bitten by a problem that came about because 5.16.x ships with a development version of EU::MakeMaker. So he proposed that production releases ship only with production versions of any modules.

Read the thread

No-taint support in Perl

In our last episode, Steffen Mueller proposed a compile time option to disable taint checking and this week Ricardo Signes (our current pumpking) wrote that it seemed "potentially useful.

Read the thread

What happened to the whole "small core" idea

Peter Rabbitson posted a lengthy email asking whatever happened to the "small core" ideals promoted by Jesse Vincent, the previous pumpking. He writes:

I will start with the TL;DR - I can not fathom why given Perl's 
*exceptional* modularization track record, the general tendency on p5p 
still is "MOAR CORE FEATURES!!!". I also do not understand how does this 
sentiment continue to survive given an overwhelming mass of core devs 
opposing such experiments (I do substantiate this claim - keep reading).

The whole email is worth reading, and there were several thoughtful replies, although Ricardo's reply came on October 29, just after the cutoff for this summary.

Read the thread

subroutine signatures

Peter Martini checks in with a status update on his subroutine signature work, including some discussions around behavior when too few or too many arguments are provided, how to programmatically get the expected parameter list, and finally a promise to continue working on things given all of the feedback.

He writes:

I think I'll stop stoking the fires til I clear off the work on my plate,
which includes:

* Make a new branch to I can create a new series of commits cleanly

* The code cleanups Father C posted.

* Remove the @_ ban (I'll commit it and immediately revert it in the new
branch, so it can be easily added back)

*** In the commit adding it, I'll ban goto from a sub with a signature, so
there'll be record of that.

** Strict parameter count checking*.  sub foo($bar) requires exactly one
parameter.  sub foo(@bar) or sub foo(%bar) requires 0 or more, and will
die/croak otherwise

* Make goto &foo work

* Make the signature parameter in the padlist an AV* instead of an int
(mainly future proofing)

* Rename the proto attribute to prototype (Father C prefers prototype, and
I don't recall anyone else having a preference one way or another)

* should be aware of the prototype attribute (but I think
it should only be aware of it enough to say use : prototype() directly)

* Change the name of the feature to just 'signatures' (but flagged as

* Make sure all tests pass at each commit

Thread about too many arguments

Thread about too few arguments

Dave Rolsky's concerns

Thread about stepping back

Thread about status



I'm always happy to read these summaries, because I don't always grind thru the whole mailing list's messages.

This time it's an especial Three Cheers for Peter Rabbitson.

And not just for his whole complaint, but for this: "auto-deref (which has not yet backfired, but it will)". I told you so, the minute I say the proposal. I admit I do dislike the complexity of say,
my($data) = {stack => [], ...};
push @{$$data{stack} }, $x;
But does it have to be 'fixed'? IMHO the auto-deref is a timebomb. We'll see.

And Peter, the reason for the madness you write about in general (not auto-deref explicitly) is that people in groups do things which those individuals would never do when acting as individuals. This is a sad and hard-won realization eventually achieved by all those who deal with such cases. Witness group activity of /all/ types, political/religious (which includes Communism and Nazism)/etc/etc. It's virtually unheard of for a sensible individual to have the wisdom and power to block such activity :-((.


It's sadly too early for cheers. The only *independent* party who replied to the very core of my complaint was bulk88. That is "why is everyone silent when an obvious trainwreck is being designed". The rest of the massive thread was me parring down the folks blindly supporting a future at any cost.

Basically as the one who started the thread I deem it an utter failure, and a waste of everyone's time. Which is indeed sad :(

Hi Peter

Understand. I replied (I think) to a blog entry on this site.

I see several courses of action:

  • None. Most likely.

  • An explicit policy of leaving things as-is. See above.

  • A decision to eliminate the feature. Preferred.

  • A compromise. This is my 2nd preferred. It is: Add something like:

    use autovivify 'arrayref';
    use autovivify qw/arrayref hashref/;

    So the user forces the option on, and the auditor of the code is warned.


About Perl 5 Porters Summaries

user-pic Weekly p5p summaries