Mailing List Archive

On Sat, 17 Feb 2024 at 05:11, Graham Knop <haarg@haarg.org> wrote:

> * a %q to access B::perlstring/quotemeta or something similar
>

I like this. It would also be nice to have a mode that escapes the content,
much like our internal functions for escaping strings do. Along with this
I always wished sprintf had the functionality to completely replace formats.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

On Sat, Feb 17, 2024 at 05:11:22AM +0100, Graham Knop wrote:
> This week, we discussed:
>
> - draft tests+docs received from Martijn Lievaart (“M4”) for a
> logical xor (^^) operator

Having docs and tests written in advance makes it much easier for an
implementor to actually start working.

For small, non-controversial features (like ^^ was), the effort of
writing and discussing a PPC seems out of proportion. The time is much
better spent in writing actual docs and tests, creating a draft pull
request, and pitching it on the list to find an implementor.

In the worst case, p5p finds out it is in fact a feature that needs more
discussion, and a good chunk of the PPC has already been written.

--
Philippe Bruhat (BooK)

When the employee is a fool, so is the employer.
(Moral from Groo The Wanderer #26 (Epic))

On Sat, 17 Feb 2024 09:07:53 +0100
"Philippe Bruhat (BooK)" <book@cpan.org> wrote:

> On Sat, Feb 17, 2024 at 05:11:22AM +0100, Graham Knop wrote:
> > This week, we discussed:
> >
> > - draft tests+docs received from Martijn Lievaart (“M4”) for a
> > logical xor (^^) operator
>
> Having docs and tests written in advance makes it much easier for an
> implementor to actually start working.
>
> For small, non-controversial features (like ^^ was), the effort of
> writing and discussing a PPC seems out of proportion. The time is much
> better spent in writing actual docs and tests, creating a draft pull
> request, and pitching it on the list to find an implementor.

+1

I found it much easier and quicker to start implementing that because
the tests were already in place, and knowing the docs are there too
meant I didn't have to do that bit either. It took me only maybe a
couple of hours to write an implementation for it:

https://github.com/Perl/perl5/pull/21996

(still draft at the moment while we work out some more tests)


But yes - this is a model I'd like to use more in future, if we can...

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

Thanks for the updates.

+1 for ^^ and %q.


> - the responses saying no to adding Data::Printer in core that it
> doesn’t seem like it would be popular


That's sad to hear, I'd definitely switch using it instead of ::Dumper.

On Sat, Feb 17, 2024 at 5:11?AM Graham Knop <haarg@haarg.org> wrote:

> This week, we discussed:
>
> - working out a timeline of what should go in to 5.39.8, 5.39.9, and
> what to defer to 5.41
> - draft tests+docs received from Martijn Lievaart (“M4”) for a
> logical xor (^^) operator
> - the responses saying no to adding Data::Printer in core that it
> doesn’t seem like it would be popular
> - some potential new sprintf format templates:
> * a float template that produces the shortest string that
> represents the exact float (similar to what Math::Ryu does),
> * a %q to access B::perlstring/quotemeta or something similar
> - the realisation that, some months ago, Mark Gardner had
> volunteered to work on the SSL-in-core project, and we haven’t heard
> from them since.
>

On 2/18/24 10:34, Elvin Aslanov wrote:
>
> On Sat, Feb 17, 2024 at 5:11?AM Graham Knop <haarg@haarg.org> wrote:
>   - the responses saying no to adding Data::Printer in core that
> it doesn’t seem like it would be popular
>
>
> That's sad to hear, I'd definitely switch using it instead of ::Dumper.

I think most peoples' responses were that they would enjoy Data::Printer
in core, but that there are probably better ways to achieve that effect
than just bundling the Data::Printer cpan module as-is.  I'm still a big
fan of the idea of a 'show' builtin that provides a natural API for
Data::Printer (or others) to plug into.  If more people chimed in with
support for that idea, I'd write up an official proposal.

-Mike C

On 2024-02-18 1:31 p.m., Michael Conrad wrote:
> On 2/18/24 10:34, Elvin Aslanov wrote:
>>
>> On Sat, Feb 17, 2024 at 5:11?AM Graham Knop <haarg@haarg.org> wrote:
>>   - the responses saying no to adding Data::Printer in core that it
>> doesn’t seem like it would be popular
>>
>>
>> That's sad to hear, I'd definitely switch using it instead of ::Dumper.
>
> I think most peoples' responses were that they would enjoy Data::Printer in
> core, but that there are probably better ways to achieve that effect than just
> bundling the Data::Printer cpan module as-is.  I'm still a big fan of the idea
> of a 'show' builtin that provides a natural API for Data::Printer (or others) to
> plug into.  If more people chimed in with support for that idea, I'd write up an
> official proposal.

What's stopping people who want to use Data::Printer from just using it from
CPAN? Why does it have to be bundled with Perl as a precondition for usage? If
anything, depending on it from CPAN would make it MORE widely usable rather than
less. -- Darren Duncan

Op 18-02-2024 om 22:31 schreef Michael Conrad:
> On 2/18/24 10:34, Elvin Aslanov wrote:
>>
>> On Sat, Feb 17, 2024 at 5:11?AM Graham Knop <haarg@haarg.org> wrote:
>>   - the responses saying no to adding Data::Printer in core that
>> it doesn’t seem like it would be popular
>>
>>
>> That's sad to hear, I'd definitely switch using it instead of ::Dumper.
>
> I think most peoples' responses were that they would enjoy
> Data::Printer in core, but that there are probably better ways to
> achieve that effect than just bundling the Data::Printer cpan module
> as-is.  I'm still a big fan of the idea of a 'show' builtin that
> provides a natural API for Data::Printer (or others) to plug into.  If
> more people chimed in with support for that idea, I'd write up an
> official proposal.
>

Being the one that asked Paul why Data::Dumper was not in core, I'm
thrilled to see that this discussion took place, and I do think this is
the best proposal to come out of the discussion. In other words, I would
love that!


HTH,

M4

Op 18-02-2024 om 23:36 schreef Darren Duncan:
> On 2024-02-18 1:31 p.m., Michael Conrad wrote:
>> On 2/18/24 10:34, Elvin Aslanov wrote:
>>>
>>>     On Sat, Feb 17, 2024 at 5:11?AM Graham Knop <haarg@haarg.org>
>>> wrote:
>>>       - the responses saying no to adding Data::Printer in core that it
>>>     doesn’t seem like it would be popular
>>>
>>>
>>> That's sad to hear, I'd definitely switch using it instead of ::Dumper.
>>
>> I think most peoples' responses were that they would enjoy
>> Data::Printer in core, but that there are probably better ways to
>> achieve that effect than just bundling the Data::Printer cpan module
>> as-is.  I'm still a big fan of the idea of a 'show' builtin that
>> provides a natural API for Data::Printer (or others) to plug into. 
>> If more people chimed in with support for that idea, I'd write up an
>> official proposal.
>
> What's stopping people who want to use Data::Printer from just using
> it from CPAN?  Why does it have to be bundled with Perl as a
> precondition for usage?  If anything, depending on it from CPAN would
> make it MORE widely usable rather than less. -- Darren Duncan
>

The idea, AFAICT, is a show builtin, that by default uses Data::Dumper
(as that is in core) or maybe, maybe something explicitly added to core
for this purpose (which might be Data::Printer). This new builtin has
hooks which would allow the user to configure by which module they want
their data to be shown. That module should have an interface that is
compatible with those hooks.


So if Data::Dumper is chosen as the default data printer (which makes
sense), it would need to be modified to be able for it to hook into this
builtin. Also, Data::Printer would have to be modified before people
could install it and use it as their data printer, but many would
probably do so. And if you don't like it, you could your own
Data::Fancy::Decorator, if it is compatible with the hooks, it can be
installed as the default data printer.


This is just a convenience obviously, but it would be awfully convenient
to have a 'show' built in do sensible things, and be configurable to
boot, instead of having to deal with the awful Data::Dumper interface
(or the only slightly less awful Data::Dump or Data::Printer interface).


HTH,

M4

On 2/19/24 14:25, Martijn Lievaart via perl5-porters wrote:
> Op 18-02-2024 om 23:36 schreef Darren Duncan:
>> On 2024-02-18 1:31 p.m., Michael Conrad wrote:
>>> On 2/18/24 10:34, Elvin Aslanov wrote:
>>>>
>>>>     On Sat, Feb 17, 2024 at 5:11?AM Graham Knop <haarg@haarg.org>
>>>> wrote:
>>>>       - the responses saying no to adding Data::Printer in core
>>>> that it
>>>>     doesn’t seem like it would be popular
>>>>
>>>>
>>>> That's sad to hear, I'd definitely switch using it instead of
>>>> ::Dumper.
>>>
>>> I think most peoples' responses were that they would enjoy
>>> Data::Printer in core, but that there are probably better ways to
>>> achieve that effect than just bundling the Data::Printer cpan module
>>> as-is.  I'm still a big fan of the idea of a 'show' builtin that
>>> provides a natural API for Data::Printer (or others) to plug into. 
>>> If more people chimed in with support for that idea, I'd write up an
>>> official proposal.
>>
>> What's stopping people who want to use Data::Printer from just using
>> it from CPAN?  Why does it have to be bundled with Perl as a
>> precondition for usage?  If anything, depending on it from CPAN would
>> make it MORE widely usable rather than less. -- Darren Duncan
>>
> ...
>
> This is just a convenience obviously, but it would be awfully
> convenient to have a 'show' built in do sensible things, and be
> configurable to boot, instead of having to deal with the awful
> Data::Dumper interface (or the only slightly less awful Data::Dump or
> Data::Printer interface).

Right!  And, save you the minor annoyance of a 'use' line for it.  The
'show' builtin would load the dumper module on demand, but also be
available in the syntax without the dumper module being loaded yet.  It
would be handy in forum discussions, like

    so try this:
    perl -MSomeModule -E 'show SomeModule->new(...)'

instead of

    so try this:
    perl -MSomeModule -MDDP -E '&p(SomeModule->new(...))'
    Oh, but you need to install Data::Printer first
    Well you can also use Data::Dumper.  Let me check, it would be
    perl -MSomeModule -MData::Dumper -E 'say Dumper(SomeModule->new(...))'

And, another nuance of the idea, if Data::Printer was available in core
then some people would start depending on it explicitly to show
debugging information to module users.  That would take away the choice
of dumper for users of those modules.  If a 'show' builtin is core, and
modules start using that for debugging, then users of the modules are
getting a dump with their preferred dumper.

-Mike C