[Python-Dev] Re: The order of operands in the comparison
20.07.19 18:26, Guido van Rossum пише: In an ideal world, needle is on the right. Let's replace needle with a constant: which of the following looks more natural? for x in sequence: if x == 5: return True or for x in sequence: if 5 == x: return True For me, 'x == 5' wins with a huge margin. (There is a subculture of C coders who have trained themselves to write '5 == x' because they're afraid of accidentally typing 'x = 5', but that doesn't apply to Python.) Should we unify the stdlib? I'm not sure -- it feels like a sufficiently obscure area that we won't get much benefit out of it (people should fix their __eq__ implementation to properly return NotImplemented) and changing it would surely cause some mysterious breakage in some code we cannot control. Thank you. The majority of the code uses needle on the right. There are just 6 places where it is on the left, and the half of them look copy-pasted, and in one place the C code differs from the corresponding Python implementation. There is an order more places where needle is on the right (and it is always on the right in the Python code). So I prefer to fix these few places to get rid of the minor inconsistency. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/VOE23UOO33ZPHWJNNX6QHEPBQVJ7VTIS/
[Python-Dev] Re: The order of operands in the comparison
Serhiy Storchaka wrote: > Thank you. The majority of the code uses needle on the right. There are > just 6 places where it is on the left, and the half of them look > copy-pasted, and in one place the C code differs from the corresponding > Python implementation. There is an order more places where needle is on > the right (and it is always on the right in the Python code). So I > prefer to fix these few places to get rid of the minor inconsistency. If there are only a few places where the needle is on the left and there's not a specific functionality requirement/limitation in those locations which prevent it from being on the right, it's better to have consistency. Is there any particular benefit from having the needle on the left side, or was it just a personal preference from the developer who first implemented the code in those 6 locations? ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/JYQ5YFUWLGULRUX5T36KD6EJEKKY3L22/
[Python-Dev] Re: The order of operands in the comparison
22.07.19 11:04, Kyle Stanley пише: Serhiy Storchaka wrote: Thank you. The majority of the code uses needle on the right. There are just 6 places where it is on the left, and the half of them look copy-pasted, and in one place the C code differs from the corresponding Python implementation. There is an order more places where needle is on the right (and it is always on the right in the Python code). So I prefer to fix these few places to get rid of the minor inconsistency. If there are only a few places where the needle is on the left and there's not a specific functionality requirement/limitation in those locations which prevent it from being on the right, it's better to have consistency. Is there any particular benefit from having the needle on the left side, or was it just a personal preference from the developer who first implemented the code in those 6 locations? See https://bugs.python.org/issue37648. Seems somebody once wrote the code for list.__contains__, and then it was copied to other places. The code in _asynciomodule.c might be independent, but it is inconsistent with the Python code. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/5TX2LX4NIYJ3EHWGQSZ2M7FKGJ2XPLU7/
[Python-Dev] Python 3.7.4, Visual Studio versions for building modules from source
HI, Not sure if this is the right place to ask, but I am trying to build pywin32-224 from source for Python 3.7.4. I think this might be the right list as this seems to be a generic problem I am having, but I want to focus on one particular module. First, I know I could get this via 'pip install', but I want to build from source to see what it takes in terms of the Windows SDK and Visual Studio versions for some other work I am doing. I am using Python 3.7.4, and I have Visual Studio 2017 15.9 (released July of this year). I see this when running 'python setup.y build': error: Microsoft Visual C++ 14.1 is required. Get it with "Microsoft Visual C++ Build Tools": https://visualstudio.microsoft.com/downloads/ I have tried various compilers from that link (VS 2015, VS 2017, and even VS 2019), but no joy. I also have the Windows SDK 8.1 and 10 installed (pywin32 wants the 8.1 SDK) Does anyone have any ideas as to what I am doing wrong, or if there is some weird underlying issue with setuptools and/or distutils? Thanks, Tom ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/4V3F6GRM4LBOYKXBIMAM47HCLA5J6XG3/
[Python-Dev] Re: What is a public API?
Kyle Stanley wrote: > Serhiy Storchaka wrote: > > Either we establish the rule that all non-public > > names must be > > underscored, and do mass renaming through the whole stdlib. Or allow to > > use non-underscored names for internal things and leave the sources in > > Personally, I would be the most in favor of doing a mass renaming through > > stdlib, > at least for any public facing modules (if they don't start with an > underscore, as that > already implies the entire module is internal). Otherwise, I have a feeling > similar issues > will be brought up repeatedly by confused end-users. Same would happen with a rename where people's code suddenly broke. We don't do renames on purpose without a proper deprecation cycle and doing that en-mass would be extremely disruptive. -Brett > This change would also follow the guideline of "Explicit is better than > implicit" by > explicitly defining any function in a public-facing module as private or > public through > the existence or lack of an underscore. There would be some cost associated > with > implementing this change, but it would definitely be worthwhile if it settled > the public > vs private misunderstandings. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/6SP5WOAKP3PQMDJNAF2GJJQQJMZTCJR4/
[Python-Dev] Re: What is a public API?
Brett Cannon wrote: > Same would happen with a rename where people's code suddenly broke. We > don't do renames on purpose without a proper deprecation cycle and doing that > en-mass would be extremely disruptive. Good point, this would probably have to be a gradual change if it did happen, rather than being at all once. If it were to happen with a proper deprecation cycle and clear communication, I think it would result in significantly less confusion overall and provide a higher degree of consistency across stdlib in the long term. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/FYV3Q3YW2KWZGZ7VKMF2AXY3DUNDHWE6/
[Python-Dev] Re: What is a public API?
On Mon, Jul 22, 2019 at 10:02:12PM -, Kyle Stanley wrote about renaming non-public names with a leading underscore: > Good point, this would probably have to be a gradual change if it did > happen, rather than being at all once. If it were to happen with a > proper deprecation cycle and clear communication, I think it would > result in significantly less confusion overall and provide a higher > degree of consistency across stdlib in the long term. You say "significantly less confusion" but I don't think there's much confusion in the first place, so any benefit will be a marginal improvement in clarity, not solving a serious problem. In all my years of using Python, I can only recall one major incident where confusion between public/non-public naming conventions caused a serious problem -- and the details are fuzzy. One of the std lib modules had imported a function for internal use, and then removed it, breaking code that wrongly treated it as part of the public API. So it clearly *does* happen that people misuse private implementation details, but frankly that's going to happen even if we named them all "_private_implementation_detail_dont_use_this_you_have_been_warned" *wink* So in my opinion, "fixing" the std lib to prefix all non-public names to use a leading underscore is going to have only a minor benefit. To that we have to counter with the costs: 1. Somebody has to do the work, review the changes, etc and that takes time and energy that might be better spent on other things. 2. Most abuses of non-public names are harmless; but by deprecating and then changing the name, we guarantee that we'll break people's code, even if it otherwise would have happily worked for years. (Even if it is *strictly speaking* wrong and bad for people to use non-public names in their code, "no harm, no foul" applies: we shouldn't break their code just to make a point.) 3. Leading underscores adds a cost when reading code: against the clarity of "its private" we have the physical cost of reading underscores and the question of how to pronounce them. 4. And the significant cost when writing code. Almost all imports will have to be written like these: import sys as _sys from math import sin as _sin, cos as _cos as well as the mental discipline to ensure that every non-public name in the module is prefixed with an underscore. Let me be frank: you want to shift responsibility of recognising public APIs from the user of the code to the author of the code. Regardless of whether it is worthwhile or not, that's a real cost for developers. That cost is why we have the rule "unless explicitly documented public, all imports are private even if not prefixed with an underscore". All these costs strongly suggest to me that we shouldn't try to "fix" the entire std lib. Let's fix issues when and as they come up, on a case-by-case basis, rather than pre-emptively churning a lot of code. -- Steven ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/FQQALDPECYOFSEF54QQS7JWWSOYOPPW3/
[Python-Dev] Re: Python 3.7.4, Visual Studio versions for building modules from source
On 22Jul.2019 0825, Kacvinsky, Tom wrote: > HI, > > Not sure if this is the right place to ask, but I am trying to build > pywin32-224 from source for Python 3.7.4. I think this might > be the right list as this seems to be a generic problem I am having, but I > want to focus on one particular module. First, I know > I could get this via 'pip install', but I want to build from source to see > what it takes in terms of the Windows SDK and Visual Studio > versions for some other work I am doing. This is probably not the best place to ask, though I can understand why you ended up here. Please try this command: -m test -v test_distutils -m *get_vc* If the tests pass, post to [email protected] or the Packaging category on https://discuss.python.org/ If the tests fail, post the output into a new bug at https://bugs.python.org/ along with If the tests are skipped, you probably did not install the C++ or "Python Native Development" options for Visual Studio. You can run "Visual Studio Installer" from Start to change your installed options. Cheers, Steve ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/L25BIUGNGBYTPJ6ZKG5KGWGNYLYYW2UE/
[Python-Dev] Re: What is a public API?
Upon further consideration and reading your response, I'm starting to think that the proposal to perform a mass renaming across stdlib might have been a bit too drastic, even if it was done over a longer period of time. Thanks for the detailed explanation of the costs, that significantly improved my understanding of the situation. My primary motivation was to provide more explicit declaration of public vs private, not only for the purpose of shifting the responsibility to the authors, but also to shift the liability of using private members to the user. >From my perspective, if the communication is 100% clear that a particular >function is not public, the developers are able to make changes to it more >easily without being as concerned about the impact it will have on users. >Nothing prevents the users from using it anyways, but if a change that occurs >to a private function breaks their functionality, it's completely on them. >With the current system, users can potentially make the argument that they >weren't certain that it the function or module in question was private. Being >concerned about breaking the functionality for users on non-public functions >seems to entirely defeat the purpose of them. I also dislike the idea of adding the underscores or dealing with it on a case-by-case basis, due to the inconsistency it would provide across stdlib. In some cases the inconsistency might be necessary, but I'd rather avoid it if possible. Also, is the rule "unless explicitly documented public, all imports are private even if not prefixed with an underscore" officially stated anywhere, or is it mostly implied? Personally, I think that it should be explicitly stated in a public manner if it's the methodology being followed. A solid alternative proposal would also be Barry's public decorator proposal: https://public.readthedocs.io/en/latest/. I remember him saying that it was largely rejected by the community when it was proposed, but I'm not certain as to why. It would be far easier to implement something like this than it would be to rename all of the non-public functions. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/OA7KTZFYJKKNGLX6GRGNMUGBZ34MDMWC/
[Python-Dev] Re: Python 3.7.4, Visual Studio versions for building modules from source
On 22.07.2019 18:25, Kacvinsky, Tom wrote: HI, Not sure if this is the right place to ask, but I am trying to build pywin32-224 from source for Python 3.7.4. I think this might be the right list as this seems to be a generic problem I am having, but I want to focus on one particular module. First, I know I could get this via 'pip install', but I want to build from source to see what it takes in terms of the Windows SDK and Visual Studio versions for some other work I am doing. I am using Python 3.7.4, and I have Visual Studio 2017 15.9 (released July of this year). I see this when running 'python setup.y build': error: Microsoft Visual C++ 14.1 is required. Get it with "Microsoft Visual C++ Build Tools": https://visualstudio.microsoft.com/downloads/ I have tried various compilers from that link (VS 2015, VS 2017, and even VS 2019), but no joy. I also have the Windows SDK 8.1 and 10 installed (pywin32 wants the 8.1 SDK) Does anyone have any ideas as to what I am doing wrong, or if there is some weird underlying issue with setuptools and/or distutils? Distutils supports the same compiler setup that is used to build Python itself. As such, it can be seen in PCBuild/readme.txt in the source code (https://github.com/python/cpython/blob/3.7/PCbuild/readme.txt). If the error says that "Microsoft Visual C++ 14.1 is required", be sure to select "v141 tools" in VS installer (readme.txt doesn't say this explicitly but it's a mandatory component when selecting VC++ support). Setuptools supports more compiler setups. They don't see to be listed in the docs but are listed in https://github.com/pypa/setuptools/blob/master/setuptools/msvc.py . --- Last time I checked, the information about supported compiler setups was gathered at https://wiki.python.org/moin/WindowsCompilers. I see that it doesn't have an entry for MSVC 14.1. Documentation on distutils.msvccompiler (https://docs.python.org/3/distutils/apiref.html?highlight=msvccompiler#module-distutils.msvccompiler) also mentions versions but it's severely outdated. Should it refer to readme.txt? -- Regards, Ivan ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/SJPMTBXZWVKPZ72C5T52DRBG6KZWE77J/
[Python-Dev] Re: Replacing 4 underscores with a $ sign, idea for a PEP
I have changed my mind. I will not be taking part in these mailing lists any further for the time being. My thinking about the issue I have raised has evolved and I have more developed ideas to offer, but for the case to be made properly with any chance of success, the first thing that should happen is for this present mode of communication to be upgraded with something more modern and useable. An interface where posting does not have a latency of several hours, where theads may be managed and moved between lists if needed, or deleted if needed, where code snippets may be represented properly. If the Steering Council is genuine in their call for greater inclusiveness, and in particular in better serving the needs of the "novice, non-technical" users, they need to ensure the communication is unhindered. Compared to other possible solutions that exist nowadays, these mailing lists are stone-age. I'll keep an eye on developments and will return with a proposal for an easy-to-use Tool su perset of the present object/class/instance paradigm, targeting the aforementioned segment of users. For now, I wish you all the very best in your work taking Python forward. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/JWV7DBAXBLVNNSWXY5ITWG73WXWGKZN4/
