[Python-Dev] Re: Improving inspect capabilities for classes
On Mon, Jun 15, 2020 at 7:22 AM Thomas Viehmann <
tv.python-dev.python@beamnet.de> wrote:
> Hello,
>
> thank you for making Python and the neat inspect module.
>
> I would love to hear your opinion on the following aspect of inspect
> that I believe might be worth improving:
>
> Consider the following program saved in a file (say hello.py):
>
> import inspect
>
> def hello():
> print("Hello World")
> print(inspect.getsource(hello))
>
> class Hello:
> def __init__(self):
> print("Hello World")
> print(inspect.getsource(Hello))
>
>
> Running hello.py will, unsurprisingly, print the source of hello and Hello.
>
> Now, some of us use an Jupyter (with the capabilities provided by
> IPython) notebooks, which are a great tool and awesome match with
> Python. These notebooks can be large and complex enough to want to use
> introspection on methods defined in itself (also, I'm prototyping things
> I might want to use as a library in Notebooks a lot, and I think I'm not
> alone).
>
> IPython enhances the interactive console to enable introspection (by
> providing "files" for the cells).
> As a result, the following will work as expected:
>
> def hello():
> print("Hello World")
> print(inspect.getsource(hello))
>
> However, it does not work for classes:
> class Hello:
> def __init__(self):
> print("Hello World")
> print(inspect.getsource(Hello))
>
> will run into an error in a Jupyter notebook, more precisely
>
> TypeError: is a built-in class
>
> The reason why the latter does not work is because inspect cannot find a
> source file.
>
> The technical background is that for a function hello, inspect.getfile
> finds the file through hello.__code__.co_filename
> which IPython can arrange for, while for the class Hello, it tries
> `Hello.__module__`, which is `__main__` and then would see if
> sys.modules[Hello.__module__] has a __file__ attribute, which it does
> not (and which could not be disambiguated into cell-level).
>
> I once made a PR in github #13894 and earlier
> https://bugs.python.org/issue33826 but got, let's say, reactions that
> were not entirely encouraging. I still think that it is a useful feature
> and I don't think that there are readily available solutions and after
> another year has passed, I humbly submit this for your considerations.
>
> Best regards and thank you.
>
> Thomas
>
It would probably help if you didn't bury the lede: You have a languishing
bug+PR that would benefit users of Jupyter Notebooks, and you would like
some help getting your proposal accepted. The proposal is to add a
`__filename__` attribute to classes, and the problem it solves is that
currently inspect.getsource() uses the class's `__module__` attribute,
which in Jupyter's case points to `__main__` for all classes defined in
cells. There can be only one file per module object so Jupyter cannot
trick inspect.getsource() into showing the source of the cell containing
the class definition (which it manages to do for functions, because of the
`__code__.co_filename` attribute).
I could think of a trick that inspect.getsource() might use if the class
contains at least one method: it could look at a method and try its
`__code__.co_filename` attribute (maybe only if the `__file__` attribute
for the module found via the class's `__module__` doesn't exist -- I'm sure
Jupyter can arrange for that to be the case). But I see how that would be a
problem (I can think of plenty of reasons why a class might not have any
methods).
I do think that your proposal is reasonable, although I wonder what the
Jupyter developers think of it. (How closely are you connected to that
project?)
Hopefully some other core dev will now take pity on you.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
[Python-Dev] Re: REPL output bug
On Mon, Jun 15, 2020 at 8:31 PM Steven D'Aprano wrote:
> On Fri, Jun 12, 2020 at 09:01:33AM +0100, Rob Cliffe via Python-Dev wrote:
> > It appears that the requested characters are output, *followed by* the
> > number of characters output
> > (which is the value returned by sys.stdout.write) and a newline.
> > Surely this is not the intended behaviour.
>
> Of course it is. The whole point of the REPL is to evaluate an
> expression and have the result printed. (That's the P in REPL :-)
>
> `stdout.write(...)` is an expression that returns a value, so the REPL
> prints it.
>
The expected behavior, at least for me until I read this thread, was that
the REPL would print the result of a *bare* expression, meaning when the
complete statement entered is an expression when taken as a whole.
In other words, I would expect the following input and output in Python 3:
>>> sys.stdout.write('\r1')
12
>>> for i in range(1, 11):
...sys.stdout.write('\r%d' % i)
...time.sleep(1)
10>>>
because the first statement is, as a whole, a single expression and thus
should print its result, but a for statement and block is not a single
expression taken as a whole and therefore should not print intermediate (or
final) results.
___
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/YMVL7RMQTYA7JIGTUQI6ZNS3MAHZRVK6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proposed release schedule for 3.5.9
Oh, good point! I forgot about that and was, uh, looking in the wrong place. Yes, the next version will be 3.5.10. //arry/ On 6/14/20 2:30 PM, John Thorvald Wodder II wrote: 3.5.9 was already released back in November. Yes, it's (almost) the same code as 3.5.8, but its version number (as reported by `python -V` etc.) is still 3.5.9. Releasing another 3.5.9 would just lead to confusion at best. I feel that the July release should be numbered 3.5.10 instead. -- John Wodder ___ 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/7Z6HBMUYGTB55QEASAOVML4VIDI3TKVS/ 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/PPNY4TA43NAYE526FSQ4TIYRB6PLQXRV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: REPL output bug
On Fri, Jun 12, 2020 at 09:01:33AM +0100, Rob Cliffe via Python-Dev wrote:
> If I run the following program (using Python 3.8.3 on a Windows 10 laptop):
>
> import sys, time
> for i in range(1,11):
> sys.stdout.write('\r%d' % i)
In Python 2, the 'write()` method returns None, which is suppressed in
the REPR. In Python 3, the `write` method returns the number of bytes
(or characters, I forget which...) actually written, which is not
suppressed.
I've been bitten by this myself, forgetting that in a script any result
not bound to a variable gets silently thrown away, but in the REPL it
gets printed.
> It appears that the requested characters are output, *followed by* the
> number of characters output
> (which is the value returned by sys.stdout.write) and a newline.
> Surely this is not the intended behaviour.
Of course it is. The whole point of the REPL is to evaluate an
expression and have the result printed. (That's the P in REPL :-)
`stdout.write(...)` is an expression that returns a value, so the REPL
prints it.
--
Steven
___
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/OWEUOVRPUR5JWALK32C3ZP6WESSUV6QK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: REPL output bug
On 2020-06-15 15:26, Ivan Pozdeev via Python-Dev wrote:
On 12.06.2020 11:01, Rob Cliffe via Python-Dev wrote:
If I run the following program (using Python 3.8.3 on a Windows 10
laptop):
import sys, time
for i in range(1,11):
sys.stdout.write('\r%d' % i)
time.sleep(1)
As intended, it displays '1', replacing it at 1-second intervals with
'2', '3' ... '10'.
Now run the same code inside the REPL:
Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:20:19) [MSC v.1925
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, time
>>> for i in range(1,11):
... sys.stdout.write('\r%d' % i)
... time.sleep(1)
...
12
22
32
42
52
62
72
82
92
103
>>>
It appears that the requested characters are output, *followed by*
the number of characters output
(which is the value returned by sys.stdout.write) and a newline.
Surely this is not the intended behaviour.
sys.stderr behaves the same as sys.stdout.
3.7.4 win64 works as expected (i.e. prints and overwrites only the
numbers) and I see nothing relevant in
https://docs.python.org/3/whatsnew/3.8.html
So I'd say this is a bug.
Python 2 does NOT exhibit this behaviour:
Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:19:08) [MSC v.1500
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, time
>>> for i in range(1,11):
... sys.stdout.write('\r%d' % i)
... time.sleep(1)
...
10>>>
# displays '1', '2' ... '10' as intended.
Best wishes
Rob Cliffe
___
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/T3BVZMBLWK3PMLRL2XCQFMLATGRTUPYE/
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/6BS3GXCS63PTXZMOMZSC6M5DHNAJO5FX/
Code of Conduct: http://python.org/psf/codeofconduct/
I just tested with 3.7.3 and got the same results as originally
described. Is there something different about 3.7.4 on win7?
Python 3.7.3 (default, Dec 20 2019, 18:57:59)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> import time
>>> for i in range(1,11):
... sys.stdout.write('\r%d' % i)
... time.sleep(1)
...
12
22
32
42
52
62
72
82
92
103
(I also tested with 3.8.3 with the same results)
Joseph J
___
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/TOSIE4NBT3LVO2ZNUM7FDLTWIIYNJWSP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: REPL output bug
On 12.06.2020 11:01, Rob Cliffe via Python-Dev wrote:
If I run the following program (using Python 3.8.3 on a Windows 10 laptop):
import sys, time
for i in range(1,11):
sys.stdout.write('\r%d' % i)
time.sleep(1)
As intended, it displays '1', replacing it at 1-second intervals with '2', '3'
... '10'.
Now run the same code inside the REPL:
Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:20:19) [MSC v.1925 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, time
>>> for i in range(1,11):
... sys.stdout.write('\r%d' % i)
... time.sleep(1)
...
12
22
32
42
52
62
72
82
92
103
>>>
It appears that the requested characters are output, *followed by* the number
of characters output
(which is the value returned by sys.stdout.write) and a newline.
Surely this is not the intended behaviour.
sys.stderr behaves the same as sys.stdout.
3.7.4 win64 works as expected (i.e. prints and overwrites only the numbers) and I see nothing relevant in
https://docs.python.org/3/whatsnew/3.8.html
So I'd say this is a bug.
Python 2 does NOT exhibit this behaviour:
Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:19:08) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, time
>>> for i in range(1,11):
... sys.stdout.write('\r%d' % i)
... time.sleep(1)
...
10>>>
# displays '1', '2' ... '10' as intended.
Best wishes
Rob Cliffe
___
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/T3BVZMBLWK3PMLRL2XCQFMLATGRTUPYE/
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/6BS3GXCS63PTXZMOMZSC6M5DHNAJO5FX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: REPL output bug
On 6/12/20 4:01 AM, Rob Cliffe via Python-Dev wrote:
> If I run the following program (using Python 3.8.3 on a Windows 10
> laptop):
>
> import sys, time
> for i in range(1,11):
> sys.stdout.write('\r%d' % i)
> time.sleep(1)
>
> As intended, it displays '1', replacing it at 1-second intervals with
> '2', '3' ... '10'.
>
> Now run the same code inside the REPL:
>
> Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:20:19) [MSC v.1925
> 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys, time
> >>> for i in range(1,11):
> ... sys.stdout.write('\r%d' % i)
> ... time.sleep(1)
> ...
> 12
> 22
> 32
> 42
> 52
> 62
> 72
> 82
> 92
> 103
> >>>
>
> It appears that the requested characters are output, *followed by* the
> number of characters output
> (which is the value returned by sys.stdout.write) and a newline.
> Surely this is not the intended behaviour.
> sys.stderr behaves the same as sys.stdout.
>
> Python 2 does NOT exhibit this behaviour:
>
> Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:19:08) [MSC v.1500
> 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys, time
> >>> for i in range(1,11):
> ... sys.stdout.write('\r%d' % i)
> ... time.sleep(1)
> ...
> 10>>>
> # displays '1', '2' ... '10' as intended.
>
> Best wishes
> Rob Cliffe
Is that what the REPL is defined to do? print the results of each
statement (unless it is None), so when working on it you don't need to
say print(...) everywhere.
--
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/6QP2IUW6ZDYGUFUZNEORX3BPRMCSBWOF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: REPL output bug
> Now run the same code inside the REPL:
>
> Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:20:19) [MSC v.1925 32
> bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys, time
> >>> for i in range(1,11):
> ... sys.stdout.write('\r%d' % i)
> ... time.sleep(1)
> ...
> 12
> 22
> 32
> 42
> 52
> 62
> 72
> 82
> 92
> 103
> >>>
>
> It appears that the requested characters are output, *followed by* the
> number of characters output
> (which is the value returned by sys.stdout.write) and a newline.
> Surely this is not the intended behaviour.
> sys.stderr behaves the same as sys.stdout.
Why not? I suppose it's intended this way. A behavior change like this
does not happen by accident.
>>> for i in range(3):
... (lambda: 2)()
...
2
2
2
>>>
___
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/YP4YEXASEWEBS5DEPJKX76QVLPUSNHUX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] REPL output bug
If I run the following program (using Python 3.8.3 on a Windows 10 laptop):
import sys, time
for i in range(1,11):
sys.stdout.write('\r%d' % i)
time.sleep(1)
As intended, it displays '1', replacing it at 1-second intervals with
'2', '3' ... '10'.
Now run the same code inside the REPL:
Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:20:19) [MSC v.1925 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, time
>>> for i in range(1,11):
... sys.stdout.write('\r%d' % i)
... time.sleep(1)
...
12
22
32
42
52
62
72
82
92
103
>>>
It appears that the requested characters are output, *followed by* the
number of characters output
(which is the value returned by sys.stdout.write) and a newline.
Surely this is not the intended behaviour.
sys.stderr behaves the same as sys.stdout.
Python 2 does NOT exhibit this behaviour:
Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:19:08) [MSC v.1500 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, time
>>> for i in range(1,11):
... sys.stdout.write('\r%d' % i)
... time.sleep(1)
...
10>>>
# displays '1', '2' ... '10' as intended.
Best wishes
Rob Cliffe
___
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/T3BVZMBLWK3PMLRL2XCQFMLATGRTUPYE/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: How to specify optional support of arguments
Isn't it more Pythonic to simply call the function and an alternative path to handle the exception, anyway? Half of os needs to be tested for NotImplementedError or OSError if it's going to run anywhere outside the development environment anyway, otherwise you're stuck with only the most basic functions. What _would_ be handy is a list of what each function throws. As for the original question, since it's duplicating or wrapping a module level functionality, it should be module level, rather than function level, and if there's a better design then it would need to be ported back to os as well. Although I could also see good reasoning behind os being implicitly or having to be explicitly imported to test for the less-compatible extensions. On Sun, Jun 14, 2020 at 11:14 PM Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > > On 15.06.2020 8:45, Serhiy Storchaka wrote: > > 14.06.20 23:45, Ivan Pozdeev via Python-Dev пише: > >> 1. The documentation clearly says that it's supported depending on OS > flavor -- so if I want to know if I can supply it, I need to rather > >> check `os.name`. Those members are thus redundant. > >> > >> If the distinction is finer than os.name then I'd need some > other, case-specific check depending on what the distinction is; > >> alternatively, I could check the function's signature in its metadata > if the support is reflected in it. > > > > Yes, it is finer than os.name. It can depend on the kernel or libc > version (and we do not know which versions are required on every > > platform), and there are a lot of platforms besides the main three. The > user should not be expert in all platforms on which his program > > potentially can be ran. > > > > The function's signature is the same on all platforms. Just on some > platforms only default value can be passed (None for dir_fd) or only > > specific types of argument is accepted (path-like, but not int). > > Then a single boolean flag is clearly not enough. Compare: in > https://docs.python.org/3/library/resource.html , the set of present > RLIMIT_* > members shows which rlimits are available in the specific OS. > > So I guess you want some similar pointers that would show which relevant > #define constants (or other C-level entities that govern the > availability) were present at the time of compilation. > If availability is rather governed by a runtime than compile-time check, > then something to perform the same check should be introduced; the > distinction from .supports_stuff is it would be named after the check and > completely decoupled from any functions that might be affected by > the check. > > > > ___ > > 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/YWYTZRLQK4ZHRFX3G3MJDGN6H4BJQCKN/ > > 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/BJ7HFKNQAO3C44XQ75AEYCRTG5GMYTU5/ > 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/UOTPZGFJ4IGPWDD2G5V5GDDP3G4NDY2H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: When can we remove wchar_t* cache from string?
Hi INADA-san, IMO Python 3.11 is too early because we don't emit a DeprecationWarning on every single deprecation function. 1) Emit a DeprecationWarning at runtime (ex: Python 3.10) 2) Wait two Python releases: see https://discuss.python.org/t/pep-387-backwards-compatibilty-policy/4421 3) Remove the deprecated feature (ex: Python 3.12) I don't understand if *all* deprecated functions are causing implementation issues, or only a few of them? PyUnicode_AS_UNICODE() initializes PyASCIIObject.wstr if needed, and then return PyASCIIObject.wstr. I don't think that PyASCIIObject.wstr can be called "a cache": there are functions relying on this member. On the other hand, PyUnicode_FromUnicode(str, size) is basically a wrapper to PyUnicode_FromWideChar(): it doesn't harm to keep this wrapper to ease migration. Only PyUnicode_FromUnicode(NULL, size) is causing troubles, right? Is there a list of deprecated functions and is it possible to group them in two categories: must be removed and "can be kept for a few more releases"? If the intent is to reduce Python memory footprint, PyASCIIObject.wstr can be moved out of PyASCIIObject structure, maybe we can imagine a WeakDict. It would map a Python str object to its wstr member (wchar_* string). If the Python str object is removed, we can release the wstr string. The technical problem is that it is not possible to create a weak reference to a Python str. We may insert code in unicode_dealloc() to delete manually the wstr in this case. Maybe a _Py_hashtable_t of pycore_hashtable.h could be used for that. Since this discussion is on-going for something like 5 years in multiple bugs.python.org issues and email threads, maybe it would help to have a short PEP describing issues of the deprecated functions, explain the plan to migrate to the new functions, and give a schedule of the incompatible changes. INADA-san: would you be a candidate to write such PEP? Victor Le ven. 12 juin 2020 à 10:37, Inada Naoki a écrit : > > Hi, all. > > Py_UNICODE has been deprecated since PEP 393 (Flexible string representation). > > wchar_t* cache in the string object is used only in deprecated APIs. > It waste 1 word (8 bytes on 64bit machine) per string instance. > > The deprecated APIs are documented as "Deprecated since version 3.3, > will be removed in version 4.0." > See https://docs.python.org/3/c-api/unicode.html#deprecated-py-unicode-apis > > But when PEP 393 is implemented, no one expects 3.10 will be released. > Can we reschedule the removal? > > My proposal is, schedule the removal on Python 3.11. But we will postpone > the removal if we can not remove its usage until it. > > I grepped the use of the deprecated APIs from top 4000 PyPI packages. > > result: > https://github.com/methane/notes/blob/master/2020/wchar-cache/deprecated-use > step: https://github.com/methane/notes/blob/master/2020/wchar-cache/README.md > > I noticed: > > * Most of them are generated by Cython. > * I reported it to Cython so Cython 0.29.21 will fix them. I expect > more than 1 year > between Cython 0.29.21 and Python 3.11rc1. > * Most of them are `PyUnicode_FromUnicode(NULL, 0);` > * We may be able to keep PyUnicode_FromUnicode, but raise error when > length>0. > > 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/7JVC3IKS2V73K36ISEJAAWMRFN2T4KKR/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- 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/2NFPP623YIPFFHFOPPHPQPILEKVH4HQE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: How to specify optional support of arguments
IMO it is up to the offending module to provide an API for advertising which variant of those functions is accepted. This seems out of scope for inspect. On Sun, Jun 14, 2020 at 23:16 Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > > On 15.06.2020 8:45, Serhiy Storchaka wrote: > > 14.06.20 23:45, Ivan Pozdeev via Python-Dev пише: > >> 1. The documentation clearly says that it's supported depending on OS > flavor -- so if I want to know if I can supply it, I need to rather > >> check `os.name`. Those members are thus redundant. > >> > >> If the distinction is finer than os.name then I'd need some > other, case-specific check depending on what the distinction is; > >> alternatively, I could check the function's signature in its metadata > if the support is reflected in it. > > > > Yes, it is finer than os.name. It can depend on the kernel or libc > version (and we do not know which versions are required on every > > platform), and there are a lot of platforms besides the main three. The > user should not be expert in all platforms on which his program > > potentially can be ran. > > > > The function's signature is the same on all platforms. Just on some > platforms only default value can be passed (None for dir_fd) or only > > specific types of argument is accepted (path-like, but not int). > > Then a single boolean flag is clearly not enough. Compare: in > https://docs.python.org/3/library/resource.html , the set of present > RLIMIT_* > members shows which rlimits are available in the specific OS. > > So I guess you want some similar pointers that would show which relevant > #define constants (or other C-level entities that govern the > availability) were present at the time of compilation. > If availability is rather governed by a runtime than compile-time check, > then something to perform the same check should be introduced; the > distinction from .supports_stuff is it would be named after the check and > completely decoupled from any functions that might be affected by > the check. > > > > ___ > > 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/YWYTZRLQK4ZHRFX3G3MJDGN6H4BJQCKN/ > > 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/BJ7HFKNQAO3C44XQ75AEYCRTG5GMYTU5/ > 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/RQDE6LMXENZ7442ISM6FJIDWZF2RCCJU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Improving inspect capabilities for classes
Hello,
thank you for making Python and the neat inspect module.
I would love to hear your opinion on the following aspect of inspect
that I believe might be worth improving:
Consider the following program saved in a file (say hello.py):
import inspect
def hello():
print("Hello World")
print(inspect.getsource(hello))
class Hello:
def __init__(self):
print("Hello World")
print(inspect.getsource(Hello))
Running hello.py will, unsurprisingly, print the source of hello and Hello.
Now, some of us use an Jupyter (with the capabilities provided by
IPython) notebooks, which are a great tool and awesome match with
Python. These notebooks can be large and complex enough to want to use
introspection on methods defined in itself (also, I'm prototyping things
I might want to use as a library in Notebooks a lot, and I think I'm not
alone).
IPython enhances the interactive console to enable introspection (by
providing "files" for the cells).
As a result, the following will work as expected:
def hello():
print("Hello World")
print(inspect.getsource(hello))
However, it does not work for classes:
class Hello:
def __init__(self):
print("Hello World")
print(inspect.getsource(Hello))
will run into an error in a Jupyter notebook, more precisely
TypeError: is a built-in class
The reason why the latter does not work is because inspect cannot find a
source file.
The technical background is that for a function hello, inspect.getfile
finds the file through hello.__code__.co_filename
which IPython can arrange for, while for the class Hello, it tries
`Hello.__module__`, which is `__main__` and then would see if
sys.modules[Hello.__module__] has a __file__ attribute, which it does
not (and which could not be disambiguated into cell-level).
I once made a PR in github #13894 and earlier
https://bugs.python.org/issue33826 but got, let's say, reactions that
were not entirely encouraging. I still think that it is a useful feature
and I don't think that there are readily available solutions and after
another year has passed, I humbly submit this for your considerations.
Best regards and thank you.
Thomas
___
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/AC5B5VORS6FF6KJ3EG5DIV3ZLAQB6DIY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: When can we remove wchar_t* cache from string?
Hi Serhiy, On 15/06/2020 8:22 am, Serhiy Storchaka wrote: 12.06.20 11:32, Inada Naoki пише: Hi, all. Py_UNICODE has been deprecated since PEP 393 (Flexible string representation). wchar_t* cache in the string object is used only in deprecated APIs. It waste 1 word (8 bytes on 64bit machine) per string instance. The deprecated APIs are documented as "Deprecated since version 3.3, will be removed in version 4.0." See https://docs.python.org/3/c-api/unicode.html#deprecated-py-unicode-apis But when PEP 393 is implemented, no one expects 3.10 will be released. Can we reschedule the removal? My proposal is, schedule the removal on Python 3.11. But we will postpone the removal if we can not remove its usage until it. I have a plan for more graduate removing of this feature. I created a PR which adds several compile options, so Python can be built in one of three modes: I don't like this approach. Adding compile time options means we need to test more versions, but is no help to end users as they will end up with the release version anyway. 1. Support wchar_t* cache and use it. It is the current mode. 2. Support wchar_t* cache, but do not use it internally in CPython. It can be used to test whether getting rid of the wchar_t* cache can have negative effects. We can test an performance impacts in the usual way, but comparing the before and after versions of any changes. 3. Do not support wchar_t* cache. It is binary incompatible build. Its purpose is to allow authors of third-party libraries to prepare to future breakage. Deprecation warnings allow third-parties to fix things before they are removed, without anyone having to compile their own version of Python. The plan is: 1. Add support of the above compile options. Unfortunately I did not have time to do this before feature freeze in 3.9, but maybe make an exception? 2. Make option 2 default. 3. Remove option 1. 4. Enable compiler deprecations for all legacy C API. Currently they are silenced for the C API used internally. 5. Make legacy C API always failing. 6. Remove legacy C API from header files. There is a long way to steps 5 and 6. I think 3.11 is too early. https://bugs.python.org/issue36346 https://github.com/python/cpython/pull/12409 ___ 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/IB5M72AV3YD5UFF5KV3YAI7HQ3WD3HQ5/ 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/APN4D47QZ2AZPVC427OFXAOVESZME7VS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [capi-sig] Re: Removal of _Py_ForgetReference from public header in 3.9 issue
On 15.06.2020 11:02, Petr Viktorin wrote: > On 2020-06-14 22:10, cpyt...@nicwatson.org wrote: >> I maintain an open source Python module in C. I'm trying to verify for >> the first time that the module still works with cpython 3.9. This >> module does *not* use the "limited" C API. >> >> In building my module against 3.9b3, I'm getting a missing declaration >> warning on _Py_ForgetReference. My module builds and passes test fine, >> this is just a compiler warning issue. > > What does the _Py_ForgetReference function do? The [documentation] says > it's only for use in the interpereter core, so I'd assume it's . > > [documentation]: https://docs.python.org/3/c-api/refcounting.html This is typically used in error handlers of constructors where you want to avoid having the deallocator run as result of the DECREF, e.g. because the object has not been full initialized yet. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jun 15 2020) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.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/PEFTCHDRJQDATHG5LKUCBA6PTS3HOHJP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Removal of _Py_ForgetReference from public header in 3.9 issue
On 2020-06-14 22:10, cpyt...@nicwatson.org wrote: Please excuse if this is the wrong mailing list. I couldn't find one for module maintainers. This is relevant to capi-...@python.org; let's continue here. I maintain an open source Python module in C. I'm trying to verify for the first time that the module still works with cpython 3.9. This module does *not* use the "limited" C API. In building my module against 3.9b3, I'm getting a missing declaration warning on _Py_ForgetReference. My module builds and passes test fine, this is just a compiler warning issue. What does the _Py_ForgetReference function do? The [documentation] says it's only for use in the interpereter core, so I'd assume it's . [documentation]: https://docs.python.org/3/c-api/refcounting.html The change that caused this was made in: commit f58bd7c1693fe041f7296a5778d0a11287895648 Author: Victor Stinner Date: Wed Feb 5 13:12:19 2020 +0100 bpo-39542: Make PyObject_INIT() opaque in limited C API (GH-18363) ... I definitely need the _Py_ForgetReference call for a particularly hairy error condition (https://github.com/jnwatson/py-lmdb/blob/master/lmdb/cpython.c#L888 if you're curious). In fact, my tests will seg fault if I don't have that call and trace refs is enabled. I can't follow the reasoning behind the code easily. Why do you use _Py_ForgetReference and PyObject_Del, instead of Py_DECREF(self)? Should I put an #ifdef Py_TRACE_REFS around the call? Ignore it? What do you think is the proper resolution? ___ 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/4EOCN7P4HI56GQ74FY3TMIKDBIPGKL2G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Cycles in the __context__ chain
On Sun, Jun 14, 2020 at 9:19 AM Serhiy Storchaka wrote: > It is possible to create a loop by setting the __context__ attribute of > the raised exception, either explicitly, or implicitly, using "raise ... > from ...". I think we should separate the questions of what to do when (1) setting the context explicitly (e.g. setting the __context__ attribute) and (2) setting it implicitly (using e.g. the raise syntax). When setting it explicitly, I think it's acceptable to lose the previous context (because it's being done explicitly). But when done implicitly, there's an argument that we should make an effort to preserve the previous context somewhere, so information isn't lost. I also think we should be open to the option of allowing cycles to exist, and not artificially breaking them. There are a few reasons for this. First, cycles in the chain can already exist in the current code. I believe Python's traceback-formatting code already has logic to look for cycles, so it won't cause hangs there. The reason for the most recent hang was different: _PyErr_SetObject() has separate logic to look for cycles, and that cycle-detection logic has a bug that can cause hangs. Finally, if we preserve cycles, we can improve Python's traceback-formatting code to display that the exception chain has a cycle. This is ideal IMO because the user will learn of the issue and we won't destroy information. I think it's important that we aim for a solution where the user is able to learn if they have an issue with their exception-handling code (e.g. code that creates cycles). This means we shouldn't silently try to alter or "fix" the chain. Rather, we should display that there is a cycle (e.g. in the traceback-formatting code). A couple more options would be to (1) issue a warning if we are doing any artificial cycle breaking, and (2) insert a new placeholder exception where the cycle starts, with the exception string containing information about the cycle that was broken, so the user learns about it and can fix it. --Chris On Mon, Jun 15, 2020 at 12:42 AM Dennis Sweeney wrote: > Worth noting is that there is an existing loop-breaking mechanism, > but only for the newest exception being raised. In particular, option (4) > is actually the current behavior if the the most recent exception > participates in a cycle: > > Python 3.9.0b1 > >>> A, B, C, D, E = map(Exception, "ABCDE") > >>> A.__context__ = B > >>> B.__context__ = C > >>> C.__context__ = D > >>> D.__context__ = E > >>> try: > ... raise A > ... except Exception: > ... raise C > ... > Exception: B > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > File "", line 2, in > Exception: A > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > File "", line 4, in > Exception: C > > This cycle-breaking is not due to any magic in the > ``PyException_SetContext()``, > which is currently a basic one-liner, but instead comes from > ``_PyErr_SetObject`` in errors.c, which has something along the lines of: > > def _PyErr_SetObject(new_exc): > top = existing_topmost_exc() > > if top is None: > # no context > set_top_exception(new_exc) > return > > # convert new_exc class to instance if applicable. > ... > > if top is new_exc: > # already on top > return > > e = top > while True: > context = e.__context__ > if context is None: > # no loop > break > if context is new_exc: > # unlink the existing exception > e.__context__ = None > break > e = context > > new_exc.__context__ = top > set_top_exception(new_exc) > > The only trouble comes about when there is a "rho-shaped" linked list, > in which we have a cycle not involving the new exception being raised. > For instance, > > Raising A on top of (B -> C -> D -> C -> D -> C -> ...) > results in an infinite loop. > > Two possible fixes would be to either (I) use a magical ``__context__`` > setter to ensure that there is never a rho-shaped sequence, or (II) > allow arbitrary ``__context__`` graphs and then correctly handle > rho-shaped sequences in ``_PyErr_SetObject`` (i.e. at raise-time). > > Fix type (I) could result in surprising things like: > > >>> A = Exception() > >>> A.__context__ = A > >>> A.__context__ is None > True > > so I propose fix type (II). This PR is such a fix: > https://github.com/python/cpython/pull/20539 > > It basically extends the existing behavior (4) to the rho-shaped case. > > It also prevents the cycle-detecting logic from sitting in two places > (both _PyErr_SetObject and PyException_SetContext) and does not make any >
[Python-Dev] Re: Cycles in the __context__ chain
Worth noting is that there is an existing loop-breaking mechanism, but only for the newest exception being raised. In particular, option (4) is actually the current behavior if the the most recent exception participates in a cycle: Python 3.9.0b1 >>> A, B, C, D, E = map(Exception, "ABCDE") >>> A.__context__ = B >>> B.__context__ = C >>> C.__context__ = D >>> D.__context__ = E >>> try: ... raise A ... except Exception: ... raise C ... Exception: B During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 2, in Exception: A During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 4, in Exception: C This cycle-breaking is not due to any magic in the ``PyException_SetContext()``, which is currently a basic one-liner, but instead comes from ``_PyErr_SetObject`` in errors.c, which has something along the lines of: def _PyErr_SetObject(new_exc): top = existing_topmost_exc() if top is None: # no context set_top_exception(new_exc) return # convert new_exc class to instance if applicable. ... if top is new_exc: # already on top return e = top while True: context = e.__context__ if context is None: # no loop break if context is new_exc: # unlink the existing exception e.__context__ = None break e = context new_exc.__context__ = top set_top_exception(new_exc) The only trouble comes about when there is a "rho-shaped" linked list, in which we have a cycle not involving the new exception being raised. For instance, Raising A on top of (B -> C -> D -> C -> D -> C -> ...) results in an infinite loop. Two possible fixes would be to either (I) use a magical ``__context__`` setter to ensure that there is never a rho-shaped sequence, or (II) allow arbitrary ``__context__`` graphs and then correctly handle rho-shaped sequences in ``_PyErr_SetObject`` (i.e. at raise-time). Fix type (I) could result in surprising things like: >>> A = Exception() >>> A.__context__ = A >>> A.__context__ is None True so I propose fix type (II). This PR is such a fix: https://github.com/python/cpython/pull/20539 It basically extends the existing behavior (4) to the rho-shaped case. It also prevents the cycle-detecting logic from sitting in two places (both _PyErr_SetObject and PyException_SetContext) and does not make any visible functionality more magical. The only Python-visible change should be that the infinite loop is no longer possible. ___ 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/R5J5JVUJX3V4DBKVLUI2SUBRD3TRF6PV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: When can we remove wchar_t* cache from string?
> I'm sorry, I was wrong. Py_DEPRECATED(3.3) is commented out for some APIs. So Python 3.8 doesn't show warning for them. Ah, no problem. Thanks for checking up on that. > I still think 2 years are enough to removal. Hmm, okay. At the least though, it does mean we have to be a bit more vigilant in ensuring that everyone has had a chance to migrate from those APIs, and delaying the removal if not. On Sun, Jun 14, 2020 at 9:34 PM Inada Naoki wrote: > On Sat, Jun 13, 2020 at 8:20 PM Inada Naoki > wrote: > > > > 2020年6月13日(土) 20:12 Kyle Stanley : > >> > >> > Additionally, raise DeprecationWarning runtime when these APIs are > used. > >> > >> So, just to clarify, current usage of these 7 unicode APIs does not > emit any warnings and would only start doing so in 3.10? > > > > They have been deprecated in C already. Compiler emits warning. > > > > This additional proposal is adding runtime warning before removal. > > > > I'm sorry, I was wrong. Py_DEPRECATED(3.3) is commented out for some APIs. > So Python 3.8 doesn't show warning for them. > I want to uncomment them in Python 3.9. > https://github.com/python/cpython/pull/20878 > > As far as I grepped, most of PyPI packages use deprecated APIs because > Cython generates it. > Updating Cython will fix them. > Some of them are straightforward and I have created an issue or sent > pull request already. > > A few projects, pyScss and Genshi are not straightforward. But it is > not too hard and I will help them. > > I still think 2 years are enough to removal. > > Regards, > ___ 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/IKT3F2Q2CWFCRYWBKQYAL2DOZJFKQK2R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: When can we remove wchar_t* cache from string?
12.06.20 11:32, Inada Naoki пише: Hi, all. Py_UNICODE has been deprecated since PEP 393 (Flexible string representation). wchar_t* cache in the string object is used only in deprecated APIs. It waste 1 word (8 bytes on 64bit machine) per string instance. The deprecated APIs are documented as "Deprecated since version 3.3, will be removed in version 4.0." See https://docs.python.org/3/c-api/unicode.html#deprecated-py-unicode-apis But when PEP 393 is implemented, no one expects 3.10 will be released. Can we reschedule the removal? My proposal is, schedule the removal on Python 3.11. But we will postpone the removal if we can not remove its usage until it. I have a plan for more graduate removing of this feature. I created a PR which adds several compile options, so Python can be built in one of three modes: 1. Support wchar_t* cache and use it. It is the current mode. 2. Support wchar_t* cache, but do not use it internally in CPython. It can be used to test whether getting rid of the wchar_t* cache can have negative effects. 3. Do not support wchar_t* cache. It is binary incompatible build. Its purpose is to allow authors of third-party libraries to prepare to future breakage. The plan is: 1. Add support of the above compile options. Unfortunately I did not have time to do this before feature freeze in 3.9, but maybe make an exception? 2. Make option 2 default. 3. Remove option 1. 4. Enable compiler deprecations for all legacy C API. Currently they are silenced for the C API used internally. 5. Make legacy C API always failing. 6. Remove legacy C API from header files. There is a long way to steps 5 and 6. I think 3.11 is too early. https://bugs.python.org/issue36346 https://github.com/python/cpython/pull/12409 ___ 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/IB5M72AV3YD5UFF5KV3YAI7HQ3WD3HQ5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: How to specify optional support of arguments
15.06.20 04:06, Greg Ewing пише: Instead of a bunch of ad-hoc mechanisms for finding out about platform-dependent arguments, maybe there should be a function in the inspect module for testing whether a function has a given argument. Then you could say something like if inspect.hasargument(glob.glob, 'dir_fd'): ... How can the inspect module know? The function's signature is the same. Just not all values or types are accepted on all platforms. ___ 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/HKQ6J7E7QQJHS5YWP4KDPLJLQFUBPPZ4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: How to specify optional support of arguments
On 15.06.2020 8:45, Serhiy Storchaka wrote: 14.06.20 23:45, Ivan Pozdeev via Python-Dev пише: 1. The documentation clearly says that it's supported depending on OS flavor -- so if I want to know if I can supply it, I need to rather check `os.name`. Those members are thus redundant. If the distinction is finer than os.name then I'd need some other, case-specific check depending on what the distinction is; alternatively, I could check the function's signature in its metadata if the support is reflected in it. Yes, it is finer than os.name. It can depend on the kernel or libc version (and we do not know which versions are required on every platform), and there are a lot of platforms besides the main three. The user should not be expert in all platforms on which his program potentially can be ran. The function's signature is the same on all platforms. Just on some platforms only default value can be passed (None for dir_fd) or only specific types of argument is accepted (path-like, but not int). Then a single boolean flag is clearly not enough. Compare: in https://docs.python.org/3/library/resource.html , the set of present RLIMIT_* members shows which rlimits are available in the specific OS. So I guess you want some similar pointers that would show which relevant #define constants (or other C-level entities that govern the availability) were present at the time of compilation. If availability is rather governed by a runtime than compile-time check, then something to perform the same check should be introduced; the distinction from .supports_stuff is it would be named after the check and completely decoupled from any functions that might be affected by the check. ___ 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/YWYTZRLQK4ZHRFX3G3MJDGN6H4BJQCKN/ 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/BJ7HFKNQAO3C44XQ75AEYCRTG5GMYTU5/ Code of Conduct: http://python.org/psf/codeofconduct/
