Forward to the list because Abusix had blocked google.com initially.
Nam
-- Forwarded message -
From: Nam Nguyen
Date: Sun, Jul 28, 2019 at 10:18 AM
Subject: Re: [Python-ideas] Re: Universal parsing library in the stdlib to
alleviate security issues
To: Sebastian Kreft
Cc: Paul
On Thu, Jul 25, 2019 at 2:32 AM Paul Moore wrote:
> On Thu, 25 Jul 2019 at 02:16, Nam Nguyen wrote:
> > Back to my original requests to the list: 1) Whether we want to have a
> (possibly private) parsing library in the stdlib
>
> In the abstract, no. Propose a specific librar
On Wed, Jul 24, 2019 at 6:40 PM Eric V. Smith wrote:
> On 7/24/2019 9:15 PM, Nam Nguyen wrote:
> > Back to my original requests to the list: 1) Whether we want to have a
> > (possibly private) parsing library in the stdlib, and 2) What features
> > it should have. I have
On Tue, Jul 23, 2019 at 8:06 PM Andrew Barnert wrote:
> On Jul 23, 2019, at 18:44, Nam Nguyen wrote:
> >
> > FYI, my current proof of concept parser is at ~300 lines of code, with
> debugging trace support. Other than performance (which I don't intend to
> tackle in
On Sun, Jul 21, 2019 at 2:50 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> On Jul 21, 2019, at 14:13, Barry wrote:
> >
> >>> On 21 Jul 2019, at 19:03, Steven D'Aprano wrote:
> >>>
> >>> On Sun, Jul 21, 2019 at 08:48:49AM +0100, Barry Scott wrote:
> >>>
> >>> I took at
fault. These features are not
available in my library.
Finally, pyparsing has some limitations of its own. Some of them are
inability to handle recursive grammars, ambiguities, and context sensitive
grammars.
Maybe you could compare the timings?
>
I've just pushed out
https:
ked into pyparsing (https://github.com/pyparsing/pyparsing)?
> It somehow looks relevant.
>
> On Mon, Jul 15, 2019 at 6:45 PM Nam Nguyen wrote:
>
>> Hello list,
>>
>> I sent an email to this list two or three months ago about the same idea.
>> In that discussion, there we
On Thu, Jul 18, 2019 at 12:07 AM Barry Scott wrote:
>
>
> On 18 Jul 2019, at 05:23, Nam Nguyen wrote:
>
> On Wed, Jul 17, 2019 at 12:38 AM Barry Scott
> wrote:
>
>> But if your use cases call for performance, it is perfectly fine to
>> understand the
On Wed, Jul 17, 2019 at 12:38 AM Barry Scott wrote:
> But if your use cases call for performance, it is perfectly fine to
> understand the tradeoffs, and opt in to the more appropriate solutions.
> And, of course, maybe there is a solution that could satisfy *both*.
>
> Generally speaking,
On Mon, Jul 15, 2019 at 8:47 PM Andrew Barnert wrote:
> On Jul 15, 2019, at 18:44, Nam Nguyen wrote:
>
> I have implemented a tiny (~200 SLOCs) package at
> https://gitlab.com/nam-nguyen/parser_compynator that demonstrates
> something like this is possible. There are several e
On Tue, Jul 16, 2019 at 1:18 PM Barry wrote:
>
>
> > On 16 Jul 2019, at 04:47, Andrew Barnert via Python-ideas <
> python-ideas@python.org> wrote:
> >
> > How often do you need to parse a million URLs in your inner loop?
>
> As it happens i work on code that would be impacted by such a slow
such as short XML fragments in which end tags must match start tags.
I have implemented a tiny (~200 SLOCs) package at
https://gitlab.com/nam-nguyen/parser_compynator that demonstrates something
like this is possible. There are several examples for you to have a feel of
it, as well as some early
On Mon, Apr 8, 2019 at 7:59 AM Christopher Barker
wrote:
>
>
> On Mon, Apr 8, 2019 at 12:02 AM Paul Moore wrote:
>
>> I would expect that the only reasonable way of getting a parsing
>> library in the stdlib would be to propose an established one from PyPI
>> to be moved into the stdlib
>
>
>
On Mon, Apr 1, 2019 at 3:13 PM Terry Reedy wrote:
> On 4/1/2019 1:14 AM, Guido van Rossum wrote:
> > We do have a parser generator in the standard library:
> > https://github.com/python/cpython/tree/master/Lib/lib2to3/pgen2
>
> It is effectively undocumented and by inference discouraged from
:
> On Sun, Mar 31, 2019 at 9:17 PM Nam Nguyen wrote:
> > Installing a package out of stdlib does not solve the problem that
> motivated this thread. The libraries included in the stdlib can't use those
> parsers.
>
> Can you be more specific about exactly which code in the stdl
e also have to explain why it needs to be in the standard library
>> rather than installed by 'pip install someparser'.
>>
>
Installing a package out of stdlib does not solve the problem that
motivated this thread. The libraries included in the stdlib can't use those
parse
Hello list,
What do you think of a universal parsing library in the stdlib mainly for
use by other libraries in the stdlib?
Through out the years we have had many issues with protocol parsing. Some
have even introduced security bugs. The main cause of these issues is the
use of simple regular
17 matches
Mail list logo
