On Thu, Oct 24, 2019 at 1:20 AM Christopher Barker wrote:
>
> On Wed, Oct 23, 2019 at 5:42 AM Rhodri James wrote:
>>
> frankly, the | is obscure to most of us. And it started as "bitwise or", and
> evokes the __or__ magic method -- so why are we all convinced that somehow
> it's inextricably li
On Oct 23, 2019, at 22:45, Greg Ewing wrote:
>
> Andrew Barnert via Python-ideas wrote:
>> Someone earlier in this thread said we could optimize calling split on a
>> string literal, just as we can and do optimize iterating over a list literal
>> in a for statement.
>> The counter argument—which
> On 24 Oct 2019, at 01:02, Christopher Barker wrote:
>
>
>> On Sun, Oct 13, 2019 at 12:52 PM Andrew Barnert via Python-ideas
>> wrote:
>
>> The main problem is that a str is a sequence of single-character str, each
>> of which is a one-element sequence of itself, etc. forever. If you wan
Andrew Barnert via Python-ideas wrote:
Someone earlier in this thread said we could optimize calling split on a
string literal, just as we can and do optimize iterating over a list literal
in a for statement.
The counter argument—which I thought you were adding onto—is that this would
be bad bec
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 separator makes some sense (not knowing Mongolian in the
> least).
D'uh! stupid bug:
> Is this the same code points identified by `str.isspace`?
>
> I haven't checked -- so I will:
>
> and the answer is no:
>
> wrong, the answer is yes:
$ python weird_spaces.py
x x x xx x x x x x x x x x x xx x x xx
['x', 'x', 'x', 'x\u180ex', 'x', 'x', 'x', 'x', 'x', 'x', 'x
On Wed, Oct 23, 2019 at 6:04 PM David Mertz wrote:
> Is this the same code points identified by `str.isspace`?
>
I haven't checked -- so I will:
and the answer is no:
$ python weird_spaces.py
x x x xx x x x x x x x x x x xx x x xx
['x', 'x', 'x', 'x\u180ex', 'x', 'x', 'x', 'x', 'x', 'x', 'x'
There's a reason I've never actually proposed adding a char
On Wed, Oct 23, 2019 at 5:34 PM Andrew Barnert wrote:
> Well, just adding a char type (and presumably a way of defining char
literals) wouldn’t be too disruptive.
sure.
> But changing str to iterate chars instead of strs, that pr
Is this the same code points identified by `str.isspace`?
Thanks for doing that. I would have soon otherwise. Still, "most of them"
isn't actually a precise answer for an uncertain string. :-)
On Wed, Oct 23, 2019, 8:57 PM Christopher Barker
wrote:
> On Wed, Oct 23, 2019 at 5:53 PM Andrew Barne
On Wed, Oct 23, 2019 at 5:53 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> > To be fair, I also don't know which of those split on str.split() with
> no arguments to the method either.
>
I couldn't resist -- the answer is most of them:
#!/usr/bin/env python
weird_spaces
On Oct 23, 2019, at 16:26, David Mertz wrote:
>
> To be fair, I also don't know which of those split on str.split() with no
> arguments to the method either.
I would assume the rule is the same rule used by str.isspace, and that this
rule is either the simple one (category is Zs) or the full o
On Oct 23, 2019, at 16:00, Christopher Barker wrote:
>
>> On Sun, Oct 13, 2019 at 12:52 PM Andrew Barnert via Python-ideas
>> wrote:
>
>> The main problem is that a str is a sequence of single-character str, each
>> of which is a one-element sequence of itself, etc. forever. If you wanted to
On Wed, Oct 23, 2019 at 7:17 PM David Mertz wrote:
> Contains any of the following (non-escaped) characters. If they occur
> inside quotes, it seems straightforward, but in this new '%w[]' thing, who
> knows?
>
> U+00A0 NO-BREAK SPACE foo bar As a space, but often not adjusted
> U+1680 OGHAM SPAC
On Wed, Oct 23, 2019, 4:31 PM Steven D'Aprano
> David, you literally wrote the book on text processing in Python. I think
> you are being disingenious here, and below when you describe a standard
> string hex-escape \x20 that has been in Python forever and in just about
> all C-like languages as "
On Sun, Oct 13, 2019 at 12:52 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> The main problem is that a str is a sequence of single-character str, each
> of which is a one-element sequence of itself, etc. forever. If you wanted
> to change this, I think it would make more s
On Thu, Oct 24, 2019 at 12:34 AM Richard Musil wrote:
> Can we agree on the reply from Serhiy and close this discussion?
>
> The proposed change does not bring any advantage apart from few saved
> keystrokes and even that is questionable, because it makes the code more
> prone to misreading/misin
On Wed, Oct 23, 2019 at 4:33 PM Serhiy Storchaka
wrote:
> 23.10.19 14:00, Steven D'Aprano пише:
> > So please do educate me Serhiy, which one is the One Obvious Way that we
> > should all agree is the right thing to do?
>
> If you need a constant number, the most obvious way is to write it as a
>
On Thu, Oct 24, 2019 at 9:12 AM Christopher Barker wrote:
>
> On Wed, Oct 23, 2019 at 1:41 PM Steven D'Aprano wrote:
>> Virtually overnight, the Python community got used to the opposite
>> change, with f-strings: something that looks like a string is actually
>> code containing identifiers and e
On Wed, Oct 23, 2019 at 1:41 PM Steven D'Aprano wrote:
> In another comment, you asserted that we all have editors that help
> with typing quotes. Don't you have an editor that formats identifiers
> differently from string literals?
>
OK -- but which is it? do we expect people to have smart edit
On Oct 23, 2019, at 13:10, Steven D'Aprano wrote:
>
> David, you literally wrote the book on text processing in Python. I
> think you are being disingenious here, and below when you describe a
> standard string hex-escape \x20 that has been in Python forever and in
> just about all C-like lang
On Wed, Oct 23, 2019 at 09:06:49AM -0700, Christopher Barker wrote:
> As for:
>
> %w[red green blue]
>
> The [] make it pretty clear at a glance that I'm dealing with a list -- but
> the lack of quotes is really likely to confuse me -- particularly if I have
> identifiers with similar names!
In
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_items:
for another in more_items:
On Wed, Oct 23, 2019 at 12:02:37PM -0400, David Mertz wrote:
> >
> >
> > > colors2 = "cyan forest green burnt umber".split()
> > > # oops, not what I wanted, quote each separately
Ha, speaking about "Oops" moments, I *totally* failed to notice that
"forest green" is intended to be a single col
Jan Greis wrote:
> On 22/10/2019 06:43, Richard Musil wrote:
> > It is not a "concatenation" though, because you lost
> > {"key1": "val1"}
> > in the process. The concatenation is not _just_ "writing something
> > after something", you can do it with anything, but the actual
> > operation, produ
I don't see what's wrong with `["one", "two", "three"]`. It's the most explicit
and from the compiler perspective it's probably also as optimal as it can get.
Also it doesn't hurt readability. Actually it helps. With syntax highlighting
the word boundaries immediately become clear.
If you're ha
On Wed, Oct 23, 2019 at 1:19 PM Christopher Barker
wrote:
> On Wed, Oct 23, 2019 at 5:42 AM Rhodri James wrote:
>
>> > I'm surprised by that description. I don't think it is just newcomers
>> > who either suggest or prefer plus over pipe, and I don't think that pipe
>> > is "more accurate".
>>
>
Other folks (and I earlier) have explained why we think | is the better choice,
if less obvious.
On 2019-10-22 21:41, Steven D'Aprano wrote:
I think that is patronising to anyone, newbies and experienced
programmers alike, who know and expect that merging dicts with an
operator will have the sa
On Thu, Oct 24, 2019 at 4:22 AM Andrew Barnert via Python-ideas
wrote:
>
> On Oct 23, 2019, at 10:04, Christopher Barker wrote:
> >
> > This talk about optimization is confusing me:
>
> The main argument for why “a b c”.split() is not good enough, and therefore
> we need a new syntax, is that it
On Oct 23, 2019, at 10:04, Christopher Barker wrote:
>
> This talk about optimization is confusing me:
The main argument for why “a b c”.split() is not good enough, and therefore we
need a new syntax, is that it’s “too slow”.
Someone earlier in this thread said we could optimize calling split
On Mon, Oct 21, 2019 at 4:49 PM Brandt Bucher
wrote:
> Meitham Jamaa wrote:
> > The fact dict is a mutable object makes this PEP very complicated.
>
no, it doesn't -- a mutable inside a container of any sort has the same
issues:
Yes, that does cause it's confusion, but this proposal doesn't cha
This talk about optimization is confusing me:
These are literals -- they should only get processed once, generally on
module import.
If you are putting a long list of literal strings inside a tight loop, you
are already not concerned with performance.
Performance is absolutely the LAST reason to
On 23/10/2019 16:16, Steven D'Aprano wrote:
On Wed, Oct 23, 2019 at 03:16:51PM +0100, Rhodri James wrote:
I'm seriously not getting the issue people have with
colours1 = ["red", "green", "blue"]
which has the advantage of saying what it means.
As opposed to the alternatives, which say somet
On Oct 23, 2019, at 03:08, Steven D'Aprano wrote:
>
> It could also be done by a source code preprocessor, or an AST
> transformation, without changing syntax.
>
> But the advantage of changing the syntax is that it becomes the One
> Obvious Way, and you know it will be efficient whatever vers
On Wed, Oct 23, 2019 at 5:42 AM Rhodri James wrote:
> > I'm surprised by that description. I don't think it is just newcomers
> > who either suggest or prefer plus over pipe, and I don't think that pipe
> > is "more accurate".
>
> +1 (as one of the non-newcomers who prefers plus)
>
me too.
fran
On Wed, Oct 23, 2019 at 8:45 AM Chris Angelico wrote:
> > This would be a good argument if Python be a write-only language.
>
> I'm pretty sure the character counts are the same whether you're
> reading or writing. If anything, writing is based on keystrokes, but
> reading is based on characters.
On Wed, Oct 23, 2019 at 11:44 AM Chris Angelico wrote:
> On Thu, Oct 24, 2019 at 2:39 AM Serhiy Storchaka
> wrote:
> >
> > 23.10.19 18:16, Steven D'Aprano пише:
> > > The average word length in English is five characters. That means that
> > > in a list of typical English words, more than a thir
>
>
> > colors2 = "cyan forest green burnt umber".split()
> > # oops, not what I wanted, quote each separately
>
> It isn't shared by the proposal.
>
> colors2 = %w[cyan forest green burnt\x20umber]
>
I don't get it. There is weird escaping of spaces that aren't split? That
is confusing an
On Wed, Oct 23, 2019 at 10:59 AM Steven D'Aprano
wrote:
> On Wed, Oct 23, 2019 at 10:09:41AM -0400, 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
> >
> > Lat
I have to say that I'm really surprised that this idea is gaining this much
traction. And this is why:
Shorthand for a list of stings, whether this proposal, or the "list of
strings".split() "hack" -- is useful primarily for what I"d call
"scripting",rather than "software development".
There is n
On Thu, Oct 24, 2019 at 2:39 AM Serhiy Storchaka wrote:
>
> 23.10.19 18:16, Steven D'Aprano пише:
> > The average word length in English is five characters. That means that
> > in a list of typical English words, more than a third of the expression
> > is made up of the quotes and commas. In the e
23.10.19 18:16, Steven D'Aprano пише:
The average word length in English is five characters. That means that
in a list of typical English words, more than a third of the expression
is made up of the quotes and commas. In the example you give, there are
twelve characters in the words themselves an
On Thu, Oct 24, 2019 at 2:20 AM Steven D'Aprano wrote:
> Hand-writing repetitive, dumb, mechanical code is an anti-pattern. I'm
> sure that, somewhere out there, there's a coder who prefers to write:
>
> [mylist[1], mylist[2], mylist[3], mylist[4], mylist[5]]
>
> instead of the obvious slice,
On Wed, Oct 23, 2019 at 03:16:51PM +0100, Rhodri James wrote:
> I'm seriously not getting the issue people have with
>
> colours1 = ["red", "green", "blue"]
>
> which has the advantage of saying what it means.
As opposed to the alternatives, which say something different from what
they mean?
On Wed, Oct 23, 2019 at 7:03 AM Todd wrote:
> On Sat, Apr 7, 2018 at 4:48 AM Paul Moore wrote:
>
>> On 7 April 2018 at 08:44, Raymond Hettinger
>> wrote:
>> > Agreed that the "chain([x], it)" step is obscure. That's a bit of a
>> bummer -- one of the goals for the itertools module was to be a
On Wed, Oct 23, 2019 at 10:09:41AM -0400, 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,
23.10.19 14:00, Steven D'Aprano пише:
On Wed, Oct 23, 2019 at 01:42:11PM +0300, Serhiy Storchaka wrote:
23.10.19 13:08, Steven D'Aprano пише:
But the advantage of changing the syntax is that it becomes the One
Obvious Way, and you know it will be efficient whatever version or
implementation of
On 23/10/2019 15:09, 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 separate
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
On Wed, Oct 23, 2019, 7:03 AM Steven
On Sat, Apr 7, 2018 at 4:48 AM Paul Moore wrote:
> On 7 April 2018 at 08:44, Raymond Hettinger
> wrote:
> > Agreed that the "chain([x], it)" step is obscure. That's a bit of a
> bummer -- one of the goals for the itertools module was to be a generic
> toolkit for chopping-up, modifying, and spl
On Wed, Oct 23, 2019 at 5:30 AM Steven D'Aprano wrote:
> On Tue, Oct 22, 2019 at 08:53:53PM -0400, Todd wrote:
>
> [I wrote this]
> > > I would expect %w{ ... } to return a set, not a list:
> > >
> > > %w[ ... ] # list
> > > %w{ ... ] # set
> > > %w( ... ) # tuple
> > >
>
> [Todd r
On 23/10/2019 05:41, Steven D'Aprano wrote:
On Tue, Oct 22, 2019 at 11:39:59AM -0700, Mike Miller wrote:
On 2019-10-18 10:23, Ricky Teachey wrote:
but i'm -0 because i am very concerned it will not be obvious to new
learners, without constantly looking it up, whether adding two mappings
togethe
On 22/10/2019 20:53, Steve Jorgensen wrote:
See
https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Literals#The_%_Notation
for what Ruby offers.
For me, the arrays are the most useful aspect.
%w{one two three}
=> ["one", "two", "three"]
This smells like Perl's quoting operators
On 10/23/19 6:07 AM, Ricky Teachey wrote:
I would expect %w{ ... } to return a set, not a list:
%w[ ... ] # list
%w{ ... ] # set
%w( ... ) # tuple
and I would describe them as list/set/tuple "word literals". Unlike
list etc displays [spam, eggs, cheese
> I would expect %w{ ... } to return a set, not a list:
>
> %w[ ... ] # list
> %w{ ... ] # set
> %w( ... ) # tuple
>
> and I would describe them as list/set/tuple "word literals". Unlike
> list etc displays [spam, eggs, cheese] these would actually be true
> literals that can be dete
On Wed, Oct 23, 2019 at 01:42:11PM +0300, Serhiy Storchaka wrote:
> 23.10.19 13:08, Steven D'Aprano пише:
> >But the advantage of changing the syntax is that it becomes the One
> >Obvious Way, and you know it will be efficient whatever version or
> >implementation of Python you are using.
>
> Ther
On Wed, Oct 23, 2019 at 9:23 PM Steven D'Aprano wrote:
>
> On Wed, Oct 23, 2019 at 08:50:06PM +1100, Chris Angelico wrote:
> > On Wed, Oct 23, 2019 at 8:33 PM Steven D'Aprano wrote:
> > > The most complicated feature I can think of is whether we should allow
> > > escaping spaces or not:
> > >
>
23.10.19 13:08, Steven D'Aprano пише:
But the advantage of changing the syntax is that it becomes the One
Obvious Way, and you know it will be efficient whatever version or
implementation of Python you are using.
There is already the One Obvious Way, and you know it will work whatever
version
On Wed, Oct 23, 2019 at 08:50:06PM +1100, Chris Angelico wrote:
> On Wed, Oct 23, 2019 at 8:33 PM Steven D'Aprano wrote:
> > The most complicated feature I can think of is whether we should allow
> > escaping spaces or not:
> >
> > names = %w[Aaron Susan Helen Fred Mary\ Beth]
> > names =
On Wed, Oct 23, 2019 at 11:47:04AM +1100, Chris Angelico wrote:
> This could be done as an optimization without changing syntax or
> semantics.. As long as the initial string is provided as a literal, it
> should be possible to call the method at compile time, since (as far
> as I know) every stri
On Wed, Oct 23, 2019 at 8:33 PM Steven D'Aprano wrote:
> The most complicated feature I can think of is whether we should allow
> escaping spaces or not:
>
> names = %w[Aaron Susan Helen Fred Mary\ Beth]
> names = %w[Aaron Susan Helen Fred Mary%x20Beth]
>
The second one? No. If you want t
On Tue, Oct 22, 2019 at 08:53:53PM -0400, Todd wrote:
[I wrote this]
> > I would expect %w{ ... } to return a set, not a list:
> >
> > %w[ ... ] # list
> > %w{ ... ] # set
> > %w( ... ) # tuple
> >
[Todd replied]
> This is growing into an entire new group of constructors for a ver
From: Andrew Barnert via Python-ideas
>So yes, Christopher is wrong to suggest that the new operators should be
part of Mapping, but only because he should have said (and presumably
meant) MutableMapping.
Indeed I did, thanks. I wasn't really thinking about it, because there
isn't a immutable Map
62 matches
Mail list logo
