[Python-ideas] Re: Suggestion for language addition

On Wed, Dec 4, 2019 at 7:28 PM Jan Bakuwel wrote: > It's clear that I failed to convince even a single person so it's time > to drop it. Great to have this list to test the waters so to speak :-) > This is exactly why not every idea needs a PEP :) Discuss first, PEP later. ChrisA

[Python-ideas] Re: Archiving Threads / Closing Threads

On 04/12/2019 03:50, Abdur-Rahmaan Janhangeer wrote: Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius On Wed, 4 Dec 2019, 07:38 Steven D'Aprano, wrote: What problem are you trying to solve? Are we suffering under a burden of pople

[Python-ideas] Re: Fwd: re.findfirst()

04.12.19 03:46, Oscar Benjamin пише: result = next(re.finditer(...), None) if result is None: # raise or something else: # use result `next(re.finditer(...), None)` is a weird way of writing `re.search(...)`. `next(re.finditer(...), defaults)` is the same as `re.search(...) or

[Python-ideas] Re: Suggestion for language addition

Hi Andrew, On 4/12/19 5:15 pm, Andrew Barnert wrote: On Dec 3, 2019, at 14:34, Jan Bakuwel wrote: People focus on the silly example and suggest that the code needs refactoring but that is besides the point. You’re the one who gave that example as motivation, and who specifically

[Python-ideas] Re: Sets for easy interning(?)

On Wed, Dec 04, 2019 at 07:11:39PM +1300, Greg Ewing wrote: > On 4/12/19 12:53 pm, Soni L. wrote: > >Okay, sometimes it's also used for that. But the main use-case is for > >lowering RAM usage for immutable objects. > > Citation needed. If that's true, why does Python intern > names used in

[Python-ideas] Re: math.copysign not to introduce float

Thanks for all the input! I don't know if I agree that it's a slippery slope, since copysign seems to me of a different nature compared to e.g. sin. How important to use this: Many languages do feature a sign function, if that's of any worth. copysign is python's closest built-in equivalent. I

[Python-ideas] Re: Fwd: re.findfirst()

On Wed, Dec 4, 2019 at 12:34 AM Serhiy Storchaka wrote: > `next(re.finditer(...), None)` is a weird way of writing `re.search(...)`. > > `next(re.finditer(...), defaults)` is the same as `re.search(...) or > defaults`. > Not so fast. re.search() returns a Match object, while re.finditer() and

[Python-ideas] Re: Archiving Threads / Closing Threads

Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius On Wed, 4 Dec 2019, 15:16 Rhodri James, wrote: > > Which is a problem because...? > > -- > Rhodri James *-* Kynesim Ltd > An advantage. If the topic goes round several times, the mods closing

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

03.12.19 20:43, Brett Cannon пише: -1 from me. I can see someone not realizing an operator was changed, assuming it's standard semantics, and then having things break subtly. And debugging this wouldn't be fun either. To me this is monkeypatching without an explicit need for it, i.e. if you

[Python-ideas] Re: Archiving Threads / Closing Threads

On 04/12/2019 12:44, Abdur-Rahmaan Janhangeer wrote: Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius On Wed, 4 Dec 2019, 15:16 Rhodri James, wrote: Which is a problem because...? -- Rhodri James *-* Kynesim Ltd An advantage. If the

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

On 12/04/2019 08:39 AM, Random832 wrote: On Wed, Dec 4, 2019, at 08:26, Serhiy Storchaka wrote: 03.12.19 20:43, Brett Cannon пише: -1 from me. I can see someone not realizing an operator was changed, assuming it's standard semantics, and then having things break subtly. And debugging this

[Python-ideas] Re: math.copysign not to introduce float

[Guido] > I suspect Tim Peters had a good reason to include copysign() rather than > sign(). Tim wasn't involved in this one :-) But copysign is a "recommended" function in IEEE-754, and was eventually added to the C standard (for libm). So supplying it in `math` was really a no-brainer for

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

On Wed, Dec 4, 2019, at 08:26, Serhiy Storchaka wrote: > 03.12.19 20:43, Brett Cannon пише: > > -1 from me. I can see someone not realizing an operator was changed, > > assuming it's standard semantics, and then having things break subtly. > > And debugging this wouldn't be fun either. To me

[Python-ideas] Re: Fwd: re.findfirst()

04.12.19 20:01, Guido van Rossum пише: On Wed, Dec 4, 2019 at 9:18 AM Serhiy Storchaka > wrote: [Guido]  > I think I am +1 on  > adding re.findfirst() as proposed by the OP. It is not clear what it should return. A Match object, a string, a

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

04.12.19 20:24, Guido van Rossum пише: Your example uses sets -- did you mean {3: 4} instead of {3}? Sorry. Yes, I meant {3: 4}. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org

[Python-ideas] Re: Suggestion for language addition

On Wed, Dec 4, 2019, 3:31 AM Jan Bakuwel wrote: > Ada even has "named loops", a really cool feature that allows you to exit > an outer loop inside an inner loop by "exiting" the loop referring to it's > name > While I am among the everybody not convinced by needing "end" constructs, I've often

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

Oh, that’s fair. I don’t think we should update Mapping or MutableMapping. People who want this for their own class can override __or__ and __ror__. On Wed, Dec 4, 2019 at 11:19 Serhiy Storchaka wrote: > 04.12.19 20:18, Guido van Rossum пише: > > On Tue, Dec 3, 2019 at 2:10 AM Serhiy Storchaka

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

On Thu, Dec 5, 2019 at 3:41 AM Random832 wrote: > > On Wed, Dec 4, 2019, at 08:26, Serhiy Storchaka wrote: > > 03.12.19 20:43, Brett Cannon пише: > > > -1 from me. I can see someone not realizing an operator was changed, > > > assuming it's standard semantics, and then having things break subtly.

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

On Wed, Dec 4, 2019, at 11:51, Chris Angelico wrote: > Which of these are you expecting to be detected, and thus cause the > change in bytecode? More or less the same sort of operations where the use of the name super is detected within methods and causes the enclosing class to have a __class__

[Python-ideas] Re: Fwd: re.findfirst()

04.12.19 18:05, Guido van Rossum пише: On Wed, Dec 4, 2019 at 12:34 AM Serhiy Storchaka > wrote: `next(re.finditer(...), None)` is a weird way of writing `re.search(...)`. `next(re.finditer(...), defaults)` is the same as `re.search(...) or

[Python-ideas] Re: Fwd: re.findfirst()

On Wed, Dec 4, 2019 at 9:18 AM Serhiy Storchaka wrote: > [Guido] > > I think I am +1 on > > adding re.findfirst() as proposed by the OP. > > It is not clear what it should return. A Match object, a string, a > tuple, whatever? What should it return if no match found -- None, en > empty string,

[Python-ideas] Re: Fwd: re.findfirst()

Fair enough. I’ll let the OP defend his use case. On Wed, Dec 4, 2019 at 10:51 Serhiy Storchaka wrote: > 04.12.19 20:01, Guido van Rossum пише: > > On Wed, Dec 4, 2019 at 9:18 AM Serhiy Storchaka > > > > wrote: > > > > [Guido] > > > I think I am +1 on > >

[Python-ideas] Re: Archiving Threads / Closing Threads

On 12/04/2019 04:44 AM, Abdur-Rahmaan Janhangeer wrote: An advantage. If the topic goes round several times, the mods closing the topic freezes the thread so that the thread does not gets filled with unnecessary details. By the time the topic has gone around several times, it is already

[Python-ideas] Re: math.copysign not to introduce float

I suspect Tim Peters had a good reason to include copysign() rather than sign(). On Wed, Dec 4, 2019 at 10:28 AM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote: > On Dec 4, 2019, at 06:57, Marein wrote: > > > > I was using it like this: range(start, end, sign(end-start)), to >

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

04.12.19 20:18, Guido van Rossum пише: On Tue, Dec 3, 2019 at 2:10 AM Serhiy Storchaka > wrote: And the same question for |. Should `{} | Mapping()` and `{} | []` work? Ditto -- {} | Mapping() should work, but {} | [] should not. set() | Set() falls back to

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

On Wed, Dec 4, 2019, at 11:49, Ethan Furman wrote: > On 12/04/2019 08:39 AM, Random832 wrote: > > On Wed, Dec 4, 2019, at 08:26, Serhiy Storchaka wrote: > >> 03.12.19 20:43, Brett Cannon пише: > >>> -1 from me. I can see someone not realizing an operator was changed, > >>> assuming it's standard

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

04.12.19 18:39, Random832 пише: On Wed, Dec 4, 2019, at 08:26, Serhiy Storchaka wrote: 03.12.19 20:43, Brett Cannon пише: -1 from me. I can see someone not realizing an operator was changed, assuming it's standard semantics, and then having things break subtly. And debugging this wouldn't be

[Python-ideas] Re: Fwd: re.findfirst()

On Wed, Dec 4, 2019, at 11:05, Guido van Rossum wrote: > Not so fast. re.search() returns a Match object, while re.finditer() > and re.findall() return strings. For people who are just interested in > strings, the Match object is just a distraction. I think I am +1 on > adding re.findfirst() as

[Python-ideas] Re: math.copysign not to introduce float

On Dec 4, 2019, at 06:57, Marein wrote: > > I was using it like this: range(start, end, sign(end-start)), to > automatically have a range going up or down. But that's really the only > concrete case I know. If your only use for non-float-specific copysign would be implementing sign, why not

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

On Tue, Dec 3, 2019 at 5:58 PM Random832 wrote: > On Tue, Dec 3, 2019, at 13:43, Brett Cannon wrote: > > -1 from me. I can see someone not realizing an operator was changed, > > assuming it's standard semantics, and then having things break subtly. > > And debugging this wouldn't be fun either.

[Python-ideas] Re: Suggestion for language addition

On Wed, 4 Dec 2019 at 21:16, Anders Hovmöller wrote: > > On 4 Dec 2019, at 21:28, Soni L. wrote: > >> On 2019-12-04 5:12 p.m., Mike Miller wrote: > >> > >>> On 2019-12-04 11:05, David Mertz wrote: > >>> I've often wanted named loops. I know approaches to this have been > >>> proposed many

[Python-ideas] Re: Suggestion for language addition

> On 4 Dec 2019, at 21:28, Soni L. wrote: > >  > >> On 2019-12-04 5:12 p.m., Mike Miller wrote: >> >>> On 2019-12-04 11:05, David Mertz wrote: >>> I've often wanted named loops. I know approaches to this have been proposed >>> many times, and they all have their own warts. E.g. an ad hoc

[Python-ideas] Re: Suggestion for language addition

On Dec 4, 2019, at 14:56, Oscar Benjamin wrote: > > My suggestion would be to use a > function rather than exceptions: > > stuff = [10, 20, 30] > other_stuff = [1, 2, 3] > > def func(): >for x in stuff: >for y in other_stuff: >print(x, y) >if x + y > 21: >

[Python-ideas] Re: Suggestion for language addition

On 2019-12-04 11:05, David Mertz wrote: I've often wanted named loops. I know approaches to this have been proposed many times, and they all have their own warts. E.g. an ad hoc pseudo code that may or may not match any previous proposal: for x in stuff as outer:     for y in other_stuff as

[Python-ideas] Re: Suggestion for language addition

On 2019-12-04 6:05 p.m., Anders Hovmöller wrote: > On 4 Dec 2019, at 21:28, Soni L. wrote: > >  > >> On 2019-12-04 5:12 p.m., Mike Miller wrote: >> >>> On 2019-12-04 11:05, David Mertz wrote: >>> I've often wanted named loops. I know approaches to this have been proposed many times,

[Python-ideas] Re: Suggestion for language addition

Actually, I found it's rejected PEP: https://www.python.org/dev/peps/pep-3136/. It looks like the first of several ideas there matches my ad hoc syntax. It *was* 2007, in distant pre-walrus memory. But I'm not sure the SC would revisit Guido's ruling. On Wed, Dec 4, 2019, 6:45 PM Andrew Barnert

[Python-ideas] Re: Suggestion for language addition

On 2019-12-04 5:12 p.m., Mike Miller wrote: On 2019-12-04 11:05, David Mertz wrote: I've often wanted named loops. I know approaches to this have been proposed many times, and they all have their own warts. E.g. an ad hoc pseudo code that may or may not match any previous proposal: for x

[Python-ideas] Re: Suggestion for language addition

These are all a little bit ugly IMO. I've never written the contextlib.suppress style, but I have the others. Usually what I'll actually do is: for x in stuff: break_outer = False for y in other_stuff: do_whatever(x, y) if cond: break_outer = True

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

We could treat it as a kind of future statement. If there’s a top level statement that defines the magic identitier we generate the special bytecode. On Wed, Dec 4, 2019 at 12:26 Brett Cannon wrote: > > > On Tue, Dec 3, 2019 at 5:58 PM Random832 wrote: > >> On Tue, Dec 3, 2019, at 13:43, Brett

[Python-ideas] Re: Suggestion for language addition

On Dec 4, 2019, at 12:14, Mike Miller wrote: > >  >> On 2019-12-04 11:05, David Mertz wrote: >> I've often wanted named loops. I know approaches to this have been proposed >> many times, and they all have their own warts. E.g. an ad hoc pseudo code >> that may or may not match any previous

[Python-ideas] Re: Fwd: re.findfirst()

Well said! On Wed, Dec 4, 2019 at 16:33 Juancarlo Añez wrote: > > > On Wed, Dec 4, 2019 at 3:02 PM Guido van Rossum wrote: > >> Fair enough. I’ll let the OP defend his use case. >> > > The OP thinks that the case for wanting just the string for a first regex > match, or a verifiable default if

[Python-ideas] Re: Suggestion for language addition

On Dec 4, 2019, at 16:04, David Mertz wrote: > >  > Actually, I found it's rejected PEP: > https://www.python.org/dev/peps/pep-3136/. > > It looks like the first of several ideas there matches my ad hoc syntax. It > *was* 2007, in distant pre-walrus memory. But I'm not sure the SC would >

[Python-ideas] Re: Suggestion for language addition

On 5/12/19 1:03 pm, David Mertz wrote: Actually, I found it's rejected PEP: https://www.python.org/dev/peps/pep-3136/. It looks like the first of several ideas there matches my ad hoc syntax. It *was* 2007, in distant pre-walrus memory. But I'm not sure the SC would revisit Guido's ruling.

[Python-ideas] Re: Suggestion for language addition

On Dec 4, 2019, at 17:55, Jan Bakuwel wrote: > > > Just read Guido's reason for rejecting named loops, interesting. It seems we > have different ideas about what "code clarity" means and that's perfectly > fine of course. Beauty is in the eye of the beholder. To refer once again to > Ada

[Python-ideas] Re: Suggestion for language addition

05.12.19 04:43, Andrew Barnert via Python-ideas пише: Yes, you have to unlearn it. Exceptions are not that expensive in Python (and in a lot of other modern languages)—but even if they were, you’d still have to deal with the fact that Python uses them pervasively. Every for loop ends with an

[Python-ideas] Re: Fwd: re.findfirst()

> On Wed, Dec 4, 2019 at 16:33 Juancarlo Añez wrote: is troublesome. >> >> The proposed implementation of a findfirst() would handle many common cases, >> and be friendly to newcomers (why do I need to deal with a Match object?), >> specially if the semantics are those of findall(): >> >>

[Python-ideas] Re: Suggestion for language addition

Hi Andrew, On 5/12/19 3:43 pm, Andrew Barnert wrote: On Dec 4, 2019, at 17:55, Jan Bakuwel wrote: Just read Guido's reason for rejecting named loops, interesting. It seems we have different ideas about what "code clarity" means and that's perfectly fine of course. Beauty is in the eye of

[Python-ideas] Re: Fwd: re.findfirst()

On Wed, Dec 4, 2019 at 16:33 Juancarlo Añez > wrote: The OP thinks that the case for wanting just the string for a first regex match, or a verifiable default if there is no match, is way too common, that the advice on the web is not very good (it

[Python-ideas] Re: Archiving Threads / Closing Threads

On Wed, Dec 4, 2019 at 4:47 AM Rhodri James wrote: > Sorry, but that's true of any conversation. If you want information out > of a thread, you are going to have to put in the work of reading and > comprehending it. The only way around that is to get a technical PA to > read and comprehend it