Re: [Python-Dev] Call for prudence about PEP-572
[Eric V. Smith] > > there is at least one place > where the grammar does forbid you from doing something that would > > otherwise make be allowable: decorators. > [Greg Ewing] > And that was a controversial issue at the time. I don't remember there being much of an objective argument for the restriction -- > it was more or less a matter of "Guido wanted it that way". > Start here: https://mail.python.org/pipermail/python-dev/2004-August/046711.html My favorite in that thread was Michael Hudson vigorously arguing what a sad loss it would be if Python hadn't allowed class C(random.choice([dict, list])): pass ;-) ___ 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] Call for prudence about PEP-572
Eric V. Smith wrote: there is at least one place where the grammar does forbid you from doing something that would otherwise make be allowable: decorators. And that was a controversial issue at the time. I don't remember there being much of an objective argument for the restriction -- it was more or less a matter of "Guido wanted it that way". -- Greg ___ 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] Time for 3.4.9 and 3.5.6
On Sun, Jul 8, 2018, 18:30 Eric V. Smith, wrote: > On 7/8/2018 8:35 PM, Terry Reedy wrote: > > On 7/8/2018 1:05 PM, Ivan Pozdeev via Python-Dev wrote: > >> I'll use this opportunity to remind you that 3.4 build is broken -- it > >> can't be built from start to installer with the instructions given > >> because of outside factors (CPython has migrated from Hg to Git). > >> https://bugs.python.org/issue31623 about this was ignored (see > >> https://bugs.python.org/issue31623#msg303708 for supplemental fixes). > >> > >> If this isn't something considered needing a fix, the claim that 3.4 > >> is supported in any shape and form is but a pretense > > > > Another wild exaggeration that inhibits me, and I suspect others, from > > attending to your legitimate issue. > > Yes, thanks for writing this, Terry. Given Ivan's previous behavior on > his "Drop/deprecate Tkinter?" thread, and combined with this thread, I'm > unlikely to spend my free time on his particular issue here. > Ditto for this specific issue and in general. People forget that we are doing all of this as a kindness for the community since most of us probably don't benefit from another 3.4 release, so any negativity is at best treated with indifference and at worst as de-motivating to any effort into open source (I know for me I'm definitely no longer in the mood to spend my free time on open source today if this is how people are going to treat my hard, volunteer work). -Brett > Eric > ___ > 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/brett%40python.org > ___ 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] Time for 3.4.9 and 3.5.6
On 7/8/2018 8:35 PM, Terry Reedy wrote: On 7/8/2018 1:05 PM, Ivan Pozdeev via Python-Dev wrote: I'll use this opportunity to remind you that 3.4 build is broken -- it can't be built from start to installer with the instructions given because of outside factors (CPython has migrated from Hg to Git). https://bugs.python.org/issue31623 about this was ignored (see https://bugs.python.org/issue31623#msg303708 for supplemental fixes). If this isn't something considered needing a fix, the claim that 3.4 is supported in any shape and form is but a pretense Another wild exaggeration that inhibits me, and I suspect others, from attending to your legitimate issue. Yes, thanks for writing this, Terry. Given Ivan's previous behavior on his "Drop/deprecate Tkinter?" thread, and combined with this thread, I'm unlikely to spend my free time on his particular issue here. Eric ___ 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] Time for 3.4.9 and 3.5.6
On 7/8/2018 1:05 PM, Ivan Pozdeev via Python-Dev wrote: I'll use this opportunity to remind you that 3.4 build is broken -- it can't be built from start to installer with the instructions given because of outside factors (CPython has migrated from Hg to Git). https://bugs.python.org/issue31623 about this was ignored (see https://bugs.python.org/issue31623#msg303708 for supplemental fixes). If this isn't something considered needing a fix, the claim that 3.4 is supported in any shape and form is but a pretense Another wild exaggeration that inhibits me, and I suspect others, from attending to your legitimate issue. -- if something can't be built, it can't be used. but 3.4 source security releases can be built and used on *nix. What is true is that we do not currently support building new releases on XP. We never did for 3.5, and can no longer test for 3.4. Partly as a consequence, we are not currently supporting (updating scripts for) building 3.4 on Windows. But Windows is not all systems. On 08.07.2018 10:45, Larry Hastings wrote: My six-month cadence means it's time for the next releases of 3.4 and 3.5. There haven't been many changes since the last releases--two, to be exact. These two security fixes were backported to both 3.4 and 3.5: * bpo-32981: Fix catastrophic backtracking vulns (GH-5955) * bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) 3.5 also got some doc-only changes related to the online "version switcher" dropdown. (They weren't backported to 3.4 because we don't list 3.4 in the version switcher dropdown anymore.) There are currently no PRs open for either 3.4 or 3.5, I verified that https://bugs.python.org/issue31623 is open and marked for 3.4 and has been so since last September. Unless you think there is plausible chance that it might be applied before the end, I think you should reject and close it now. That said, searching for open 3.4 issues returns 1617 items, almost none of which are even possibly applicable. You cannot even begin to wade thru and fix the headers. Adding type 'security' gives 8 hits, none of which are the 2 above. 4 have patches attached, which need to be turned into PRs to proceed. You might look at these 4. and they also have no open "release blocker" or "deferred blocker" bugs. It seems things are pretty quiet in our two security-fixes-only branches--a good way to be! I therefore propose to cut the RCs in a week and a half, and the finals two weeks later. So: Wednesday July 18 2018 - 3.4.9rc1 and 3.5.6rc1 Wednesday August 1 2018 - 3.4.9 final and 3.5.6 final I presume that this will be the last before the wrap-up next March. -- Terry Jan Reedy ___ 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] Time for 3.4.9 and 3.5.6
On 09.07.2018 1:32, Larry Hastings wrote: On 07/08/2018 10:05 AM, Ivan Pozdeev via Python-Dev wrote: I'll use this opportunity to remind you that 3.4 build is broken -- it can't be built from start to installer with the instructions given because of outside factors (CPython has migrated from Hg to Git). https://bugs.python.org/issue31623 about this was ignored (see https://bugs.python.org/issue31623#msg303708 for supplemental fixes). If this isn't something considered needing a fix, the claim that 3.4 is supported in any shape and form is but a pretense -- if something can't be built, it can't be used. By "3.4 build is broken", you mean that building the installer is broken on Windows. Sadly the maintainer of that installer is no longer part of the Python community, and as a Linux-only dev I have no way of testing any proposed change. Not only that, building the binaries is also broken as per https://bugs.python.org/issue31645 (that's one of the aforementioned "supplemental fixes"). More importantly, 3.4 is in security-fixes-only mode, which means that changes that aren't security fixes won't be accepted. Fixing this would not be a security fix. So even if the patch was clean and well-reviewed and worked perfectly I'm simply not going to merge it into 3.4. The 3.4 tree is only going to be in security-fixes mode for another eight months anyway, after which I will retire as 3.4 release manager, and 3.4 will no longer be supported by the Python core development community at all. I kinda don't see a point of claiming any kind of support and doing any work if the codebase is unusable. All that achieves is confused users and wasted time for everyone involved. If you "a Linux-only dev" and no-one is going to look at the Windows part, why not just say clearly that this version line is not supported outside Linux? I'm okay with that (what is and isn't supported is none of my business). At least, there won't be a nasty surprise when I rely on the team's claim that the code is workable, and it actually isn't -- and another one when I go for the trouble to provide a fix, and is told that I'm a troublemaker and has just massively wasted my and everybody else's time as a thanks. Besides, that'll be a reason to officially close all still-open tickets for 3.4/3.5 (there are about 2000 that are mentioning them) regardless of the topic (I've checked that none are currently marked as security issues). As pointed out in that bpo issue: if the problem is entirely due to switching from "git" to "hg", then you should have very little difficulty working around that. You can use a git-to-hg bridge, or create a local-only hg repo from the 3.4 tree. That should permit you to build your own installers. I'm a little sad that the 3.4 Windows installers no longer build directly out-of-tree without such a workaround, but sometimes that's just what happens with a Python release three major releases out of date languishing in security-fixes-only mode. //arry/ ___ 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/vano%40mail.mipt.ru ___ 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] Call for prudence about PEP-572
Fair enough. I will. Sorry for the extra pressure at this particular stage.
On Mon, 9 Jul 2018 at 00:06, Guido van Rossum wrote:
> Since you CC'ed me explicitly I feel compelled to respond. I have read
> your reasoning, and I simply don't agree with it. A few months ago I would
> have happily explained why (there is a reason) but given the endless debate
> we've already seen I am simply too tired for another long email. Please
> give me the benefit of the doubt. The sky is not falling.
>
> On Sun, Jul 8, 2018 at 2:27 PM Giampaolo Rodola'
> wrote:
>
>> On Sun, Jul 8, 2018 at 7:24 PM Chris Angelico wrote:
>> >
>> > On Mon, Jul 9, 2018 at 3:14 AM, Giampaolo Rodola'
>> wrote:
>> > >
>> > >
>> > > On Sun, Jul 8, 2018 at 6:45 PM Steve Holden
>> wrote:
>> > >>
>> > >> On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola' <
>> g.rod...@gmail.com>
>> > >> wrote:
>> > >>>
>> > >>> [...]
>> > >>> I find that (space between the parentheses of a function call
>> statement)
>> > >>> too unnatural as a place where to put an assignment. It is not even
>> > >>> "guarded" by a keyword like "if" or "while" which can help as
>> indicators
>> > >>> that an assignment may occur. Also, I think it's way too easy to
>> confuse it
>> > >>> with a keyword argument:
>> > >>>
>> > >>> >>> foo(x = 1) # keyword arg
>> > >>> >>> foo(x := 1) # assignment + value passing
>> > >>> [...]
>> > >>
>> > >>
>> > >> But the PEP 8 spellings are
>> > >>
>> > >> foo(x=1)
>> > >>
>> > >> and
>> > >>
>> > >>f(x := 1).
>> > >>
>> > >> The extra spacing makes it obvious that this isn't a regular named
>> > >> argument.
>> > >
>> > >
>> > > What if the author of the code I'm reading didn't respect PEP-8? I
>> don't
>> > > think it's fair to invoke PEP-8 as a counter-measure to obviate a
>> syntax
>> > > which can clearly be mistaken with something else simply by omitting 2
>> > > spaces. Not to mention that I don't see why anyone would want to
>> declare a
>> > > variable in there in the first place.
>> > >
>> >
>> > It's not about why someone would want to assign inside a function
>> > call. It's about why it should be forbidden. Perhaps nobody has a good
>> > reason to use THlS_OBJECT as a variable name, and it's potentially
>> > very confusing; but should the grammar of Python forbid it? No.
>> > Because there is no value in forbidding it.
>>
>> I'll try to give some reasons on why I think it should be forbidden.
>> In order of importance, more or less:
>>
>> 1) Because of readability and because it's ambiguous. foo(x := 1) and
>> foo(x = 1) are visually too similar and mean 2 completely different
>> things. And no, I don't think PEP-8 compliant variants are much
>> better:
>> >>> foo(x := 1)
>> >>> foo(x=1)
>> Good luck explaining the difference between the two to a beginner
>> including the introduction of PEP-8 concepts and why spaces are so
>> important in this case. The fact that spaces are more important here
>> than in other places alone makes me think this is unlikely a good
>> idea.
>>
>> 2) It's an incentive to write more compact code at the expense of
>> readability. I see := being used in "if" and "while" statements as
>> different in this regard. They imply an indented code block will
>> follow and the variables being set in the "if/while" statement will be
>> used right after that, supposedly in the very next line and *in that
>> block only*. This is what
>> https://github.com/python/cpython/pull/8122/files is all about,
>> really. There is no block in this case hence AFAICT this syntax is
>> only meant for writing one-liners.
>>
>> 3) := assignments in {if, while, yield, assert} statements are more
>> clearly noticeable because delimited by such keywords whereas a
>> function call can appear anywhere in the code. The only way to easily
>> track assignments such as foo(x := 1) is via linting.
>>
>> 4) IMO this is the main bit of PEP-572 which can be subject to serious
>> abuse. The value of "explicit is better than implicit" is an advanced
>> concept. We can't expect it can be grasped by everybody. Many folks
>> may be tempted to write one-liners at the top of a function and even
>> feel good about it because a bunch of lines were saved. Potentially *a
>> lot* of lines can be saved so it even more advanced users may be
>> tempted to use it. After all the language allows it + "it's brand new
>> syntax so it must be good".
>>
>> 5) It has no keyword argument correspondence. If foo(x := 1) is
>> allowed then why this one is not?
>> >>> foo(x=(x := 1))
>> (I don't think it should BTW: it's not pretty)
>>
>> 6) Differently from := usage in {if, while, comprehensions} no valid
>> use case which would justify its usage has been provided so far.
>> AFAICT the only valid use case is for writing one-liners.
>>
>> 7) Defining something in there just feels wrong (to me at least)
>>
>> 8) I'm pretty sure any linter would emit a warning by default so why
>> bother adding support for a brand new syntax which we
Re: [Python-Dev] [python-committers] Time for 3.4.9 and 3.5.6
On 07/08/2018 11:50 AM, Ned Deily wrote: On Jul 8, 2018, at 14:23, Julien Palard via Python-Dev wrote: [Larry] 3.5 also got some doc-only changes related to the online "version switcher" dropdown. About this I have a question: the switchers for english version of 3.4 and 3.5 are disabled (https://docs.python.org/3.5/) but not disabled for translations (https://docs.python.org/fr/3.5/). I don't see any mention of dropping them in PEP 101, and I don't think it's a good thing (UX point of view). Should I re-enable version and language switchers on 3.5? I think so and I can do, just give me the go (or the argument/pointers on why it's disabled). I'm not Larry but I believe the reason that the switchers are missing on the on-line versions of 3.4 and 3.5 docs is that we release managers manually build and update the doc sets for release branches that are in security-fix-only mode (and that have been taken out of the automatic docs-build script) and we're not clever enough to know to build them with the switchers enabled. If we can document that in our release process, that would be cool. Yes, exactly! The place to document the process would be PEP 101. (Or, if you wanted to volunteer to handle building and deploying the online docs /for/ the RMs, that works too!) I know there's an automated system that rebuilds the docs on a regular (daily? hourly?) basis for certain versions. I suspect the RMs all have login credentials for the machine where that happens. If you could make it so we could manually kick off a doc rebuild for a specific version (and tell us how to do it) that would be perfect! //arry/ ___ 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] Time for 3.4.9 and 3.5.6
On 07/08/2018 10:05 AM, Ivan Pozdeev via Python-Dev wrote: I'll use this opportunity to remind you that 3.4 build is broken -- it can't be built from start to installer with the instructions given because of outside factors (CPython has migrated from Hg to Git). https://bugs.python.org/issue31623 about this was ignored (see https://bugs.python.org/issue31623#msg303708 for supplemental fixes). If this isn't something considered needing a fix, the claim that 3.4 is supported in any shape and form is but a pretense -- if something can't be built, it can't be used. By "3.4 build is broken", you mean that building the installer is broken on Windows. Sadly the maintainer of that installer is no longer part of the Python community, and as a Linux-only dev I have no way of testing any proposed change. More importantly, 3.4 is in security-fixes-only mode, which means that changes that aren't security fixes won't be accepted. Fixing this would not be a security fix. So even if the patch was clean and well-reviewed and worked perfectly I'm simply not going to merge it into 3.4. The 3.4 tree is only going to be in security-fixes mode for another eight months anyway, after which I will retire as 3.4 release manager, and 3.4 will no longer be supported by the Python core development community at all. As pointed out in that bpo issue: if the problem is entirely due to switching from "git" to "hg", then you should have very little difficulty working around that. You can use a git-to-hg bridge, or create a local-only hg repo from the 3.4 tree. That should permit you to build your own installers. I'm a little sad that the 3.4 Windows installers no longer build directly out-of-tree without such a workaround, but sometimes that's just what happens with a Python release three major releases out of date languishing in security-fixes-only mode. //arry/ ___ 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] Call for prudence about PEP-572
Since you CC'ed me explicitly I feel compelled to respond. I have read your
reasoning, and I simply don't agree with it. A few months ago I would have
happily explained why (there is a reason) but given the endless debate
we've already seen I am simply too tired for another long email. Please
give me the benefit of the doubt. The sky is not falling.
On Sun, Jul 8, 2018 at 2:27 PM Giampaolo Rodola' wrote:
> On Sun, Jul 8, 2018 at 7:24 PM Chris Angelico wrote:
> >
> > On Mon, Jul 9, 2018 at 3:14 AM, Giampaolo Rodola'
> wrote:
> > >
> > >
> > > On Sun, Jul 8, 2018 at 6:45 PM Steve Holden
> wrote:
> > >>
> > >> On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola' <
> g.rod...@gmail.com>
> > >> wrote:
> > >>>
> > >>> [...]
> > >>> I find that (space between the parentheses of a function call
> statement)
> > >>> too unnatural as a place where to put an assignment. It is not even
> > >>> "guarded" by a keyword like "if" or "while" which can help as
> indicators
> > >>> that an assignment may occur. Also, I think it's way too easy to
> confuse it
> > >>> with a keyword argument:
> > >>>
> > >>> >>> foo(x = 1) # keyword arg
> > >>> >>> foo(x := 1) # assignment + value passing
> > >>> [...]
> > >>
> > >>
> > >> But the PEP 8 spellings are
> > >>
> > >> foo(x=1)
> > >>
> > >> and
> > >>
> > >>f(x := 1).
> > >>
> > >> The extra spacing makes it obvious that this isn't a regular named
> > >> argument.
> > >
> > >
> > > What if the author of the code I'm reading didn't respect PEP-8? I
> don't
> > > think it's fair to invoke PEP-8 as a counter-measure to obviate a
> syntax
> > > which can clearly be mistaken with something else simply by omitting 2
> > > spaces. Not to mention that I don't see why anyone would want to
> declare a
> > > variable in there in the first place.
> > >
> >
> > It's not about why someone would want to assign inside a function
> > call. It's about why it should be forbidden. Perhaps nobody has a good
> > reason to use THlS_OBJECT as a variable name, and it's potentially
> > very confusing; but should the grammar of Python forbid it? No.
> > Because there is no value in forbidding it.
>
> I'll try to give some reasons on why I think it should be forbidden.
> In order of importance, more or less:
>
> 1) Because of readability and because it's ambiguous. foo(x := 1) and
> foo(x = 1) are visually too similar and mean 2 completely different
> things. And no, I don't think PEP-8 compliant variants are much
> better:
> >>> foo(x := 1)
> >>> foo(x=1)
> Good luck explaining the difference between the two to a beginner
> including the introduction of PEP-8 concepts and why spaces are so
> important in this case. The fact that spaces are more important here
> than in other places alone makes me think this is unlikely a good
> idea.
>
> 2) It's an incentive to write more compact code at the expense of
> readability. I see := being used in "if" and "while" statements as
> different in this regard. They imply an indented code block will
> follow and the variables being set in the "if/while" statement will be
> used right after that, supposedly in the very next line and *in that
> block only*. This is what
> https://github.com/python/cpython/pull/8122/files is all about,
> really. There is no block in this case hence AFAICT this syntax is
> only meant for writing one-liners.
>
> 3) := assignments in {if, while, yield, assert} statements are more
> clearly noticeable because delimited by such keywords whereas a
> function call can appear anywhere in the code. The only way to easily
> track assignments such as foo(x := 1) is via linting.
>
> 4) IMO this is the main bit of PEP-572 which can be subject to serious
> abuse. The value of "explicit is better than implicit" is an advanced
> concept. We can't expect it can be grasped by everybody. Many folks
> may be tempted to write one-liners at the top of a function and even
> feel good about it because a bunch of lines were saved. Potentially *a
> lot* of lines can be saved so it even more advanced users may be
> tempted to use it. After all the language allows it + "it's brand new
> syntax so it must be good".
>
> 5) It has no keyword argument correspondence. If foo(x := 1) is
> allowed then why this one is not?
> >>> foo(x=(x := 1))
> (I don't think it should BTW: it's not pretty)
>
> 6) Differently from := usage in {if, while, comprehensions} no valid
> use case which would justify its usage has been provided so far.
> AFAICT the only valid use case is for writing one-liners.
>
> 7) Defining something in there just feels wrong (to me at least)
>
> 8) I'm pretty sure any linter would emit a warning by default so why
> bother adding support for a brand new syntax which we already know it
> would be discouraged anyway?
>
> 9) It goes against half of the Python Zen.
>
> --
> Giampaolo - http://grodola.blogspot.com
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing
Re: [Python-Dev] Call for prudence about PEP-572
On Mon, Jul 9, 2018 at 7:27 AM, Giampaolo Rodola' wrote: > 5) It has no keyword argument correspondence. If foo(x := 1) is > allowed then why this one is not? > >>> foo(x=(x := 1)) > (I don't think it should BTW: it's not pretty) Actually it is. Nothing wrong with that. It assigns to 'x' in the local scope, and also passes that as a keyword parameter named 'x'. 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] Call for prudence about PEP-572
On Sun, Jul 8, 2018 at 7:24 PM Chris Angelico wrote:
>
> On Mon, Jul 9, 2018 at 3:14 AM, Giampaolo Rodola' wrote:
> >
> >
> > On Sun, Jul 8, 2018 at 6:45 PM Steve Holden wrote:
> >>
> >> On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola'
> >> wrote:
> >>>
> >>> [...]
> >>> I find that (space between the parentheses of a function call statement)
> >>> too unnatural as a place where to put an assignment. It is not even
> >>> "guarded" by a keyword like "if" or "while" which can help as indicators
> >>> that an assignment may occur. Also, I think it's way too easy to confuse
> >>> it
> >>> with a keyword argument:
> >>>
> >>> >>> foo(x = 1) # keyword arg
> >>> >>> foo(x := 1) # assignment + value passing
> >>> [...]
> >>
> >>
> >> But the PEP 8 spellings are
> >>
> >> foo(x=1)
> >>
> >> and
> >>
> >>f(x := 1).
> >>
> >> The extra spacing makes it obvious that this isn't a regular named
> >> argument.
> >
> >
> > What if the author of the code I'm reading didn't respect PEP-8? I don't
> > think it's fair to invoke PEP-8 as a counter-measure to obviate a syntax
> > which can clearly be mistaken with something else simply by omitting 2
> > spaces. Not to mention that I don't see why anyone would want to declare a
> > variable in there in the first place.
> >
>
> It's not about why someone would want to assign inside a function
> call. It's about why it should be forbidden. Perhaps nobody has a good
> reason to use THlS_OBJECT as a variable name, and it's potentially
> very confusing; but should the grammar of Python forbid it? No.
> Because there is no value in forbidding it.
I'll try to give some reasons on why I think it should be forbidden.
In order of importance, more or less:
1) Because of readability and because it's ambiguous. foo(x := 1) and
foo(x = 1) are visually too similar and mean 2 completely different
things. And no, I don't think PEP-8 compliant variants are much
better:
>>> foo(x := 1)
>>> foo(x=1)
Good luck explaining the difference between the two to a beginner
including the introduction of PEP-8 concepts and why spaces are so
important in this case. The fact that spaces are more important here
than in other places alone makes me think this is unlikely a good
idea.
2) It's an incentive to write more compact code at the expense of
readability. I see := being used in "if" and "while" statements as
different in this regard. They imply an indented code block will
follow and the variables being set in the "if/while" statement will be
used right after that, supposedly in the very next line and *in that
block only*. This is what
https://github.com/python/cpython/pull/8122/files is all about,
really. There is no block in this case hence AFAICT this syntax is
only meant for writing one-liners.
3) := assignments in {if, while, yield, assert} statements are more
clearly noticeable because delimited by such keywords whereas a
function call can appear anywhere in the code. The only way to easily
track assignments such as foo(x := 1) is via linting.
4) IMO this is the main bit of PEP-572 which can be subject to serious
abuse. The value of "explicit is better than implicit" is an advanced
concept. We can't expect it can be grasped by everybody. Many folks
may be tempted to write one-liners at the top of a function and even
feel good about it because a bunch of lines were saved. Potentially *a
lot* of lines can be saved so it even more advanced users may be
tempted to use it. After all the language allows it + "it's brand new
syntax so it must be good".
5) It has no keyword argument correspondence. If foo(x := 1) is
allowed then why this one is not?
>>> foo(x=(x := 1))
(I don't think it should BTW: it's not pretty)
6) Differently from := usage in {if, while, comprehensions} no valid
use case which would justify its usage has been provided so far.
AFAICT the only valid use case is for writing one-liners.
7) Defining something in there just feels wrong (to me at least)
8) I'm pretty sure any linter would emit a warning by default so why
bother adding support for a brand new syntax which we already know it
would be discouraged anyway?
9) It goes against half of the Python Zen.
--
Giampaolo - http://grodola.blogspot.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 575, 576, 579 and 580
On 07/07/18 22:11, Jeroen Demeyer wrote: On 2018-07-07 15:38, Mark Shannon wrote: Hi, We seem to have a plethora of PEPs where we really ought to have one (or none?). - PEP 575 has been withdrawn. - PEP 579 is an informational PEP with the bigger picture; it does contain some of the requirements that you want to discuss here. - PEP 580 and PEP 576 are two alternative implementations of a protocol to optimize callables implemented in C. 5. It should speed up CPython for the standard benchmark suite. I'd like to replace this by: must *not slow down* the standard benchmark suite and preferable should not slow down anything. I've added you suggestion, and everyone else's, to this github repo: https://github.com/markshannon/extended-calling-convention Feel free to comment on github, submit PRs or just email me directly if you have anything else you want to add. Cheers, Mark. ___ 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] [python-committers] Time for 3.4.9 and 3.5.6
On Jul 8, 2018, at 14:23, Julien Palard via Python-Dev wrote: > [Larry] >> 3.5 also got some doc-only changes related to the online "version switcher" >> dropdown. > > About this I have a question: the switchers for english version of 3.4 and > 3.5 are disabled (https://docs.python.org/3.5/) but not disabled for > translations (https://docs.python.org/fr/3.5/). I don't see any mention of > dropping them in PEP 101, and I don't think it's a good thing (UX point of > view). > > Should I re-enable version and language switchers on 3.5? I think so and I > can do, just give me the go (or the argument/pointers on why it's disabled). I'm not Larry but I believe the reason that the switchers are missing on the on-line versions of 3.4 and 3.5 docs is that we release managers manually build and update the doc sets for release branches that are in security-fix-only mode (and that have been taken out of the automatic docs-build script) and we're not clever enough to know to build them with the switchers enabled. If we can document that in our release process, that would be cool. -- Ned Deily n...@python.org -- [] ___ 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] [python-committers] Time for 3.4.9 and 3.5.6
Hi, [Larry] > 3.5 also got some doc-only changes related to the online "version switcher" > dropdown. About this I have a question: the switchers for english version of 3.4 and 3.5 are disabled (https://docs.python.org/3.5/) but not disabled for translations (https://docs.python.org/fr/3.5/). I don't see any mention of dropping them in PEP 101, and I don't think it's a good thing (UX point of view). Should I re-enable version and language switchers on 3.5? I think so and I can do, just give me the go (or the argument/pointers on why it's disabled). Bests, -- Julien Palard https://mdk.fr ___ 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] Call for prudence about PEP-572
I'm sure that only 1 or 2 people cares about my opinion on this, but I will say that PEP 572 is taking one of my least favorite features of C/C++ and adding it to Python. About the only good thing I can say about it is that it might make some things more convenient to write. Worse to read, worse to debug, and definitely less clear unless you've got a comment to explain. At least in my case, the places I use them in C are places I feel *bad* about later. Partly because I know I'm usually trying to over-optimize, but partly because inline assignments are a big enough source of enough security vulnerabilities to make me question *any* language that decides to add them (especially 25+ years after the fact). Like... an entire async syntax and asyncio was modified in 3.6 (coroutine trampolines are tough without syntax, I get you, I did threads instead of dealing with them back in '05 because I couldn't get them quite right), but inline assignments just now? I'm at a loss. On the Python side, I wouldn't accept any patches in any of my projects to include := assignments, because those colons look like monitor grit, and/or a mistake (like someone wanted != but got := ), and means that my 2.6-3.6 compatible code is now 3.7+ only. I get that language evolution is a thing (my failures to try move *this* language in a direction I thought useful is part of why I stopped posting here), but hiding a colon in the middle of a line is not particularly explicit. And it definitely doesn't help for maintaining any of the software that I'm personally responsible for maintaining across the range of Python versions. I know you all don't care about me and my libraries, but at least consider the thousands of other libraries written and maintained by other folks. I mean, unless you all want 3.7+ - only libraries. To me, it seems like a lot of movement to support a feature that a lot of folks straight up don't want. But I don't have my finger on the pulse of Python or Python-dev, so maybe there are a bunch of folks coming from Go, Pascal, Smalltalk, etc., who are jonesin' for a hit of that :=, or have use-cases where this is a huge productivity improvement, and not a glaring security hole waiting to get them. I just don't know. But I also don't see a burning need; I'm 19 years in on this Python train, and I've never needed := before. Reading the PEP, the PR for changes to the Python standard library, email threads in support of the feature, etc., it just doesn't feel compelling. My $2, because that was a bit more than 2 cents worth of opinion, - Josiah On Sun, Jul 8, 2018 at 10:14 AM, Giampaolo Rodola' wrote: > > > On Sun, Jul 8, 2018 at 6:45 PM Steve Holden wrote: > >> On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola' >> wrote: >> >>> [...] >>> I find that (space between the parentheses of a function call >>> statement) too unnatural as a place where to put an assignment. It is >>> not even "guarded" by a keyword like "if" or "while" which can help as >>> indicators that an assignment may occur. Also, I think it's way too easy to >>> confuse it with a keyword argument: >>> >>> >>> foo(x = 1) # keyword arg >>> >>> foo(x := 1) # assignment + value passing >>> [...] >>> >> >> But the PEP 8 spellings are >> >> foo(x=1) >> >> and >> >>f(x := 1). >> >> The extra spacing makes it obvious that this isn't a regular named >> argument. >> > > What if the author of the code I'm reading didn't respect PEP-8? I don't > think it's fair to invoke PEP-8 as a counter-measure to obviate a syntax > which can clearly be mistaken with something else simply by omitting 2 > spaces. Not to mention that I don't see why anyone would want to declare a > variable in there in the first place. > > -- > Giampaolo - http://grodola.blogspot.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/ > josiah.carlson%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] Call for prudence about PEP-572
On 7/8/2018 1:59 PM, Chris Angelico wrote: On Mon, Jul 9, 2018 at 3:55 AM, Eric V. Smith wrote: I agree with Chris in this case. That said, there is at least one place where the grammar does forbid you from doing something that would otherwise make be allowable: decorators. @lookup[0] File "", line 1 @lookup[0] ^ SyntaxError: invalid syntax But this works: new_decorator = lookup[0] @new_decorator ... def f(): pass Thus, the idea of restricting the type of expression that can be used in particular circumstances is not without precedent, and should not be dismissed at face value. That is, unless we want to remove the restriction on decorators, which I'm okay with, too. I have occasionally wanted to do something more complicated with a decorator, and used the workaround above. This is true. I wasn't around when decorator syntax was discussed; what were the reasons for this being the way it is? It isn't simply "'@' test". I was around, but I don't recall the exact reasoning. Something along the lines of YAGNI, I believe. The first reference I found to it is https://mail.python.org/pipermail/python-ideas/2009-September/005623.html, although surely there are older ones, and even this email references an older super-confusing use of lambdas in decorators. In any event, I see no reason to restrict where assignment expressions can be used. Eric ___ 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] Call for prudence about PEP-572
On Mon, Jul 9, 2018 at 3:55 AM, Eric V. Smith wrote: > I agree with Chris in this case. That said, there is at least one place > where the grammar does forbid you from doing something that would otherwise > make be allowable: decorators. > @lookup[0] > File "", line 1 > @lookup[0] >^ > SyntaxError: invalid syntax > > But this works: > new_decorator = lookup[0] @new_decorator > ... def f(): pass > > Thus, the idea of restricting the type of expression that can be used in > particular circumstances is not without precedent, and should not be > dismissed at face value. That is, unless we want to remove the restriction > on decorators, which I'm okay with, too. I have occasionally wanted to do > something more complicated with a decorator, and used the workaround above. > This is true. I wasn't around when decorator syntax was discussed; what were the reasons for this being the way it is? It isn't simply "'@' test". 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] Call for prudence about PEP-572
On 7/8/2018 1:23 PM, Chris Angelico wrote: On Mon, Jul 9, 2018 at 3:14 AM, Giampaolo Rodola' wrote: On Sun, Jul 8, 2018 at 6:45 PM Steve Holden wrote: But the PEP 8 spellings are foo(x=1) and f(x := 1). The extra spacing makes it obvious that this isn't a regular named argument. What if the author of the code I'm reading didn't respect PEP-8? I don't think it's fair to invoke PEP-8 as a counter-measure to obviate a syntax which can clearly be mistaken with something else simply by omitting 2 spaces. Not to mention that I don't see why anyone would want to declare a variable in there in the first place. It's not about why someone would want to assign inside a function call. It's about why it should be forbidden. Perhaps nobody has a good reason to use THlS_OBJECT as a variable name, and it's potentially very confusing; but should the grammar of Python forbid it? No. Because there is no value in forbidding it. Python's grammar has a number of weird edge cases due to necessity (for instance, "for x in a if cond else b:" works, but not in a comprehension), and when there's an actual conflict, sure, you can say "but nobody would ever want to do that, so we'll forbid it". In this case, there is no conflict. I agree with Chris in this case. That said, there is at least one place where the grammar does forbid you from doing something that would otherwise make be allowable: decorators. >>> @lookup[0] File "", line 1 @lookup[0] ^ SyntaxError: invalid syntax But this works: >>> new_decorator = lookup[0] >>> @new_decorator ... def f(): pass Thus, the idea of restricting the type of expression that can be used in particular circumstances is not without precedent, and should not be dismissed at face value. That is, unless we want to remove the restriction on decorators, which I'm okay with, too. I have occasionally wanted to do something more complicated with a decorator, and used the workaround above. Eric ___ 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] Call for prudence about PEP-572
The case I find more reasonable is assignment in earlier arguments: z = something () w = myfun(x := get_data(), y=calculate(x, z)) I would probably recommend against that in code review, but it's not absurdly obfuscated. On Sun, Jul 8, 2018, 1:15 PM Giampaolo Rodola' wrote: > > > On Sun, Jul 8, 2018 at 6:45 PM Steve Holden wrote: > >> On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola' >> wrote: >> >>> [...] >>> I find that (space between the parentheses of a function call >>> statement) too unnatural as a place where to put an assignment. It is >>> not even "guarded" by a keyword like "if" or "while" which can help as >>> indicators that an assignment may occur. Also, I think it's way too easy to >>> confuse it with a keyword argument: >>> >>> >>> foo(x = 1) # keyword arg >>> >>> foo(x := 1) # assignment + value passing >>> [...] >>> >> >> But the PEP 8 spellings are >> >> foo(x=1) >> >> and >> >>f(x := 1). >> >> The extra spacing makes it obvious that this isn't a regular named >> argument. >> > > What if the author of the code I'm reading didn't respect PEP-8? I don't > think it's fair to invoke PEP-8 as a counter-measure to obviate a syntax > which can clearly be mistaken with something else simply by omitting 2 > spaces. Not to mention that I don't see why anyone would want to declare a > variable in there in the first place. > > -- > Giampaolo - http://grodola.blogspot.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/mertz%40gnosis.cx > ___ 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] Call for prudence about PEP-572
On Mon, Jul 9, 2018 at 3:14 AM, Giampaolo Rodola' wrote: > > > On Sun, Jul 8, 2018 at 6:45 PM Steve Holden wrote: >> >> On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola' >> wrote: >>> >>> [...] >>> I find that (space between the parentheses of a function call statement) >>> too unnatural as a place where to put an assignment. It is not even >>> "guarded" by a keyword like "if" or "while" which can help as indicators >>> that an assignment may occur. Also, I think it's way too easy to confuse it >>> with a keyword argument: >>> >>> >>> foo(x = 1) # keyword arg >>> >>> foo(x := 1) # assignment + value passing >>> [...] >> >> >> But the PEP 8 spellings are >> >> foo(x=1) >> >> and >> >>f(x := 1). >> >> The extra spacing makes it obvious that this isn't a regular named >> argument. > > > What if the author of the code I'm reading didn't respect PEP-8? I don't > think it's fair to invoke PEP-8 as a counter-measure to obviate a syntax > which can clearly be mistaken with something else simply by omitting 2 > spaces. Not to mention that I don't see why anyone would want to declare a > variable in there in the first place. > It's not about why someone would want to assign inside a function call. It's about why it should be forbidden. Perhaps nobody has a good reason to use THlS_OBJECT as a variable name, and it's potentially very confusing; but should the grammar of Python forbid it? No. Because there is no value in forbidding it. Python's grammar has a number of weird edge cases due to necessity (for instance, "for x in a if cond else b:" works, but not in a comprehension), and when there's an actual conflict, sure, you can say "but nobody would ever want to do that, so we'll forbid it". In this case, there is no conflict. 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] Call for prudence about PEP-572
On Sun, Jul 8, 2018 at 6:45 PM Steve Holden wrote: > On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola' > wrote: > >> [...] >> I find that (space between the parentheses of a function call statement) >> too unnatural as a place where to put an assignment. It is not even >> "guarded" by a keyword like "if" or "while" which can help as indicators >> that an assignment may occur. Also, I think it's way too easy to confuse it >> with a keyword argument: >> >> >>> foo(x = 1) # keyword arg >> >>> foo(x := 1) # assignment + value passing >> [...] >> > > But the PEP 8 spellings are > > foo(x=1) > > and > >f(x := 1). > > The extra spacing makes it obvious that this isn't a regular named > argument. > What if the author of the code I'm reading didn't respect PEP-8? I don't think it's fair to invoke PEP-8 as a counter-measure to obviate a syntax which can clearly be mistaken with something else simply by omitting 2 spaces. Not to mention that I don't see why anyone would want to declare a variable in there in the first place. -- Giampaolo - http://grodola.blogspot.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] Time for 3.4.9 and 3.5.6
I'll use this opportunity to remind you that 3.4 build is broken -- it can't be built from start to installer with the instructions given because of outside factors (CPython has migrated from Hg to Git). https://bugs.python.org/issue31623 about this was ignored (see https://bugs.python.org/issue31623#msg303708 for supplemental fixes). If this isn't something considered needing a fix, the claim that 3.4 is supported in any shape and form is but a pretense -- if something can't be built, it can't be used. On 08.07.2018 10:45, Larry Hastings wrote: My six-month cadence means it's time for the next releases of 3.4 and 3.5. There haven't been many changes since the last releases--two, to be exact. These two security fixes were backported to both 3.4 and 3.5: * bpo-32981: Fix catastrophic backtracking vulns (GH-5955) * bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) 3.5 also got some doc-only changes related to the online "version switcher" dropdown. (They weren't backported to 3.4 because we don't list 3.4 in the version switcher dropdown anymore.) There are currently no PRs open for either 3.4 or 3.5, and they also have no open "release blocker" or "deferred blocker" bugs. It seems things are pretty quiet in our two security-fixes-only branches--a good way to be! I therefore propose to cut the RCs in a week and a half, and the finals two weeks later. So: Wednesday July 18 2018 - 3.4.9rc1 and 3.5.6rc1 Wednesday August 1 2018 - 3.4.9 final and 3.5.6 final If anybody needs more time I'm totally happy to accommodate them--you can probably have all the time you need. I'm trying to keep to my rough six-month cadence, but honestly that's pretty arbitrary. Thanks to all of you who keep making 3.4 and 3.5 better, //arry/ ___ 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/vano%40mail.mipt.ru ___ 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] Call for prudence about PEP-572
On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola' wrote: > [...] > I find that (space between the parentheses of a function call statement) > too unnatural as a place where to put an assignment. It is not even > "guarded" by a keyword like "if" or "while" which can help as indicators > that an assignment may occur. Also, I think it's way too easy to confuse it > with a keyword argument: > > >>> foo(x = 1) # keyword arg > >>> foo(x := 1) # assignment + value passing > [...] > But the PEP 8 spellings are foo(x=1) and f(x := 1). The extra spacing makes it obvious that this isn't a regular named argument. ___ 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] Call for prudence about PEP-572
On 7/8/2018 5:41 AM, Giampaolo Rodola' wrote: As for "assert" what I'm concern about is the proliferation of things like this: class Foo: def __init__(self): assert self.x := fun1() assert self.y := fun2() assert self.z := fun3() When I look at that my brain tells me that the main subject of the line is "assert", not the assignment, but maybe it's just because I'm not used to it. That aside there's the question of what to do when "python -O" switch is used. With this in place "-O" would acquire a new meaning, as it would disable "assert" statements AND assignments. It has always meant "disable the assert statement and therefore any side effects the expression has". It's just that now the side effects are more obvious, or maybe easier to create. Even pre-572 I've been bitten by this, I'm ashamed to admit. Eric ___ 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] Call for prudence about PEP-572
On Sat, Jul 7, 2018 at 5:48 PM Guido van Rossum wrote: > Enforcing such restrictions in the grammar would actually be complicated, > due to nesting -- but even if it wasn't, I wouldn't want to, as I don't > want to limit future generations to only the benefits of the new construct > that we can now come up with. Orthogonality is a good thing in my mind, > else we might never have had nested functions or conditional imports. > Got it. As to why you might want to use := in a function call, I could imagine > writing > > if validate(name := re.search(pattern, line).group(1)): > return name > I meant this case: >>> foo(x := 1) # execute "x = 1" AND "foo(1)" I find that (space between the parentheses of a function call statement) too unnatural as a place where to put an assignment. It is not even "guarded" by a keyword like "if" or "while" which can help as indicators that an assignment may occur. Also, I think it's way too easy to confuse it with a keyword argument: >>> foo(x = 1) # keyword arg >>> foo(x := 1) # assignment + value passing As for "assert" what I'm concern about is the proliferation of things like this: class Foo: def __init__(self): assert self.x := fun1() assert self.y := fun2() assert self.z := fun3() When I look at that my brain tells me that the main subject of the line is "assert", not the assignment, but maybe it's just because I'm not used to it. That aside there's the question of what to do when "python -O" switch is used. With this in place "-O" would acquire a new meaning, as it would disable "assert" statements AND assignments. > On Sat, Jul 7, 2018 at 6:12 AM Giampaolo Rodola' > wrote: > >> Sorry in advance for opening yet another topic about PEP-572. With >> PEP-572 being officially accepted I know debating its inclusion in the >> language is a useless exercise at this point, but since it's still in >> "draft" status I would like to express my opinion as I think this is a >> feature which can potentially be abused fairly easily. FWIW I initially >> found myself disliking the idea as a whole but >> https://github.com/python/cpython/pull/8122 made me (and others) >> reconsider it quite a bit (see: >> https://twitter.com/grodola/status/1015251302350245888). PR-8122 clearly >> shows an improvement in expressiveness and compactness (many folks argue >> this is too much) but PEP-572 as it currently stands is too permissive >> IMHO. My concern about "easily abusable ugly cases" still remains, and I >> think they should be banned instead of just discouraged in the PEP or in >> the doc. Since we spend way more time *reading* code rather than writing >> it, as a "reader" I would expect a more prudent approach to the problem. >> >> Proposal >> >> >> 1) allow only one := assignment per line in "if" statements: >> >>> if x := val1 and y := val2: # SyntaxError or SyntaxWarning >> >>> if x == val1 and y := val2: # SyntaxError or SyntaxWarning >> >>> if x := val1 and y == val2: # SyntaxError or SyntaxWarning >> >>> if x := val1: # OK >> >>> if (x := val1): # OK >> >> 2) allow := in "while" statements, "if" statements and comprehensions >> only: >> >>> foo(x := 0) # SyntaxError >> >>> yield x := 3 # SyntaxError >> >>> assert y := 3 # SyntaxError >> >> 3) (debatable) disallow := if the variable is already defined: >> >>> x = 5 >> >>> if (x := val): # SyntaxError or SyntaxWarning >> >> 4) ban "a = (b := c)", "x = a := (b := (c := d))" and similar (they're >> just too ugly IMHO) >> >> Rationale 1 >> === >> >> In visual terms assignments in Python have always occurred at the >> BEGINNING of the line and always on the most LEFT side: >> >> >>> foo = fun1() >> >>> bar = fun2() >> >>> baz = fun3() >> >> That is where I naturally expect an assignment to be when reading code. >> My main concern with PEP-572 is that an assignments can now occur at *any >> point* in the line: >> >> >>> foo = fun1() >> >>> bar = fun2() >> >>> if foo == val1 and bar == val2 and baz := fun3(): >> ...... >> >> That forces me to visually scan the whole line horizontally from left to >> right 'till its end, looking for possible variables being set. I'm co # >> execute "foo(1)" AND "x = 1"ncerned that I will miss := occurrences because >> visually they are very similar to == unless parentheses are made mandatory: >> >> >>> if foo == val1 and bar == val2 and (baz := fun3()): >> ...... >> >> Also, in case of multi-line conditionals I have to visually scan the >> construct both horizontally AND vertically: >> >> >>> if (foo == val1 and \ >> ...bar == val2 and \ >> ...baz := val3): >> ... ... >> >> Again, that is not a place where I would expect to find or look for a >> variable assignment. I know I wouldn't like to read or review a code which >> does that and I suspect linters will likely end up
[Python-Dev] Time for 3.4.9 and 3.5.6
My six-month cadence means it's time for the next releases of 3.4 and 3.5. There haven't been many changes since the last releases--two, to be exact. These two security fixes were backported to both 3.4 and 3.5: * bpo-32981: Fix catastrophic backtracking vulns (GH-5955) * bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) 3.5 also got some doc-only changes related to the online "version switcher" dropdown. (They weren't backported to 3.4 because we don't list 3.4 in the version switcher dropdown anymore.) There are currently no PRs open for either 3.4 or 3.5, and they also have no open "release blocker" or "deferred blocker" bugs. It seems things are pretty quiet in our two security-fixes-only branches--a good way to be! I therefore propose to cut the RCs in a week and a half, and the finals two weeks later. So: Wednesday July 18 2018 - 3.4.9rc1 and 3.5.6rc1 Wednesday August 1 2018 - 3.4.9 final and 3.5.6 final If anybody needs more time I'm totally happy to accommodate them--you can probably have all the time you need. I'm trying to keep to my rough six-month cadence, but honestly that's pretty arbitrary. Thanks to all of you who keep making 3.4 and 3.5 better, //arry/ ___ 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] On the METH_FASTCALL calling convention
Jeroen Demeyer schrieb am 08.07.2018 um 09:07: > On 2018-07-07 10:55, Serhiy Storchaka wrote: >> The first part of >> handling arguments can be made outside of the C function, by the calling >> API. > > Sure, it could be done but I don't see the advantage. I don't think you > will gain performance because you are just moving code from one place to > another. You probably can, by allowing the caller to decide how to map the keyword arguments. Passing them as a flat array is the fastest way for the callee to evaluate them, so that's great. For the caller, they might already be available in that format or not, so the caller can save time if they are, and only needs to invest time if they are not. > And how do you plan to deal with *args and **kwds in your > proposal? You'll need to make sure that this doesn't become slower. That, on the other hand, is an actual concern. If we already have a tuple and dict, unpacking them for the call and then repacking them on the other side is a serious performance regression – for this specific use case. The question is, how important is that use case compared to everything else? And, since we have more than one supported signature anyway, can we leave that case to a non-fastcall case? In the end, it's up to the callee to decide which protocol to support and use, and if the intention is to work with **kwargs, then maybe the callee should not use the fastcall protocol in the first place. Stefan ___ 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] On the METH_FASTCALL calling convention
On 2018-07-07 10:55, Serhiy Storchaka wrote: The first part of handling arguments can be made outside of the C function, by the calling API. Sure, it could be done but I don't see the advantage. I don't think you will gain performance because you are just moving code from one place to another. And how do you plan to deal with *args and **kwds in your proposal? You'll need to make sure that this doesn't become slower. ___ 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
