[Python-Dev] Re: Intended invariants for signals in CPython
On Fri., 26 Jun. 2020, 7:02 am Chris Jerdonek, wrote: > On Wed, Jun 24, 2020 at 5:15 PM Yonatan Zunger via Python-Dev < > python-dev@python.org> wrote: > >> That said, the meta-question still applies: Are there things which are >> generally intended *not* to be interruptible by signals, and if so, is >> there some consistent way of indicating this? >> > > Yonatan, Nathaniel Smith wrote an interesting post a few years ago that > includes some background about signal handling: > https://vorpus.org/blog/control-c-handling-in-python-and-trio/ > Related to that is this CPython bug report: https://bugs.python.org/issue29988 The short version is that Greg Smith and I tried to close some of the remaining signal safety holes a couple of years ago, and I made it as far as building better tools for provoking the bugs (this is the origin of per-opcode tracing hooks in CPython), but we never came up with an actual solution. So the workaround remains to run anything that absolutely cannot be interrupted by poorly timed signals in a subthread, and dedicate the main thread to signal handling. Cheers, Nick. > ___ 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/UIBSEBHFMVEUQ6FMEIJEQFH42RCNRE2A/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup
On Thu., 25 Jun. 2020, 5:41 am Guido van Rossum, wrote:
> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
> commenting on these until we've done so:
>
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
>
> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
> variable binding and '?' for a wildcard.)
>
I'm not sure if it's a separate point or not, but something I would like to
see the PEP take into account is whether or not the destructuring syntax
(especially for mappings) could become the basis for a future proposed
enhancement to assignment statements that effectively allowed an assignment
statement to be a shorthand for:
match RHS:
case LHS:
pass # Just doing a destructuring assignment
else:
raise ValueError("Could not match RHS to LHS")
In "y, x = x, y" the fact the names are being used as both lvalues and
rvalues is indicated solely by their appearing on both sides of the
assignment statement.
This is the strongest existing precedent for all names in case expressions
being lvalues by default and having a separate marker for rvalues.
However, I believe it's also a reasonably strong argument *against* using
"." as that rvalue marker, as in "obj.x, obj.y = x, y" the dotted
references remain lvalues, they don't implicitly turn into rvalues.
Interestingly though, what those points suggest is that to be forward
compatible with a possible extension to assignment statements, the PEP is
correct that any syntactic marker would need to be on the *rvalues* that
are constraining the match, putting any chosen symbol (e.g. "?") squarely
in the wildcard role rather than the "lvalue marker" role.
y,? = returns_2_tuple()
y,?None = returns_2_tuple() # Exception if 2nd element is not == None
y,?sentinel = returns_2_tuple() # Exception if 2nd element is not ==
sentinel
y,*? = returns_iterable()
The main mindset shift this approach would require relative to the PEP as
currently written is in explicitly treating the case expression syntax as
an evolution of the existing lvalue syntax in assignment statements rather
than treating it as the introduction of a third independent kind of
expression syntax.
Cheers,
Nick.
>
___
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/7HNAT2EI5UJGRUYIOVHDKJCVDBSSC2CX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The Anti-PEP
On Sat., 27 Jun. 2020, 3:42 am Brett Cannon, wrote: > > > On Thu, Jun 25, 2020 at 1:37 PM Chris Jerdonek > wrote: > >> On Thu, Jun 25, 2020 at 11:52 AM Brett Cannon wrote: >> >>> On Thu, Jun 25, 2020 at 5:45 AM Antoine Pitrou >>> wrote: >>> I don't think this really works. A PEP has to present a consistent view of the world, and works as a cohesive whole. Arguments against a PEP don't form a PEP in themselves, they don't need to be consistent with each other; they merely oppose a particular set of propositions. So an "anti-PEP" would not be anything like a PEP; it would just be a list of assorted arguments. >>> >>> I agree, and that's what the Rejected Ideas section is supposed to >>> capture. >>> >> >> When I read the description of Rejected Ideas in PEP 1, it seems like >> it's more for ideas that have been rejected that are still in line with the >> overall PEP / motivation. >> > > We can change PEP 1 if necessary to make people feel more comfortable in > using the Rejected Ideas section to record objections. > The most effective cases where I've seen this done have involved putting an explicit "Do nothing" or "Preserve the status quo" heading under "Rejected Ideas". Another related element is to list folks that contribute significantly to that aspect of the PEP in an Acknowledgements section - adding them as co-authors doesn't make sense (as being listed as a co-author typically implies endorsement), but having specific names listed helps people to feel heard as long as they saw at least one of the listed names stating their own objections during the discussion. Cheers, Nick. > ___ 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/ZJ7NL6KNWNM3ZYD7UM2XQKGTASPMJPPQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Plan to remove Py_UNICODE APis except PEP 623.
Hi, all. I proposed PEP 623 to remove Unicode APIs deprecated by PEP 393. In this thread, I am proposing removal of Py_UNICODE (not Unicode objects) APIs deprecated by PEP 393. Please reply for any comments. ## Undocumented, have Py_DEPRECATED There is no problem to remove them in Python 3.10. I will just do it. * Py_UNICODE_str*** functions -- already removed in https://github.com/python/cpython/pull/21164 * PyUnicode_GetMax() ## Documented and have Py_DEPRECATED * PyLong_FromUnicode * PyUnicode_AsUnicodeCopy * PyUnicode_Encode * PyUnicode_EncodeUTF7 * PyUnicode_EncodeUTF8 * PyUnicode_EncodeUTF16 * PyUnicode_EncodeUTF32 * PyUnicode_EncodeUnicodeEscape * PyUnicode_EncodeRawUnicodeEscape * PyUnicode_EncodeLatin1 * PyUnicode_EncodeASCII * PyUnicode_EncodeCharmap * PyUnicode_TranslateCharmap * PyUnicode_EncodeMBCS These APIs are documented. The document has ``.. deprecated:: 3.3 4.0`` directive. They have been `Py_DEPRECATED` since Python 3.6 too. Plan: Change the document to ``.. deprecated:: 3.0 3.10`` and remove them in Python 3.10. ## PyUnicode_EncodeDecimal It is not documented. It has not been deprecated by Py_DEPRECATED. Plan: Add Py_DEPRECATED in Python 3.9 and remove it in 3.11. ## PyUnicode_TransformDecimalToASCII It is documented, but doesn't have ``deprecated`` directive. It is not deprecated by Py_DEPRECATED. Plan: Add Py_DEPRECATED and ``deprecated 3.3 3.11`` directive in 3.9, and remove it in 3.11. ## _PyUnicode_ToLowercase, _PyUnicode_ToUppercase They are not deprecated by PEP 393, but bpo-12736. They are documented as deprecated, but don't have ``Py_DEPRECATED``. Plan: Add Py_DEPRECATED in 3.9, and remove them in 3.11. Note: _PyUnicode_ToTitlecase has Py_DEPRECATED. It can be removed in 3.10. -- 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/S7KW2U6IGXZFBMGS6WSJB26NZIBW4OLE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
Em sáb., 27 de jun. de 2020 às 11:12, Richard Damon <
rich...@damon-family.org> escreveu:
> On 6/27/20 5:36 AM, Stephen J. Turnbull wrote:
> > Richard Damon writes:
> >
> > > I thought _ was also commonly used as:
> > >
> > > first, -, last = (1, 2, 3)
> > >
> > > as a generic don't care about assignment.
> >
> > It is. But there are other options (eg, 'ignored') if '_' is used for
> > translation in the same scope.
> >
> > > I guess since the above will create a local, so not overwrite a
> > > 'global' function _ for translations, so the above usage works as
> > > long as that function (or whatever namespace you are in) doesn't
> > > use _ for translations.
> >
> > Exactly.
> >
> > > As long as the bindings in match also make the symbol a local
> > > (which seems reasonable) then you would get a similar restriction.
> >
> > It's quite different. First, it surely won't make other symbols
> > match-local. Of course there will be times when you do all the work
> > inside the match statement. But often you'll want to do bindings in a
> > match statement, then use those outside. The second problem is that
> > this use of '_' isn't optional. It's part of the syntax. That means
> > that you can't use the traditional marking of a translateable string
> > (and it's not just tradition; there is a lot of external software that
> > expects it) in that scope.
> >
> > So it's practically important, if not theoretically necessary, that
> > 'case _' not bind '_'.
> >
> > Steve
>
> I wasn't imply local to the match statement, but if the match is used
> inside a function, where using the binding operatior = will create a
> local name, even if there is a corresponding global name that matches
> (unless you use the global statement), will a match statement that binds
> to a name that hasn't bee made a local name by having an explicit
> assignment to it, actually bind to a global that might be present, or
> will it create a local? My first feeling is that binding to the global
> would be surprising.
>
> i.e.
>
> foo = 1
>
> def bar(baz):
>
> match baz:
>
> case 1: print('baz was one')
>
> case foo: print('baz was ', foo)
>
> bar(2)
>
> print(foo)
>
>
> will this script create a new foo name inside bar, so that when we
> return, the module global foo is still 1, or did be bind to the global
> and change it?
>
> Rebinding a global without a global statement would be unexpected
> (normally we can mutate the global, but not rebind it)
>
> --
> Richard Damon
> ___
> 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/A2YKBTEHILHRNLN62LIPNAXCDG73ACD6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
I think that global binding make no sense, it will break a lot of code
silently, think about this
def bar(baz):
match baz:
case bar: pass
IMHO, the most obvious solution is that the bind should be available only
inside case block and if you need to change a global or a nonlocal you do
this explicitly inside the case block, if this is the case you can pickup a
bind name that doesn't shadow the desired variable. This way the intention
to overwrite a global/nonlocal is clear in code
--
“If you're going to try, go all the way. Otherwise, don't even start. ..."
Charles Bukowski
___
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/SE5LVGEEIP7OI2KRREOAWJDLMMCKF6HR/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On 6/27/20 5:36 AM, Stephen J. Turnbull wrote:
> Richard Damon writes:
>
> > I thought _ was also commonly used as:
> >
> > first, -, last = (1, 2, 3)
> >
> > as a generic don't care about assignment.
>
> It is. But there are other options (eg, 'ignored') if '_' is used for
> translation in the same scope.
>
> > I guess since the above will create a local, so not overwrite a
> > 'global' function _ for translations, so the above usage works as
> > long as that function (or whatever namespace you are in) doesn't
> > use _ for translations.
>
> Exactly.
>
> > As long as the bindings in match also make the symbol a local
> > (which seems reasonable) then you would get a similar restriction.
>
> It's quite different. First, it surely won't make other symbols
> match-local. Of course there will be times when you do all the work
> inside the match statement. But often you'll want to do bindings in a
> match statement, then use those outside. The second problem is that
> this use of '_' isn't optional. It's part of the syntax. That means
> that you can't use the traditional marking of a translateable string
> (and it's not just tradition; there is a lot of external software that
> expects it) in that scope.
>
> So it's practically important, if not theoretically necessary, that
> 'case _' not bind '_'.
>
> Steve
I wasn't imply local to the match statement, but if the match is used
inside a function, where using the binding operatior = will create a
local name, even if there is a corresponding global name that matches
(unless you use the global statement), will a match statement that binds
to a name that hasn't bee made a local name by having an explicit
assignment to it, actually bind to a global that might be present, or
will it create a local? My first feeling is that binding to the global
would be surprising.
i.e.
foo = 1
def bar(baz):
match baz:
case 1: print('baz was one')
case foo: print('baz was ', foo)
bar(2)
print(foo)
will this script create a new foo name inside bar, so that when we
return, the module global foo is still 1, or did be bind to the global
and change it?
Rebinding a global without a global statement would be unexpected
(normally we can mutate the global, but not rebind it)
--
Richard Damon
___
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/A2YKBTEHILHRNLN62LIPNAXCDG73ACD6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
Richard Damon writes: > I thought _ was also commonly used as: > > first, -, last = (1, 2, 3) > > as a generic don't care about assignment. It is. But there are other options (eg, 'ignored') if '_' is used for translation in the same scope. > I guess since the above will create a local, so not overwrite a > 'global' function _ for translations, so the above usage works as > long as that function (or whatever namespace you are in) doesn't > use _ for translations. Exactly. > As long as the bindings in match also make the symbol a local > (which seems reasonable) then you would get a similar restriction. It's quite different. First, it surely won't make other symbols match-local. Of course there will be times when you do all the work inside the match statement. But often you'll want to do bindings in a match statement, then use those outside. The second problem is that this use of '_' isn't optional. It's part of the syntax. That means that you can't use the traditional marking of a translateable string (and it's not just tradition; there is a lot of external software that expects it) in that scope. So it's practically important, if not theoretically necessary, that 'case _' not bind '_'. 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/6SDEJKTXJE4HS5CM2HIGB3ZYS5IN2BAZ/ Code of Conduct: http://python.org/psf/codeofconduct/
