Hello,
On Sun, 7 Feb 2021 04:53:43 +0300
Ivan Pozdeev wrote:
> On 07.02.2021 0:24, Paul Sokolovsky wrote:
> > Hello,
> >
> > On Sun, 7 Feb 2021 00:00:41 +0300
> > Ivan Pozdeev via Python-Dev wrote:
> >
> >> Who said "__future__"?
> > Other people said __future__. And yet other said "it's
Hello,
On Sat, 6 Feb 2021 23:05:19 -0800
Guido van Rossum wrote:
> That’s incorrect. __future__ is used when something new and
> *incompatible* is being introduced (and the old way is being
> deprecated at the same time). For experimental modules we use the
> term provisional. There’s no
That’s incorrect. __future__ is used when something new and *incompatible*
is being introduced (and the old way is being deprecated at the same time).
For experimental modules we use the term provisional. There’s no official
term for experimental syntax (since we’ve never had any), but we could
Hello,
On Sun, 07 Feb 2021 13:32:17 +1300
Greg Ewing wrote:
> On 7/02/21 9:58 am, Steve Holden wrote:
> > My suggestion that it be introduced via __future__ due to its
> > contentious nature met immediate resistance.
>
> __future__ is for things that are changing in incompatible ways.
>
Hello,
On Sun, 7 Feb 2021 13:21:08 +1100
Steven D'Aprano wrote:
> On Sat, Feb 06, 2021 at 10:00:16PM -0300, Luciano Ramalho wrote:
> > On Sat, Feb 6, 2021 at 6:23 PM Chris Angelico
> > wrote:
> > > How will a __future__ import help here? Are there syntactic or
> > > behavioural changes that
Hello,
On Sun, 7 Feb 2021 01:17:31 +
Paul Bryan wrote:
> On Sat, 2021-02-06 at 22:00 -0300, Luciano Ramalho wrote:
>
> > A __future__ import would make clear to all that the feature is
> > experimental, and maybe there could be __future__ imports for
> > different parts of the proposal.
On Sat, Feb 06, 2021 at 10:00:16PM -0300, Luciano Ramalho wrote:
> On Sat, Feb 6, 2021 at 6:23 PM Chris Angelico wrote:
> > How will a __future__ import help here? Are there syntactic or
> > behavioural changes that would be worth applying to some modules and
> > not others? The entire point of a
On 07.02.2021 0:24, Paul Sokolovsky wrote:
Hello,
On Sun, 7 Feb 2021 00:00:41 +0300
Ivan Pozdeev via Python-Dev wrote:
Who said "__future__"?
Other people said __future__. And yet other said "it's ok the way it
is, it's better to have it like that then keep not having it". And yet
other
I send a pull request https://github.com/python/peps/pull/1799
* Add Backward/Forward Compatibility section
* Add How to teach this section
* Remove io.LOCALE_ENCODING constant
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To
On Sat, 2021-02-06 at 22:05 -0300, Luciano Ramalho wrote:
> The initial pattern matching syntax and semantics with its many
> corner
> cases may be incompatible with a future way of doing pattern matching
> that is better.
Then that future incompatible way should be marked with __future__, not
On Sat, 2021-02-06 at 22:00 -0300, Luciano Ramalho wrote:
> A __future__ import would make clear to all that the feature is
> experimental, and maybe there could be __future__ imports for
> different parts of the proposal.
That's not my understanding. My understanding is __future__ is meant
for
On Sat, Feb 6, 2021 at 9:34 PM Greg Ewing wrote:
> __future__ is for things that are changing in incompatible ways.
> This is an entirely new feature that doesn't conflict with anything
> existing, so it doesn't need __future__.
The initial pattern matching syntax and semantics with its many
On Sat, Feb 6, 2021 at 6:23 PM Chris Angelico wrote:
> How will a __future__ import help here? Are there syntactic or
> behavioural changes that would be worth applying to some modules and
> not others? The entire point of a __future__ import is to maintain
> backward compatibility by, for
On 7/02/21 9:58 am, Steve Holden wrote:
My suggestion that it be introduced via __future__ due to its
contentious nature met immediate resistance.
__future__ is for things that are changing in incompatible ways.
This is an entirely new feature that doesn't conflict with anything
existing, so
Good luck in your quest.
Kind regards,
Steve
On Sat, Feb 6, 2021 at 9:00 PM Ivan Pozdeev wrote:
> Who said "__future__"? I said "3rd-party library". Independent from the
> CPython project.
> Maybe even a few of them -- to try out conflicting visions that emerged in
> the discussions.
> On
On Sun, Feb 7, 2021 at 8:14 AM Luciano Ramalho wrote:
>
> On Sat, Feb 6, 2021 at 6:04 PM Steve Holden wrote:
> >
> > My suggestion that it be introduced via __future__ due to its contentious
> > nature met immediate resistance. No point going down that road.
>
> This is really unfortunate.
>
>
Hello,
On Sun, 7 Feb 2021 00:00:41 +0300
Ivan Pozdeev via Python-Dev wrote:
> Who said "__future__"?
Other people said __future__. And yet other said "it's ok the way it
is, it's better to have it like that then keep not having it". And yet
other said something else (multiple else's).
> I
On Sat, Feb 6, 2021 at 6:04 PM Steve Holden wrote:
>
> My suggestion that it be introduced via __future__ due to its contentious
> nature met immediate resistance. No point going down that road.
This is really unfortunate.
I agree this is a huge language change and it should only be approved
Who said "__future__"? I said "3rd-party library". Independent from the CPython
project.
Maybe even a few of them -- to try out conflicting visions that emerged in the
discussions.
On 06.02.2021 23:58, Steve Holden wrote:
My suggestion that it be introduced via __future__ due to its
My suggestion that it be introduced via __future__ due to its contentious
nature met immediate resistance. No point going down that road.
Kind regards,
Steve
On Sat, Feb 6, 2021 at 8:15 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:
> With such a large new area of functionality
With such a large new area of functionality that's at odds with existing syntax and semantics and a lack of clear vision and agreement, it
sounds like this would be better first added as a 3rd-party library to let the syntax and semantics mature. (To allow new syntax, it'll
probably be parsing
Hi Mark,
I think some of these issues have already been raised and replied (even if
no agreement has been reached). but this is a good summary, so let me reply
with a summary of responses for this.
On Sat, 6 Feb 2021 at 15:51, Mark Shannon wrote:
> Hi,
>
> Since a decision on PEP 634 is
Yes. It's already supported in the branch. You can do
MyType[whatever=5]. One could possibly change dict to allow both the
specification dict[str, int] and dict[key=str, value=int], but this
specific change of the dict class is not part of the implementation
nor the PEP (nor I expect it to happen,
Hey everyone,
Just following up on this PR since it's been quiet for the last week. We've
added test cases to confirm that this is still an issue in the latest build
which needs fixing.
We've also determined that this bug affects moving immutable directories
too, though only on darwin (MacOS).
On Sat, Feb 6, 2021 at 03:13 Larry Hastings wrote:
> On 2/5/21 4:25 PM, Stefano Borini wrote:
>
> dicts and lists will keep working as before. They will not support
> keyword arguments (probably ever, as there is no clear semantic for
> them) and the current implementation simply throws an error
Hi,
Since a decision on PEP 634 is imminent, I'd like to reiterate some
concerns that I voiced last year.
I am worried about the semantics and implementation of PEP 634.
I don't want to comment on the merits of pattern matching in general, or
the proposed syntax in PEP 634 (or PEP 640 or PEP
On Tue, Feb 2, 2021 at 1:40 PM Inada Naoki wrote:
>
> On Tue, Feb 2, 2021 at 12:23 AM Victor Stinner wrote:
> >
> >
> > > Add ``io.LOCALE_ENCODING = "locale"`` constant too. This constant can
> > > be used to avoid confusing ``LookupError: unknown encoding: locale``
> > > error when the code is
On 2/5/21 4:25 PM, Stefano Borini wrote:
dicts and lists will keep working as before. They will not support
keyword arguments (probably ever, as there is no clear semantic for
them) and the current implementation simply throws an error if the
user tries to.
Is the plan to add PEP 637 support
On Sat, 6 Feb 2021 at 08:56, Batuhan Taskaya wrote:
>
> Lurking around the discussions I started to wonder whether this syntax
> actually worths the burden it introduces.
It has been discussed for weeks on py-ideas.
> As you have commented out
> earlier, there are no use cases in the built-in
Hello,
On Sat, 6 Feb 2021 10:46:54 +0200
Serhiy Storchaka wrote:
> 05.02.21 09:51, Paul Sokolovsky пише:
> > a0 = 0
> > b0 = 10
> > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5:
> > a2 = a1 + 1
> > b2 = b1 + 1
>
> Such code quickly becomes unreadable. Especially if in real code
Hello,
On Sat, 06 Feb 2021 12:35:09 +1300
Greg Ewing wrote:
> On 5/02/21 8:51 pm, Paul Sokolovsky wrote:
> > a = 0
> > while a < 5:
> > a += 1
> >
> >
> > becomes:
> >
> >
> > a0 = 0
> > while (a1 := phi(a0, a2)) < 5:
> > a2 = a1 + 1
>
> SSA seems to be something
Lurking around the discussions I started to wonder whether this syntax
actually worths the burden it introduces. As you have commented out
earlier, there are no use cases in the built-in types, perhaps a
research would be great regarding possible use cases of keyword
arguments in and out of the
05.02.21 09:51, Paul Sokolovsky пише:
> a0 = 0
> b0 = 10
> while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5:
> a2 = a1 + 1
> b2 = b1 + 1
Such code quickly becomes unreadable. Especially if in real code
function has additional arguments and names are longer that 2-3 characters.
The
33 matches
Mail list logo
