Re: [Python-Dev] PEP 572: Assignment Expressions
Replying also to the list. On 22 April 2018 at 09:14, Ivan Levkivskyi wrote: > On 20 April 2018 at 21:59, Guido van Rossum wrote: > >> Does the PEP currently propose to *allow* that horrible example? I >> thought Tim Peters successfully pleaded to *only* allow a single "NAME := >> ". You don't have to implement this restriction -- we know it's >> possible to implement, and if specifying this alone were to pull enough >> people from -1 to +0 there's a lot of hope! >> >> > * FWIW I an -1 on anything but a simple name. > > * Also Tim proposed a good idea to call these "binding expressions". > Because in contrasts the different purposes. Binding expressions would be > probably typically used to (temporarily) name an expression, while > assignment statements are actually creating "variables" -- long living > names intended to be accessed externally to a class/module. The latter > access can be programmed to trigger arbitrary complex code (see properties, > __getattr__/__setattr__, etc). > > * Re implementing restrictions: there is a CST -> AST step that will allow > to easily prohibit unwanted forms (FWIW this is how unpacking an chaining > is prohibited for annotated assignments). > > * Re using plain "=": Although I am still using this in C quite often, I > was bitten badly by this several times when I was younger, I don't want a > similar experience when _learning_ Python. > > Modulo these points I would be +0 on the PEP. > > -- > Ivan > > > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] https://bugs.python.org/issue33127 breaks pip / easy_install / pipenv etc in corporate networks on MS Windows using self-signed certificates
On 17Apr2018 0246, Oleg Sivokon wrote:
> It is common practice in corporate networks that connect MS Windows ...
> If you are referring to Python on Windows, this was never true. We've
> always relied on OpenSSL and at best will read locally installed
> certificates (and by default, most certificates are not locally
> installed). This should not have changed recently, and certainly not
> with the bug you reference.
I was simply parroting whatever our IT people told me. I don't use MS Windows,
and know very little about administration of this OS. I'll be happy to tell
them what you just wrote.
> I'm asking that this be made configurable / possible to disable using simple
> means, perhaps an environment variable / registry key or similar.
> I'm not clear on what you're asking for. The only thing we can disable
> is reading OS certificates into OpenSSL, and that would be the opposite
> of what you are having trouble with.
I'm still investigating what the actual problem was, and what exactly changed.
It might have been related to PyPI using new hosts, but, to be absolutely
honest, pip and similar tools don't make it easy to debug this problem. The
problem with these tools is that they lose all context information about SSL
errors, so it's not possible to know what the exact problem was. Setting up a
development environment on MS Windows to try to debug Python interpreter in
order to discover this information so far has been frustratingly painful (it's
been about a decade since I used MS Windows for anything related to
programming).
> PS. I still cannot register to the bug tracker (never received a confirmation
> email), this is why you are reading this email.
> I would guess it ended up in a junk mail folder, though that may be
> controlled by your organization rather than anywhere you can get to it.
> Perhaps using an alternate email address will be easiest?
No, it was simply never received (maybe it was somehow filtered out by the MS
Exchange filters, I know very little about it, but it never made it to my
mailbox). Whatever the case, I will never know that because, apparently, our
IT are either too lazy or don't know what they are doing...
This communication and all information contained in or attached to it is
confidential, intended solely for the addressee, may be legally privileged and
is the intellectual property of one of the companies of NEX Group plc ("NEX")
or third parties. If you are not the intended addressee or receive this message
in error, please immediately delete all copies of it and notify the sender. We
have taken precautions to minimise the risk of transmitting software viruses,
but we advise you to carry out your own virus checks on any attachments. We do
not accept liability for any loss or damage caused by software viruses. NEX
reserves the right to monitor all communications. We do not accept any legal
responsibility for the content of communications, and no communication shall be
considered legally binding. Furthermore, if the content of this communication
is personal or unconnected with our business, we accept no liability or
responsibility for it. NEX Group plc is a public limited company regi
stered in England and Wales under number 10013770 and certain of its
affiliates are authorised and regulated by regulatory authorities. For further
regulatory information please see www.NEX.com.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
Tim Peters wrote: > [Christoph Groth ] > > I hope to have shown [1] that the same could be done for > > assignments. A consistent value can be defined for any assignment > > statement. So, all assignment statements could be redefined as > > expressions and the language would continue to work and even be > > (perfectly?) backwards-compatible. > > Except for shells. When I type, e.g., > > >>> xs = sorted(iterator_returning_a_billion_strings) > > I really don't want to wait for hours before I can type again ;-) In > the same way now, when someone calls a function at a shell but doesn't > want to see its result, they do something like > > >>> xxx = function(a, b, c) Yes, that's a serious problem with making all assignments expressions. Assignments are so common in interactive use that displaying their values could be quickly annoying. There are several possible solutions. For example, the IPython shell interprets a trailing semicolon as "do not show the result of the expression". A better solution seems to be to only treat assignments that are surrounded by the mandatory parens as expressions and keep the old-style assignments as statements, e.g. >>> a = 3 >>> (a = 3) # currently a SyntaxError 3 So, strictly speaking, there would be distinct assignment statements and expressions, but it would be still easy conceptually because one could say: Any valid assignment statement can be turned into an expression by surrounding it with parentheses. There is no difference in semantics. > There's also that you're not considering the other half: that every > existing assignment statement could be viewed as being as expression > does not imply that every existing assignment statement could be used > everywhere an expression can be used. Syntax matters, and function > call argument lists in particular already bristle with their own > meanings for commas, equal signs, and asterisks. The language was > designed with "and the twain shall never meet" in mind ;-) For > example, what would > > f(a=b) > > mean? It would, of course, mean the same as it does now. (Otherwise backwards compatibility would be broken.) However, f((a=b)) which currently is a syntax error, would mean: bind the value of 'b' to the name 'a' and call 'f' with the value of that expression. The extra parens would be required around any assignment expression. I believe that this also solves all the other problems that you raise with regard to commas etc. So, you see, promoting assignments to expressions is indeed feasible. The advantages are the conceptual simplicity, and the familiar syntax. The syntax is also a disadvantage, because it is somewhat ugly: while (item = get()): process(item) There's also potential for misuse, but firstly that is something that is not unheard of in Python and secondly assignment expressions could be (at least initially) limited to only a subset of the forms that are allowed for assignment statements. If I had to choose between the above and ":= binding expressions", I guess I would tend to prefer the latter because they are sufficient, nicer looking and offer less potential for trouble. But I think that it is worth to fully discuss the above idea as well. IMHO it should be at least briefly mentioned in the "rejected ideas" of PEP 572, because it is arguably the most self-evident way to introduce name-binding expressions into the language. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
On Sun, Apr 22, 2018 at 7:29 PM, Christoph Groth wrote: > If I had to choose between the above and ":= binding expressions", I > guess I would tend to prefer the latter because they are sufficient, > nicer looking and offer less potential for trouble. But I think that it > is worth to fully discuss the above idea as well. IMHO it should be at > least briefly mentioned in the "rejected ideas" of PEP 572, because it > is arguably the most self-evident way to introduce name-binding > expressions into the language. It's in the FAQ. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 561 implemented and minor clarification
On 12 April 2018 at 09:59, Ethan Smith wrote: > Hello, > > I've updated PEP 561 to clarify that any installed stub package should > supersede an installed inline package. In other words if there is: > > /global/site-packages/pkg/ > /user/site-packages/pkg-stubs/ > > Even if pkg in the global site packages is found first and marks that it > supports types, the stub package should supersede it. > > I also point to mypy's docs on its implementation of the PEP (which can be > read about here: https://mypy.readthedocs.io/en/latest/installed_packages. > html). The implementation has been merged into master and will be > available in the 0.590 release. > > This clarification totally makes sense for me. I could easily imagine a scenario where are third party provides more advanced/precise/detailed types for a package that already supports typing. Also thanks for writing the implementation, hopefully, this PEP will be accepted soon and it will solve one of the major problems in typing ecosystem. -- Ivan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Introducing python.zulipchat.com
On 22 April 2018 at 00:05, Brett Cannon wrote: > The Zulip project maintainers are active on our instance so after you join > go to the Zulip stream and start a topic about this. I did - "Zulip -> Sign up". I don't know of a way to put a link to that topic here, but I assume it's findable in the UI. There's been no replies yet. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] https://bugs.python.org/issue33127 breaks pip / easy_install / pipenv etc in corporate networks on MS Windows using self-signed certificates
On 17 April 2018 at 19:46, Oleg Sivokon wrote: > It is common practice in corporate networks that connect MS Windows machines > to redirect all (encrypted included) traffic through company's router. If this has only started happening recently, then the cause is more likely to be related to PyPI switching over to requiring TLS v1.2+ for all client access: a sufficiently outdated man-in-the-middle SSL/TLS proxy may not be able to meet PyPI's client security requirements. See https://pyfound.blogspot.com.au/2017/01/time-to-upgrade-your-python-tls-v12.html for more details. (If that's the problem, it would affect all versions of Python equally though). Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Introducing python.zulipchat.com
On 22 April 2018 at 21:47, Paul Moore wrote: > On 22 April 2018 at 00:05, Brett Cannon wrote: >> The Zulip project maintainers are active on our instance so after you join >> go to the Zulip stream and start a topic about this. > > I did - "Zulip -> Sign up". I don't know of a way to put a link to > that topic here, but I assume it's findable in the UI. For anyone else with the same question: clicking on the topic title in either the side navbar or the stream overview will give you a view specific to the topic that also serves as a shareable link. In this case: https://python.zulipchat.com/#narrow/stream/116410-zulip/topic/Sign.20up Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
2018-04-21 4:44 GMT+03:00 Tim Peters : > [Chris Angelico ] > > I don't see much value in restricting the assignment target to names > > only, but if that's what it takes, it can be restricted, at least > > initially. > > I believe this point was made most clearly before by Terry Reedy, but > it bears repeating :-) This is from the PEP's motivation: > > """ > Naming the result of an expression is an important part of > programming, allowing a descriptive name to be used in place of a > longer expression, and permitting reuse. > """ > > As "head arguments" go, that's a good one! But restricting assignment > expressions to > > identifier ":=" expression > > satisfies it. If what's of value is to name the result of an > expression, that single case handles that and _only_ that. In a > sense, it's "the simplest thing that could possibly work", and that's > generally a good thing to aim for. > > Python assignment _statements_ are way more complex than that. > Besides just giving names to expression results, they can also > implicitly invoke arbitrarily complex __setitem__ and __setattr__ > methods on targets, rely on all sorts of side effects across chained > assignments, and support funky syntax for magically iterating over an > expression's iterable result. > > While that can all be useful _in_ an assignment statement, the PEP's > motivation doesn't say a word about why any of _that_ would also be > useful buried inside an assignment expression. There doesn't appear > to be a good "head argument" for why, besides "why not?". That's not > enough. > I agree with you. During the discussion on python-ideas there was not explicitly suggested to limit assignment target to name only but that was often implicitly implied. So explicit is better than implicit :) The main reason for such criticism was related to the fact that almost all of the examples from the PEP use `name := expression` form. Also it was noted that 99% of use-cases where this feature will be _nice_ to have is `while` and `if` statements (including ternary from). Although one of the prerequisites for writing this PEP was the use of the assignment expression in the lists, it will rarely be used in them, and even more rarely it will be a justified usage of. In addition, in the case of the general assignment expression and the chosen operator `: =`, which solves the problem of distinctness from `==`, I see no reason, or more precisely how to explain, why will not other forms `+=`, `*=` become expressions either? And then we are faced with with all the beauty of side effects, sequnce points, ... And while in Python it's much easier to resolve this - Python will no longer be Python. I'm glad that this does not happen. Since the discussion moves towards a simplified form - `binding expression`, where assignment target can be name only. Will you be _happy_ with the choice of `:=` operator? Which is perceived as `=`, but with very limited capabilities. Therefore, as I see it, with this _limited power_ it is one of design goals to make the syntax forms of `assignment statement` and `assignment expression` to be distinct and `:=` does not help with this. This does not mean that this new syntax form should not be convenient, but it should be different from the usual `=` form. Otherwise, the question about ".1 + .2" will have competitors :-) > I think it's no coincidence that every example of an _intended_ use is > of the simple > > identifier ":=" expression > > form. There are no examples of fancier targets in the PEP, and - more > importantly - also none I saw in the hundreds of mailing-list messages > since this started. Except for a few of mine, where I tried to > demonstrate why _trying_ fancier targets in examples derived from real > code made the original "loop and a half" code _worse_ And where other > people were illustrating how incomprehensibly code _could_ be written > (which isn't a real interest of mine). With kind regards, -gdg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
2018-04-22 14:10 GMT+03:00 Kirill Balunov : > > Although one of the prerequisites for writing this PEP was the use of the > assignment expression in the lists > Sorry, typo: in compehensions/generators. > it will rarely be used in them, and even more rarely it will be a > justified usage of. > With kind regards, -gdg > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Introducing python.zulipchat.com
On 22 April 2018 at 15:39, Nick Coghlan wrote: > On 22 April 2018 at 21:47, Paul Moore wrote: >> On 22 April 2018 at 00:05, Brett Cannon wrote: >>> The Zulip project maintainers are active on our instance so after you join >>> go to the Zulip stream and start a topic about this. >> >> I did - "Zulip -> Sign up". I don't know of a way to put a link to >> that topic here, but I assume it's findable in the UI. > > For anyone else with the same question: clicking on the topic title in > either the side navbar or the stream overview will give you a view > specific to the topic that also serves as a shareable link. In this > case: > > https://python.zulipchat.com/#narrow/stream/116410-zulip/topic/Sign.20up > lol, I'm so used to web apps *not* providing URLs specific to where you are in them (I'm not even sure what the term for this is - "doing the web properly"? :-)) that it never even occurred to me that the link in my browser bar was usable! Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Introducing python.zulipchat.com
On Sunday, April 22, 2018, Paul Moore wrote: > On 22 April 2018 at 15:39, Nick Coghlan wrote: > > On 22 April 2018 at 21:47, Paul Moore wrote: > >> On 22 April 2018 at 00:05, Brett Cannon wrote: > >>> The Zulip project maintainers are active on our instance so after you > join > >>> go to the Zulip stream and start a topic about this. > >> > >> I did - "Zulip -> Sign up". I don't know of a way to put a link to > >> that topic here, but I assume it's findable in the UI. > > > > For anyone else with the same question: clicking on the topic title in > > either the side navbar or the stream overview will give you a view > > specific to the topic that also serves as a shareable link. In this > > case: > > > > https://python.zulipchat.com/#narrow/stream/116410-zulip/ > topic/Sign.20up > > > > lol, I'm so used to web apps *not* providing URLs specific to where > you are in them (I'm not even sure what the term for this is - "doing > the web properly"? :-)) that it never even occurred to me that the > link in my browser bar was usable! "Deep linking" with a "#fragment-identifier". https://en.wikipedia.org/wiki/Deep_linking https://en.wikipedia.org/wiki/Fragment_identifier > > Paul > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > wes.turner%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
On 2018-04-21 19:57, Chris Angelico wrote: Thanks for being patient. Looks like the crux of the issue is that "with … as" binds the result of the enter function rather than the context-manager object, as it might first appear. Therefore it's not compatible with how "as" is used for direct name bindings after "import" statements or this sub-proposal. Additionally, "except Class as instance" names the instance rather than the class. So, the "as" keyword is already operating at an intuitive level rather than idealistic perfection. Three different semantics for import/with/except, correct? This sub-proposal lines up with the import use, I believe. Given that there are no use cases for using assignment-expressions in the import/with/except statements, and it could be documented that if one insists an extra set of parens could make it work: with (callable() as cm_obj) as enter_result_obj: pass It doesn't feel like this issue should be a blocker. TL;DR - Been feebly trying to make the argument that everyday "intuitive consistency" (where the expression will be used) is more important than avoiding theoretical problems. I've never seen complex with/except statements in the wild and don't expect this feature to significantly alter that. -Mike ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
On 2018-04-22 12:37, Chris Angelico wrote: > Kinda, except that that's not quite a match either. But mainly, the > comparison with 'with' and 'except' is dangerously incompatible. Hmm, looks very close conceptually, though mechanics are different. Dangerous feels like an exaggeration however. I've made the argument that occurrences would be very rare, but if I'm wrong, the code should blow up on its first run. Perhaps a sanity check could be put in? There is a section of your PEP that argues against the "bad code could potentially be written" argument, and think it applies here. > Maybe not, but why not just use ':=' to avoid that? Don't hate it but feels like Pascal and C and not "Pythonic." Too many colons, avoiding the questions about the difference between "=" and ":=". Expression first is another win. People know how to use "as". > Intuitive consistency isn't enough to handle complex cases. > Programming languages that favour intuitive consistency end up with a > million special cases. Ok, but I think we have all the tools we need here, there's just an extra place to stub your toe out in the weeds. To turn the question around, are we really worried that this awkward code (or some variant) is about to be written? with (cm_obj := callable()) as enter_result_obj: cm_obj.write() # AttributeError If not, I argue it is a theoretical problem that, if hit, blows up immediately. -Mike ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
On Mon, Apr 23, 2018 at 6:22 AM, Mike Miller wrote:
> On 2018-04-22 12:37, Chris Angelico wrote:
>> Kinda, except that that's not quite a match either. But mainly, the
>> comparison with 'with' and 'except' is dangerously incompatible.
>
> Hmm, looks very close conceptually, though mechanics are different.
>
> Dangerous feels like an exaggeration however. I've made the argument that
> occurrences would be very rare, but if I'm wrong, the code should blow up on
> its first run. Perhaps a sanity check could be put in?
with open(fn) as f:
with (open(fn) as f):
These two do the same thing, but only because a file object's
__enter__ returns self. So it's dangerous, because it WILL work... and
people will get into the habit of parenthesizing to permit a 'with'
statement to go across line breaks. And then they'll use a different
context manager, like closing(), or a PsycoPG2 database connection (I
think), where it returns something else. And it'll work, until they go
over multiple lines, and then suddenly the semantics change. It's as
bad as writing JavaScript code like this:
function f(x) {
return x
+ 1;
}
and then transforming it to this:
function f(x) {
return
x + 1;
}
and having it change in behaviour. (Yes, it happens. Welcome to
JavaScript, where implicit semicolons are a thing.)
>> Intuitive consistency isn't enough to handle complex cases.
>> Programming languages that favour intuitive consistency end up with a
>> million special cases.
>
> Ok, but I think we have all the tools we need here, there's just an extra
> place to stub your toe out in the weeds.
>
> To turn the question around, are we really worried that this awkward code
> (or some variant) is about to be written?
>
> with (cm_obj := callable()) as enter_result_obj:
> cm_obj.write() # AttributeError
>
> If not, I argue it is a theoretical problem that, if hit, blows up
> immediately.
Were it to blow up immediately, I wouldn't be too bothered.
ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
This example makes me want “if expr as name:” (same semantics as ‘with’, and the name is always bound to the expression result regardless of truthiness), but doesn’t move me on assignment expressions. Cheers, Steve Top-posted from my Windows phone From: Guido van Rossum Sent: Saturday, April 21, 2018 19:09 To: Steven D'Aprano Cc: Python-Dev Subject: Re: [Python-Dev] PEP 572: Assignment Expressions On Sat, Apr 21, 2018 at 6:13 PM, Steven D'Aprano wrote: On Sat, Apr 21, 2018 at 08:35:51PM +0100, Matthew Woodcraft wrote: > Well, that's a reason to make the example a bit more realistic, then. > > Say: > > if match := re.search(pat1, text): > do_something_with(match.group(0)) > elif match := re.search(pat2, text): > do_something_else_with(match.group(0), match.group(1)) > elif match := re.search(pat3, text): > do_some_other_things_with(match.group(0)) > and_also_with(match.group(1), match.group(2)) I don't think that a bunch of generic "do_something_with" functions is precisely "realistic". If I saw something like that, I'd try very hard to find a way to refactor it into code like this: for handler in handlers: if handler.match(text): handler.process() break else: # handle no-match case here where the knowledge of what to search for, where to search for it, how to search for it, and what to do when found, was encapsulated in the handler objects. Your tastes may vary. But your point is well-taken that the version with binding assignment (thanks Tim!) is nicer to read than the current procedural version: match = re.search(pat1, text) if match: do_something_with(match.group(0)) else: match = re.search(pat2, text) if match: do_something_else_with(match.group(0), match.group(1)) else: match = = re.search(pat3, text) do_some_other_things_with(match.group(0)) and_also_with(match.group(1), match.group(2)) I just don't think it counts as a motivating use-case distinct from the single match case. The version of this code found in reality is not as regular as the example quoted, and the rebuttal "but I would rewrite it with a loop" shoots a straw man. To me the if-elif-elif portion of the example is very much a separate motivation, since being able to put the assignment in the elif clause avoids runaway indentation. I've regretted not being able to use elif in this kind of situation many times, whereas in the single match case I don't find it a burden to assign the variable in a separate statement preceding the if-clause. (I guess this is a case of "flat is better than nested" -- thanks Tim! :-) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
On 2018-04-22 14:33, Chris Angelico wrote: with open(fn) as f: with (open(fn) as f): These two do the same thing, but only because a file object's __enter__ returns self. So it's dangerous, because it WILL work... and people will get into the habit of parenthesizing to permit a 'with' statement to go across line breaks. And then they'll use a different context manager, like closing(), or a PsycoPG2 database connection (I think), where it returns something else. And it'll work, until they go over multiple lines, and then suddenly the semantics change. Why do you think folks will be rushing to parenthesize with statements when it has always been a syntax error, there is years of code and docs that show otherwise, no use cases, and will take years for 3.8 to trickle out? Seems remote, and there are mitigations that could be done. Again it's back to "people could write bad code," but they already can with only +/* and (). -Mike ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
On Mon, Apr 23, 2018 at 8:20 AM, Mike Miller wrote: > > On 2018-04-22 14:33, Chris Angelico wrote: >> >> with open(fn) as f: >> with (open(fn) as f): >> >> These two do the same thing, but only because a file object's >> __enter__ returns self. So it's dangerous, because it WILL work... and >> people will get into the habit of parenthesizing to permit a 'with' >> statement to go across line breaks. And then they'll use a different >> context manager, like closing(), or a PsycoPG2 database connection (I >> think), where it returns something else. And it'll work, until they go >> over multiple lines, and then suddenly the semantics change. > > > > Why do you think folks will be rushing to parenthesize with statements when > it has always been a syntax error, there is years of code and docs that show > otherwise, no use cases, and will take years for 3.8 to trickle out? Because it's been requested a number of times as a way to allow a 'with' statement to go across lines without backslashes. If it becomes possible, it will be used. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
On Sun, Apr 22, 2018 at 3:13 PM, Steve Dower wrote:
> This example makes me want “if expr as name:” (same semantics as ‘with’,
> and the name is always bound to the expression result regardless of
> truthiness), but doesn’t move me on assignment expressions.
>
In reality there often are other conditions being applied to the match for
which `if expr as name` is inadequate. The simplest would be something like
if ...:
elif (m := re.match('(.*):(.*)', line)) and m.group(1) == m.group(2):
And the match() call may not even be the first thing to check -- e.g. we
could have
elif line is not None and (m := re.match('(.*):(.*)', line)) and
m.group(1) == m.group(2):
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
Please stop debating ` as `. Nobody is being swayed by anything in this subthread. Let's move on. On Sun, Apr 22, 2018 at 3:27 PM, Chris Angelico wrote: > On Mon, Apr 23, 2018 at 8:20 AM, Mike Miller > wrote: > > > > On 2018-04-22 14:33, Chris Angelico wrote: > >> > >> with open(fn) as f: > >> with (open(fn) as f): > >> > >> These two do the same thing, but only because a file object's > >> __enter__ returns self. So it's dangerous, because it WILL work... and > >> people will get into the habit of parenthesizing to permit a 'with' > >> statement to go across line breaks. And then they'll use a different > >> context manager, like closing(), or a PsycoPG2 database connection (I > >> think), where it returns something else. And it'll work, until they go > >> over multiple lines, and then suddenly the semantics change. > > > > > > > > Why do you think folks will be rushing to parenthesize with statements > when > > it has always been a syntax error, there is years of code and docs that > show > > otherwise, no use cases, and will take years for 3.8 to trickle out? > > Because it's been requested a number of times as a way to allow a > 'with' statement to go across lines without backslashes. > > If it becomes possible, it will be used. > > ChrisA > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
[Guido]
> In reality there often are other conditions being applied to the match for
> which `if expr as name` is inadequate. The simplest would be something like
>
> if ...:
>
> elif (m := re.match('(.*):(.*)', line)) and m.group(1) == m.group(2):
>
>
> And the match() call may not even be the first thing to check -- e.g. we
> could have
>
> elif line is not None and (m := re.match('(.*):(.*)', line)) and
> m.group(1) == m.group(2):
I find myself warming more to binding expressions the more I keep them
in mind while writing new code. And I think it may be helpful to
continue showing real examples where they would help.
Today's example: I happened to code this a few hours ago:
diff = x - x_base
if diff:
g = gcd(diff, n)
if g > 1:
return g
It's not really hard to follow, but two levels of nesting "feels
excessive", as does using the names "diff" and "g" three times each.
It's _really_ an "and" test: if the diff isn't 0 and gcd(diff, n) >
1, return the gcd. That's how I _thought_ of it from the start.
Which this alternative expresses directly:
if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
return g
That's so Pythonic I could cry ;-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
