Le 20/05/2018 à 03:43, Steven D'Aprano a écrit :
I've somewhat arbitrarily cut the list off at "languages ranked above 1%
on TIOBE", but we have to cut the list of somewhere. And of course in
certain specific industries the standard languages may be very
different, e.g. there are still tens of m
I thought this thread did a good job of establishing that looking at other
languages
is not going to help with introducing assignment expressions into Python.
It was still
interesting to read.
If we can't copy from other languages (or even agree on *which* languages
to copy),
Python will have to d
On Tue, May 22, 2018 at 11:45 AM, Brendan Barnwell
wrote:
> On 2018-05-21 12:11, Chris Angelico wrote:
>>
>> Much more useful would be to look at languages that (a) work in a
>> field where programmers have ample freedom to choose between
>> languages, and (b) have been around long enough to actua
On 2018-05-21 12:11, Chris Angelico wrote:
Much more useful would be to look at languages that (a) work in a
field where programmers have ample freedom to choose between
languages, and (b) have been around long enough to actually
demonstrate that people want to use them. Look through the Stack
Ov
I don't know what to do with this thread. I enjoyed reading Mike's survey
of what other languages do. I also enjoyed Chris's survey of what some
other languages do. Then the thread veered off into several unproductive
directions at once: a mini-tutorial for Rebol (or Red?), and endless
bickering ab
On Mon, May 21, 2018 at 7:40 PM, Steven D'Aprano wrote:
> On Mon, May 21, 2018 at 09:43:45AM -0700, Mike Miller wrote:
>> To clarify there were three main criteria, and one minor. Newer,
>> popular/becoming industry standard, and designed to address shortcomings in
>> previous generations. Final
On Tue, May 22, 2018 at 10:45 AM, Mike Miller wrote:
>
> On 2018-05-21 16:40, Steven D'Aprano wrote:
>
> Consider the link Chris sent above:
>
> https://insights.stackoverflow.com/survey/2018/#most-loved-dreaded-and-wanted
>
> The top six coincide with my list, plus TypeScript (superset of JS) and
On 2018-05-21 16:40, Steven D'Aprano wrote:
Consider the link Chris sent above:
https://insights.stackoverflow.com/survey/2018/#most-loved-dreaded-and-wanted
The top six coincide with my list, plus TypeScript (superset of JS) and Python.
I'm pretty happy with those chosen, considering.
-Mik
On 2018-05-21 16:50, Steven D'Aprano wrote:
Your conclusion does not follow even from the limited sample of
They're not going in the direction of assignment-expressions everywhere, but
rather one built in to the if/while statement.
Coffeescript could certainly be a good candidate, though fa
On Mon, May 21, 2018 at 10:00:01AM -0700, Mike Miller wrote:
> It is true that := handles more (perhaps less-common) use cases, but
> subjectively it is not as "Pythonic." Also doesn't appear to be the
> direction the surveyed languages are going.
Your conclusion does not follow even from the
On Mon, May 21, 2018 at 09:43:45AM -0700, Mike Miller wrote:
> To clarify there were three main criteria, and one minor. Newer,
> popular/becoming industry standard, and designed to address shortcomings in
> previous generations. Finally, the limit of my energy when already working
> on a proj
If the ability to capture a subexpression is given up on, then we are are
down to
just capturing the value of the predicate in if statements. In loops, it is
only the
predicate and iteration index.
If you mashup `if` and `def`, you end up with this mess:
if get_something() def (value):
Chris makes a lot of good points regarding *which* languages to look at, but
it seems like that line of enquiry is unlikely to suggest anything more
than it
has so far, especially if we're limiting it to languages everyone has heard
of.
They either use a keyword, an operator, don't support the feat
On Tue, May 22, 2018 at 2:43 AM, Mike Miller wrote:
> To clarify there were three main criteria, and one minor. Newer,
> popular/becoming industry standard, and designed to address shortcomings in
> previous generations. Finally, the limit of my energy when already working
> on a project.
Note
On 5/21/2018 9:14 AM, Rhodri James wrote:
On 21/05/18 12:29, Daniel Moisset wrote:
On 21 May 2018 at 12:05, Rhodri James
wrote:
with my usual use cases. What I normally want is the Python
equivalent of:
while ((v = get_something()) != INCONVENIENT_SENTINEL)
do_something(v);
Tha
On 2018-05-21 05:22, Juancarlo Añez wrote:
>
This is a good summary of the choices. I think the second one is a good
compromise. More elegant, yet avoiding the problems with assignment-expressions
available everywhere.
It is true that := handles more (perhaps less-common) use cases, but
s
To clarify there were three main criteria, and one minor. Newer,
popular/becoming industry standard, and designed to address shortcomings in
previous generations. Finally, the limit of my energy when already working on a
project.
I also should have provided the link to the previous discussio
>
> for v in iter(get_something, INCOVENIENT_SENTINEL):
> do_something(v)
>
> There are many ways round my use case, all of them inelegant. That has to
> be one of the less comprehensible alternatives.
In for-loops (because they include an assignment already) we can improve
this with more i
On 21/05/18 13:22, Juancarlo Añez wrote:
while ((v = get_something()) != INCONVENIENT_SENTINEL)
do_something(v);
The current pattern in Python would be something like:
v = get_something()
while v != INCONVENIENT_SENTINEL:
do_something(v)
v = get_something()
Actually mo
On 21/05/18 12:29, Daniel Moisset wrote:
On 21 May 2018 at 12:05, Rhodri James wrote:
Thanks for the analysis, but I'm afraid I must disagree with your
recommendation. It was the thought I first had when Chris came out with
his first draft of the PEP several months ago, but it's not enough t
Sorry, hit send by accident. I meant to say:
do_something(v) *if* v != INCONVENIENT_SENTINEL *else break*
-- Carl Smith
carl.in...@gmail.com
On 21 May 2018 at 13:37, Carl Smith wrote:
> v = get_something()
>
> while v != INCONVENIENT_SENTINEL:
>
> do_something(v)
>
> v = get_someth
v = get_something()
while v != INCONVENIENT_SENTINEL:
do_something(v)
v = get_something()
I'd personally go with:
while True:
v = get_something()
if v != INCONVENIENT_SENTINEL: break
do_something(v)
But it's not much different. I'd really like to be ab
> while ((v = get_something()) != INCONVENIENT_SENTINEL)
> do_something(v);
>
The current pattern in Python would be something like:
v = get_something()
while v != INCONVENIENT_SENTINEL:
do_something(v)
v = get_something()
With "as" allowed in "while", they pattern might be:
w
On Mon, May 21, 2018, 03:58 Rhodri James wrote:
> On 20/05/18 06:19, Matt Arcidy wrote:
> > On Sat, May 19, 2018, 11:07 Kirill Balunov
> wrote:
> >
> >>
> >>
> >> I think I have a very strong argument "why are not others valid" -
> Because
> >> already three months have passed and among 1300+ me
On 21 May 2018 at 12:05, Rhodri James wrote:
>
> Thanks for the analysis, but I'm afraid I must disagree with your
> recommendation. It was the thought I first had when Chris came out with
> his first draft of the PEP several months ago, but it's not enough to cope
> with my usual use cases. Wh
On 19/05/18 01:54, Mike Miller wrote:
In short, extend the "if/elif", "while", and comprehension to:
if pattern.search(data) as match:
…
while read_next_item() as value:
…
Thanks for the analysis, but I'm afraid I must disagree with your
recommendation. It was th
On 20/05/18 06:19, Matt Arcidy wrote:
On Sat, May 19, 2018, 11:07 Kirill Balunov wrote:
I think I have a very strong argument "why are not others valid" - Because
already three months have passed and among 1300+ messages there was not a
single real example where assignment expression would b
> > print(child_pid) # child_pid is undefined
>
> Why on earth would it be undefined?
>
Indeed, users would expect the new uses of "as" to behave as the previous
ones. The problem is that "with" and "except" do things differently:
In [*1*]: *import* *os*
In [*2*]: *with* open(os.path.expandus
[Tim, on Rebol/Red]
>> >> x: 12 y: 13
>> == 13
>> >> [x y]
>> == [x y]
>> >>
>> >> do [x y]
>> == 13
[Greg Ewing ]
> How does scoping work? If you pass a block to a function
> which evaluates it, how are names in the block resolved?
Too involved, but basically a form of lexical scoping. Rebol
st
On Sun, May 20, 2018 at 10:57:39AM -0700, Mike Miller wrote:
> You seem determined to throw out requirements when it suits. One of which
> was for newer languages.
YOU are the one who changed the requirements: first you said "newer
languages", then you changed it to industry standard.
I showed
On Sun, May 20, 2018 at 02:53:46PM -0400, Juancarlo Añez wrote:
> This shouldn't be:
>
> if os.fork() as child_pid:
> parent(child_pid)
> else:
>child()
>
> print(child_pid) # child_pid is undefined
Why on earth would it be undefined?
Anyway, if you want to propose an alternative to
Tim Peters wrote:
x: 12 y: 13
== 13
[x y]
== [x y]
do [x y]
== 13
How does scoping work? If you pass a block to a function
which evaluates it, how are names in the block resolved?
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
htt
[Tim]
>> I was an early REBOL user, and my head still hurts ;-) It was ...
>> different, for sure.
[Steven D'Aprano ]
> Yeah, to me it looks more like a prefix version of Forth than Lisp.
> Complete with "anything can be a name":
The example I gave just strung "words" together, but just as
funda
Anyone can trivially construct a scope that limits applicable cases to
support a specific point. This thread is pointless without full context.
On Sun, May 20, 2018, 11:05 Mike Miller wrote:
> For more background, this is the thread that inspired this one:
>
> https://mail.python.org/piper
> What would be the benefit of adding the "as child_pid" syntax? The
> full assignment expression syntax completely covers all the jobs that
> you can do with a capturing if statement.
>
>
The "as" syntax over "if" and "while" may go in with all the restrictions
and caveats already discussed.
The
For more background, this is the thread that inspired this one:
https://mail.python.org/pipermail/python-dev/2018-April/153071.html
-Mike
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
C
You seem determined to throw out requirements when it suits. One of which was
for newer languages. While this thread's original post was not so specific on
that, in a previous post (I believe you read) defined that as created in the
"last decade or so". The ones created to address shortcoming
On Mon, May 21, 2018 at 1:19 AM, Juancarlo Añez wrote:
> IMPORTANT NOTE:
>
> Enabling "as" in "if" and "while" doesn't have to be at the expense of some
> form of assignment expression. We've been having this discussion as if has
> to be either one or the other, and there's no reason we can't hav
On Sun, May 20, 2018 at 1:35 AM, Steven D'Aprano
wrote:
>
> but maybe when languages are weird enough they all look the same :-)
>
>
https://www.dreamsongs.com/WorseIsBetter.html
Look at what happened with PERL...
IMPORTANT NOTE:
Enabling "as" in "if" and "while" doesn't have to be at the ex
Steven D'Aprano wrote:
Yeah, to me it looks more like a prefix version of Forth than Lisp.
Throf?
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/p
On Sun, May 20, 2018 at 12:21:16AM -0500, Tim Peters wrote:
> I was an early REBOL user, and my head still hurts ;-) It was ...
> different, for sure.
[...]
Yeah, to me it looks more like a prefix version of Forth than Lisp.
Complete with "anything can be a name":
> Yup! "i1+2=3*88" is a vari
[Steven D'Aprano ]
> ...
> Red (2011)
> ...
> ... claims to be nearly identical to Rebol.
>
> Wikipedia describes Rebol (and presumably Red) as not having either
> expressions or statements in usual sense. Based on my reading, it is
> kinda-sorta like Forth except without the stack or the postfix s
On Sat, May 19, 2018, 11:07 Kirill Balunov wrote:
>
>
> I think I have a very strong argument "why are not others valid" - Because
> already three months have passed and among 1300+ messages there was not a
> single real example where assignment expression would be convenient or
> useful outside
On Sun, May 20, 2018 at 11:43 AM, Steven D'Aprano wrote:
> Out of those industry standard languages (as ranked by TIOBE, other
> methodology may result in other rankings) we find:
>
> 8/12 have some form of assignment expressions;
> (Java, C, C++, C#, PHP, Javascript, Ruby, R)
>
> 4/12 do not (Pyt
On Sat, May 19, 2018 at 04:28:10PM -0700, Mike Miller wrote:
>
> On 2018-05-19 06:41, Steven D'Aprano wrote:
> >Details follow below.
>
> Thanks for this, had some more time to read it more closely. Correct me if
> I'm probably wrong, but most of these are not used by many. Except perhaps:
Ac
On 2018-05-19 16:00, Chris Angelico wrote:
But you can't put a comparison after the assignment, if it's part of
the syntax of the 'if' statement. That's not how grammar works. So you
have two options: either the ONLY thing you can capture is the
condition value (which you already know to be trut
On 2018-05-19 06:41, Steven D'Aprano wrote:
Details follow below.
Thanks for this, had some more time to read it more closely. Correct me if I'm
probably wrong, but most of these are not used by many. Except perhaps:
- Typescript, which is constrained by a compatibility goal with JavaScri
On Sun, May 20, 2018 at 8:56 AM, Mike Miller wrote:
>
> On 2018-05-18 19:14, Chris Angelico wrote:
>>
>> Yes, largely because it's insufficient for all but a small handful of
>> situations. I mentioned that in the previous email.
>
>
> I'd argue that they are the bulk of occurrences, that's why th
On 2018-05-18 19:14, Chris Angelico wrote:
Yes, largely because it's insufficient for all but a small handful of
situations. I mentioned that in the previous email.
I'd argue that they are the bulk of occurrences, that's why they've been chosen
as the compromise in those languages.
Once the
On Sat, May 19, 2018 at 9:40 AM, Mike Miller
wrote:
>
> On 2018-05-19 06:41, Steven D'Aprano wrote:
>
>> Thanks for writing up the summary, but you have picked a very narrow
>> subset of new languages. One might even say a biased subset. How about
>> these new languages?
>>
>
> Certainly. I chos
On 2018-05-18 18:10, Chris Angelico wrote:
The bit that you tag on as an afterthought is actually critically
important here. You have two options:
1) The 'as' is part of the syntax of the 'if' and 'while' statements; or
This first choice appears the more conservative compromise that several h
Also meant to mention, I didn't pick them specifically in advance to match a
goal. I was mildly surprised at their similar design on that front.
-Mike
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/pytho
> JavaScript and PHP are abysmally designed languages, so we should
> put little weight on any precedent they set.
JavaScript has issues, due to its unique history, but to dismiss
the entire language as too poorly designed to take seriously...
Many clever people prefer JS to Python.
-- Carl Smi
On Sun, May 20, 2018 at 4:07 AM, Kirill Balunov wrote:
> [Chris]
>
>> The bit that you tag on as an afterthought is actually critically
>> important here. You have two options:
>> 1) The 'as' is part of the syntax of the 'if' and 'while' statements; or
>> 2) The 'as' is part of the definition of a
2018-05-19 3:54 GMT+03:00 Mike Miller :
> Background:
>
> While the previous discussions about assignment-expressions (PEP 572)
> (abbreviated AE below) have been raging one thing that was noticeable is
> that
> folks have been looking back to C for a solution.
>
> But how are newer languages solv
On 2018-05-19 06:41, Steven D'Aprano wrote:
TypeScript (2012)
- a strict superset of Javascript, including assignment expressions
Hack (2014)
- a (not quite full) superset of PHP, including assignment expressions
Overall your list is fair, and you're right that more languages could
be consi
On 2018-05-19 06:41, Steven D'Aprano wrote:
Thanks for writing up the summary, but you have picked a very narrow
subset of new languages. One might even say a biased subset. How about
these new languages?
Certainly. I chose basically on whether it was well used (popular), I'd heard
about it,
Thanks for writing up the summary, but you have picked a very narrow
subset of new languages. One might even say a biased subset. How about
these new languages?
Elixir, Elm, TypeScript, Hack, Julia, Perl6, Ring, LiveScript,
Ballerina, Crystal, Opa, Red, Ceylon
TL;DR
At least 10 out of these 1
On Sat, May 19, 2018 at 02:11:38PM +1200, Greg Ewing wrote:
> Chris Angelico wrote:
> >The 'as' syntax has been hammered out in great detail and is no longer
> >recommended due to its negative interactions with existing constructs.
>
> Allowing it in arbitrary expressions has been ruled out on
> t
On Sat, May 19, 2018 at 4:12 PM, Greg Ewing wrote:
> Paul Svensson wrote:
>
>> I don't quite get what's so subtle about it, am I missing something?
>>
>> The "with" keyword calls "__enter__", and "as" gives it a name.
>>
>> Just like "-x + y" is different from "-(x + y)",
>
>
> I think the differe
Paul Svensson wrote:
I don't quite get what's so subtle about it, am I missing something?
The "with" keyword calls "__enter__", and "as" gives it a name.
Just like "-x + y" is different from "-(x + y)",
I think the difference is that mentally one already tends to
think of "with x as y" being
On Sat, 19 May 2018, Greg Ewing wrote:
Chris Angelico wrote:
The 'as' syntax has been hammered out in great detail and is no longer
recommended due to its negative interactions with existing constructs.
Allowing it in arbitrary expressions has been ruled out on
the grounds that the difference
On 19 May 2018 at 10:54, Mike Miller wrote:
> Background:
>
> While the previous discussions about assignment-expressions (PEP 572)
> (abbreviated AE below) have been raging one thing that was noticeable is
> that
> folks have been looking back to C for a solution.
>
> But how are newer languages
On 2018-05-18 17:54, Mike Miller wrote:
> Background:
>
> While the previous discussions about assignment-expressions (PEP 572)
> (abbreviated AE below) have been raging one thing that was noticeable
is that
> folks have been looking back to C for a solution.
>
> But how are newer languages solv
On Sat, May 19, 2018 at 12:11 PM, Greg Ewing
wrote:
> Chris Angelico wrote:
>>
>> The 'as' syntax has been hammered out in great detail and is no longer
>> recommended due to its negative interactions with existing constructs.
>
>
> Allowing it in arbitrary expressions has been ruled out on
> the
Chris Angelico wrote:
The 'as' syntax has been hammered out in great detail and is no longer
recommended due to its negative interactions with existing constructs.
Allowing it in arbitrary expressions has been ruled out on
the grounds that the difference between "with x as y:" and
"with (x as y
Conclusions
>
>
> It appears assignment expressions are no longer the favored solution for
> the
> "assign and compare" use case. Not one of these five newer languages
> supports
> them fully, as the language generations from C to C# did.
>
> Of those that have recognized the use case
On Sat, May 19, 2018 at 10:54 AM, Mike Miller wrote:
> In short, extend the "if/elif", "while", and comprehension to:
>
> if pattern.search(data) as match:
> …
>
> while read_next_item() as value:
> …
>
> May be best to disallow multiple assignment/conditions for now, but u
68 matches
Mail list logo
