[Python-ideas] Re: Make itertools recipes license easier

On Thu, Oct 24, 2019 at 3:21 PM Guido van Rossum wrote: > OK, let's see if we can do CC0. Todd, do you want to read through the link > Steven gave and find out how we should apply this, either to just the > itertools examples, or possibly to all examples in the docs? > Obviously all examples in

[Python-ideas] Re: Python 4000: Have stringlike objects provide sequence views rather than being sequences

On Oct 24, 2019, at 14:13, Greg Ewing wrote: > > I'm thinking of things like a function to recursively flatten > a nested list. You probably want it to stop when it gets to a > string, and not flatten the string into a list of characters. A function to recursively flatten a nested list should on

[Python-ideas] Re: Make itertools recipes license easier

OK, let's see if we can do CC0. Todd, do you want to read through the link Steven gave and find out how we should apply this, either to just the itertools examples, or possibly to all examples in the docs? On Thu, Oct 24, 2019 at 2:01 PM Steven D'Aprano wrote: > On Thu, Oct 24, 2019 at 12:36:40P

[Python-ideas] Re: Python 4000: Have stringlike objects provide sequence views rather than being sequences

Christopher Barker wrote: wouldn't it? once you got to an object that couldn't be iterated, you'd know you had an atomic value. I'm thinking of things like a function to recursively flatten a nested list. You probably want it to stop when it gets to a string, and not flatten the string into a l

[Python-ideas] Re: Make itertools recipes license easier

On Thu, Oct 24, 2019 at 12:36:40PM -0700, Christopher Barker wrote: > IANAL, but if we could put a clause in the docs that all recipes are in the > public domain, that would be great. The public domain is *exceedingly* problematic. Many juristictions do not have any legal process for putting thin

[Python-ideas] Re: Make itertools recipes license easier

IANAL, but if we could put a clause in the docs that all recipes are in the public domain, that would be great. -CHB On Thu, Oct 24, 2019 at 11:42 AM Todd wrote: > Per Guido's suggestion, I am starting a new thread on this. > > The itertools module documentation has a bunch of recipes that give

[Python-ideas] Make itertools recipes license easier

Per Guido's suggestion, I am starting a new thread on this. The itertools module documentation has a bunch of recipes that give various ways to combine the existing functions for useful tasks. [1] The issue is that these recipes are part of the documentation, and although IANAL, as far as I can t

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

On Oct 23, 2019, at 23:47, Inada Naoki wrote: > > But if we use + for dict merging, I think we should add + to set too. > Then the set has `.union()`, `|` and `+` for the same behavior. I don’t think we really need that. If set and dict have only a tiny bit of overlap in their API today (beyond

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

This is getting a little ridiculous. If you can get by with a single literal list of words, write it once. ...if it's long enough to be annoying or becomes a maintenance burden, use the `split()` idiom. ...if that's considered a "hack" or "bad form", then run it in the shell once and copy/paste

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

On 17/10/2019 14:59:13, Anders Hovmöller wrote: On 17 Oct 2019, at 14:26, Chris Angelico wrote: On Thu, Oct 17, 2019 at 11:08 PM Anders Hovmöller wrote: So how can you get a type error when doing a*b is the real question. And the answer is now obvious: any time the programmer thinks

[Python-ideas] Re: Python 4000: Have stringlike objects provide sequence views rather than being sequences

On Thu, Oct 24, 2019 at 1:13 AM Greg Ewing wrote: > Christopher Barker wrote: > > I've always wondered > > how disruptive it would be to add a char type > > I'm not sure if it would help much. Usually the problem with > strings being sequences of strings lies in the fact that they're > sequences

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

On Wed, Oct 23, 2019 at 11:47 PM Inada Naoki wrote: > So reusing | to set union is very natural to me. > I understand that, and agree -- it made sense to me when set() was introduced. But that wasn't my point -- we are not deciding now what operator to use for set union, we are deciding what op

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

On Thu, Oct 24, 2019 at 7:53 AM Ethan Furman wrote: > > for something in lots_of_items: > > for another in more_items: > > function(spam, eggs, "cyan,forest green,burnt > umber".split(',')) > > If you have a tight loop that is a performance bottleneck (you did > measure

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

> no one can tell what either '+' or '|' does in this context without > guessing, because it does do neither "arithmetic addition", nor > "concatenation", nor "union set" (or bitwise op, or any other op one could > come up). '+' is more familiar or '|' might even be completely new for some > users,

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

On 10/23/2019 01:08 PM, Steven D'Aprano wrote: On Wed, Oct 23, 2019 at 11:59:44AM -0400, Todd wrote: Compare that to: colors2 = "cyan,forest green,burnt umber".split(',') Sure, that's not going away. But consider that you're using this inside a tight loop: for something in lots_of_item

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

On 10/23/2019 01:36 PM, Steven D'Aprano wrote: Virtually overnight, the Python community got used to the opposite change, with f-strings . . . * citation needed -- ~Ethan~ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

On 10/24/2019 04:03 AM, Steven D'Aprano wrote: The current "obvious" solution is tedious, annoying, verbose (about a third longer than it need be) and error-prone.^1 --> print("So should we have syntax for sentence literals" ... "so we don't forget spaces, too?") ^1 I'm gratified to s

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

On 10/24/2019 07:07 AM, Steven D'Aprano wrote: On Thu, Oct 24, 2019 at 02:00:50PM +0100, Rhodri James wrote: The fact is, %w[...] doesn't look like anything else Python does It looks like a list display [...] with a prefix. It looks like gobbledygook. -- ~Ethan~ ___

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

On Thu, Oct 24, 2019 at 02:00:50PM +0100, Rhodri James wrote: > The fact is, %w[...] doesn't look like anything else > Python does It looks like a list display [...] with a prefix. -- Steven ___ Python-ideas mailing list -- python-ideas@python.org T

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

On Thu, Oct 24, 2019, 9:01 AM Rhodri James > I think the strongest argument against both this proposal and the habit of > using split() is that everyone looking at your example string of colours, > including you and me, missed "forest green" the first time round. I noticed that. Is forest green

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

Steven D'Aprano wrote: > We're talking about an operator to copy-and-update a dict, not invade > Iraq. [grin] Fair enough. In the interim, actually, I realized some semantic downsides of using pipe. If a user happens to draw an analogy to logical 'or', the 'which one wins' semantics is differ

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

On 24/10/2019 11:33, Steven D'Aprano wrote: On Wed, Oct 23, 2019 at 06:01:06PM +0100, Rhodri James wrote: The proposed: %w[red green blue] says that this is something, good luck figuring out what. You don't need *luck* to figure out what it does, you need five seconds in the REPL. One of t

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

On Thu, Oct 24, 2019 at 10:01:28AM -, brian.sk...@gmail.com wrote: > So: In most cases, uptake will be slow anyways. I'd rather have it be > a bit slower, and use an operator that will make people think more > carefully about what it does while they're learning to use it. o_O We're talking

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

24.10.19 14:27, David Mertz пише: On Thu, Oct 24, 2019, 7:19 AM Richard Damon > wrote: My one comment about this is to quote from PEP 20, the Zen of Python There should be one-- and preferably only one --obvious way to do it. No problem, the new synta

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

Todd wrote: > Compare that to: > colors2 = "cyan,forest green,burnt umber".split(',') > or, if you follow pep8-style commas: > colors2 = "cyan, forest green, burnt umber".split(', ') > This is one of the many cases where being able to specify the delimiter > helps. That's a very useful suggestion.

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

On Thu, Oct 24, 2019, 7:19 AM Richard Damon wrote: > My one comment about this is to quote from PEP 20, the Zen of Python > > There should be one-- and preferably only one --obvious way to do it. > No problem, the new syntax doesn't risk being obvious! ;-) >

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

David Mertz wrote: > One big problem with the current obvious way would be shared by the > proposal. This hits me fairly often. > colors1 = "red green blue".split() # happy > Later > colors2 = "cyan forest green burnt umber".split() > # oops, not what I wanted, quote each separately Good point

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

For a while I used to use a Perl-inspired `q("red green blue")` as a shortcut. That's one character more than the proposed syntax, I leave the one line implementation to readers.[*] Despite saving some characters, it wasn't important enough to bother keeping in a utility module, let alone song as

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

On 10/23/19 11:27 PM, Andrew Barnert via Python-ideas wrote: > On Oct 23, 2019, at 18:59, Christopher Barker wrote: >> Since I'm doing this, the three that aren't are: >> >> U+180E MONGOLIAN VOWEL SEPARATOR >> U+200B ZERO WIDTH SPACE >> U+FEFF ZERO WIDTH NO-BREAK SPACE >> >> The Mongolian vowel se

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

My one comment about this is to quote from PEP 20, the Zen of Python There should be one-- and preferably only one --obvious way to do it. Yes, this does get broken at times with additions to the language, But this whole proposal to me seems to be an effort to introduce an alternate way to do s

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

On Wed, Oct 23, 2019 at 10:04:36AM -0700, Christopher Barker wrote: > I'm not saying that things like this shouldn't be optimized -- faster > import is a good thing, but I am saying it's not a reason to add a language > feature. I'm not sure why import is relevent here. We're not saying that per

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

On Wed, Oct 23, 2019 at 06:01:06PM +0100, Rhodri James wrote: > The proposed: > > %w[red green blue] > > says that this is something, good luck figuring out what. You don't need *luck* to figure out what it does, you need five seconds in the REPL. One of the most annoying tendencies on this m

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

Christopher Barker wrote: > if | is implemented, I'll bet you dollars to donuts that it will get used > far less than if + were used. > (though some on this thread would think that's a good thing :-) ) > -CHB (Non-beginner, |-preferrer) I think Christopher is correct here, but only to a point. I

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

David Mertz wrote: But it's hard to think of an occasion when I would have needed to enter a space by code point rather than just quoted. If you ever desperately need to enter some Python code using a keyboard with a broken space key, you might be glad to have the option! -- eval('\x70\x72\x6

[Python-ideas] Re: Python 4000: Have stringlike objects provide sequence views rather than being sequences

Christopher Barker wrote: I've always wondered how disruptive it would be to add a char type I'm not sure if it would help much. Usually the problem with strings being sequences of strings lies in the fact that they're sequences at all. Code that operates generically on nested sequences often h