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):
On Mon, May 21, 2018 at 11:22:17AM -0700, Chris Barker wrote:
> On Sat, May 19, 2018 at 6:52 AM, Steven D'Aprano
> wrote:
>
> > Philosophical arguments about the nature of computer memory aside, byte
> > objects in Python are collections of ints.
> >
>
> not when you start talking about bit-wise
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 Sat, May 19, 2018 at 6:52 AM, Steven D'Aprano
wrote:
> Philosophical arguments about the nature of computer memory aside, byte
> objects in Python are collections of ints.
>
not when you start talking about bit-wise operations :-)
If a "byte" in python was an integer, then we'd use b**2 rath
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
27 matches
Mail list logo
