Stack-based LL(1) push down automata can be implemented by hand, indeed isn’t
that that a textmateLanguage file is? There’s also the option of using Iro to
generate a tmLanguage.
___
Python-ideas mailing list
Python-ideas@python.org
> On 1 Apr 2019, at 04:58, David Mertz wrote:
>
>
>> Lacking a good set of semantics for removing multiple affixes at once, we
>> shouldn't rush to guess what people want. You don't even know what behaviour
>> YOU want, let alone what the community as a whole needs.
>
>
> This is both
We do have a parser generator in the standard library:
https://github.com/python/cpython/tree/master/Lib/lib2to3/pgen2
On Sun, Mar 31, 2019 at 9:17 PM Nam Nguyen wrote:
> On Sun, Mar 31, 2019 at 12:13 PM David Mertz wrote:
>
>> I just found this nice summary. It's not complete, but it looks
Steven D'Aprano wrote:
The best thing is that there will no longer be any confusion as to
whether you are looking at a Unicode string or a byte-string:
a = a.new_string_trimmed_on_the_left()
a = a.new_bytes_trimmed_on_the_left()
To keep the RUE happy, instead of a "string" we should
> On 1 Apr 2019, at 02:23, David Mertz wrote:
>
>> On Sun, Mar 31, 2019, 8:11 PM Steven D'Aprano wrote:
>> Regarding later proposals to add support for multiple affixes, to
>> recursively delete the affix repeatedly, and to take an additional
>> argument to limit how many affixes will be
On Sun, Mar 31, 2019 at 12:13 PM David Mertz wrote:
> I just found this nice summary. It's not complete, but it looks well
> written. https://tomassetti.me/parsing-in-python/
>
> On Sun, Mar 31, 2019, 3:09 PM David Mertz wrote:
>
>> There are about a half dozen widely used parsing libraries for
On Mon, Apr 1, 2019 at 12:35 PM Steven D'Aprano wrote:
>
> On Sun, Mar 31, 2019 at 08:23:05PM -0400, David Mertz wrote:
> > On Sun, Mar 31, 2019, 8:11 PM Steven D'Aprano wrote:
> >
> > > Regarding later proposals to add support for multiple affixes, to
> > > recursively delete the affix
On Sun, Mar 31, 2019, 9:35 PM Steven D'Aprano wrote:
> > That's simply not true, and I think it's clearly illustrated by the
> example I gave a few times. Not just conceivably, but FREQUENTLY I write
> code to accomplish the effect of the suggested:
> >
> > basename = fname.rstrip(('.jpg',
On Sun, Mar 31, 2019 at 08:23:05PM -0400, David Mertz wrote:
> On Sun, Mar 31, 2019, 8:11 PM Steven D'Aprano wrote:
>
> > Regarding later proposals to add support for multiple affixes, to
> > recursively delete the affix repeatedly, and to take an additional
> > argument to limit how many
On Sun, Mar 31, 2019, 8:11 PM Steven D'Aprano wrote:
> Regarding later proposals to add support for multiple affixes, to
> recursively delete the affix repeatedly, and to take an additional
> argument to limit how many affixes will be removed: YAGNI.
>
That's simply not true, and I think it's
Thank you, this is a simple, unambiguous proposal which meets a real need
and will help prevent a lot of wasted developer time misusing [lr]strip
and then reporting it as a bug: remove a single prefix or suffix.
This is a useful string primitive provided by other modern languages and
libraries,
On Mon, Apr 1, 2019 at 11:00 AM Steven D'Aprano wrote:
>
> On Mon, Apr 01, 2019 at 12:02:25PM +1300, Greg Ewing wrote:
> > Dan Sommers wrote:
> >
> > >without_prefix
> > >without_suffix
> > >
> > >They're a little longer, but IMO "without" helps
> > >reenforce the immutability of the underlying
Dan Sommers wrote:
without_prefix
without_suffix
They're a little longer, but IMO "without" helps
reenforce the immutability of the underlying string.
We don't seem to worry about that distinction for other
string methods, such as lstrip and rstrip.
--
Greg
> On 31 Mar 2019, at 21:32, Christopher Barker wrote:
>
>
> without_prefix
> without_suffix
>
> They're a little longer, but IMO "without" helps
> reenforce the immutability of the underlying string. None
> of these functions actually remove part of the original
> string, but rather they
> without_prefix
> without_suffix
>
> They're a little longer, but IMO "without" helps
> reenforce the immutability of the underlying string. None
> of these functions actually remove part of the original
> string, but rather they return a new string that's the
> original string without some
I just found this nice summary. It's not complete, but it looks well
written. https://tomassetti.me/parsing-in-python/
On Sun, Mar 31, 2019, 3:09 PM David Mertz wrote:
> There are about a half dozen widely used parsing libraries for Python.
> Each one of them takes a dramatically different
What does it mean to be a universal parser? In my mind, to be universal you
should be able to parse anything, so you'd need something as versatile as
any Turing language, so one could stick with the one we already have
(Python). I'm vaguely aware of levels of grammar (regular, context-free?,
On Sun, Mar 31, 2019 at 12:09 PM MRAB wrote:
> > That said, I really like Brandt's ideas of expanding the signature of
> > .lstrip/.rstrip instead.
> >
> > mystring.rstrip("abcd") # remove any of these single character suffixes
>
> It removes _all_ of the single character suffixes.
>
> >
On 2019-03-31 16:48, David Mertz wrote:
The only reason I would support the idea would be to allow multiple
suffixes (or prefixes). Otherwise, it just does too little for a new
method. But adding that capability of startswith/endswith makes the cut
off something easy to get wrong and
The only reason I would support the idea would be to allow multiple
suffixes (or prefixes). Otherwise, it just does too little for a new
method. But adding that capability of startswith/endswith makes the cut off
something easy to get wrong and non-trivial to implement.
That said, I really like
On 3/31/19 1:48 AM, Chris Angelico wrote:
If we're bikeshedding the actual method names, I think it would be
good to have a list of viable options. A quick skim through the thread
gives me these:
* cut_prefix/cut_suffix
* strip_prefix/strip_suffix
* cut_start/cut_end
* Any of the above with
Sorry one more time (it is early morning and I should drink a cup of coffee
first before posting here). Of course it should be `tuple(sorted(('al',
'ical'), key=len, reverse=True))`, I hope it was obvious to everyone from
the very beginning.
with kind regards,
-gdg
вс, 31 мар. 2019 г. в 11:53,
On Sun, Mar 31, 2019 at 7:36 PM Steven D'Aprano wrote:
>
> On Sun, Mar 31, 2019 at 04:48:36PM +1100, Chris Angelico wrote:
>
> > Regardless of the method name, IMO the functions should accept a tuple
> > of test strings, as startswith/endwith do. That's a feature that can't
> > easily be spelled
That's why strip_prefix(suffix) is a better name, can't double think.
On март 31 2019, at 11:56 утра, Steven D'Aprano wrote:
> On Sun, Mar 31, 2019 at 07:35:22PM +1100, Steven D'Aprano wrote:
>
> > "musical".lcut(('al', 'ical'))
> Oops, typo, I was thinking rcut and wrote lcut :-(
> --
> Steven
On Sun, Mar 31, 2019 at 07:35:22PM +1100, Steven D'Aprano wrote:
> "musical".lcut(('al', 'ical'))
Oops, typo, I was thinking rcut and wrote lcut :-(
--
Steven
___
Python-ideas mailing list
Python-ideas@python.org
вс, 31 мар. 2019 г. в 11:45, Kirill Balunov :
>
>
> вс, 31 мар. 2019 г. в 11:36, Steven D'Aprano :
>
>> There's a slight problem with that: what happens if more than one suffix
>> matches? E.g. given:
>>
>> "musical".lcut(('al', 'ical'))
>>
>> should the suffix "al" be removed, leaving
вс, 31 мар. 2019 г. в 11:36, Steven D'Aprano :
> There's a slight problem with that: what happens if more than one suffix
> matches? E.g. given:
>
> "musical".lcut(('al', 'ical'))
>
> should the suffix "al" be removed, leaving "music"? (First match wins.)
>
> Or should the suffix "ical" be
On Sun, Mar 31, 2019 at 04:48:36PM +1100, Chris Angelico wrote:
> Regardless of the method name, IMO the functions should accept a tuple
> of test strings, as startswith/endwith do. That's a feature that can't
> easily be spelled in a one-liner. (Though stacked suffixes shouldn't
> all be removed
28 matches
Mail list logo
