On Thu, Jul 5, 2018 at 9:02 PM Alexander Belopolsky
wrote:
> What happened to the "consenting adults" philosophy?
Just anecdotally, I've run into a number of professionals recently
who've come out of Java environments who really dislike the
"consenting adults" approach. While they value much tha
I don't know Serhiy's idea about how METH_FASTCALL | METH_KEYWORDS
calling convention can be improved in the future.
When I reading PEP 580, I liked your Py PyCCall_FastCall signature.
Maybe, one way to improve METH_FASTCALL | METH_KEYWORDS can be this.
kwds can be either tuple or dict.
---
Anyw
On Fri, Jul 6, 2018 at 12:48 PM, Alexander Belopolsky
wrote:
>
> Python really has a strong C legacy and this is the area where I agree that
> C designers made a mistake by picking a symmetric symbol (=) for an
> asymmetric operation. On top of that, they picked an asymmetric digraph (!=)
> for a
On Thu, Jul 5, 2018, 7:46 PM Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
> It also appears that there are no cases where = can be substituted for :=
> and not cause a syntax error. This means that ":" in ":=" is strictly
> redundant.
>
Under your proposal, this is ambiguous: '
[Tim]
> It doesn't even exist yet, but Googling on
> python operator :=
>
> already returns a directly relevant hit on the first page for me:
>
>
> https://stackoverflow.com/questions/26000198/what-does-colon-equal-in-python-mean
> ...
>
[Guido, who later apologized for unclear quoting, hi
Sorry for messing up the quoting. I blame GMail. Only the text starting
"Since this thread is dead" was mine.
On Thu, Jul 5, 2018 at 8:20 PM Guido van Rossum wrote:
> On Thu, Jul 5, 2018 at 7:12 PM Tim Peters wrote:
> It doesn't even exist yet, but Googling on
>
> python operator :=
>
> alr
On Thu, Jul 5, 2018 at 7:12 PM Tim Peters wrote:
It doesn't even exist yet, but Googling on
python operator :=
already returns a directly relevant hit on the first page for me:
https://stackoverflow.com/questions/26000198/what-does-colon-equal-in-python-mean
The hits above it are all to o
I'm not the world's leading expert on Python bytecode anymore, but unless
there's something I'm missing your conclusion looks eminently reasonable,
and so I expect you'll get very little traction on this thread. (If you had
wanted to get a megathread you should have written "FASTCALL considered
har
[Alexander Belopolsky]
> > Do we want to protect users who
> > cannot tell = from == so much that we are willing to cause Python to be
> > the first language with two non-interchangeable assignment operators?
>
[Steven D'Aprano][
Not even close to the first. Go beat us to it -- it has both = an
On Thu, Jul 5, 2018 at 10:10 PM Tim Peters wrote:
> ..
> I solved the problem in my own code by using an editor that displays a
> single "=" in C source as a left-arrow graphic (that's one of its
> C-specific display options - again a response to how notorious this
> bug-magnet is). So assignmen
On Thu, Jul 05, 2018 at 09:00:39PM -0400, Alexander Belopolsky wrote:
> Do we want to protect users who
> cannot tell = from == so much that we are willing to cause Python to be
> the first language with two non-interchangeable assignment operators?
Not even close to the first. Go beat us to it
[Alexander Belopolsky]
>>> ...
>>> I also think that the dreadfulness of mistyping = where == is expected
>>> is exaggerated.
[Tim]
>> There are a number of core devs who would be rabidly opposed
>> to allowing that confusion in Python, due to still-remembered
>> real-life nightmares in C. For
On Wed, Jul 4, 2018 at 7:42 PM Steven D'Aprano wrote:
> On Wed, Jul 04, 2018 at 01:00:41PM -0700, Devin Jeanpierre wrote:
> > On Wed, Jul 4, 2018 at 11:04 AM Steven D'Aprano wrote:
> > > Did you actually mean arbitrary simple statements?
> > >
> > > if import math; mylist.sort(); print("WTF am I
On Thu, Jul 5, 2018 at 8:28 PM Tim Peters wrote:
> [Alexander Belopolsky]
> > ...
> > I also think that the dreadfulness of mistyping = where == is expected
> > is exaggerated.
>
> There are a number of core devs who would be rabidly opposed to allowing
> that confusion in Python, due to still-
[Alexander Belopolsky]
> ...
> I also think that the dreadfulness of mistyping = where == is expected
> is exaggerated.
There are a number of core devs who would be rabidly opposed to allowing
that confusion in Python, due to still-remembered real-life nightmares in
C. For example, me ;-) It o
Sorry, I tried this too. If you think the response to the current version
of the PEP is strong, the negative reaction to that version was way
stronger, and I decided not to pursue it.
On Thu, Jul 5, 2018 at 5:00 PM Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>
>
> On Thu, Jul 5,
On Fri, Jul 6, 2018 at 10:17 AM, Guido van Rossum wrote:
>> I'm still wondering if it might make sense to define a new
>> "TargetScopeError" subclass of SyntaxError for that last case, since it
>> isn't the assignment expression syntax itself that's the problem: it's where
>> that expression is lo
On Thu, Jul 5, 2018 at 3:35 PM Nick Coghlan wrote:
> Guido did fully specify this in his post on "__parentlocal" scoping, in
> response to my request that this be clearly spelled out in the PEP (that
> specification just hasn't been rolled back into the PEP yet).
>
Having written it up that way,
On Thu, Jul 5, 2018 at 7:47 PM Yury Selivanov
wrote:
> I think I tried a variation of your proposal here
> https://mail.python.org/pipermail/python-dev/2018-April/152939.html
> and nobody really liked it.
>
> Right. I now recall your proposal. I think I did not support it at the
time because I w
I think I tried a variation of your proposal here
https://mail.python.org/pipermail/python-dev/2018-April/152939.html
and nobody really liked it.
Yury
On Thu, Jul 5, 2018 at 7:44 PM Alexander Belopolsky
wrote:
>
> I wish I had more time to make my case, but with the PEP 572 pronouncement
> immin
On Thu, Jul 5, 2018 at 3:45 PM Nick Coghlan wrote:
>
>
> On Thu., 5 Jul. 2018, 3:17 pm Guido van Rossum, wrote:
>
>> Let me be slightly contrarian. :-)
>>
>> On Wed, Jul 4, 2018 at 9:12 PM Chris Angelico wrote:
>>
>>> Definitely against augmentation, for several reasons:
>>>
>>> 1) Spelling - s
I wish I had more time to make my case, but with the PEP 572 pronouncement
imminent, let me make an attempt to save Python from having two assignment
operators.
I've re-read the PEP, and honestly I am warming up to the idea of allowing
a limited form of assignment in expressions. It looks like in
Please, Mike, can you stop? The race is over and your horse has lost. I
really value all the input I've received during the months of discussion
(including your research into what other languages do), but in the end my
"evaluation function" (to use somewhat hip lingo :-) is different from
yours. Fo
On Thu, Jul 5, 2018 at 3:06 PM Nick Coghlan wrote:
>
>
> On Thu., 5 Jul. 2018, 1:21 am Guido van Rossum, wrote:
>
>> Correct, there shouldn't be any additional corner cases for your PEP due
>> to inline assignments. We're not introducing new scopes nor other runtime
>> mechanisms; the target of
On Thu., 5 Jul. 2018, 3:17 pm Guido van Rossum, wrote:
> Let me be slightly contrarian. :-)
>
> On Wed, Jul 4, 2018 at 9:12 PM Chris Angelico wrote:
>
>> Definitely against augmentation, for several reasons:
>>
>> 1) Spelling - should it be :+= or +:= ?
>>
>
> That one's easy. As Nick's (withdra
Thanks you for writing up a proposal. There have been many proposals made,
including 'EXPR as NAME', similar to yours. It even has a small section in
the PEP: https://www.python.org/dev/peps/pep-0572/#alternative-spellings.
It's really hard to choose between alternatives, but all things considered
On Thu., 5 Jul. 2018, 10:23 am Steve Dower, wrote:
> On 04Jul2018 1518, Tim Peters wrote:
> > The only new thing is specifying the scope of `a`, where "local to f"
> > means exactly the same thing as for any other name local to a function
> > today. So far as the PEP semantics go, it doesn't eve
On Thu., 5 Jul. 2018, 1:21 am Guido van Rossum, wrote:
> Correct, there shouldn't be any additional corner cases for your PEP due
> to inline assignments. We're not introducing new scopes nor other runtime
> mechanisms; the target of an inline assignment is either a global or a cell
> (nonlocal)
Hi,
I wrote more pull requests in the meanwhile to see how assignment
expressions could be used in the standard library. I combined my 5 PR
into a new single PR to see all changes at once:
https://github.com/python/cpython/pull/8122/files
Again, all these PR must not be merged. I only wrote t
On Wed, Jul 4, 2018 at 7:20 AM, David Mertz wrote:
>
> That said, this is a silly game either way. And even though you CAN
> (sometimes) bind in an expression pre-572, that's one of those perverse
> corners that one shouldn't actually use.
>
not only shouldn't by hardly anyone ever does / would
Would it be possible to get outside experts to help? Like Cython or numpy
devs?
On Thu, Jul 5, 2018 at 8:09 AM Jeroen Demeyer wrote:
> On 2018-07-05 14:20, INADA Naoki wrote:
> > What you can do is "divide and conquer". Split PEP in small topics we
> > can focus.
>
> The PEP is already small an
On 2018-07-05 10:52, Ivan Pozdeev via Python-Dev wrote:
>
Perhaps, however I'm not advocating using "EXPR as NAME" with "with" as it
wouldn't be useful enough, only limited to if/while/comp.
-Mike
___
Python-Dev mailing list
Python-Dev@python.org
Hi,
I bring a strong proposal that is prematurely rejected but indeed the
most likely to be accepted to our community.
That is to select `as` spelling not `:=` and modify `with` and
`except` statements. Here is this.
* Below is copy-pasted from my gist:
https://gist.github.com/rnarkk/cdabceaedbdb
I started porting my project [1] to Python 3.7 and came across bpo-29218:
"The unused distutils install_misc command has been removed." [2]
Historically, the distutils package was very conservative about changes
because many 3rd party packages extended it in ways unforeseen by the
Python core de
On Thu, Jul 05, 2018 at 08:52:24PM +0300, Ivan Pozdeev via Python-Dev wrote:
> * Same goes for `except`: doesn't accept expressions, same semantic.
py> def make_exception(arg):
... return ValueError if arg else TypeError
...
py> expr = [make_exception]
py> try:
... 1+"1"
... except expr[
On 05.07.2018 3:22, Chris Angelico wrote:
Python uses "as NAME" for things that
are quite different from this, so it's confusing
I wrote in
https://mail.python.org/pipermail/python-dev/2018-June/154066.html that
this is easily refutable.
Looks like not for everybody. Okay, here goes:
The cons
[Victor Stinner]
> FYI I'm trying to use assignment expressions on the stdlib because
> *all* examples of the PEP 572 look artificial to me.
>
All the examples in my Appendix A were derived from real. pre-existing code
(although mostly my own). It's turned out that several others with your
compl
On 2018-07-05 04:28, Ivan Pozdeev via Python-Dev wrote:
This is as intended.
I wanted to show my summary and Chris' refuttal, with links to both original
posts. Because my letter is much shorter than the originals while carrying the
same message. Also to show that I've made the same mistake,
On 2018-07-04 17:22, Chris Angelico wrote:
- the "if expr as name:" syntax is able to handle only the tiniest
proportion of cases, because many MANY situations require a condition
after that. You can't write this, for instance:
if f(x) as spam < 0:
print(spam)
The original use cases did
On 2018-07-04 23:20, Steven D'Aprano wrote:
It simply isn't true that modern languages are moving away from
assignment expressions. Some are. Some aren't. Even those that don't
support assignment expressions in general usually support special syntax
to allow it in a few contexts.
The older po
On 05.07.2018 15:20, Victor Stinner wrote:
Hi,
My work (*) in the "Assignment expression and coding style: the while
True case" thread helped me to understand something about the
*intended* scope.
While technically, assignment expressions keep the same scoping rules
than assignment statements,
After "Assignment expression and coding style: the while True case",
here is the part 2: analysis of the "if (var := expr): ..." case.
2018-07-05 14:20 GMT+02:00 Victor Stinner :
> *intended* scope.
I generated the giant pull request #8116 to show where I consider that
"if (var := expr): ..." wou
On 2018-07-05 16:07, Victor Stinner wrote:
2018-07-05 15:14 GMT+02:00 Gustavo Carneiro :
I don't know if you're trying to propose something clever here, like "if (x
:= func()):" would assign to 'x' only inside the "then" body of the if, but
IMHO that would be a terrible idea:
I don't propose t
2018-07-05 15:14 GMT+02:00 Gustavo Carneiro :
> I don't know if you're trying to propose something clever here, like "if (x
> := func()):" would assign to 'x' only inside the "then" body of the if, but
> IMHO that would be a terrible idea:
I don't propose to change the PEP 572. I'm trying to expla
On 2018-07-05 14:20, INADA Naoki wrote:
What you can do is "divide and conquer". Split PEP in small topics we
can focus.
The PEP is already small and focused, I really did my best to make it as
minimal as possible. I don't see a meaningful way to split it up even
further.
__
Hello all,
As discussed in some other threads ([1], [2]), we should discuss the
METH_FASTCALL calling convention.
For passing only positional arguments, a C array of Python objects is
used, which is as fast as it can get. When the Python interpreter calls
a function, it builds that C array o
On Thu, Jul 5, 2018 at 11:14 PM, Gustavo Carneiro wrote:
> On Thu, 5 Jul 2018 at 13:43, Victor Stinner wrote:
>>
>> Hi,
>>
>> My work (*) in the "Assignment expression and coding style: the while
>> True case" thread helped me to understand something about the
>> *intended* scope.
>>
>> While tec
On Thu, 5 Jul 2018 at 13:43, Victor Stinner wrote:
> Hi,
>
> My work (*) in the "Assignment expression and coding style: the while
> True case" thread helped me to understand something about the
> *intended* scope.
>
> While technically, assignment expressions keep the same scoping rules
> than a
On Thu, Jul 5, 2018 at 9:02 PM Jeroen Demeyer wrote:
>
> On 2018-07-05 13:32, INADA Naoki wrote:
> > Core devs interested in this area is limited resource.
>
> I know and unfortunately there is nothing that I can do about that. It
> would be a pity that PEP 580 (or a variant like PEP 576) is not a
Hi,
My work (*) in the "Assignment expression and coding style: the while
True case" thread helped me to understand something about the
*intended* scope.
While technically, assignment expressions keep the same scoping rules
than assignment statements, writing "if (x := func()): ..." or "while
(x
2018-07-05 9:10 GMT+02:00 Tim Peters :
> I'm all in favor of what Victor is doing: looking at how this stuff will
> work in actual code. That's a great antidote to the spread of theoretical
> fears.
FYI I'm trying to use assignment expressions on the stdlib because
*all* examples of the PEP 572
On 2018-07-05 13:32, INADA Naoki wrote:
Core devs interested in this area is limited resource.
I know and unfortunately there is nothing that I can do about that. It
would be a pity that PEP 580 (or a variant like PEP 576) is not accepted
simply because no core developer cares enough.
As f
On Thu, Jul 5, 2018 at 6:31 PM Jeroen Demeyer wrote:
>
> On 2018-07-05 05:41, INADA Naoki wrote:
> > And stabilizing calling convention is prerequirements of designing new
> > calling APIs.
>
> I don't see why. I made my PEP with the assumption that the
> METH_FASTCALL calling convention won't cha
On 05.07.2018 9:20, Steven D'Aprano wrote:
On Thu, Jul 05, 2018 at 05:33:50AM +0300, Ivan Pozdeev via Python-Dev wrote:
And https://mail.python.org/pipermail/python-dev/2018-June/154160.html
disproves the "chosen often these days in new languages".
Ivan, I think you may have linked to the wron
On 05.07.2018 9:47, Steven D'Aprano wrote:
On Thu, Jul 05, 2018 at 12:51:37AM +0200, Victor Stinner wrote:
I propose to start the discussion about "coding style" (where are
assignment expressions appropriate or not?) with the "while True"
case.
We don't even have an official implementation yet
On Thu, 5 Jul 2018 13:58:42 +0300
Ivan Pozdeev via Python-Dev wrote:
> On 05.07.2018 9:23, Serhiy Storchaka wrote:
> > 05.07.18 01:51, Victor Stinner пише:
> >> == Pattern 1, straighforward ==
> >>
> >> while True:
> >> line = input.readline()
> >> if not line:
> >> break
> >
On 05.07.2018 9:23, Serhiy Storchaka wrote:
05.07.18 01:51, Victor Stinner пише:
== Pattern 1, straighforward ==
while True:
line = input.readline()
if not line:
break
...
IMHO here assingment expression is appropriate here. The code remains
straighfoward to read.
whil
On 2018-07-05 05:41, INADA Naoki wrote:
And stabilizing calling convention is prerequirements of designing new
calling APIs.
I don't see why. I made my PEP with the assumption that the
METH_FASTCALL calling convention won't change. As far as I know, nobody
advocated for changing it. But even
[Victor Stinner]
>
> > I propose to start the discussion about "coding style" (where are
> > assignment expressions appropriate or not?) with the "while True"
> > case.
>
[Steven D'Aprano]
> We don't even have an official implementation yet, and you already want
> to start prescribing coding styl
59 matches
Mail list logo
