[Python-Dev] Re: Switching to Discourse
I think it's a great idea! :) [1] LLVM did the same recently (though they imported all previous messages from the mailinglist, thus making them searchable in discourse) [2 - announcement; 3 - retro], and by and large, I think it was a success. One of the comments in the retro was: > Searching the archives is much easier and have found me many old threads that > I probably would have problem finding before since I haven’t been subscribed > for that long. I that it would be worth considering importing the mailing list into a separate discourse category that's then archived, but at least searchable. This would also lower the hurdle of new(er) contributors to investigate previous discussion on a given topic. [1] https://discuss.python.org/t/what-i-miss-here-coming-from-users-rust-lang-org/13859/9 [2] https://blog.llvm.org/posts/2022-01-07-moving-to-discourse/ [3] https://discourse.llvm.org/t/response-to-the-move-to-discourse-retrospective/63159 ___ 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/OXT7GFFMSQITQKAEH42COI2PSCFTAJVW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [RELEASE] The cursed fourth Python 3.11 beta (3.11.0b4) is available
Agreed on all 4 counts! :) ___ 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/ERRID6WTR2RMXIUT4MN2JRAGOW6IDAHT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [RELEASE] The cursed fourth Python 3.11 beta (3.11.0b4) is available
> Also the GH bot is using DD/MM/ date format :-( whyy? Because github is international, and everyone but the US seems to agree that ``` /\ / \ /\ / day \ /\ / \ /month \ /__\ /\ / year \ /\ ``` is preferable to ``` __ / \ /month \ /__\ /\ / \ /\ / day \ ___/\___ /\ / year \ /\ ``` ___ 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/EQO2SCU76WC6JQAZOFVUZ2RHW4LU7GXI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Using the Python C API in C++
> Not for me to answer, I'm not a proponent of the change. I'm sure if > you read past discussions here and on Discourse you'll find answers > from the people who studied the problem carefully. The opening mail proposed C++11 without rationale or references. I did search the archives and discourse before, but nothing stood out, and I don't think an encyclopedic knowledge of past python-dev discussions is a reasonable requirement to comment or propose a variation on its merits. > I thought you might have something to add to the conversation, but I guess > not? I find this tone quite out-of-place. I made a proposal (based on compiler support, version hygiene and compatibility with newer standards), and I'd have been more than happy to hear arguments (like Antoine's) or references for the merits of preferring C++11 (though, again, the point became moot since Victor correctly pointed out we can test against several versions). Still, the insinuation (as it arrives on my end) that I shouldn't participate seems really unnecessary. Best, H. ___ 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/7SSI53EDU2U565O2TYRTU4CPYLVXPO5K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Using the Python C API in C++
> I work on Apache Arrow, where the C++ parts require C++11 (and we can't go further than this for now because of R compatibility concerns). Thanks for the datapoint, that's reasonable of course (though I'll note you're using abseil at least through grpc, and abseil is scheduled to remove C++11 support this year: https://abseil.io/blog/20201001-platforms). > We could say that enabling the Python bindings switches the required C++ > version to C++14, but that would bring complication for no actual again > given that you're not likely to benefit from C++14 features in the > header files of a *C* project, are you? I get your point, and I agree. My argument was to ensure compatibility with more recent standard versions, and Victor already suggested that several versions could be tested. Best H. ___ 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/X7KTI36ZWSYOURPEG3NFKEFO7TQ5L2WE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Using the Python C API in C++
> > While I don't know who proposed C++11 or where, I'd therefore like > > to propose to move to _at least_ C++14. > > What benefits does this have for Python development? Likewise I can ask what benefits choosing C++11 would have? In general, I think standards and compilers need version hygiene like anything else, just with a larger lag. But even in the standard things get deprecated occasionally, and more importantly: new warnings may get issued, and being able to include CPython into C++ warning-free was one of the points that Victor mentioned specifically. ___ 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/KGJN7LN6FWAYFF2IYH5FMWWPEIWH5OMG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Using the Python C API in C++
> In terms of C++ version, it was proposed to target C++11. GCC 5 has full C++14 support (one library functionality missing), and so does VS2015 onwards as well as Clang 3.4, see https://en.cppreference.com/w/cpp/compiler_support I doubt that any older compilers are in use _anywhere_ in reasonable numbers that this should constrain the development of CPython. While I don't know who proposed C++11 or where, I'd therefore like to propose to move to _at least_ C++14. Note that https://github.com/python/peps/pull/2309 already bumped the required C-standard to C11, and originally defined this as > The C11 subset are features supported by GCC 8.5, > clang 8.0, and MSVC of Visual Studio 2017. If those versions should be regarded as the lower bounds of compiler support (are they - or anything lower - tested on the build bots...?), then C++17 core language support would automatically fall out of this (there are some stragglers for full stdlib support, especially in clang; but that is usually not an issue). Best H. ___ 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/AGUI6B6W55TUXL6SA7KQQGPYYSRJNCFH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
> And it seems like we still care about support Visual Studio 2017, even > if Visual Studio 2019 and 2022 are available. Can we make this more concrete? Do we know of affected parties? Numbers of affected users? Or are we just conservatively guesstimating the thickness of the long tail of support? On top of that, I think the formulation you chose does not map correctly to actual compiler capabilities. C99 (minus C11 optionals) only arrived in VS2019, there were still gaps in VS2017. I would advocate bumping the requirement to VS2019. Yes, there is a built-in reluctance to update toolchains, but MSFT has been _extremely_ conservative w.r.t. ABI-compatibility (e.g. the whole story with [[msvc::no_unique_address]]), and I just don't see the argument why a non-negligible portion of users cannot upgrade to the fully-compatible-with-everything-previously VS2019. > "Python 3.11 and newer versions use C99 in the public C API and use a > subset of C11 in Python internals. The public C API should be > compatible with C++. The C11 subset are features supported by GCC 8.5, > clang 8.0, and MSVC of Visual Studio 2017." If we were to require VS2019, then the formulation could be much nicer (IMO): """ Python 3.11 and newer versions use C99 in the public C API (without those features that became optional in C11), while Python internals may use C11 (again without optional features). The public C API should be compatible with C++. """ ___ 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/PAIVGORIDRIGLPCSQI5KN6U6CKFTBHPX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
> While the SC's decision to keep the syntax uniform is certainly laudable, > it's creating the issue of packaging new complexities into a very limited > syntactic & semantic space (e.g. no new magic symbols like "->", which I > agree with BTW), leaving only very verbose solutions that the typing crowd is > chafing against. Seems that I unintentionally ended up jinxing the callable type syntax PEP - I must have misread some of the discussions up until that point, thinking that "->" had been already ruled out - sorry! > I think accepting that typing has a syntactic cost on the python language as > a whole is unavoidable at some point (and I'm not saying that's a bad thing). > Having a separate & opt-in mini-language for type declarations seems like a > really clean way to delineate that cost resp. extension, and I especially > like the t''-string syntax. In light of the rejection of that PEP, I think this point is worth revisiting (in due time). ___ 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/BKMUZVICTAOZXS6QA2XXO7YMIFBYWB3E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
> Maybe a more practical approach would be to use C99 "except of features not supported by MSVC of Visual Studio 2019"? This could be formulated in a more neutral way by saying "C99 without the things that became optional in C11", or perhaps "C11 without optional features" (at least from the POV of MSVC, haven't checked the other compilers/platforms for C11-compliance). > In practice, we can try to support VS 2017, the version currently recommended by the devguide: That is becoming dated quickly, as Microsoft has deprecated, and is removing, that version quite rapidly from their CI services (azure/GHA), i.e. mid March, see: https://github.com/actions/virtual-environments/issues/4312. It's understandable in the sense that they don't want to support a third version in addition to vs2022 and vs2019, but the net effect is that very few (open source) projects will keep using vs2017 going forward. ___ 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/IIZ6LXK2MANUHZAMYSXDF5KPF3VIRKDJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
I find this a really elegant approach. While the SC's decision to keep the syntax uniform is certainly laudable, it's creating the issue of packaging new complexities into a very limited syntactic & semantic space (e.g. no new magic symbols like "->", which I agree with BTW), leaving only very verbose solutions that the typing crowd is chafing against. I think accepting that typing has a syntactic cost on the python language as a whole is unavoidable at some point (and I'm not saying that's a bad thing). Having a separate & opt-in mini-language for type declarations seems like a really clean way to delineate that cost resp. extension, and I especially like the t''-string syntax. Best, H. ___ 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/OLI7H6H6COIREFFY3VMJDVPJHNI5HVGS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
Baptiste Carvello wrote: > y = config["handler"]["parameters"]["y"] with KeyError as None I love the look of this! While it doesn't address everything that PEP505 does, that's IMO a good thing, because - as other people mentioned already - None does too many things already. On another note, the whole discussion reminds me of wg21.link/p0798, which is about adding something quite similar to C++ (was accepted into C++23), and contains a decent overview of how other languages solve the same thing. Even though the approach there is probably not applicable (as all python types are implicitly `Optional` in the sense of "can be None", i.e. that API would have to be added all the way down to `object`), it's still ironic that C++'s `and_then` looks more pythonic than what's proposed here. ___ 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/6JD5VGTVE2TVHUMU7OWIYT7QJEKAGRI7/ Code of Conduct: http://python.org/psf/codeofconduct/
