develooper Front page | perl.perl5.porters | Postings from February 2012

Re: How we deprecate (was Re: Deprecating '\w {' in v5.16)

Thread Previous | Thread Next
Karl Williamson
February 1, 2012 10:29
Re: How we deprecate (was Re: Deprecating '\w {' in v5.16)
Message ID:
On 01/31/2012 12:15 AM, wrote:
> David Golden<>  wrote:
> :On Mon, Jan 30, 2012 at 3:06 AM,<>  wrote:
> :>  I consider this deprecation risky:  Further, I consider there is a non-zero
> :>  probability that once we try it we may find that the practice we wish
> :>  to deprecate is so widespread that we reconsider our approach.
> :>  [snip]
> :>  Attempting this at the start of a cycle would give us the space we need
> :>  to discover whether it's a really bad idea.
> :
> :Apologies in advance for "picking on you", but this is a good example
> :of the confusion of issues/arguments that I would like to avoid.
> Fair enough: I foolishly attempted to strengthen my argument by throwing
> additional risks in, but instead managed to obscure it so effectively
> that my main point was exactly the bit you snipped:
> :In particular, this isn't some practice that was previously dubious or
> :"always broken" - as far as I know, the norm and received wisdom has
> :always been "don't escape what doesn't require it".
> In recent years we have deprecated a number of dubious practices, that
> were always either broken, or so hard to use correctly that the vast
> majority of uses were broken.
> For such cases, it is IMO reasonable to say "we're going to cause you
> some pain now, but it's for your own (immediate) good - chances are
> what we're pointing out to you was in any case a bug in your code".
> This is not such a case. The benefit to the user is much more nebulous
> and long-term, and is in large part no more than the spillover effect
> of the benefits to p5p (which is not to be underestimated, but will be
> hard to communicate).
> :(b) "a non-zero probability that once we try it we may find that the
> :practice we wish to deprecate is so widespread that we reconsider our
> :approach"
> :
> :I argue that we have no way to know this during the development cycle
> :beyond the sort of "grep/smoke CPAN" approaches already done.  This is
> :only something we'll find out after a stable release when the broader
> :userbase starts to use it (which might not happen for years).  This is
> :not an argument to delay; this is an argument not to do it because of
> :the risks involved.
> :
> :(c) "Attempting this at the start of a cycle would give us the space
> :we need to discover whether it's a really bad idea."
> :
> :This *is* an argument for delay, but much as with (b), I don't think
> :it's legitimate for the same reason I cited above.
> I see (c) as a way to discover (b) with less pain for our users.
> The alternate proposal of 3-step deprecation (augmenting (c) with
> a "notice of intent" in the imminent release) works even better, as
> far as I'm concerned. Better still would be means, mentioned in that
> notice, for users voluntarily to enable the future deprecation warning.
> It is true that we rarely find out about problems a proposed change
> would cause from the wider userbase without a release. I see that,
> in this case, as an argument for greater caution, and for putting more
> effort into finding new avenues for communication and/or mitigation.
> :Thus, if your recommendation is "not now", then only (a) seems to have
> :merit.  Alternatively, if you're argument is "never", then only (b)
> :seems to have merit.  If many people feel the same either (a) or (b),
> :then it probably does rise to the level of "controversial feature".
> My recommendation is "not now", on the strength of current information.
> If further information, such as greps and CPAN smokes, were to show
> that it is a much smaller issue than that initial test run implied,
> it might be more justifiable.
> Hugo

That initial test run was for the more general case.  None of those 
found were for the more restricted case.   I did a grep of cpan for the 
restricted case, and the results are below.

I used Dave Golden's cpangrep on a minicpan mirror I keep.  I tried 
using a 5.12 Perl and a 5.14 Perl, and both times it eventually crashed 
with the following error message:

panic: realloc at /home/khw/devel/lib/perl5/5.14.0/IO/Uncompress/ 
line 1121.

The list of the 6328 distros that it got through is attached.  There are 
always problems with some of the distros.  Also attached is an error log 
if you care to verify that important distros weren't skipped.

After going through the results and weeding out false positives, the 
following real instances were left.  (These would not include things 
from evals, and similar.)

(It is not clear to me that the first one is dealing with a regex.)

   \"o}w, \e}} Q. and J.~R. R. To\u e}in and\'o} Bar ~\aa}nd\SS}\v{s}}, 
  T\`a\v{ s}}}
  T\`a\v{ s }}}

   	$tag =~ s/\s{2,*}/ /g;




       if ($input =~ s/\A{\s*//) # Curly bracket ": going to the 
"answer" section






       $c += s/(TEST\s{)/$1/g;


       $c += s/(TEST\s{)/$1/g;


       $c += s/(TEST\s{)/$1/g;

       $c += s/(TEST\s{)/$1/g;





Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About