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 2018-06-13 06:48, Nick Coghlan wrote:
On 13 June 2018 at 11:06, Michael Selik mailto:m...@selik.org>> wrote:
Google will probably fix this problem for you after dataclasses
become popular. The docs will gain a bunch of inbound links and the
issue will (probably) solve itself as ti
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 Thu, Jun 14, 2018 at 2:58 AM, Greg Ewing wrote:
> Mikhail V wrote:
>>
>> L ^= item
>> is
>> L.append(item)
>> or
>> L += [item]
>
>
> Okay, that achieves an in-place append, but it's not exactly
> obvious to the unenlightened what it does, whereas append()
> is pretty self-explanatory.
>
Sure,
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
Stephan Houben wrote:
Yes that is what my code does.
It reduces degrees to [0,90].
Only for the special angles, though. Richard's point is that you
need to do tha for *all* angles to avoid discontinuities with
large angles.
This is not how sine functions are calculated. They are calculated by
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
Mikhail V wrote:
L ^= item
is
L.append(item)
or
L += [item]
Okay, that achieves an in-place append, but it's not exactly
obvious to the unenlightened what it does, whereas append()
is pretty self-explanatory.
Also, using the slice version to do an insert
L[i:i] ^= item
is not as efficient
Mikhail V wrote:
But if you say that special-casing of [i:j] here would be hard to implement,
then maybe insert() idea should be dropped.
Since I wrote that I realised that it's not true --
given an infix ^ operator like you propose, the in-place
version of it would actually give the desired re
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 Tue, Jun 12, 2018 at 5:34 AM Michel Desmoulin
wrote:
[..]
> But even if I have spoken up then, my experience with Python-idea is
that most of the time, people would have told me "no". They would have
told me that "nobody is going to do that".
> I'm getting used to it. It took me a lot of time
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 Wed, Jun 13, 2018 at 5:46 PM, Chris Angelico wrote:
> On Thu, Jun 14, 2018 at 12:40 AM, Mikhail V wrote:
>> L1 = L2 ^ item
>> is
>> L1 = L2 + [item]
>>
>> and
>> L ^= item
>> is
>> L.append(item)
>> or
>> L += [item]
>
> Okay. Now it all is coherent and makes perfect sense... but you're
> off
[Richard Damon]
> My first comment is that special casing values like this can lead to
> some very undesirable properties when you use the function for numerical
> analysis. Suddenly your sind is no longer continuous (sind(x) is no
> longer the limit of sind(x+d) as d goes to 0).
>
> As I stated i
On Wed, Jun 13, 2018, 06:51 Nick Coghlan wrote:
> On 13 June 2018 at 11:06, Michael Selik wrote:
>
>> Google will probably fix this problem for you after dataclasses become
>> popular. The docs will gain a bunch of inbound links and the issue will
>> (probably) solve itself as time passes.
>>
>
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 have finished my "meta-PEP" for issues with built-in (implemented in
C) functions and methods. This is meant to become an "informational"
(not standards track) PEP for other PEPs to refer to.
You can read the full text at
https://github.com/jdemeyer/PEP-functions-meta
I also give brief ideas
On Thu, Jun 14, 2018 at 12:40 AM, Mikhail V wrote:
> On Wed, Jun 13, 2018 at 5:13 PM, Chris Angelico wrote:
>> On Thu, Jun 14, 2018 at 12:04 AM, Mikhail V wrote:
>>> On Wed, Jun 13, 2018 at 2:15 AM, Greg Ewing
>>> wrote:
Mikhail V wrote:
>
>>> Sorry for repeating myself, the idea was that
On Wed, Jun 13, 2018 at 5:13 PM, Chris Angelico wrote:
> On Thu, Jun 14, 2018 at 12:04 AM, Mikhail V wrote:
>> On Wed, Jun 13, 2018 at 2:15 AM, Greg Ewing
>> wrote:
>>> Mikhail V wrote:
>> Sorry for repeating myself, the idea was that the default meaning is
>> append(),
>> i.e. normal operato
On Thu, Jun 14, 2018 at 12:04 AM, Mikhail V wrote:
> On Wed, Jun 13, 2018 at 2:15 AM, Greg Ewing
> wrote:
>> Mikhail V wrote:
>>>
>
>> My feeling is that inserting is not a frequent enough operation
>> to warrant having its own operator, especially not when there
>> is already a syntax that does
On Wed, Jun 13, 2018 at 2:15 AM, Greg Ewing wrote:
> Mikhail V wrote:
>>
> My feeling is that inserting is not a frequent enough operation
> to warrant having its own operator, especially not when there
> is already a syntax that does the same thing.
Depends on what you count as 'insert' - appen
On 13 June 2018 at 11:06, Michael Selik wrote:
> Google will probably fix this problem for you after dataclasses become
> popular. The docs will gain a bunch of inbound links and the issue will
> (probably) solve itself as time passes.
>
Sometimes when reading a PEP it isn't especially clear exa
>> 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
Op wo 13 jun. 2018 13:12 schreef Richard Damon :
> My first comment is that special casing values like this can lead to
> some very undesirable properties when you use the function for numerical
> analysis. Suddenly your sind is no longer continuous (sind(x) is no
> longer the limit of sind(x+d) a
My first comment is that special casing values like this can lead to
some very undesirable properties when you use the function for numerical
analysis. Suddenly your sind is no longer continuous (sind(x) is no
longer the limit of sind(x+d) as d goes to 0).
As I stated in my initial comment on this
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
2018-06-13 12:08 GMT+02:00 Robert Vanden Eynde :
> Then of you also want 45, you could do % 15 ? :D
>
Sure, but how the lookup is done in the Python reference code is
ultimately not so important, since it will need to be rewritten in C
if it is to be included in the math package (math is C-only).
Then of you also want 45, you could do % 15 ? :D
Le mer. 13 juin 2018 à 12:07, Stephan Houben a
écrit :
> 2018-06-13 12:00 GMT+02:00 Robert Vanden Eynde :
>
>> What was wrong with my initial implementation with a lookup table ? :D
>>
>> def sind(x):
>> if x % 90 == 0:
>> return (0, 1
2018-06-13 12:00 GMT+02:00 Robert Vanden Eynde :
> What was wrong with my initial implementation with a lookup table ? :D
>
> def sind(x):
> if x % 90 == 0:
> return (0, 1, 0, -1)[int(x // 90) % 4]
> else:
> return sin(radians(x))
>
I kinda missed it, but now you ask:
1.
What was wrong with my initial implementation with a lookup table ? :D
def sind(x):
if x % 90 == 0:
return (0, 1, 0, -1)[int(x // 90) % 4]
else:
return sin(radians(x))
If you want to support multiples of 30, you can do % 30 and // 30.
Le mer. 13 juin 2018 à 09:51, Stephan
Op di 12 jun. 2018 12:41 schreef Nathaniel Smith :
> On Tue, Jun 12, 2018, 00:03 Stephan Houben wrote:
>
>> Hi all,
>>
>> I wrote a possible implementation of sindg:
>>
>> https://gist.github.com/stephanh42/336d54a53b31104b97e46156c7deacdd
>>
>> This code first reduces the angle to the [0,90] int
47 matches
Mail list logo
