[Python-Dev] Re: python.org doc portal question/bug

[Ivan Pozdeev via Python-Dev]

I just missed it, too, even though I specifically looked for it.

I was looking for "help"/"feedback"/"contact".
The page I found, https://www.python.org/about/help/, in a text specifically saying about getting help, mentions webmas...@python.org 
 but doesn't say a word about the tracker.


On 04.12.2020 2:38, Guido van Rossum wrote:

It's funny, that link is on every page, but nobody ever sees it. :-)

On Thu, Dec 3, 2020 at 3:35 PM Jonathan Goble mailto:jcgob...@gmail.com>> wrote:

On Thu, Dec 3, 2020 at 6:16 PM Guido van Rossum mailto:gu...@python.org>> wrote:

If you want to get the attention of the people who maintain the 
website, please look at the bottom of any page on python.org
 and file an issue at the GitHub tracker linked 
there.


Done: https://github.com/python/pythondotorg/issues/1697 
 Thanks for the pointer.



--
--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 topython-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-dev@python.org/message/U5IVOV2NS64LL4PGNBOCOXNPEORK7WMG/
Code of Conduct:http://python.org/psf/codeofconduct/


--
Regards,
Ivan

___
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/57ESVPNLLU5PF3GB6XGFMBB43PR37CGW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2020-11-27 - 2020-12-04)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7561 (-18)
  closed 46745 (+103)
  total  54306 (+85)

Open issues with patches: 3050 


Issues opened (53)
==

#41879: Outdated description of async iterables in documentation of as
https://bugs.python.org/issue41879  reopened by nickgaya

#42491: Tkinter wait_visibility hanging when used in thread
https://bugs.python.org/issue42491  opened by spcmicro

#42492: [unittest] Missing docs for context manager attributes
https://bugs.python.org/issue42492  opened by jayman

#42498: smtplib is glitchy after receive server code 500
https://bugs.python.org/issue42498  opened by izomiac

#42504: Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big Sur
https://bugs.python.org/issue42504  opened by fxcoudert

#42507: test_ttk_guionly test failures on macOS with Tcl/Tk 8.6.10
https://bugs.python.org/issue42507  opened by ned.deily

#42508: macOS IDLE with Tk 8.6.10 in 3.9.1rc1 universal2 installer fai
https://bugs.python.org/issue42508  opened by ned.deily

#42512: typing: Confusing that BinaryIO and IO[bytes] cannot be used i
https://bugs.python.org/issue42512  opened by conchylicultor

#42513: Socket.recv hangs
https://bugs.python.org/issue42513  opened by Barney Stratford

#42514: Relocatable framework for macOS
https://bugs.python.org/issue42514  opened by gregneagle

#42516: Add function to get caller's name
https://bugs.python.org/issue42516  opened by steve.dower

#42517: Enum: do not convert private names into members
https://bugs.python.org/issue42517  opened by ethan.furman

#42519: [C API] Upgrade the C API in extension modules
https://bugs.python.org/issue42519  opened by vstinner

#42520: add_dll_directory only accepts absolute paths
https://bugs.python.org/issue42520  opened by Antony.Lee

#42524: pdb access to return value
https://bugs.python.org/issue42524  opened by Romuald

#42525: Optimize class/module level annotation
https://bugs.python.org/issue42525  opened by uriyyo

#42526: Exceptions in asyncio.Server callbacks are not retrievable
https://bugs.python.org/issue42526  opened by tmewett

#42527: UnicodeEncode error in BaseHttpRequestHandler class when send 
https://bugs.python.org/issue42527  opened by wangyanfeng.p

#42528: Improve the docs of most Py*_Check{,Exact} API calls
https://bugs.python.org/issue42528  opened by antocuni

#42529: CPython DLL initialization routine failed from PYC cache file
https://bugs.python.org/issue42529  opened by Thrameos

#42531: importlib.resources.path() raises TypeError for packages witho
https://bugs.python.org/issue42531  opened by William.Schwartz

#42532: spec_arg's __bool__ is called while initializing NonCallableMo
https://bugs.python.org/issue42532  opened by idanweiss97

#42533: Document encodings.idna limitations
https://bugs.python.org/issue42533  opened by rixx

#42534: venv does not work correctly when imported from .zip
https://bugs.python.org/issue42534  opened by jussienko

#42535: unittest.patch confuses modules with base modules
https://bugs.python.org/issue42535  opened by twolodzko

#42536: Iterating on a zip keeps objects alive longer than expected (t
https://bugs.python.org/issue42536  opened by vstinner

#42538: AsyncIO strange behaviour
https://bugs.python.org/issue42538  opened by Alexander-Greckov

#42539: Missing parenthesis in `platform._sys_version_parser`
https://bugs.python.org/issue42539  opened by crazy95sun

#42540: Debug pymalloc crash when using os.fork() [regression]
https://bugs.python.org/issue42540  opened by CendioOssman

#42541: Tkinter colours wrong on MacOS universal2
https://bugs.python.org/issue42541  opened by epaine

#42542: weakref documentation does not fully describe proxies
https://bugs.python.org/issue42542  opened by rgov

#42543: case sensitivity in open() arguments
https://bugs.python.org/issue42543  opened by sean.grogan

#42544: In windows, asyncio.run_in_executor strips logger class inform
https://bugs.python.org/issue42544  opened by adsherman09

#42545: Check that all symbols in the limited ABI are exported
https://bugs.python.org/issue42545  opened by pablogsal

#42547: argparse: add_argument(... nargs='+', metavar=) does no
https://bugs.python.org/issue42547  opened by m_khvoinitsky

#42548: debugger stops at breakpoint of `pass` that is not actually re
https://bugs.python.org/issue42548  opened by gatekeeper.mail

#42549: "quopri" line endings not standard conform
https://bugs.python.org/issue42549  opened by dmaurer

#42551: Generator `yield`s counted as primitive calls by cProfile
https://bugs.python.org/issue42551  opened by matthew.suozzo

#42552: Automatically set parent thread idents on thread start
https://bugs.python.org/issue42552  opened by gaborjbernat

#42554: distutils.util.get_platform() depends on minor version for mac
https://bugs.pyth

[Python-Dev] Pattern Matching Scope

[Jim J. Jewett]

[Steven D'Aprano st...@pearwood.info  responding to Paul Sokolovsky] wrote:
> > Let us be clear: failed matches do not affect
> > surrounding
> > namespaces unless you declare capture variables as global or
> > nonglobal. They might affect the current namespace, but not
> > surrounding namespaces. Failed matches will not leak out to
> > surrounding namespaces.
> > The problem is that intuitively (just like with "for"),

> "case a, b if a != b:" opens a new namespace for "a" and "b". That's why
> I talk about "surrounding namespace". Then if a particular case
> matching succeeds, weak of us (myself including) expect "a" and "b"
> to magically appear outside the "case" too. But if the case didn't
> match, nope, I don't expect "a" and "b" to appear there, it's not
> intuitive at all ;-).

I'm getting a bit confused over when people mean "the PEP currently says" vs 
"the implementation probably should" vs "the PEP should additionally require" 
vs "the PEP should instead say".

To be more specific, I'm not sure what is intended for the 2nd or 3rd case 
below, which reuse a variable "bound" by the first (failed) match.  Nor am I 
sure whether it matters that the first match fails on the guard predicate, 
instead of immediately on the match.
 
case (a, b, c) if f():  # assume f() returns false

case (a, b) if a == c:  # is a still bound from case above?  Is that 
implementation-dependent?

case (d = a):  # is a still bound from case above?  Is that 
implementation-dependent?  Is it even still possible to put restrictions in 
before the guard clause, like d=4?

My previous belief was that this was implementation defined, because the cases 
could be processed in parallel, so that the first case might not have finished 
by the time variable a was needed in the later cases.  My reading of PEP 634 
suggests that there is a linearization, but only of the guards, so ... now I am 
not sure.

-jJ
___
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/F5KRIPR4HUDG6TIUWLYBD6CBUFKPLYVF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Pattern Matching Scope

[Ethan Furman]

On 12/4/20 11:15 AM, Jim J. Jewett wrote:


To be more specific, I'm not sure what is intended for the 2nd or 3rd case below, which 
reuse a variable "bound" by the first (failed) match.  Nor am I sure whether it 
matters that the first match fails on the guard predicate, instead of immediately on the 
match.


Here's my understanding of it:


 case (a, b, c) if f():  # assume f() returns false


a, b, and c and are initially bound from matches to the object in question, whether they remain bound after f() fails is 
implementation dependent and should not be relied upon



 case (a, b) if a == c:  # is a still bound from case above?  Is that 
implementation-dependent?


a and b are initially bound from matches to the object in question, and the `a` in `a == c` has that new value; `c`, 
however, could be the `c` from the first, failed, match -- presumably this is simply a bug in the above match block 
because it seems like a bad idea to overwrite an already present variable (`c` in this case) in a first match when later 
matches depend on it.



 case (d = a):  # is a still bound from case above?  Is that 
implementation-dependent?  Is it even still possible to put restrictions in 
before the guard clause, like d=4?


`a` is bound to the `d` attribute of the match object.

The implementation defined aspect is whether names remain bound after match and/or guard failures.  In the above code 
that uncertainty only affects the name `c` as it's the only one used both inside one match and in a guard in a different 
match.


--
~Ethan~
___
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/AUOET7RISAQM2CK565FALM2ZBFFOIUPI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Pattern Matching Scope

[Daniel Moisset]

This is an answer to "what PEP 634 proposes":

On Fri, 4 Dec 2020 at 19:18, Jim J. Jewett  wrote:

> (...)
> I'm getting a bit confused over when people mean "the PEP currently says"
> vs "the implementation probably should" vs "the PEP should additionally
> require" vs "the PEP should instead say".
>
> To be more specific, I'm not sure what is intended for the 2nd or 3rd case
> below, which reuse a variable "bound" by the first (failed) match.  Nor am
> I sure whether it matters that the first match fails on the guard
> predicate, instead of immediately on the match.
>
> case (a, b, c) if f():  # assume f() returns false
>

This will guarantee binding of a, b, and c when the subject is a sequence
of 3 elements. Otherwise, which are assigned is implementation defined.
Nothing of this is affected in any way by the behaviour of f, and the
binding is guaranteed to be done before f is called.


>
> case (a, b) if a == c:  # is a still bound from case above?  Is that
> implementation-dependent?
>

This will guarantee binding of a and b when the subject is a sequence of 2
elements. Otherwise, which are assigned is implementation defined. Nothing
of this is affected in any way by the behaviour of a==c, and the binding is
guaranteed to be done before the equality is computed.


>
> case (d = a):  # is a still bound from case above?  Is that
> implementation-dependent?  Is it even still possible to put restrictions in
> before the guard clause, like d=4?
>

This is a SyntaxError, (d=a) is not a pattern.

To summarize:
* on a successful match of the *pattern* (ignoring the guard), all captured
variables are bound, and that happens before the guard is evaluated
* on a failed match, an arbitrary subset of the variables may be bound, and
the guard is guaranteed to not be evaluated.

My previous belief was that this was implementation defined, because the
> cases could be processed in parallel, so that the first case might not have
> finished by the time variable a was needed in the later cases.  My reading
> of PEP 634 suggests that there is a linearization, but only of the guards,
> so ... now I am not sure.
>
> -jJ
> ___
> 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/F5KRIPR4HUDG6TIUWLYBD6CBUFKPLYVF/
> 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/V5DDEGA6CQLBQCMMRCS5QUKGTN37R6BC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Pattern Matching Scope

[Ethan Furman]

On 12/4/20 12:45 PM, Daniel Moisset wrote:


     case (d = a):



This is a SyntaxError, (d=a) is not a pattern.


Ah, right.  I was thinking of the case when a type was specified, aka

case MyObj(d = a):

--
~Ethan~
___
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/KGO6ALVU7GADZ6ZCIGSPZJVKFBNI2SEY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

[Guido van Rossum]

I hope more of the regulars here jump on this bandwagon. It will be a great
day when Paul posts one of his offensive posts and there is just deafening
silence.

Paul was in my (very short) kill file for years but I decided to give him
another chance. And he blew it.

There is a reason why he was banned from micropython, and you all are
seeing it here — he just can’t help himself.

Probably he’s hoping to be banned for a COC violation. Let’s not give him
that satisfaction.

—Guido (speaking for myself only)

On Tue, Dec 1, 2020 at 15:11 Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Paul Sokolovsky writes:
>
>  > Sorry, but there may be a suggestion of tactics of sneaking somebody's
>  > "pet feature" past the attention of core developers by employing
>  > sycophant techniques.
>
> I've had enough of your random aspersions.  They make it impossible
> for me to continue reading your posts.  I'll join David with a
> "moderate" -100 on your proposals, and bid you "good day".
> ___
> 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/3BAYVC53Z7ZS2UQ4NLAJGIBFJ62DI3NK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/RADAUJGFQLUG2YIQBQF622RY3TRZSTKO/
Code of Conduct: http://python.org/psf/codeofconduct/