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
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.
>
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
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
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
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
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
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
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.
>
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
> 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
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
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
>
[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
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.
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
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
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
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' -
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
>> 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
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
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
> 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
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)
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
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
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
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,
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,
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]
39 matches
Mail list logo
