[Python-ideas] Re: Top Level Await in Python like in Deno
Yes I can, but I am taking about to use it without `asyncio.run` Whenever Python in Top-Level faces with await it will wrap calling all top level statement in async function (for example) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OV5EU3LLWRK5IDZS7V6YZUJI2HYM36FU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Iterable scalar values returning itself ones?
On 2021-04-16 at 04:03:33 +1000,
Chris Angelico wrote:
> So brace-left, brace-right is "{}" but compose, brace-left,
> brace-right is "∅". If absolutely every Python programmer had this
> available, it might be enough to distinguish empty dict from empty
> set.
But if an empty set is composed from an empty dict, then the empty set
is not empty.
Unless it weighs as much as a duck?
Or your're Dutch?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/2A4H67PTTBURVAPNTP6DASFNNWASEJLD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Iterable scalar values returning itself ones?
On Fri, Apr 16, 2021 at 1:35 AM David Mertz wrote:
>>
>> Yes. Scalars aren't containers. Except strs, which are containers
>>
>> all the way down. :-þ
>
>
> Wow... how do I get a keyboard with a thorn character on it? :-)
>
Configure a Compose key, then use this:
: "þ" thorn # LATIN SMALL LETTER THORN
Incidentally, the same file has this in it:
: "∅" U2205 # EMPTY SET
So brace-left, brace-right is "{}" but compose, brace-left,
brace-right is "∅". If absolutely every Python programmer had this
available, it might be enough to distinguish empty dict from empty
set.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ZFSHWEBJ5EBLEBIXMWEDQ7JKFFYZVLXP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Iterable scalar values returning itself ones?
> > Yes. Scalars aren't containers. Except strs, which are containers > all the way down. :-þ Wow... how do I get a keyboard with a thorn character on it? :-) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/L7VGHHCU73NCI7GSEYUJSWT6QIPK42A4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Iterable scalar values returning itself ones?
Hans Ginzel writes:
> Are there any reasons not to make scalar types iterable returning
> the value ones?
Yes. Scalars aren't containers. Except strs, which are containers
all the way down. :-þ If we must iterate scalars, then at the very
least we should conform to existing mathematical interpretations of
scalars as containers. For example
for i in 3:
print(i)
could produce
set()
{set()}
{set(), {set()}}
(or perhaps an arbitrary shuffle of those, since 3 is a scalar,
there's no order to be preserved!) and
for i in 16853193807528738685:
print(i)
could produce
"h"
"e"
"l"
"l"
"o"
" "
"g"
"o"
"e"
"d"
"e"
"l"
More seriously, the string non-example gives a hint at the real
reason. Some algorithms iterate and recurse over containers of
containers of ... until they hit scalars, then they do something with
the scalars. Such algorithms will infloop if scalars are made
iterable. This comes up with respect to strings occasionally (even on
the dev lists where everybody knows nothing is going to be done about
one-character strings). That kind of thing means that you're going to
have to check for types you don't want to iterate in many cases.
And it will drive type-checking and linting software mad.
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/KMY2Y3N4C2INKGPSSP7MY5GKXN7QKWEF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Why not deprecate Py_XDECREF in a future python version? Maybe a DeprecationWarning for now?
Thanks for clarifying. And I wasn't telling to write
if (obj != NULL) {
Py_DECREF(obj);
}
I was actually proposing to change the code in the static inline function
_Py_DECREF by putting all of the code in the function inside the if block.
But Chris has a point. If we know for sure that it isn't NULL, why have an
unnecessary branch? And it's true. It would have to execute one more step (the
if block) every time Py_DECREF is used when it is actually not needed.
Moreover I thought about what you said Serhiy about breaking every bit of code.
Actually I knew it would break that's why I said in future Python version.
But anyway it's not necessary to change Py_DECREF and moreover deprecating
Py_XDECREF would cause even more problem.
Thanking you,
With Regards
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/U5MWF7FHQDPFBZ3M3SYFWNLVUCRSDT3E/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Why not deprecate Py_XDECREF in a future python version? Maybe a DeprecationWarning for now?
On Thu, Apr 15, 2021 at 5:05 PM Shreyan Avigyan wrote: > > After going through the > https://github.com/python/cpython/blob/master/Include/object.h it seems that > Py_XDECREF is just calling Py_DECREF if the PyObject pointer is not NULL. > This if statement could be directly implemented in Py_DECREF right? Therefore > is it really required to have Py_XDECREF? Why not use a DeprecationWarning > for now and plan to deprecate Py_XDECREF in the near future? > How about implementing an if statement in Py_DECREF to make it work like > Py_XDECREF? > If you know for sure that it isn't NULL, why have an unnecessary branch? More importantly: why change things? How much is gained by the deprecation? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/P4QEMISXG32X2M4GD4PHHQ4MYRNBNM6E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Why not deprecate Py_XDECREF in a future python version? Maybe a DeprecationWarning for now?
15.04.21 10:03, Shreyan Avigyan пише:
> After going through the
> https://github.com/python/cpython/blob/master/Include/object.h it seems that
> Py_XDECREF is just calling Py_DECREF if the PyObject pointer is not NULL.
> This if statement could be directly implemented in Py_DECREF right? Therefore
> is it really required to have Py_XDECREF? Why not use a DeprecationWarning
> for now and plan to deprecate Py_XDECREF in the near future?
> How about implementing an if statement in Py_DECREF to make it work like
> Py_XDECREF?
Py_XDECREF is a convenient macro which allows you to write one line
Py_XDECREF(obj);
instead of 3 lines
if (obj != NULL) {
Py_DECREF(obj);
}
The code would look uglier without it.
Also, it is very difficult to deprecate it, because it is one of most
used macros/functions. You propose to break all existing extensions.
What exactly problem do you try to solve?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/NU5CUMJXLGUAOOQE5ZSA7PNJCKXVVD2Z/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Why not deprecate Py_XDECREF in a future python version? Maybe a DeprecationWarning for now?
After going through the https://github.com/python/cpython/blob/master/Include/object.h it seems that Py_XDECREF is just calling Py_DECREF if the PyObject pointer is not NULL. This if statement could be directly implemented in Py_DECREF right? Therefore is it really required to have Py_XDECREF? Why not use a DeprecationWarning for now and plan to deprecate Py_XDECREF in the near future? How about implementing an if statement in Py_DECREF to make it work like Py_XDECREF? Thanking you, With Regards ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TDXJZJF35JF2WVZXE6L6EIJRZSKLSZBU/ Code of Conduct: http://python.org/psf/codeofconduct/
