Le 14/06/2018 à 07:29, Steven D'Aprano a écrit :
> On Wed, Jun 13, 2018 at 10:59:34PM +0200, Michel Desmoulin wrote:
>
>>> Attaching an entire module to a type is probably worse than
>>> adding a slew of extra methods to the type.
>>>
>>
>> Not my point.
>>
>> str.re would not be the re module,
from a lurker's perspective, why not just implement str.compile() as
new method, and methods where it's relevant support it's result as
argument ? That's a small change in additions, and the other methods
in the normal case just do the same as now. It's also pretty clear
what things like "whatever"
On Thu, Jun 14, 2018, 11:22 PM Franklin? Lee
wrote:
> P.S.: Is there any way of guessing what proportion of Python programs
> use `re`, either explicitly or implicitly? How many programs will, at
> some point in their runtime, load the `re` module?
>
GitHub posts it's data to Google BigQuery. It
On Thu, Jun 14, 2018 at 2:12 AM, Brendan Barnwell wrote:
> On 2018-06-13 22:29, Steven D'Aprano wrote:
>>
>> On Wed, Jun 13, 2018 at 10:59:34PM +0200, Michel Desmoulin wrote:
>>
>>> > Attaching an entire module to a type is probably worse than
>>> > adding a slew of extra methods to the type.
>>>
Oleg Broytman wrote:
import re as regular_expressions_operations
Personally I would use
import re as ridiculously_enigmatic_operations
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-id
Steven D'Aprano wrote:
So math.sin is little different from math_sin, but the fact that math
alone is a module, a first-class object, and not just a prefix of the
name, makes a big difference.
This is important because it provides ways of referring to
things in the module without having to wri
On Thu, Jun 14, 2018 at 12:22:45AM -0700, Brendan Barnwell
wrote:
> If anything, I think the name "re" is too short
> and cryptic and should be made longer!
import re as regular_expressions_operations
> --
> Brendan Barnwell
Oleg.
--
Oleg Broytmanhttps://phdru.name/
On Thu, Jun 14, 2018 at 12:12:34AM -0700, Brendan Barnwell
wrote:
> as we all know, namespaces are one
> honking great idea!
Flat is better than nested, so additional string.re subnamespace is
not needed.
> --
> Brendan Barnwell
Oleg.
--
Oleg Broytmanhttps://phdru.name/
On Thu, Jun 14, 2018 at 6:21 PM, Steven D'Aprano wrote:
> On Thu, Jun 14, 2018 at 12:12:34AM -0700, Brendan Barnwell wrote:
>> On 2018-06-13 23:37, Chris Angelico wrote:
> [...]
>> >How is this materially different from:
>> >
>> >"some string".re_match(...)
>> >
>> >? It's not a grouped namespace
On Thu, Jun 14, 2018 at 12:12:34AM -0700, Brendan Barnwell wrote:
> On 2018-06-13 23:37, Chris Angelico wrote:
[...]
> >How is this materially different from:
> >
> >"some string".re_match(...)
> >
> >? It's not a grouped namespace in any technical sense, but to any
> >human, a set of methods that
On Thu, Jun 14, 2018 at 12:22:45AM -0700, Brendan Barnwell wrote:
> Unless a special regex syntax is added, I don't see that there's
> much benefit to allowing a compiled object as the argument.
Fair enough -- I'm not convinced that this proposal is either desirable
or necessary eit
On Thu, Jun 14, 2018 at 06:33:14PM +1200, Greg Ewing wrote:
> Steven D'Aprano wrote:
> >- should targets match longest first or shortest first? or a flag
> > to choose which you want?
> >
> >- what if you have multiple targets and you need to give some longer
> > ones priority, and some shorter o
On 2018-06-14 00:10, Steven D'Aprano wrote:
Rather than add eight new methods, we could allow the existing string
methods to take pattern objects as arguments. That gives us potentially:
count, endswith, find, index, lstrip, partition, replace, rfind,
rindex, rpartition, rsplit, rstrip
On 2018-06-13 23:37, Chris Angelico wrote:
str.re can be a descriptor object which "knows" which string
instance it is bound to. This kind of thing is common in many libraries.
Pandas for example has all kinds of things like df.loc[1:3],
df.column.str.startswith('blah'), etc. The "loc"
On Wed, Jun 13, 2018 at 11:12:43PM -0700, Brendan Barnwell wrote:
> >How would this work? If I say:
> >
> >"My string".re.match(...)
> >
> >if str.re is "just a namespace" how will the match function know the
> >string it is to operate on?
>
> str.re can be a descriptor object which "knows"
On Thu, Jun 14, 2018 at 4:12 PM, Brendan Barnwell wrote:
> On 2018-06-13 22:29, Steven D'Aprano wrote:
>>
>> On Wed, Jun 13, 2018 at 10:59:34PM +0200, Michel Desmoulin wrote:
>>
>>> > Attaching an entire module to a type is probably worse than
>>> > adding a slew of extra methods to the type.
>>>
Steven D'Aprano wrote:
- should targets match longest first or shortest first? or a flag
to choose which you want?
- what if you have multiple targets and you need to give some longer
ones priority, and some shorter ones?
I think the suggestion made earlier is reasonable: match
them in the
On 2018-06-13 22:29, Steven D'Aprano wrote:
On Wed, Jun 13, 2018 at 10:59:34PM +0200, Michel Desmoulin wrote:
> Attaching an entire module to a type is probably worse than
> adding a slew of extra methods to the type.
>
Not my point.
str.re would not be the re module, just a namespace where t
On Wed, Jun 13, 2018 at 10:43:43PM +0200, Michel Desmoulin wrote:
> str.replace come to mind. It's a annoying to have to chain it 5 times
> while we could pass optionally a tuple.
Its not so simple. Multiple replacements underspecifies the behaviour.
The simplest behaviour is to have
astrin
On Wed, Jun 13, 2018 at 10:59:34PM +0200, Michel Desmoulin wrote:
> > Attaching an entire module to a type is probably worse than
> > adding a slew of extra methods to the type.
> >
>
> Not my point.
>
> str.re would not be the re module, just a namespace where to group all
> regex related stri
On Wed, Jun 13, 2018 at 8:15 PM, Greg Ewing wrote:
> Chris Angelico wrote:
>>
>> This would want to be semantically different from chained
>> calls, in that a single replace([x,y,z], q) would avoid re-replacing;
>
>
> +1, this would be REALLY handy!
>
> It's easy to trip yourself up with chained r
Chris Angelico wrote:
This would want to be semantically different from chained
calls, in that a single replace([x,y,z], q) would avoid re-replacing;
+1, this would be REALLY handy!
It's easy to trip yourself up with chained replacements
if you're not careful -- like I did once when escaping
t
Michel Desmoulin wrote:
Also, we do have to saturate the str namespace with all the re
functions. We could decide to go for `str.re.stuff`.
However, note that this is not as simple as just adding a
class attribute to str that references the re module,
since presumably you want to be able to wri
Clint Hepner wrote:
Strictly speaking, a regular expression is just a string that encodes of a
(non)deterministic finite automata.
More strictly speaking, regular expressions themselves are agnostic about
determinism vs. non-determinism, since for any NFA you can always find
an equivalent DFA.
On Wed, Jun 13, 2018 at 3:54 PM MRAB wrote:
> Would it check first-to-last or longest-to-shortest? I think that
> longest-to-shortest would be the most useful.
>
> >>> old = ('cat', 'cats')
> >>> new = ('mouse', 'mice')
> >>>
> >>> # First-to-last.
> >>> 'cats'.replace(old, new)
> 'mouses'
>
On Thu, Jun 14, 2018 at 8:54 AM, MRAB wrote:
> On 2018-06-13 21:52, Chris Angelico wrote:
>>
>> On Thu, Jun 14, 2018 at 6:43 AM, Michel Desmoulin
>> wrote:
>>>
>>>
>>>
>>> Le 13/06/2018 à 19:11, Mike Miller a écrit :
On 2018-06-13 06:33, Michel Desmoulin wrote:
>
>
> I
On 2018-06-13 21:52, Chris Angelico wrote:
On Thu, Jun 14, 2018 at 6:43 AM, Michel Desmoulin
wrote:
Le 13/06/2018 à 19:11, Mike Miller a écrit :
On 2018-06-13 06:33, Michel Desmoulin wrote:
I often wished for findall and sub to be string methods, so +1 on that.
Agreed, and there are a
On Wed, Jun 13, 2018, 4:44 PM Michel Desmoulin
wrote:
> several startswith() and endswith() require a loop, but we could make
> them accept *args.
>
You mean something like:
"Lorem ipsum".startswith(('Lo', 'Hi', 'Foo'))
You might want to check the time machine.
>
_
Le 13/06/2018 à 22:53, David Mertz a écrit :
> On Wed, Jun 13, 2018, 4:44 PM Michel Desmoulin
> mailto:desmoulinmic...@gmail.com>> wrote:
>
> several startswith() and endswith() require a loop, but we could
> make them accept *args.
>
>
> You mean something like:
>
> "Lorem ipsum".sta
>
> Both accept a tuple. For example:
>
>>>> "foo".startswith(("f", "b"))
>True
>>>> "bar".startswith(("f", "b"))
>True
>
Nice. Now let's do that for str.replace.
>> Also, we do have to saturate the str namespace with all the re
>> functions. We could decide to go for `str.re
On Thu, Jun 14, 2018 at 6:43 AM, Michel Desmoulin
wrote:
>
>
> Le 13/06/2018 à 19:11, Mike Miller a écrit :
>>
>> On 2018-06-13 06:33, Michel Desmoulin wrote:
>>>
>>> I often wished for findall and sub to be string methods, so +1 on that.
>>>
>>
>> Agreed, and there are a few string functions that
> On 2018 Jun 13 , at 4:43 p, Michel Desmoulin
> wrote:
>
>
>
> Le 13/06/2018 à 19:11, Mike Miller a écrit :
>>
>> On 2018-06-13 06:33, Michel Desmoulin wrote:
>>>
>>> I often wished for findall and sub to be string methods, so +1 on that.
>>>
>>
>> Agreed, and there are a few string func
Le 13/06/2018 à 19:11, Mike Miller a écrit :
>
> On 2018-06-13 06:33, Michel Desmoulin wrote:
>>
>> I often wished for findall and sub to be string methods, so +1 on that.
>>
>
> Agreed, and there are a few string functions that could be extended (to
> take a sequence) to handle more cases that
On 2018-06-13 06:33, Michel Desmoulin wrote:
I often wished for findall and sub to be string methods, so +1 on that.
Agreed, and there are a few string functions that could be extended (to take a
sequence) to handle more cases that push folks to regex, perhaps earlier than
they should.
>> I suggest building all regex operations into the str class itself, as well
>> as a new syntax for regular expressions.
>
>There are many different regular expression implementation (regex,
> re2). How to make ``s.search(pattern)`` work with all of them?
>
You don't, they work stand alone
Le 13/06/2018 à 13:06, Ken Hilton a écrit :
> Hi all,
>
> Regexes are really useful in many places, and to me it's sad to see the
> builtin "re" module having to resort to requiring a source string as an
> argument. It would be much more elegant to simply do "s.search(pattern)"
> than "re.search
On Wed, Jun 13, 2018 at 07:06:09PM +0800, Ken Hilton
wrote:
> Regexes are really useful in many places, and to me it's sad to see the
> builtin "re" module having to resort to requiring a source string as an
> argument. It would be much more elegant to simply do "s.search(pattern)"
> than "re.sea
> On 2018 Jun 13 , at 7:06 a, Ken Hilton wrote:
>
> Hi all,
>
> Regexes are really useful in many places, and to me it's sad to see the
> builtin "re" module having to resort to requiring a source string as an
> argument. It would be much more elegant to simply do "s.search(pattern)" than
>
On 13/06/18 12:06, Ken Hilton wrote:
Hi all,
Regexes are really useful in many places, and to me it's sad to see the
builtin "re" module having to resort to requiring a source string as an
argument. It would be much more elegant to simply do "s.search(pattern)"
than "re.search(pattern, s)".
I su
Hi all,
Regexes are really useful in many places, and to me it's sad to see the
builtin "re" module having to resort to requiring a source string as an
argument. It would be much more elegant to simply do "s.search(pattern)"
than "re.search(pattern, s)".
I suggest building all regex operations int
40 matches
Mail list logo
