[Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)

Thautwarm Zhao yaoxiansamma at gmail.com
Sun Apr 15 14:58:22 EDT 2018


Dear Steve, I'm sorry to annoy you by my proposal, but I do think using
unicode might be wise in current stage.

\triangleq could be print with unicode number \u225c, and adding plugins to
support typing this in editors could be easy, just simply map \xxx to the
specific unicode char when we press the tab after typing it.

People using Julia language are proud of it but I think it's just something
convenient could be used in any other language.

There are other reasons to support unicode but it's out of this topic.

Although ':=' and '->' are not perfect, in the range of ASCII it seems to
be impossible to find a better one.

<python-ideas-request at python.org> 于 2018年4月16日周一 上午12:53写道:

> Send Python-ideas mailing list submissions to
>         python-ideas at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.python.org/mailman/listinfo/python-ideas
> or, via email, send a message with subject or body 'help' to
>         python-ideas-request at python.org
>
> You can reach the person managing the list at
>         python-ideas-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-ideas digest..."
> Today's Topics:
>
>    1. Re: Rewriting file - pythonic way (Mahmoud Hashemi)
>    2. Re: Start argument for itertools.accumulate() [Was: Proposal:
>       A Reduce-Map Comprehension and a "last" builtin] (Tim Peters)
>    3. Re: Spelling of Assignment Expressions PEP 572 (was post #4)
>       (Steven D'Aprano)
>    4. Re: Rewriting file - pythonic way (Oleg Broytman)
>    5. Re: A cute Python implementation of itertools.tee (Tim Peters)
>
>
>
> ---------- Forwarded message ----------
> From: Mahmoud Hashemi <mahmoud at hatnote.com>
> To: python-ideas <python-ideas at python.org>
> Cc:
> Bcc:
> Date: Sun, 15 Apr 2018 09:10:57 -0700
> Subject: Re: [Python-ideas] Rewriting file - pythonic way
> Depending on how firm your requirements around locking are, you may find
> this code useful:
> https://github.com/mahmoud/boltons/blob/6b0721b6aeda6d3ec6f5d31be7c741bc7fcc4635/boltons/fileutils.py#L303
>
> (docs here:
> http://boltons.readthedocs.io/en/latest/fileutils.html#atomic-file-saving
> )
>
> Basically every operating system has _some_ way of doing an atomic file
> replacement, letting us guarantee that a file at a given location is always
> valid. atomic_save provides a unified interface to that cross-platform
> behavior.
>
> The code does not do locking, as neither I nor its other users have wanted
> it, but I'd be happy to extend it if there's a sensible default.
>
> On Sun, Apr 15, 2018 at 8:19 AM, Oleg Broytman <phd at phdru.name> wrote:
>
>> On Sun, Apr 15, 2018 at 05:15:55PM +0300, Alexey Shrub <ashrub at yandex.ru>
>> wrote:
>> > В Воскресенье, 15 апр. 2018 в 2:40 , Nick Coghlan <ncoghlan at gmail.com>
>> > написал:
>> > > https://bugs.python.org/issue8604#msg174104 is the relevant tracker
>> > > discussion
>> >
>> > Thanks all, I agree that universal and absolutly safe solution is very
>> > difficult, but for experiment I made some draft
>> > https://github.com/worldmind/scripts/tree/master/filerewrite
>>
>>    Good!
>>
>> > main code here
>> >
>> https://github.com/worldmind/scripts/blob/master/filerewrite/filerewrite.py#L46
>>
>>    Can I recommend to catch exceptions in `backuper.backup()`,
>> cleanup backuper and unlock locker?
>>
>> Oleg.
>> --
>>      Oleg Broytman            http://phdru.name/
>> phd at phdru.name
>>            Programmers don't die, they just GOSUB without RETURN.
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
>
>
> ---------- Forwarded message ----------
> From: Tim Peters <tim.peters at gmail.com>
> To: Raymond Hettinger <raymond.hettinger at gmail.com>
> Cc: Python-Ideas <python-ideas at python.org>
> Bcc:
> Date: Sun, 15 Apr 2018 11:15:18 -0500
> Subject: Re: [Python-ideas] Start argument for itertools.accumulate()
> [Was: Proposal: A Reduce-Map Comprehension and a "last" builtin]
> [Raymond Hettinger <raymond.hettinger at gmail.com>]
> > Q. Do other languages do it?
> > A. Numpy, no. R, no. APL, no. Mathematica, no. Haskell, yes.
> >
> >     *
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.ufunc.accumulate.html
> >     *
> https://stat.ethz.ch/R-manual/R-devel/library/base/html/cumsum.html
> >     * http://microapl.com/apl/apl_concepts_chapter5.html
> >       \+ 1 2 3 4 5
> >       1 3 6 10 15
> >     * https://reference.wolfram.com/language/ref/Accumulate.html
> >     * https://www.haskell.org/hoogle/?hoogle=mapAccumL
>
> There's also C++, which is pretty much "yes" to every variation
> discussed so far:
>
> * partial_sum() is like Python's current accumulate(), including
> defaulting to doing addition.
>
> http://en.cppreference.com/w/cpp/algorithm/partial_sum
>
> * inclusive_scan() is also like accumulate(), but allows an optional
> "init" argument (which is returned if specified), and there's no
> guarantee of "left-to-right" evaluation (it's intended for associative
> binary functions, and wants to allow parallelism in the
> implementation).
>
> http://en.cppreference.com/w/cpp/algorithm/inclusive_scan
>
> * exclusive_scan() is like inclusive_scan(), but _requires_ an "init"
> argument (which is not returned).
>
> http://en.cppreference.com/w/cpp/algorithm/exclusive_scan
>
> * accumulate() is like Python's functools.reduce(), but the operation
> is optional and defaults to addition, and an "init" argument is
> required.
>
> http://en.cppreference.com/w/cpp/algorithm/accumulate
>
>
>
>
> ---------- Forwarded message ----------
> From: "Steven D'Aprano" <steve at pearwood.info>
> To: python-ideas at python.org
> Cc:
> Bcc:
> Date: Mon, 16 Apr 2018 02:15:59 +1000
> Subject: Re: [Python-ideas] Spelling of Assignment Expressions PEP 572
> (was post #4)
> On Sun, Apr 15, 2018 at 11:11:37PM +0800, Thautwarm Zhao wrote:
>
> > I think maybe we can use unicode characters like ≜ (\triangleq) and add
> the
> > support of unicode completion to python repl. The unicode completion of
> > editors or ides has been quite mature.
>
> What key combination do I need to type to get ≜ in the following editors
> please? I tried typing \triangleq but all I got was \triangleq.
>
> Notepad (Windows)
> Brackets (Mac)
> BBEdit (Mac)
> kwrite (Linux)
> kate
> nano
> geany
> gedit
>
> as well as IDLE, my mail client (kmail, Thunderbird or mutt), my web
> browsers (Firefox, Opera and Chromium), the interactive interpreter in
> various different consoles, my Usenet client (Pan and KNode) and IRC
> (pidgin).
>
> Oh, having it work in LibreOffice and GoogleApps too would be nice,
> although not essential since I don't often write code in them.
>
> And what decent fonts do I need to install for ≜ to show up as something
> other than a square box ("missing glyph")?
>
>
> --
> Steve
>
>
>
>
> ---------- Forwarded message ----------
> From: Oleg Broytman <phd at phdru.name>
> To: python-ideas at python.org
> Cc:
> Bcc:
> Date: Sun, 15 Apr 2018 18:49:16 +0200
> Subject: Re: [Python-ideas] Rewriting file - pythonic way
> On Sun, Apr 15, 2018 at 09:10:57AM -0700, Mahmoud Hashemi <
> mahmoud at hatnote.com> wrote:
> > Depending on how firm your requirements around locking are, you may find
> > this code useful:
> >
> https://github.com/mahmoud/boltons/blob/6b0721b6aeda6d3ec6f5d31be7c741bc7fcc4635/boltons/fileutils.py#L303
> >
> > (docs here:
> >
> http://boltons.readthedocs.io/en/latest/fileutils.html#atomic-file-saving
> )
> >
> > Basically every operating system has _some_ way of doing an atomic file
> > replacement, letting us guarantee that a file at a given location is
> always
> > valid. atomic_save provides a unified interface to that cross-platform
> > behavior.
> >
> > The code does not do locking, as neither I nor its other users have
> wanted
> > it, but I'd be happy to extend it if there's a sensible default.
>
>    I don't like it renames the file at the end. Renaming could lead to
> changed file ownership and permissions; restoring permissions is not
> always possible, restoring ownership is almost never possible. Renaming
> is also not always possible due to restricted directory permissions.
>
> > On Sun, Apr 15, 2018 at 8:19 AM, Oleg Broytman <phd at phdru.name> wrote:
> >
> > > On Sun, Apr 15, 2018 at 05:15:55PM +0300, Alexey Shrub <
> ashrub at yandex.ru>
> > > wrote:
> > > > В Воскресенье, 15 апр. 2018 в 2:40 , Nick Coghlan <
> ncoghlan at gmail.com>
> > > > написал:
> > > > > https://bugs.python.org/issue8604#msg174104 is the relevant
> tracker
> > > > > discussion
> > > >
> > > > Thanks all, I agree that universal and absolutly safe solution is
> very
> > > > difficult, but for experiment I made some draft
> > > > https://github.com/worldmind/scripts/tree/master/filerewrite
> > >
> > >    Good!
> > >
> > > > main code here
> > > > https://github.com/worldmind/scripts/blob/master/
> > > filerewrite/filerewrite.py#L46
> > >
> > >    Can I recommend to catch exceptions in `backuper.backup()`,
> > > cleanup backuper and unlock locker?
>
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            phd at phdru.name
>            Programmers don't die, they just GOSUB without RETURN.
>
>
>
>
> ---------- Forwarded message ----------
> From: Tim Peters <tim.peters at gmail.com>
> To: Antoine Pitrou <solipsis at pitrou.net>
> Cc: Python-Ideas <python-ideas at python.org>
> Bcc:
> Date: Sun, 15 Apr 2018 11:52:49 -0500
> Subject: Re: [Python-ideas] A cute Python implementation of itertools.tee
> [Antoine Pitrou <solipsis at pitrou.net>]
> > This implementation doesn't work with Python 3.7 or 3.8.
> > I've tried it here:
> > https://gist.github.com/pitrou/b3991f638300edb6d06b5be23a4c66d6
> >
> > and get:
> > Traceback (most recent call last):
> >   File "mytee.py", line 14, in gen
> >     mylast = last[1] = last = [next(it), None]
> > StopIteration
> >
> > The above exception was the direct cause of the following exception:
> >
> > Traceback (most recent call last):
> >   File "mytee.py", line 47, in <module>
> >     run(mytee1)
> >   File "mytee.py", line 36, in run
> >     lists[i].append(next(iters[i]))
> > RuntimeError: generator raised StopIteration
> >
> > (Yuck!)
>
> Thanks for trying!  I wonder whether that will break other code.  I
> wrote PEP 255, and this part was intentional at the time:
>
> """
> If an unhandled exception-- including, but not limited to,
> StopIteration --is raised by, OR PASSES THROUGH [emphasis added], a
> generator function, then the exception is passed on to the caller in
> the usual way, and subsequent attempts to resume the generator
> function raise StopIteration.
> """
>
> I've exploited that a number of times.
>
>
> > In short, you want the following instead:
> >
> >                 try:
> >                     mylast = last[1] = last = [next(it), None]
> >                 except StopIteration:
> >                     return
>
> No, I don't ;-)  If I have to catch StopIteration myself now, then I
> want the entire "white True:" loop in the "try" block.  Setting up
> try/except machinery anew on each iteration would add significant
> overhead; doing it just once per derived generator wouldn't.
>
>
> >>     def mytee(xs, n):
> >>         last = [None, None]
> >>
> >>         def gen(it, mylast):
> >>             nonlocal last
> >>             while True:
> >>                 mylast = mylast[1]
> >>                 if not mylast:
> >>                     mylast = last[1] = last = [next(it), None]
>
> > That's smart and obscure :-o
> > The way it works is that the `last` assignment changes the `last` value
> > seen by all derived generators, while the `last[1]` assignment updates
> > the bindings made in the other generators' `mylast` lists...  It's
> > difficult to find the words to explain it.
>
> Which is why I didn't even try - I did warn people that if they
> thought it "was obvious", they hadn't yet thought hard enough ;-)
> Good job!
>
>
> > The chained assignment makes it more difficult to parse as well (when I
> > read this I don't know if `last[i]` or `last` gets assigned first;
> > apparently the answer is `last[i]`, otherwise the recipe wouldn't work
> > correctly).
>
> Ya, I had to look it up too :-)  Although, like almost everything else
> in Python, chained assignments proceed "left to right".  I was just
> trying to make it as short as possible, to increase the "huh - can
> something that tiny really work?!" healthy skepticism factor :-)
>
>
> >  Perhaps like this:
> >
> >         while True:
> >             mylast = mylast[1]
> >             if not mylast:
> >                 try:
> >                     # Create new list link
> >                     mylast = [next(it), None]
> >                 except StopIteration:
> >                     return
> >                 else:
> >                     # Append to other generators `mylast` linked lists
> >                     last[1] = mylast
> >                     # Update shared list link
> >                     last = last[1]
> >             yield mylast[0]
>
> I certainly agree that's easier to follow.  But that wasn't really the
> point ;-)
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180415/cf6c68c1/attachment-0001.html>


More information about the Python-ideas mailing list