[Python-Dev] Re: PEP 647 Accepted

[Federico Salerno]

I don't have any decent proposal at the moment but I think coming up 
with a way to annotate side-effects of functions (including 
typeguard-ness) could come in handy. If we anticipate needing that, 
perhaps it would be beneficial to come up with that feature before 
implementing this PEP, lest we end up with something that could have 
benefitted from it but was released just before it.


Though personally I like the PEP and have no qualms about having to 
learn that TypeGuard is "a bool with a side-effect"; I don't think it's 
a problem in the first place, there are less obvious, more complicated 
things in Python that I couldn't just intuit at a glance.


On 06/04/2021 22:31, Barry Warsaw wrote:

[...]
but this also isn’t quite accurate, and we were concerned that this might be 
highly inconvenient in practice.  In a sense, the type guard-ness of the 
function is an attribute about the function, not about the parameters or return 
type, but there is no way to currently express that using Python or type 
checking syntax.

[...]
Cheers,
-Barry (on behalf of the Python Steering Council)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DUIPWYVKP5KWXHQVN5ODPQPFCMOXGWFW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Paul Moore]

On Wed, 7 Apr 2021 at 06:15, Stephen J. Turnbull
 wrote:
>
> Greg Ewing writes:
>  > On 7/04/21 5:22 am, Brandt Bucher wrote:
>  > > we might consider updating those templates if the term "Reference
>  > > Implementation" implies a higher standard than "we've put in the
>  > > work to make this happen, and you can try it out here"
>  >
>  > Maybe "prototype implementation" would be better? I think I've used
>  > that term in PEPs before.
>
> That seems to me to correspond well to Brandt's standard as expressed
> above.
>
> To me, "prototype implementation" is somewhere between "proof of
> concept" and "reference implementation", and I welcome the additional
> precision.  The big question is can such terms be used accurately (ie,
> do various people assign similar meanings to them)?
>
> I would define them functionally as
>
> proof of concept
> demonstrates some of the features, especially those that were
> considered "difficult to implement"
>
> prototype implementation
> implements the whole spec, so can be used be developers to
> prototype applications,
>
> reference implementation
> intended to be a complete and accurate implementation of the
> specification

I'm OK with these terms (although I don't actually think you *will*
get sufficient consensus on them to make them unambiguous) but with
one proviso - once the implementation is merged into the CPython
source, I think it should simply be referred to as "the
implementation" and qualifiers should be unnecessary (and should be
considered misleading).

Paul
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Z73B6K5BYFWG6N6FPIO3S3ZCADCYQ7T6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Help to Resolve issues with Pull request 25220

[anthony.flury via Python-Dev]

All,

Can someone better than me (i.e anyone) help me resolve the issues with 
Pull Request 25220.


I followed the dev guide, but I assume that between me taking my fork of 
the cpython repository, and building my pull request, another pull 
request was merged into master.


It also appears that the Documentation build is failing with an rst 
reference tag error on part of the document I never changed.


I am finding it difficult to drive github to understand how to resolve 
the conflict (i.e how to retain both sets of changes) - so any help 
would be appreciated.


Regards,

--
Anthony Flury
*Moble*: +44 07743 282707
*Home*: +44 (0)1206 391294
*email*: anthony.fl...@btinternet.com 
<>___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EPLT4DTJCTOJZ26YNMBORTL77WFLMKGD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] When we remove 'U' mode of open()?

[Inada Naoki]

'U' mode was removed once and resurrected.
https://bugs.python.org/issue39674

As far as I can see, it is postponed to Python 3.10. Am I right?
Can we remove 'U' mode in Python 3.10?

Regards,
-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VM3GYZDHQCXSDHZCGDA5W7ZPBYRIJPGA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Stephen J. Turnbull]

Paul Moore writes:

 > I'm OK with these terms (although I don't actually think you *will*
 > get sufficient consensus on them to make them unambiguous)



 > once the implementation is merged into the CPython source, I think
 > it should simply be referred to as "the implementation" and
 > qualifiers should be unnecessary (and should be considered
 > misleading).

Sounds good to me.

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OAUHG4RSYKJBCWRBDYQ25GOCHRGATKUS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: When we remove 'U' mode of open()?

[Miro Hrončok]

On 07. 04. 21 14:53, Inada Naoki wrote:

'U' mode was removed once and resurrected.
https://bugs.python.org/issue39674

As far as I can see, it is postponed to Python 3.10. Am I right?
Can we remove 'U' mode in Python 3.10?


What is the benefit of doing it? Is the current compatibility layer to do 
nothing when "U" is passed difficult to maintain?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IBZEWUCCIO27SYQDZ2MU2ZK6QZMP4FPJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: When we remove 'U' mode of open()?

[Inada Naoki]

On Wed, Apr 7, 2021 at 11:29 PM Miro Hrončok  wrote:
>
> On 07. 04. 21 14:53, Inada Naoki wrote:
> > 'U' mode was removed once and resurrected.
> > https://bugs.python.org/issue39674
> >
> > As far as I can see, it is postponed to Python 3.10. Am I right?
> > Can we remove 'U' mode in Python 3.10?
>
> What is the benefit of doing it? Is the current compatibility layer to do
> nothing when "U" is passed difficult to maintain?
>

I am working on fileinput module:

* https://bugs.python.org/issue43712
* https://bugs.python.org/issue5758
* https://bugs.python.org/issue36865

It supports deprecated 'U' mode for now, same to builtin open().
When I read and write code and tests, I need to pay attention about
all allowed combination of mode string.

It is not difficult to maintain, but it has significant support cost.
If we don't remove it forever, accumulated cost would be very high
than users think.
It is technical debt.

Regards,
-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YBT47H36E4IWMLOFATQEIJOTQEGZ4SQE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Help to Resolve issues with Pull request 25220

[Barney Gale]

Hi Anthony,

It looks like you’ve incorporated several other changes into your commit by
mistake. The simplest thing to do might be to re-create your git branch and
PR from scratch.

If conflicting changes land while your PR is still open, you’ll need to do
something called a “rebase”. The git book
 explains this well.

Barney

On Wed, 7 Apr 2021 at 11:22, anthony.flury via Python-Dev <
python-dev@python.org> wrote:

> All,
>
> Can someone better than me (i.e anyone) help me resolve the issues with
> Pull Request 25220.
>
> I followed the dev guide, but I assume that between me taking my fork of
> the cpython repository, and building my pull request, another pull request
> was merged into master.
>
> It also appears that the Documentation build is failing with an rst
> reference tag error on part of the document I never changed.
>
> I am finding it difficult to drive github to understand how to resolve the
> conflict (i.e how to retain both sets of changes) - so any help would be
> appreciated.
>
> Regards,
> --
> Anthony Flury
> *Moble*: +44 07743 282707
> *Home*: +44 (0)1206 391294
> *email*: anthony.fl...@btinternet.com
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/EPLT4DTJCTOJZ26YNMBORTL77WFLMKGD/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/N6U63WJGFNAXBSIUUSPZ2D67P7CNQBPX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: When we remove 'U' mode of open()?

[Victor Stinner]

Hi Inada-san,

I'm +0 on removing again the flag, but I would prefer to not endorse
the responsibility. I am already responsible for enough incompatible
changes in Python 3.10 :-D

Some context on this "U" open mode. The flag is accepted by many
functions opening files. It is deprecated (emit DeprecationWarning)
for 9 years (Python 3.3, 2012).

The flag is currently ignored and is basically only kept for backward
compatibility with Python 2, whereas Python 2.7 support ended in
January 2020 (1 year ago).

I removed the flag in Python 3.9:

* https://bugs.python.org/issue37330
* 
https://github.com/python/cpython/commit/e471e72977c83664f13d041c78549140c86c92de

The removal broke the Waf build system used by the Samba project. Waf
code is copied into Samba source code (as Python copies
autoconf/automake files). So even if Waf and then the Waf copy in
Samba are updated to not pass the "U" flag, trying to build an old
Samba version will fail if the flag is removed. Andrew Bartlett
explained that it's a practical issue when bisecting a bug in Samba.
It's annoying, but likely easy to workaround (fix the local waf copy
temporarily).

Moreover, the removal broke 11 packages in Fedora:

* aubio
* openvswitch
* python-SALib
* python-altgraph
* python-apsw
* python-magic-wormhole-mailbox-server
* python-munch
* python-parameterized
* python-pylibmc
* python-sphinx-testing
* veusz

Miro Hrončok and me proposed to revert the removal in Python 3.9:
https://mail.python.org/archives/list/python-dev@python.org/thread/EYLXCGGJOUMZSE5X35ILW3UNTJM3MCRE/

The removal was reverted (accept again the flag) in Python 3.9:

* https://bugs.python.org/issue39674#msg363195
* 
https://github.com/python/cpython/commit/942f7a2dea2e95a0fa848329565c0d0288d92e47

LWN article summarizing the issue: https://lwn.net/Articles/811369/

I added a section at the very beginning of What's New in Python 3.9 to
request developers to check for DeprecationWarning in their project:
https://docs.python.org/dev/whatsnew/3.9.html#you-should-check-for-deprecationwarning-in-your-code

The idea was that Python 3.9 is the last version supporting the flag,
developers are now warned, and so the flag should be removed from
Python 3.10.

That being said, I'm kind of cautious. Each time I introduce a minor
incompatible change breaking a few projects (say 5 projects or less),
many people get angry and complain without trying to understand the
rationale. Moreover, they are silent when I say that there was a
DeprecationWarning for 9 years.

I didn't check if the 11 projects + waf + samba have been updated to
no longer pass the deprecated "U" flag.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AAPTZUY46IG2H75TQKMWHOQBVTOCXN2K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: When we remove 'U' mode of open()?

[Serhiy Storchaka]

07.04.21 19:13, Victor Stinner пише:
> Hi Inada-san,
> 
> I'm +0 on removing again the flag, but I would prefer to not endorse
> the responsibility. I am already responsible for enough incompatible
> changes in Python 3.10 :-D
> 
> Some context on this "U" open mode. The flag is accepted by many
> functions opening files. It is deprecated (emit DeprecationWarning)
> for 9 years (Python 3.3, 2012).

It was silently deprecated before 3.3 (perhaps it was no-op since 3.0).

I added DeprecationWarning with intention to remove this option in all
functions accepting it. The only non-trivial support of the "U" mode was
left in ZipFile.open(), and it was broken since beginning.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BEECCPDJUUE7MMLVD4GUCOQBDMLGP7ZE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: When we remove 'U' mode of open()?

[Antoine Pitrou]

On Wed, 7 Apr 2021 23:44:18 +0900
Inada Naoki  wrote:
> On Wed, Apr 7, 2021 at 11:29 PM Miro Hrončok  wrote:
> >
> > On 07. 04. 21 14:53, Inada Naoki wrote:  
> > > 'U' mode was removed once and resurrected.
> > > https://bugs.python.org/issue39674
> > >
> > > As far as I can see, it is postponed to Python 3.10. Am I right?
> > > Can we remove 'U' mode in Python 3.10?  
> >
> > What is the benefit of doing it? Is the current compatibility layer to do
> > nothing when "U" is passed difficult to maintain?
> >  
> 
> I am working on fileinput module:
> 
> * https://bugs.python.org/issue43712
> * https://bugs.python.org/issue5758
> * https://bugs.python.org/issue36865
> 
> It supports deprecated 'U' mode for now, same to builtin open().
> When I read and write code and tests, I need to pay attention about
> all allowed combination of mode string.

You can already remove 'U' from fileinput with necessarily removing it
from open().

Regards

Antoine.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/26AZN6PKHPGOGALX7ODDFZUUAQINY27E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Irit Katriel via Python-Dev]

On Mon, Apr 5, 2021 at 2:59 PM Chris Jerdonek 
wrote:

> This point reminded me again of this issue in the tracker ("Problems with
> recursive automatic exception chaining" from 2013):
> https://bugs.python.org/issue18861
> I'm not sure if it's exactly the same, but you can see that a couple of
> the later comments there talk about "exception trees" and other types of
> annotations.
>
> If that issue were addressed after ExceptionGroups were introduced, does
> that mean there would then be two types of exception-related trees layered
> over each other (e.g. groups of trees, trees of groups, etc)? It makes me
> wonder if there's a more general tree structure that could accommodate both
> use cases...
>
> --Chris
>

Interesting, I commented on that issue - I think we may be able to solve it
without adding more trees.

That said, we will have groups-of-trees/trees-of-groups.  Already today, an
exception plus its chained __cause__s and __context__s is the root of a
binary tree of exceptions.  The nodes of this tree represent the times that
the exceptions were caught.

An exception group is a tree where the nodes represent the times when
exceptions were grouped together and raised.

Irit
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BZWELKDUAKCOXSH5KQRFGQJRQWJ2OHKW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 647 Accepted

[Guido van Rossum]

On Wed, Apr 7, 2021 at 12:21 AM Federico Salerno 
wrote:

> I don't have any decent proposal at the moment but I think coming up with
> a way to annotate side-effects of functions (including typeguard-ness)
> could come in handy. If we anticipate needing that, perhaps it would be
> beneficial to come up with that feature before implementing this PEP, lest
> we end up with something that could have benefitted from it but was
> released just before it.
>
> Though personally I like the PEP and have no qualms about having to learn
> that TypeGuard is "a bool with a side-effect"; I don't think it's a problem
> in the first place, there are less obvious, more complicated things in
> Python that I couldn't just intuit at a glance.
>

But it isn't a "side effect". It is a distinct concept that is important to
the type checker.

Note that in TypeScript this also doesn't look like a boolean -- it uses a
unique syntax that has to be learned:

function isCustomer(partner: any): partner is Customer {
. . .
}

Arguably the TS syntax is more easily intuited without looking it up, but
TS has a certain freedom in its syntactic design that we don't have for
Python: new *syntax* has to be added to the Python parser and can't be
backported, whereas new *types* (like `TypeGuard[T]`) can easily be
backported via typing_extensions.py.

We have really tried, but we did not come up with anything better than the
current PEP.

FWIW you might be interested in Annotated (PEP 593), which can be used to
indicate various attributes of a type annotation. Before you suggest that
we adopt that instead of PEP 647, we considered that, and the consensus is
that that's not what Annotated is for (it's intended for conveying
information to tools *other* than the type checker, for example schema
checkers etc.).

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/K3YNGWKOMMBV3V3KB6Y3FRXPE7SIQ5R7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How to attract developer attention to issue tracker items?

[Brett Cannon]

On Tue, Apr 6, 2021 at 11:22 PM  wrote:

> Hi developers,
>
> What should / shouldn't I do to attract any python developer response to
> issue tracker items?  I am unsure of the proper procedure to follow so I am
> asking here first.
>

What you're doing here is probably your best bet. Unfortunately the lack of
response might stem from no core devs being interested in curses (but if
any are then hopefully this email will spark their interest).

-Brett


>
> I have filed two issues on the python issue tracker for python curses
> issues:
>
> 1.  # 43715, a documentation update request (suggested additional
> documentation file uploaded)
> 2.  # 43716, a possible ABI issue for the curses.pair_number() function
> return value in a Windows environment
>
> With respect to the documentation issue, I would appreciate any review of
> whether the suggested documentation addition that I uploaded as a text file
> is acceptable as-is or whether further refinement or correction is needed.
>
> In the case of the possible ABI issue I am uncertain whether the issue is
> in
> the python interface code or in the underlying curses implementation
> library
> (windows-curses V2.2.0 using PDCurses).  I would appreciate it if anyone
> knowledgeable of the python curses interfacing code could advise me whether
> I need to pursue the issue with the third party library provider or with
> the
> python development team.  At the moment all that I know is that the
> "workaround" that I discovered corrects the issue under Windows but is not
> necessary under linux / ncurses (in my testing I used Ubuntu 20.04 WSL2 to
> confirm that fact).
>
> TIA for your patience with my ignorance of the proper procedures and
> channels.
>
> My environment:
>
> Windows 10 Pro 64 (latest version)
> Python 3.8.9 (tags/v3.8.9:a743f81, Apr  6 2021, 14:02:34) [MSC v.1928 64
> bit
> (AMD64)]
> Windows-curses V2.2.0
>
> Peter
> --
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/RBGBZOJ267YUTTZ3JO5XUJBEG66MKL2W/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/B5E3BPIOCALTPIBOJU5Z7KJ3MFUQUSSJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: When we remove 'U' mode of open()?

[Brett Cannon]

On Wed, Apr 7, 2021 at 10:01 AM Serhiy Storchaka 
wrote:

> 07.04.21 19:13, Victor Stinner пише:
> > Hi Inada-san,
> >
> > I'm +0 on removing again the flag, but I would prefer to not endorse
> > the responsibility. I am already responsible for enough incompatible
> > changes in Python 3.10 :-D
> >
> > Some context on this "U" open mode. The flag is accepted by many
> > functions opening files. It is deprecated (emit DeprecationWarning)
> > for 9 years (Python 3.3, 2012).
>
> It was silently deprecated before 3.3 (perhaps it was no-op since 3.0).
>
> I added DeprecationWarning with intention to remove this option in all
> functions accepting it. The only non-trivial support of the "U" mode was
> left in ZipFile.open(), and it was broken since beginning.
>

I think at this point the DeprecationWarning has definitely been on long
enough, there was an explicit warning about it in Python 3.9, and 3.10 will
be nearly 2 years removed from 2.7 reaching EOL which is the only place
where "U" may still be used. So I think it's fine to drop "U" in 3.10.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VTROKN5UOU3EN6F3OLX5RUK7TVETAXKB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Help to Resolve issues with Pull request 25220

[Terry Reedy]

On 4/7/2021 12:32 PM, Barney Gale wrote:
It looks like you’ve incorporated several other changes into your commit 
by mistake.
The PR definitely has too many changes unrelated to the issue.  I 
recognize a few of the changes as related to recent merges.


  My guess that the the issue-43737 branch was branched off of 
something other than master, which is usually a fatal mistake.  The 
parent branch may also have been branched off of something other than 
master.


Tony, with rare exception, each branch should be branched directly off 
master, which means checking out master first each time.


There is probably some other bad sequence of events that could cause the 
issue.


 The simplest thing to do might be to re-create your git

branch and PR from scratch.


I agree with this.  That means updating the master branch, creating a 
new 43737 branch, make the 43737 changes, commit, and push.


Or, in case problem is elsewise, fix the merge conflict (below), merge, 
and push to your fork.  Update your master from upstream, change to 
branch, git merge upstream/master, commit to branch, push branch to 
fork, and see how things work.


If conflicting changes land while your PR is still open, you’ll 
need to 

do something called a “rebase”.


Rebasing (perhaps done incorrectly) often makes things worse.  One fixes 
a merge conflix by editing the PR branch file(s) with the conflict and 
committing a change.


However, the merge conflict in expression.rst is this:

<<< issue-43737
.. productionlist::
   lambda_expr: "lambda" [`parameter_list`]: `expression`
   lambda_expr_nocond: "lambda" [`parameter_list`]: `expression_nocond`
===
.. productionlist:: python-grammar
   lambda_expr: "lambda" [`parameter_list`] ":" `expression`
>>> master

Adding a grammar production has nothing to do with the issue.  This 
could be easily fixed by removing the lambda_expr_nocond line (and other 
junk if not editing in the local branch) but would not solve the more 
extensive issues.


--
Terry Jan Reedy


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2XS2INIFALE75X4DQZNO7ZJD5IZVCHEO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: When we remove 'U' mode of open()?

[Inada Naoki]

We are close to 3.10 beta and it is not ideal timing for removing.
So my proposal is:

* Remove 'U' in fileinput, because it makes my task little simpler.
* Remove 'U' in other places in Python 3.11, after 3.10 branch is
created (and master branch is renamed to main).

On Thu, Apr 8, 2021 at 5:45 AM Brett Cannon  wrote:
>
>
>
> On Wed, Apr 7, 2021 at 10:01 AM Serhiy Storchaka  wrote:
>>
>> 07.04.21 19:13, Victor Stinner пише:
>> > Hi Inada-san,
>> >
>> > I'm +0 on removing again the flag, but I would prefer to not endorse
>> > the responsibility. I am already responsible for enough incompatible
>> > changes in Python 3.10 :-D
>> >
>> > Some context on this "U" open mode. The flag is accepted by many
>> > functions opening files. It is deprecated (emit DeprecationWarning)
>> > for 9 years (Python 3.3, 2012).
>>
>> It was silently deprecated before 3.3 (perhaps it was no-op since 3.0).
>>
>> I added DeprecationWarning with intention to remove this option in all
>> functions accepting it. The only non-trivial support of the "U" mode was
>> left in ZipFile.open(), and it was broken since beginning.
>
>
> I think at this point the DeprecationWarning has definitely been on long 
> enough, there was an explicit warning about it in Python 3.9, and 3.10 will 
> be nearly 2 years removed from 2.7 reaching EOL which is the only place where 
> "U" may still be used. So I think it's fine to drop "U" in 3.10.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/VTROKN5UOU3EN6F3OLX5RUK7TVETAXKB/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NYVORKRSH562UMAXXLSJOOW5ECBA3HC5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: When we remove 'U' mode of open()?

[Inada Naoki]

On Thu, Apr 8, 2021 at 9:54 AM Inada Naoki  wrote:
>
> We are close to 3.10 beta and it is not ideal timing for removing.
> So my proposal is:
>
> * Remove 'U' in fileinput, because it makes my task little simpler.
> * Remove 'U' in other places in Python 3.11, after 3.10 branch is
> created (and master branch is renamed to main).
>

I rejected bpo-36865, and created a pull request fixing bpo-5758 and
bpo-43712 without touching the `mode`.
There is no need to remove 'U' soon from fileinput too. We can remove
them all in Python 3.11.

https://bugs.python.org/issue36865
https://bugs.python.org/issue5758
https://bugs.python.org/issue43712
https://github.com/python/cpython/pull/25272


-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/E62553ZLB3OBFNU3VMOLECIDKRHQ74UC/
Code of Conduct: http://python.org/psf/codeofconduct/