[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
> The main thing from a project maintenance perspective is for platforms to not become a burden to other code maintainers. PRs need to be reviewed. Every #if/#endif in code is a cognitive burden. So being a minor platform can come with unexpected breakages that need fixing due to other changes made in the codebase that did not pay attention to the platform. As we cannot expect everyone working on code to care about anything beyond the tier-1 fully supported platforms, buildbot or not. Yes, but all this doesn't apply here. We're literally talking about a few lines of autoconf and preprocessor defines [1]. In fact, the change to remove "s390 support" (in quotes because these few lines don't really can be considered platform-specific code), introduces more lines than it removes because of the comments. Adrian > [1] https://github.com/python/cpython/pull/24534/files ___ 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/OFBMDNWADAULXH7IS4ABGNSAYF4KFMI7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
There are zero technical reasons for what you are planning here.
You are inflating a few lines of autoconf into a "platform support", so you
have a reason to justify adding multiple lines of extra autoconf codes to make
life for downstream distributions harder.
I could understand the maintenance burden argument if there was actually any
maintenance burden, there isn't.
The thing is you made assumptions about how downstream distributions use Python
without doing some research first ("16-bit m68k-linux"). I have explained that
these assumptions are not correct and that downstreams do actively use Python
in ways that upstream no longer considers supported, yet you want to make
changes to make everything for downstreams harder.
I have not seen any other upstream project that is so bothered about a few
lines of autoconf code. All other upstream projects I have worked with, be it
Rust, OpenJDK, abseil-cpp and so on: None of them had problems when I sent
patches to improve the code on more architectures.
But in Python, it's suddenly a problem and you start long discussions about a
few lines of autoconf code that pose zero maintenance burden.
I absolutely don't get it.
Adrian
___
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/RD75H2KJQS2YC5H6P75PNGEDZ5UNCTHQ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Doctest crashes on unittest.call import. bpo-35753
Hello, I am trying to sort out what can be done for bpo-35753 / https://github.com/python/cpython/pull/22981 Basically any module that does "from unittest.mock import call" will crash the doctest scanner. At this point I'm not sure how to proceed at this point, there is some different ideas on how to fix it, I guess I could try to fix this differently, however I am a little worried that the different fix suggested in the PR will be higher risk, that said if folks would be up for reviewing this change I would give it a shot to code it up. Can't tell right now if there's no interest in reviewing this patch because there is a feeling that it should be done differently, or just lack of interest in doctest. Can I get clued in on what is the best way forward? I am happy to redo patch, but unsure there is enough interest in this problem for an alternative patch to be reviewed. thanks, -Alfred Forwarded Message Subject: [Python-Dev] minor PR 22981 waiting review ~20 days: https://github.com/python/cpython/pull/22981 Date: Mon, 14 Dec 2020 13:25:36 -0800 From: Alfred Perlstein Organization: FreeBSD To: Python Dev PR 22981 is a minor update to doctest to allow it to safely consume modules which contain objects that cause inspect.unwrap to throw. I believe the review comments in the PR have been addressed at this point for ~20 days. The patch is relatively small, reviews are done, but it is unmerged. Is there a way to "bump" the request for review? thank you, -Alfred ___ 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/2YFKPBDFX3Q53PMDNWAV3ZKCSTSVZJXJ/ 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/C24MPE5NUGMIDLLABR7AUONWAZOI5EWH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 597 bikeshedding: envvar / option name.
Thank you for all. I finally submit the PEP 597 with PYTHONWARNDEFAULTENCODING / warn_default_encoding. On Mon, Feb 15, 2021 at 2:28 PM Inada Naoki wrote: > > I am updating PEP 597 to include discussions in the thread. > Before finishing the PEP, I need to decide the option name. > > I used PYTHONWARNDEFAULTENCODING (envvar name) / > warn_default_encoding (-X option and sys.flags name) before, but it > seems too long and hard to type, easy to misspell. > > Currently, I use PYTHONWARNENCODING / warn_encoding, but it is not so > explicit. > > Which name is the best balance between explicitness and readability? > > * PYTHONWARNENCODING / warn_ecoding > * PYTHONWARNOMITENCODING / warn_omit_encoding > * PYTHONWARNDEFAULTENCODING / warn_default_encoding > * Anything else > > Regards, > -- > Inada Naoki -- 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/AX3YE6AM7FVV44GNQLDAFMSBWRZFWR4B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Deprecate support for mingw - add to PEP 11
On Sun, Feb 21, 2021 at 10:02 AM Dan Stromberg wrote:
>
> It looks like CPython remains 100% C, so clang becomes more attractive:
>
> https://stackoverflow.com/questions/6329688/llvm-and-visual-studio-obj-binary-incompatibility
>
> Then again, do we allow C++ extension modules? That might make C++ more
> relevant, even if CPython itself is purely C.
>
Extensions can easily be built in any language, C++ is even documented, and
I've built a simple one in Rust when I was learning it -- as long as you
use the equivalent of extern "C" { } for that language, or rebuild the
headers you need in another language (quite an undertaking, admittedly,
even with a header parser).
The line "You will still need the C compiler that was used to build Python;
typically Microsoft Visual C++." hasn't been accurate in a long time either
(it's been in there since Python 2.2, when VC++ 6.0 was the latest, which
had quite a few... quirks), anything that can digest the headers can link
via the C API just fine. I guess since it's just not tested or supported,
so you're on your own if you run into any issues with memory management,
threading conflicts, compiler bugs, header conversion issues, etc.
-Em
___
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/7VLV5LCW7XL2OILMVS57WDWDGDU5O765/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Inadequate error reporting during function call setup stage
On 2/21/2021 12:04 PM, Paul Sokolovsky wrote: Traceback (most recent call last): File "pseudoc_tool.py", line 91, in first_class_function_value(func, **pass_params) TypeError: print() got an unexpected keyword argument 'noann' This is not typical behavior in current Python (3.8+). def f(): pass def g(): f(a=0) g() for instance, results in Traceback (most recent call last): File "F:\Python\a\tem3.py", line 3, in g() File "F:\Python\a\tem3.py", line 2, in g def g(): f(a=0) TypeError: f() got an unexpected keyword argument 'a' def f(): print(b=4) def g(): f() g() gives me Traceback (most recent call last): File "F:\Python\a\tem3.py", line 3, in g() File "F:\Python\a\tem3.py", line 2, in g def g(): f() File "F:\Python\a\tem3.py", line 1, in f def f(): print(b=4) TypeError: 'b' is an invalid keyword argument for print() Can you create a minimal complete verifiable example and post it on bugs.python.org. This is where bug reports belong, not on pydev and python-ideas. I now implemented that too, and now everything makes sense: Traceback (most recent call last): File "pseudoc_tool.py", line 91, in File "../xforms.py", line 25, in print TypeError: unexpected keyword argument 'noann' Since you have a fix in your repository, perhaps you can include a PR against cpython master branch. -- Terry Jan Reedy ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QK2FWYBY3SJ2KPMJ37HCEF7QM5DDN2MT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
On Sun, Feb 21, 2021 at 4:16 AM Victor Stinner wrote: > > There is also a 4th category: platforms/archs which are really not > supported, like they legacy ones for which we removed the code :-) > Examples: BeOS, MacOS 9, platforms with no thread support, etc. > FWIW, BeOS may be resurfacing somewhat, with https://en.wikipedia.org/wiki/Haiku_(operating_system) - it's on a second beta now. ___ 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/FQY7MYCHGWBFNYQRW5LH5YMY3IJWOFWU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
On Sun, Feb 21, 2021 at 1:07 PM Gregory P. Smith wrote: > > > I'm +1 in general for your proposal. I also like the idea to adopt >> > Rust's platform support definition. >> > +1, but see below. > > The main thing from a project maintenance perspective is for platforms to > not become a burden to other code maintainers. PRs need to be reviewed. > Every #if/#endif in code is a cognitive burden. So being a minor platform > can come with unexpected breakages that need fixing due to other changes > made in the codebase that did not pay attention to the platform. As we > cannot expect everyone working on code to care about anything beyond the > tier-1 fully supported platforms, buildbot or not. > I think #ifdef's are a big part of the problem, actually. IIRC, the Linux kernel has been reducing/eliminating #ifdef's and instead using different .c's for each platform's platform-specific code. ___ 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/HRXPWBJNBCRE5RMA2KFMKWB3VA6MJZG3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
On Sun, Feb 21, 2021 at 12:03 PM Michał Górny wrote: > On Sun, 2021-02-21 at 13:35 +0100, Christian Heimes wrote: > > On 21/02/2021 13.13, Victor Stinner wrote: > > > Hi, > > > > > > I propose to actively remove support for *legacy* platforms and > > > architectures which are not supported by Python according to PEP 11 > > > rules: hardware no longer sold and end-of-life operating systems. The > > > removal should be discussed on a case by case basis, but I would like > > > to get an agreement on the overall idea first. Hobbyists wanting to > > > support these platforms/archs can continue to support them with > > > patches maintained outside Python. For example, I consider that the > > > 16-bit m68k architecture is legacy, whereas the OpenBSD platform is > > > still actively maintained. > > [...] > > > Python has different kinds of platform and architecture supports. In > > > practice, I would say that we have: > > > > > > * (1) Fully supported. Platform/architecture used by core developers > > > and have at least one working buildbot worker: fully supported. Since > > > core developers want to use Python on their machine, they fix issues > > > as soon as they notice them. Examples: x86-64 on Linux, Windows and > > > macOS. > > > > > > * (2) Best effort. Platform/architecture which has a buildbot worker > > > usually not used by core developers. Regressions (buildbot failures) > > > are reported to bugs.python.org, if someone investigates and provides > > > a fix, the fix is merged. But there is usually no "proactive" work to > > > ensure that Python works "perfectly" on these platforms. Example: > > > FreeBSD/x86-64. > > > > > > * (3) Not (officially) supported. We enter the blurry grey area. There > > > is no buildbot worker, no core dev use it, but Python contains code > > > specific to these platforms/architectures. Example: 16-bit m68k and > > > 31-bit s390 architectures, OpenBSD. > > > > > > The Rust programming language has 3 categories of Platform Support, > > > the last one is : > > > > Thanks Victor! > > > > (short reply, I'm heading out) > > > > I'm +1 in general for your proposal. I also like the idea to adopt > > Rust's platform support definition. > > > > For 3.10 I propose to add a configure option to guard builds on > > unsupported / unstable platforms. My draft PR > > > https://github.com/python/cpython/pull/24610/commits/f8d2d56757a9cec7ae4dc721047336eaba097125 > > implements a checker for unsupported platforms and adds a > > --enable-unstable-platforms flag. Configuration on unsupported platforms > > fails unless users explicitly opt-in. > > > > The checker serves two purposes: > > > > 1) It gives users an opportunity to provide full PEP 11 support > > (buildbot, engineering time) for a platform. > > Does that mean that if someone offers to run the build bot for a minor > platform and do the necessary maintenance to keep it working, they will > be able to stay? How much maintenance is actually expected, i.e. is it > sufficient to maintain CPython in a 'good enough' working state to > resolve major bugs blocking real usage on these platforms? > > Definitely start with this. This level of effort to maintain the minor platform support in-tree may be able to keep an otherwise neglected minor platform in second tier non-release-blocker best effort status. Having a buildbot, at least provides visibility, and sometimes PR authors will be sympathetic to easy edits that keep something working that way (no guarantee). The main thing from a project maintenance perspective is for platforms to not become a burden to other code maintainers. PRs need to be reviewed. Every #if/#endif in code is a cognitive burden. So being a minor platform can come with unexpected breakages that need fixing due to other changes made in the codebase that did not pay attention to the platform. As we cannot expect everyone working on code to care about anything beyond the tier-1 fully supported platforms, buildbot or not. Example: I consider many of the BSDs and the Solaris derivatives to be in this state. (non specific here, i don't even know which ones we claim are supported or not without going and reading whatever policy docs we might or might not have today - Victor alludes to this state of the world). We tend to accept patches when someone offers them. Occasionally we have a core dev who actually runs one of them. But most of us don't go out of the way ourselves to try and keep changes we make working there. We expect interested parties to jump in when something isn't working right. And will generally do related PR reviews/merges if they're not burdensome. An example of the above happening recently is VxWorks support via https://bugs.python.org/issue31904. -gps > -- > Best regards, > Michał Górny > > ___ > 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] Re: Move support of legacy platforms/architectures outside Python
On Sun, Feb 21, 2021 at 10:15 AM Christian Heimes wrote: > On 21/02/2021 13.47, glaub...@debian.org wrote: > > Rust doesn't keep any user from building Rust for Tier 2 or Tier 3 > platforms. There is no separate configure guard. All platforms that Rust > can build for, are always enabled by default. No one in Rust keeps anyone > from cross-compiling code for sparc64 or powerpcspe, for example. > > > > So if you want to copy Rust's mechanism, you should just leave it as is > and not claim that users are being confused because "m68k" shows up in > configure.ac. > > A --enable-unstable-platforms configure flag is my peace offer to meet > you half way. You get a simple way to enable builds on untested > platforms and we can clearly communicate that some OS and hardware > platforms are not supported. > I personally wouldn't want to maintain such a check in autoconf, but it'll be an isolated thing on its own, that if you or someone else creates, will do its job and not bother the rest of us. I think just publishing our list of (1) supported, (2) best-effort non-release-blocker quasi-supported, and (3) explicitly unsupported in a policy doc is sufficient. But it's not like any of us are going to stop someone from codifying that in configure.ac to require a flag. -gps > ___ > 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/W3L2RISXFKHRWPYQB232XH7PDIOPKNDY/ > 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/TX6UDWZZJX5IMJIQCGUM7C3QDJ6ESACR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
On Sun, 2021-02-21 at 13:35 +0100, Christian Heimes wrote: > On 21/02/2021 13.13, Victor Stinner wrote: > > Hi, > > > > I propose to actively remove support for *legacy* platforms and > > architectures which are not supported by Python according to PEP 11 > > rules: hardware no longer sold and end-of-life operating systems. The > > removal should be discussed on a case by case basis, but I would like > > to get an agreement on the overall idea first. Hobbyists wanting to > > support these platforms/archs can continue to support them with > > patches maintained outside Python. For example, I consider that the > > 16-bit m68k architecture is legacy, whereas the OpenBSD platform is > > still actively maintained. > [...] > > Python has different kinds of platform and architecture supports. In > > practice, I would say that we have: > > > > * (1) Fully supported. Platform/architecture used by core developers > > and have at least one working buildbot worker: fully supported. Since > > core developers want to use Python on their machine, they fix issues > > as soon as they notice them. Examples: x86-64 on Linux, Windows and > > macOS. > > > > * (2) Best effort. Platform/architecture which has a buildbot worker > > usually not used by core developers. Regressions (buildbot failures) > > are reported to bugs.python.org, if someone investigates and provides > > a fix, the fix is merged. But there is usually no "proactive" work to > > ensure that Python works "perfectly" on these platforms. Example: > > FreeBSD/x86-64. > > > > * (3) Not (officially) supported. We enter the blurry grey area. There > > is no buildbot worker, no core dev use it, but Python contains code > > specific to these platforms/architectures. Example: 16-bit m68k and > > 31-bit s390 architectures, OpenBSD. > > > > The Rust programming language has 3 categories of Platform Support, > > the last one is : > > Thanks Victor! > > (short reply, I'm heading out) > > I'm +1 in general for your proposal. I also like the idea to adopt > Rust's platform support definition. > > For 3.10 I propose to add a configure option to guard builds on > unsupported / unstable platforms. My draft PR > https://github.com/python/cpython/pull/24610/commits/f8d2d56757a9cec7ae4dc721047336eaba097125 > implements a checker for unsupported platforms and adds a > --enable-unstable-platforms flag. Configuration on unsupported platforms > fails unless users explicitly opt-in. > > The checker serves two purposes: > > 1) It gives users an opportunity to provide full PEP 11 support > (buildbot, engineering time) for a platform. Does that mean that if someone offers to run the build bot for a minor platform and do the necessary maintenance to keep it working, they will be able to stay? How much maintenance is actually expected, i.e. is it sufficient to maintain CPython in a 'good enough' working state to resolve major bugs blocking real usage on these platforms? -- Best regards, Michał Górny ___ 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/FI2D6VQQ4DBBCTYOWYMZBTSU2VWCQP34/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
On Sun, 2021-02-21 at 19:12 +0100, Christian Heimes wrote: > On 21/02/2021 13.47, glaub...@debian.org wrote: > > Rust doesn't keep any user from building Rust for Tier 2 or Tier 3 > > platforms. There is no separate configure guard. All platforms that Rust > > can build for, are always enabled by default. No one in Rust keeps anyone > > from cross-compiling code for sparc64 or powerpcspe, for example. > > > > So if you want to copy Rust's mechanism, you should just leave it as is and > > not claim that users are being confused because "m68k" shows up in > > configure.ac. > > A --enable-unstable-platforms configure flag is my peace offer to meet > you half way. You get a simple way to enable builds on untested > platforms and we can clearly communicate that some OS and hardware > platforms are not supported. Does that imply accepting non-intrusive patches for platform support, or at least not proactively removing it? -- Best regards, Michał Górny ___ 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/XKEQUDQNSQ27IJI6IH755PZYNHOQGBSF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
On 21/02/2021 13.47, glaub...@debian.org wrote: > Rust doesn't keep any user from building Rust for Tier 2 or Tier 3 platforms. > There is no separate configure guard. All platforms that Rust can build for, > are always enabled by default. No one in Rust keeps anyone from > cross-compiling code for sparc64 or powerpcspe, for example. > > So if you want to copy Rust's mechanism, you should just leave it as is and > not claim that users are being confused because "m68k" shows up in > configure.ac. A --enable-unstable-platforms configure flag is my peace offer to meet you half way. You get a simple way to enable builds on untested platforms and we can clearly communicate that some OS and hardware platforms are not supported. ___ 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/W3L2RISXFKHRWPYQB232XH7PDIOPKNDY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Deprecate support for mingw - add to PEP 11
It looks like CPython remains 100% C, so clang becomes more attractive: https://stackoverflow.com/questions/6329688/llvm-and-visual-studio-obj-binary-incompatibility Then again, do we allow C++ extension modules? That might make C++ more relevant, even if CPython itself is purely C. On Sat, Feb 20, 2021 at 9:08 PM Dan Stromberg wrote: > mingw-w64 might be a small change. > > But while one is it at, it might make sense to evaluate: > https://clang.llvm.org/docs/MSVCCompatibility.html > Apparently clang on Windows is working on calling convention compatibility > with Visual Studio. > > > On Sat, Feb 20, 2021 at 8:37 PM wrote: > >> I think perhaps we should admit that this build system is no longer >> supported. From everything I can tell, the mingw project is no longer >> maintained. The project's site, mingw.org, is no longer live; the >> project on sourceforge, although still downloaded daily, had its last >> commit almost 3 years ago - a commit which changed the official project URI >> to a new link that now is also dead. >> Looking over BPO there are a little over 50 bugs open against mingw, but >> only 7 that have any meaningful activity within the last three years. Three >> of those issues explicitly mention mingw-w64 which is an active fork of the >> original mingw project (active homepage, commits almost daily, new release >> within the last 6 months) and I wonder if this is the project the other 4 >> projects meant by "mingw"? >> Ideally any features and flags in the code base for mingw would be >> checked to already be working with mingw-w64 or else modified to work, but >> this would require a sponsor for this platform, which appears to be >> missing. Further, there is no buildbot for mingw, which should be a >> requirement to be a fully supported platform, as per this PEP. This >> potential work appears non-trivial with a cursory look at the >> mingw-w64-python pacman project, which contains close to 100 patch files. I >> am purposing instead that mingw be deprecated and, if a sponsor comes >> along, mingw-w64 can become re-supported, or newly supported depending on >> you point of view, as allowed by the PEP. >> ___ >> 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/XIWF3OYL7OQRBVRBBQCBKPPJH5OKVVRC/ >> 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/HEK67QOUQ4RD42HLBDTR3CJJNEMB3HJF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Inadequate error reporting during function call setup stage
Hello, Here's example: Traceback (most recent call last): File "pseudoc_tool.py", line 91, in first_class_function_value(func, **pass_params) TypeError: print() got an unexpected keyword argument 'noann' Ok, which "print" do you mean, dear CPython? I have a dozen of print functions (mostly methods) around. So I now need to reduce to printf debugging to find which one is actually meant. And what if that happens in 3rd-party library installed in /usr/lib? On a production system? The most interesting fact is that despite functions has always been first-class values and 30-years language history, such issues are still there. I'm fixing this right away in my Pycopy dialect, because while it's minimalist and I tremble over each half-byte added, but it's Python first of all, and Python means good error reporting. Well, actually I don't fix it right away, but work around, put putting source loc in TypeError's error message. And here's an idea of what the real fix should be: The fact that CPython (and Pycopy) sets up function's frame "outside" the function execution is an implementation detail. The model of execution should be: there's a CALL_FUNCTION/CALL_FUNCTION_KW opcode, and after it executes, the context switches to the target function, and that's *when* argument checking happens. That would give the desired behavior that the last entry in traceback is the actual function which was called and which failed parameter checks. Again, it's an implementation detail if some project doesn't do it like that, and performs param checking before actually pointing VM at the new bytecode function (from which location traceback will be automatically constructed). If it does that, it just still need to append an additional traceback entry pointing to the beginning of the target function. I now implemented that too, and now everything makes sense: Traceback (most recent call last): File "pseudoc_tool.py", line 91, in File "../xforms.py", line 25, in print TypeError: unexpected keyword argument 'noann' -- Best regards, Paul mailto:pmis...@gmail.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/VY3QAU2TEXOPELGDS7RTQOX4357QWILR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Happy 30th Birthday, Python!
On Sun, Feb 21, 2021 at 12:05 AM Larry Hastings wrote: > I guess we forgot to observe it yesterday, but: February 19, 1991, was the > day Guido first posted Python 0.9.1 to alt.sources: > > https://groups.google.com/g/alt.sources/c/O2ZSq7DiOwM/m/gcJTvCA27lMJ > > Happy 30th birthday, Python! Happy 30th Birthday, Python. Congrats to Guido. The way software was distributed then seems incredible. It's been an exciting journey for all of us. -- Senthil ___ 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/KAZXZNP7RC7K4B7W5VIRJWBYJCBNIK7Z/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
Rust doesn't keep any user from building Rust for Tier 2 or Tier 3 platforms. There is no separate configure guard. All platforms that Rust can build for, are always enabled by default. No one in Rust keeps anyone from cross-compiling code for sparc64 or powerpcspe, for example. So if you want to copy Rust's mechanism, you should just leave it as is and not claim that users are being confused because "m68k" shows up in configure.ac. Adrian ___ 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/5DXDCNS4C3JS43JGLIKYTRNV6AAQE5TD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
(Since my first reply here somehow got lost, I'm posting this again). Rust doesn't prevent anyone from building Tier 2 or Tier 3 targets. There is no limitation for "legacy" or "deprecated" targets. Any target can be built and any target can be selected by the Rust compiler for cross-compliation. So, if you want to mimic the behavior of the Rust compiler, you would obviously not guard any architectures or platforms in configure.ac. I am objecting this change as it does not reduce code complexity (on the contrary) and only causes more maintenance burden for downstream distributions. Thanks, Adrian ___ 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/EEFDCMVRNHDBUHRUXOC4TEFFYA6NETPB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
On 21/02/2021 13.13, Victor Stinner wrote: > Hi, > > I propose to actively remove support for *legacy* platforms and > architectures which are not supported by Python according to PEP 11 > rules: hardware no longer sold and end-of-life operating systems. The > removal should be discussed on a case by case basis, but I would like > to get an agreement on the overall idea first. Hobbyists wanting to > support these platforms/archs can continue to support them with > patches maintained outside Python. For example, I consider that the > 16-bit m68k architecture is legacy, whereas the OpenBSD platform is > still actively maintained. [...] > Python has different kinds of platform and architecture supports. In > practice, I would say that we have: > > * (1) Fully supported. Platform/architecture used by core developers > and have at least one working buildbot worker: fully supported. Since > core developers want to use Python on their machine, they fix issues > as soon as they notice them. Examples: x86-64 on Linux, Windows and > macOS. > > * (2) Best effort. Platform/architecture which has a buildbot worker > usually not used by core developers. Regressions (buildbot failures) > are reported to bugs.python.org, if someone investigates and provides > a fix, the fix is merged. But there is usually no "proactive" work to > ensure that Python works "perfectly" on these platforms. Example: > FreeBSD/x86-64. > > * (3) Not (officially) supported. We enter the blurry grey area. There > is no buildbot worker, no core dev use it, but Python contains code > specific to these platforms/architectures. Example: 16-bit m68k and > 31-bit s390 architectures, OpenBSD. > > The Rust programming language has 3 categories of Platform Support, > the last one is : Thanks Victor! (short reply, I'm heading out) I'm +1 in general for your proposal. I also like the idea to adopt Rust's platform support definition. For 3.10 I propose to add a configure option to guard builds on unsupported / unstable platforms. My draft PR https://github.com/python/cpython/pull/24610/commits/f8d2d56757a9cec7ae4dc721047336eaba097125 implements a checker for unsupported platforms and adds a --enable-unstable-platforms flag. Configuration on unsupported platforms fails unless users explicitly opt-in. The checker serves two purposes: 1) It gives users an opportunity to provide full PEP 11 support (buildbot, engineering time) for a platform. 2) It gives us the leverage to remove a flagged platform in the future or refuse support on BPO. Christian ___ 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/JKSE43ASVGV4DURGOEWVTQIJJM4EBOEI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Move support of legacy platforms/architectures outside Python
Hi, I propose to actively remove support for *legacy* platforms and architectures which are not supported by Python according to PEP 11 rules: hardware no longer sold and end-of-life operating systems. The removal should be discussed on a case by case basis, but I would like to get an agreement on the overall idea first. Hobbyists wanting to support these platforms/archs can continue to support them with patches maintained outside Python. For example, I consider that the 16-bit m68k architecture is legacy, whereas the OpenBSD platform is still actively maintained. I already know that there will be a strike back: "oh no, you must continue to support my architecture" and "their existing code should stay and doesn't cost anything to maintain". Python is maintained by volunteers, the majority is contributing in their free time, so people are free to use their free time as they want. You cannot ask core developers to support your favorite *legacy* platform/architecture if they don't want to. In short, I propose to move maintenance of the legacy platforms/archs outside Python: people are free to continue support them as patches. -- Concrete example: Christian Heimes proposed to drop support for 31-bit s390 Linux: https://bugs.python.org/issue43179 The lack of clear definition on how a platform is supported or not confuses users who consider that their favorite platform/arch is supported, whereas core developers don't want to support it since it would be too much work. In fact, the PEP 11 has clear and explicit rules: https://www.python.org/dev/peps/pep-0011/#supporting-platforms A platform is only considered as supported if the following two conditions are met: 1) a core developer needs to volunteer to maintain platform-specific code 2) a stable buildbot must be provided Last October, I proposed to drop Solaris support (bpo-42173). Jakub Kulik stepped in and proposed some Solaris patches, so I abandoned my idea. But I still don't see any running Solaris buildbot worker, and there is still no core developer volunteer to maintain Solaris support. It's unclear to me if Python has "best effort" support for Solaris, of if Solaris is "not supported". -- Over the years, Python was ported to tons of platforms and CPU architectures. It didn't matter if the platform or the architecture was commonly used or not. 30 years later, Python still has the code for many legacy platforms and architectures. Some hardware is no longer sold but kept alive by hobbyists, especially members of retro computing groups. Some Linux distributions like Gentoo and Debian are trying to support most architectures which are supported by these hobbyist groups, whereas some other distributions like Ubuntu are limited to a few platforms. For example, Ubuntu 20.4.2 LTS server supports 4 architectures: x86-64, AArch64 (ARM), POWER and s390x. I guess that the difference between Debian and Ubuntu is that Ubuntu is a Canonical product, Canonical sells professional support and so cannot support too many architectures. Each architecture support requires to build all packages on it, tests the packages, have experts who fix issues specific to this arch, etc. -- Python has different kinds of platform and architecture supports. In practice, I would say that we have: * (1) Fully supported. Platform/architecture used by core developers and have at least one working buildbot worker: fully supported. Since core developers want to use Python on their machine, they fix issues as soon as they notice them. Examples: x86-64 on Linux, Windows and macOS. * (2) Best effort. Platform/architecture which has a buildbot worker usually not used by core developers. Regressions (buildbot failures) are reported to bugs.python.org, if someone investigates and provides a fix, the fix is merged. But there is usually no "proactive" work to ensure that Python works "perfectly" on these platforms. Example: FreeBSD/x86-64. * (3) Not (officially) supported. We enter the blurry grey area. There is no buildbot worker, no core dev use it, but Python contains code specific to these platforms/architectures. Example: 16-bit m68k and 31-bit s390 architectures, OpenBSD. The Rust programming language has 3 categories of Platform Support, the last one is : "Tier 3 platforms are those which the Rust codebase has support for, but which are not built or tested automatically, and may not work. Official builds are not available." https://doc.rust-lang.org/nightly/rustc/platform-support.html Rust Tier 3 looks like our "Not supported" category. Maybe we should have a better definition in the PEP 11 of our 3 support levels. There is also a 4th category: platforms/archs which are really not supported, like they legacy ones for which we removed the code :-) Examples: BeOS, MacOS 9, platforms with no thread support, etc. -- There is also a "Stable Buildbot" category used by the "Release Status" web page: https://buildbot.python.org/all/#/release_status There is no clear rule why is a
[Python-Dev] Re: Security releases of CPython
Mike Miller writes:
> Sounds like automating until it is "just a push of a button,"
> should be a goal. According to Victor there has been progress, but
> always room for more.
When XEmacs was releasing betas regularly, everything from tagging the
local authoritative repo to pushing to the public repo to making
tarballs to signing and authenticating them to Mad-Libbing the form
for announcement was invocation of a single script. "Somehow" the
typical release was a me-day's work and three calendar days (and unlike
GNU Emacs with its "kitchen sink" standard library or Python with its
batteries from CR-25s to Prius power replacements, XEmacs was just the
Lisp interpreter and basic editor functions).
What takes the time?
1. A courtesy pre-announcement to core devs that the release was
coming (yes, it's on the schedule, no, they don't check their
calendars).
2. Triaging incomplete tasks other folks labeled as "important" or above.
3. Writing news (somebody always forgets, and typically the choice was
write it myself or delay the release).
4. Triaging last-minute "urgent" commits. (They rarely were.)
5. Triaging and where possible fixing test failures.
6. Rolling back premature commits.
7. Scheduling future work that didn't *need* to be in a beta release
(we had a couple of developers who were trying but couldn't write
documentation grammatically to save their commits; it just didn't
make sense to force them to do work I could do in 1/10 the effort).
8. Coordination with the dev who built Windows installers. (A few
Windows users could get pretty cranky if they didn't get an
installer within a couple hours after the Unix-oriented tarball
releases.)
The Python process is more disciplined, and has a lot of automation to
help with the QA stuff. But there's always last-minute "people work",
which is what Brooks would call an "essential difficulty." It's
pretty irreducible. I would imagine the same is true for Python RMs.
> I would argue that security releases are of higher importance than
> most,
*Some* of them are, but this just isn't true most of the time. Take
the very recent CVE-2021-3177, rated 9.8 ("critical", 9.8 out of 10, I
believe) because it *might* lead to remote code execution (RCE) under
(implausible, AFAICS) conditions in current Python. There is no RCE
exploit for arbitrary Python webapps: there are a bunch of other
conditions that must be satisfied. It might be possible to create a
denial of service for some webapps, but that still depends on only
somewhat more plausible conditions.
Then, why 9.8? Well, "remote code execution". The critical rating is
a *threat* assessment, based on *everything* going right for the
attacker, not a *risk* assessment, based on likelihood and degree of
damage. Most reported vulnerabilities have no known exploit and
potential RCE is not the common case: risk is quite small.
Such vulnerabilities must be fixed: as time goes on, risk increases.
Not just more time = more time for the black hats, but the hazard rate
increases too. The particular currently implausible kill chain may be
generalized or others may arise in future versions of Python, or more
webapps may incorporate the risky behavior, etc. But there's no
reason to believe it will be a known exploit soon, and anybody with a
million dollars at risk can (and should) keep a couple of hours of
junior developer time on call to assess risk and apply the patch if
needed. Not to mention that in 2025 there will still be a bunch of
vulnerable 3.8 and 3.9 installations online, which are still whatever
the patchlevel was when they were originally installed.
I believe that had they let this one wait until the scheduled release,
the odds are 1000:1 that *no harm whatsoever* would have been done in
that window. Nevertheless, the relevant release managers (3.8, 3.9,
and Windows) chose to make a quick release. I think "customer
relations" (which are important, I'm not deprecating them!) had as
much to do with the decision as the assessment of risk to Python
users. I am not going to second-guess the actual decision, but I do
think that this is very much a case by case issue not very different
from any "urgent" defect, and in many cases "wait for scheduled
release" is going to be a no-brainer, and in others that will be the
outcome chosen.
Some of the time, there will be an emergency release. That has been
demonstrated to be possible and realistic, even in a case like this
where the need is not open-and-shut. I don't see a need for anything
except more love for the release managers. Of course IWBNI we had the
resources to pay release managers. But we're doing OK.
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/mess
[Python-Dev] Happy 30th Birthday, Python!
I guess we forgot to observe it yesterday, but: February 19, 1991, was the day Guido first posted Python 0.9.1 to alt.sources: https://groups.google.com/g/alt.sources/c/O2ZSq7DiOwM/m/gcJTvCA27lMJ Happy 30th birthday, Python! //arry/ ___ 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/RAPFBOPRDICVP5F2GVRHICMAH5NDHXJS/ Code of Conduct: http://python.org/psf/codeofconduct/
