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

I think the set operation of dict_keys accepts any iterable by accident. There is an issue for it: https://bugs.python.org/issue38538 On Wed, Dec 4, 2019 at 4:32 PM Serhiy Storchaka wrote: > > 03.12.19 21:04, Andrew Barnert via Python-ideas пише: > > On Dec 3, 2019, at 02:00, Serhiy Storchaka

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

03.12.19 21:04, Andrew Barnert via Python-ideas пише: On Dec 3, 2019, at 02:00, Serhiy Storchaka wrote: What it will return if implement | for dicts? It should be mentioned in the PEP. It should be tested with a preliminary implementation what behavior is possible and more natural. What is

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

On Dec 3, 2019, at 20:45, Steven D'Aprano wrote: > > 1. A lot of collections define element equality using an identity test > first as an optimization (even if that means that they do the wrong > thing when NANs are involved). So that's prima facie evidence that using > `is` will be faster.

[Python-ideas] Re: Suggestion for language addition

On 4/12/19 1:51 pm, Jan Bakuwel wrote: Has it been rejected as PEP or as an idea? There has never been a PEP on it as far as I remember. Probably because it always gets shot down before it gets anywhere near that stage. One of the probable reasons for that is summed up by "preferably only

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

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 code, but not strings in general? I'd say because looking names up in dicts

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

On Tue, Dec 03, 2019 at 10:26:35AM -0800, Andrew Barnert wrote: > If you’re using interning for functionality, to distinguish two equal > strings that came from different inputs or processes, your code is > probably broken. That's not how interning works. The purpose of interning is to

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

On Dec 3, 2019, at 19:39, Steven D'Aprano wrote: > > I wish people *would* resurrect old threads, rather than just start a > new thread covering the same old ground. At least that way there is a > chance that they may have read the previous correspondence. I agree. And if it were a lot easier

[Python-ideas] Re: Suggestion for language addition

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 highlighted the “more than a page of code” thing; it’s not

[Python-ideas] Re: Suggestion for language addition

On Dec 3, 2019, at 16:54, Jan Bakuwel wrote: > >> On 4/12/19 1:07 pm, Greg Ewing wrote: >>> On 4/12/19 11:06 am, Jan Bakuwel wrote: >>> If being brought up many times, sounds like a perfect candidate for a >>> PEP to me. >> >> The implication is that it has been brought up AND REJECTED

[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, 07:38 Steven D'Aprano, wrote: > What problem are you trying to solve? Are we suffering under a burden of > pople resurrecting old threads from ten years ago, or even a year

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

On Dec 3, 2019, at 17:47, Oscar Benjamin wrote: > > On Tue, 3 Dec 2019 at 12:48, Paul Moore wrote: >> >> My impression is that he was asking for a re.findfirst(...) function >> to give a more discoverable name to the next(re.finditer((...)) idiom. >> >> As a single example of defining a

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

On Dec 3, 2019, at 15:45, Greg Ewing wrote: > > On 4/12/19 7:26 am, Andrew Barnert via Python-ideas wrote: >> If you’re using interning for functionality, to distinguish two equal >> strings that came from different inputs or processes, your code is probably >> broken. > > That's not what

[Python-ideas] Archiving Threads / Closing Threads: HOWTO in Mailman.

Richard Damon writes: > Mailman, the manager for the mailing list doesn’t offer any such > option. The closest that could be done is if a topic just goes on > too long, a filter could be added to the list configuration which > holds for moderation messages which match the subject. The problem

[Python-ideas] Re: Suggestion for language addition

Jan Bakuwel writes: > Interesting. Has it been rejected as PEP or as an idea? In this context "PEP" and "idea" are interchangeable, except that "ideas" aren't listed in PEP 0. > Having a list of "rejected" ideas/PEPs with the reasons why it was > rejected would indeed be great to have. The

[Python-ideas] Re: Suggestion for language addition

Jan Bakuwel writes: > While I like Python a lot, I do miss the support of advanced compilers > that tell me at compile time where I made a typo or logic error so I > find myself spending relatively more time debugging at runtime. That's inherent in an implementation that compiles "just in

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

On Tue, Dec 3, 2019, at 20:46, Oscar Benjamin wrote: > What exactly is the idiom here? > > Using bare next is not a good idea because it leaks StopIteration > which can have awkward side effects. So are you suggesting something > like > > result = next(re.finditer(...), None) > if result is

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

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. To me this is monkeypatching > without an explicit need

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

On Tue, 3 Dec 2019 at 12:48, Paul Moore wrote: > > My impression is that he was asking for a re.findfirst(...) function > to give a more discoverable name to the next(re.finditer((...)) idiom. > > As a single example of defining a dedicated function to replace a > one-liner, I think it's marginal

[Python-ideas] Re: Suggestion for language addition

Hi Guido, On 4/12/19 1:06 pm, Guido van Rossum wrote: I was playing the devil's advocate in jest. There is no way this will be added to Python, for a large variety of sociological and software engineering reasons. While some of the responses may to you seem like they come from inexperienced

[Python-ideas] Re: Suggestion for language addition

Hi Greg, On 4/12/19 1:07 pm, Greg Ewing wrote: On 4/12/19 11:06 am, Jan Bakuwel wrote: If being brought up many times,  sounds like a perfect candidate for a PEP to me. The implication is that it has been brought up AND REJECTED multiple times. But you do have a point -- a rejected PEP

[Python-ideas] Re: Suggestion for language addition

On 4/12/19 11:06 am, Jan Bakuwel wrote: If being brought up many times, sounds like a perfect candidate for a PEP to me. The implication is that it has been brought up AND REJECTED multiple times. But you do have a point -- a rejected PEP would provide documentation of the reasons

[Python-ideas] Re: Suggestion for language addition

I was playing the devil's advocate in jest. There is no way this will be added to Python, for a large variety of sociological and software engineering reasons. While some of the responses may to you seem like they come from inexperienced people who have not carefully read your argument, consider

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

On 2019-12-03 8:44 p.m., Greg Ewing wrote: On 4/12/19 7:26 am, Andrew Barnert via Python-ideas wrote: If you’re using interning for functionality, to distinguish two equal strings that came from different inputs or processes, your code is probably broken. That's not what interning is

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

On 4/12/19 7:26 am, Andrew Barnert via Python-ideas wrote: If you’re using interning for functionality, to distinguish two equal strings that came from different inputs or processes, your code is probably broken. That's not what interning is normally used for. Usually it's to allow test for

[Python-ideas] Re: Where should we put the python-ideas HOWTO?

C. Titus Brown wrote: > put it in the current dev guide somewhere, just so it lands in version > control. > Then iterate on both it and the dev guide. My first thought would be to merge > the content > with this document, > https://github.com/python/devguide/blob/master/langchanges.rst. This

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

Hi Abdur-Rahmaan, On 4/12/19 8:14 am, Abdur-Rahmaan Janhangeer wrote: I suggest we find a way to close a mail thread. Obviously we can't stop people from sending mails,  but, like when a mod sees the topic has been juiced out, he closes the topic which practically means: if mailman sees

[Python-ideas] Re: Suggestion for language addition

Hi all, Thanks for the feedback on the list. I just got here but enjoy the discussion. Here's my summary of what I've read. - What I've suggested has been brought up many times before. In other words, there are a lot of people who think this is useful. - People focus on the silly example

[Python-ideas] Re: Suggestion for language addition

Hi Chris, On 3/12/19 5:07 pm, Christopher Barker wrote: This is a nonstarter — meaningful indentation is a pretty baked-in ( and liked ) part of the language. I know. However why not have something that suits even more people. Meaningful indentation is great (and liked here) too... but it

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

On Dec 3, 2019, at 11:17, Abdur-Rahmaan Janhangeer wrote: > > I suggest we find a way to close a mail thread. Obviously we can't stop > people from sending mails, but, like when a mod sees the topic has been > juiced out, he closes the topic This does already happen, if only by human

[Python-ideas] Re: Suggestion for language addition

Hi Andrew, On 3/12/19 5:48 pm, Andrew Barnert wrote: On Mon, Dec 2, 2019 at 3:12 PM Jan Bakuwel > wrote: Code example: def func (i: int, j: int, k: int) -> None: if (i == 3):     while (i < 15):         i += 1         if (k == 8):        

[Python-ideas] Re: Suggestion for language addition

Hi Andrew, On 3/12/19 9:01 pm, Andrew Barnert wrote: On Dec 2, 2019, at 21:00, Guido van Rossum wrote: 3) I have been known to hold a ruler against my screen to double-check indentation. Well, if that isn’t part of your integrated development environment, you just need to switch to emacs

[Python-ideas] Re: Suggestion for language addition

Hi J, On 3/12/19 9:06 pm, J. Pic wrote: For me it's really easy given your example without the end statements. I suppose your use case is actually about much longer code, with much more cyclomatic complexity. Indeed. I recommend you run McCabe's algorithm instead to help refactor your

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

https://discuss.python.org is an instance of Discourse, which, like mailman, is also open source. https://github.com/discourse/discourse https://meta.discourse.org/t/discourse-moderation-guide/63116 https://gitlab.com/mailman/mailman I agree that Broken thread reply chains would be the likely

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

Ok posted it with the idea than mailman operated on python and the mods were hackers enough to add functionalities. Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius ___ Python-ideas mailing list --

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

> I think the small time difference you noticed is only due to method lookup. I believe it's a bit more than just the Python method lookup, but that makes some difference. Within the C-API, list += other uses list_inplace_concat [1]; whereas list.extend uses _PyList_Extend [2]. They both call

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

On Tue, 3 Dec 2019 at 19:52, Richard Damon wrote: > > Mailman, the manager for the mailing list doesn’t offer any such option. The > closest that could be done is if a topic just goes on too long, a filter > could be added to the list configuration which holds for moderation messages > which

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

Mailman, the manager for the mailing list doesn’t offer any such option. The closest that could be done is if a topic just goes on too long, a filter could be added to the list configuration which holds for moderation messages which match the subject. The problem is that if someone changes the

[Python-ideas] Archiving Threads / Closing Threads

I suggest we find a way to close a mail thread. Obviously we can't stop people from sending mails, but, like when a mod sees the topic has been juiced out, he closes the topic which practically means: if mailman sees mails being sent to a topic closed by a mod, it does not relay it to the list.

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

On Dec 3, 2019, at 02:00, Serhiy Storchaka wrote: > > > I argued for | and |= as lesser evil. But there may be a problem. Dict and > dict keys view are interchangeable in the context of some set operations: > "in" checks for existence of the key and iterating yields keys. Currently > both

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

On Tue, Dec 3, 2019 at 2:00 AM Serhiy Storchaka wrote: > [SNIP] > > ## What about performance? > > It should be mentioned in the PEP that `dict1 | dict2 | dict3` is less > efficient than `{**dict1, **dict2, **dict3}`. > ... in CPython, but is it guaranteed to be faster in e.g. PyPy? We should

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

On Tue, Dec 3, 2019 at 8:29 AM Random832 wrote: > What if there was a general mechanism to allow operators to be implemented > by user code that does not belong to the class? > > If the name [e.g.] __operatorhook_or__ is defined anywhere in a module, > within that module all calls to that

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

On Dec 3, 2019, at 09:05, Serhiy Storchaka wrote: > > Actually the semantic of the above code is different from the semantic of > `re.findall(regex, text)[0]`. findall() yields strings if the pattern > contains less than 2 capture groups and tuples if it more than 1 capture > groups. > > >>>

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

On Wed, Dec 4, 2019 at 5:27 AM Andrew Barnert via Python-ideas wrote: > > By the way, intern was still there until 2.7, but in that list of “we can’t > deprecate these but please never use them” functions at the end of builtins, > so you didn’t actually need 1.5 to test it. But I understand;

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

> On Dec 3, 2019, at 03:41, Steven D'Aprano wrote: > On Tue, Dec 03, 2019 at 01:54:44AM -0800, Andrew Barnert via Python-ideas > wrote: > On Dec 2, 2019, at 16:27, Soni L. wrote: Even use-cases where you have different objects whose differences are ignored for __eq__ and

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

No objection! Brandt > On Dec 3, 2019, at 02:17, Steven D'Aprano wrote: > Brandt, if you are reading this[1], do you have any objection to me > applying to the Steering Council for a BDFL-delegate, or would you > prefer me to wait? ___ Python-ideas

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

I think the small time difference you noticed is only due to method lookup. Le mar. 3 déc. 2019 à 13:57, Kyle Stanley a écrit : > > > Actually there's no need to optimize the |= operator -- for strings we have > > to optimize += *because* strings are immutable, but for dicts we would > >

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

03.12.19 13:53, Juancarlo Añez пише: There are many ugly recipes about to handle the common use case that could be handled by: def findfirst(regex, text, default=None, flags=0):      return next(finditer(regex, text, flags=flags), default=default) Oh, this is the most strange use

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

On Tue, Dec 3, 2019, at 11:36, Ricky Teachey wrote: > > > What if there was a general mechanism to allow operators to be implemented > > by user code that does not belong to the class? > > > > If the name [e.g.] __operatorhook_or__ is defined anywhere in a module, > > within that module all

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

> What if there was a general mechanism to allow operators to be implemented > by user code that does not belong to the class? > > If the name [e.g.] __operatorhook_or__ is defined anywhere in a module, > within that module all calls to that operator are replaced with a two-step > process: > > *

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

What if there was a general mechanism to allow operators to be implemented by user code that does not belong to the class? If the name [e.g.] __operatorhook_or__ is defined anywhere in a module, within that module all calls to that operator are replaced with a two-step process: call

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

> Actually there's no need to optimize the |= operator -- for strings we have to optimize += *because* strings are immutable, but for dicts we would define |= as essentially an alias for .update(), just like the relationship between += and .extend() for lists, and then no unnecessary objects would

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

On Tue, 3 Dec 2019 at 12:07, Steven D'Aprano wrote: > > I'm sorry Juancarlo, it's not clear to me what *precisely* your proposal > is. Are you asking for "findfirst" to be a builtin? A regex helper > function? A method on regex objects? Something else? > My impression is that he was asking for a

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

On 2019-12-03 8:34 a.m., Steven D'Aprano wrote: On Tue, Dec 03, 2019 at 01:54:44AM -0800, Andrew Barnert via Python-ideas wrote: > On Dec 2, 2019, at 16:27, Soni L. wrote: > > > > Even use-cases where you have different objects whose differences are ignored for __eq__ and __hash__ and you

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

Thanks Guido. I have some notes in progress for a third revision of the PEP, but I don't think there's anything critical in them, and certainly nothing that need delay asking for a BDFL-Delegate. Brandt, if you are reading this[1], do you have any objection to me applying to the Steering

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

There are many ugly recipes about to handle the common use case that could be handled by: def findfirst(regex, text, default=None, flags=0): return next(finditer(regex, text, flags=flags), default=default) The matching and return value semantics would be the same as those of

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

On Tue, Dec 03, 2019 at 01:54:44AM -0800, Andrew Barnert via Python-ideas wrote: > On Dec 2, 2019, at 16:27, Soni L. wrote: > > > > Even use-cases where you have different objects whose differences are > > ignored for __eq__ and __hash__ and you want to grab the one from the set > > ignoring

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

Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius On Mon, 2 Dec 2019, 23:55 Guido van Rossum, wrote: > > Also, + is already overloaded enough (numbers, strings, sequences) and we > don't need yet another, different meaning. The | operator

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

03.12.19 07:04, Guido van Rossum пише: Actually there's no need to optimize the |= operator -- for strings we have to optimize += *because* strings are immutable, but for dicts we would define |= as essentially an alias for .update(), just like the relationship between += and .extend() for

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

I general, I am against this proposition. It makes the language more complex without adding any benefit. There are already many ways of merging dicts, including the expression form. It conflicts with Counter. It can make the code more errorprone because + or | for dicts will no longer fail

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

On Dec 2, 2019, at 16:27, Soni L. wrote: > > Even use-cases where you have different objects whose differences are ignored > for __eq__ and __hash__ and you want to grab the one from the set ignoring > their differences would benefit from this. A more concrete use case might help make the

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

On Dec 2, 2019, at 22:40, Random832 wrote: > > The OP wanted to return the object that was in the set. I don't think there's > currently a way to get it in O(1) time Yeah, intersection is basically just {key for key in smaller_set if key in larger_set}, so it’s always going to return the

[Python-ideas] Re: Suggestion for language addition

03.12.19 02:02, Jan Bakuwel пише: Idea: To include optional "end if", "end while", "end for" and "end name>", "end " in the language. The Python interpreter would test that any "end" matches with the correct corresponding statements and have the correct indentation, in other words throw an

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

03.12.19 02:25, Soni L. пише: This is an odd request but it'd be nice if, given a set s = {"foo"}, s["foo"] returned the "foo" object that is actually in the set, or KeyError if the object is not present. Even use-cases where you have different objects whose differences are ignored for

[Python-ideas] Re: Suggestion for language addition

For me it's really easy given your example without the end statements. I suppose your use case is actually about much longer code, with much more cyclomatic complexity. I recommend you run McCabe's algorithm instead to help refactor your code. https://pypi.org/project/mccabe/

[Python-ideas] Re: Suggestion for language addition

On Dec 2, 2019, at 21:00, Guido van Rossum wrote: > > 3) I have been known to hold a ruler against my screen to double-check > indentation. Well, if that isn’t part of your integrated development environment, you just need to switch to emacs and give it control of a 3D printer and a robot and