[Python-Dev] Change SystemError to NOT inherit from Exception
A SystemError is typically raised from C to indicate serious bugs in the application which shouldn't normally be caught and handled. It's used for example for NULL arguments where a Python object is expected. So in some sense, SystemError is the Python equivalent of a segmentation fault. Since these exceptions should typically not be handled in a try/except Exeption block, I suggest to make SystemError inherit directly from BaseException instead of Exception. ___ 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/XA2A33CKERYELYPJS6GKVHCQAXOQKG5M/
[Python-Dev] Re: Change SystemError to NOT inherit from Exception
On 01.07.2019 12:25, Jeroen Demeyer wrote: A SystemError is typically raised from C to indicate serious bugs in the application which shouldn't normally be caught and handled. It's used for example for NULL arguments where a Python object is expected. So in some sense, SystemError is the Python equivalent of a segmentation fault. Since these exceptions should typically not be handled in a try/except Exeption block, I suggest to make SystemError inherit directly from BaseException instead of Exception. https://docs.python.org/3/library/exceptions.html#SystemError: Raised when the interpreter finds an internal error, but the situation does not look so serious to cause it to abandon all hope. <...> You should report this to the author or maintainer of your Python interpreter. For cases where the interpreter deems it too dangerous to continue, there's Py_FatalError(). And if it's safe to continue, the exception can be handled -- and since no-one specifically expecs SystemError, will be either logged, or ignored if the author explicitly doesn't mind if the particular code fails -- whether for this reason or any other. -- 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/5AFZBPYFCUB6JQV4G2OKE36WJVPJ55A3/
[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section
On Sat, Jun 29, 2019 at 10:26:04AM -0500, Skip Montanaro wrote: > > You have missed at least one: the minimum technology requirement for > > using Github is a lot more stringent than for Roundup. Github's minimum > > system requirements are higher, and it doesn't degrade as well, so > > moving to Github will make it much harder for those who are using older > > technology. If not exclude them altogether. > > Is that Git or GitHub? If the latter, more JavaScript bits or something else? I'm referring to Github. I expect it is probably Javascript. Clicking hyperlinks is fine, but things like buttons with dropdown menus, the hamburger icon, the Clone/Download button etc do nothing when I click on them. For what it's worth, I'm not using an ad blocker but I am using a moderately old Firefox. -- 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/U5GPRST2G5JOPFFFRKP3RHBFOLV4CGDQ/
[Python-Dev] Re: strip behavior provides inconsistent results with certain strings
This was quite extensively discussed on python-ideas recently: https://mail.python.org/archives/list/[email protected]/thread/RJARZSUKCXRJIP42Z2YBBAEN5XA7KEC3/#WIRID57ESUFUAQQQ6ZUY2RK5PKQQYSJ3 (I'm finding it hard to find a good thread view in the new interface -- but that will get you started) My memory of that thread is that there was a lot of bike shedding, and quite a lot of resistance to adding a couple new methods, which I personally never understood (Not why we don't want to add methods willy-nilly, but why there was this much resistance to what seems like an low-disruption, low maintenance, and helpful addition) I think it just kind of petered out, rather than being rejected, so if someone wants to take up the mantle, that would be great -- and some support from a core dev or two would probably help. -CHB On Fri, Jun 28, 2019 at 10:44 AM Brett Cannon wrote: > Glenn Linderman wrote: > > On 6/27/2019 3:09 PM, Brett Cannon wrote: > > > My guess is that without Guido to just ask this will > > > have to go to a PEP as it changes a built-in. > > > How does adding two new methods change a built-in? > > > Now if an extra parameter were added to modify lstrip, rstrip, and > strip > > to make them do something different, yes. > > But adding new methods doesn't change anything, unless someone is > > checking for their existence. > > Sure, but the built-ins are so widely used that we don't want to blindly > add every method idea that someone comes up with either. We all very much > share ownership of the built-ins, so we should all agree to changes to > them, and getting agreement means either clear consensus and/or a PEP. > > -Brett > > > My preferred color is pstrip and sstrip (prefix and suffix strip) since > > lstrip and rstrip mean left and right. > > And maybe there should be a psstrip, that takes two parameters, the > > prefix and the suffix to strip. > > Such functions would certainly reduce code in a lot of places where I do > > if string.startswith('foo'): > > string = string[ 3: ]; > > as well as making it more robust, because the string and its length have > > to stay synchronized when changes are made. > ___ > 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/SB6JECL6BUPF4Q37Q5SAGMDOQ2DI2GP5/ > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ 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/MCV2ZKH6BUZ25XQSR4TJHUC5TLOOUCP4/
[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section
On Tue, Jul 2, 2019 at 2:01 AM Steven D'Aprano wrote: > > On Sat, Jun 29, 2019 at 10:26:04AM -0500, Skip Montanaro wrote: > > > You have missed at least one: the minimum technology requirement for > > > using Github is a lot more stringent than for Roundup. Github's minimum > > > system requirements are higher, and it doesn't degrade as well, so > > > moving to Github will make it much harder for those who are using older > > > technology. If not exclude them altogether. > > > > Is that Git or GitHub? If the latter, more JavaScript bits or something > > else? > > I'm referring to Github. I expect it is probably Javascript. Clicking > hyperlinks is fine, but things like buttons with dropdown menus, the > hamburger icon, the Clone/Download button etc do nothing when I click on > them. > > For what it's worth, I'm not using an ad blocker but I am using a > moderately old Firefox. > I'd be interested to know whether that's actually an issue with system requirements (insufficient hardware) or with the age of the browser (lacking some feature). Particular browser versions aren't supported forever. ChrisA ___ 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/GDCDNNTAS3V6W5R7XXECDEJLTI3QKSNE/
[Python-Dev] Re: Building Standalone Python Applications with PyOxidizer
Congrats on this new tool -- I'll be checking it out. With a quick glance at the docs, I see this: """ PyOxidizer loads everything from memory and there is no explicit I/O being performed. When you import a Python module, the bytecode for that module is being loaded from a memory address in the executable using zero-copy. This makes PyOxidizer executables faster to start and import - faster than a python executable itself! """ This made me think of a recent thread either here or on python-ideas about optimizing the cPython start up time. In particular the idea of bundling the core parts of the stdlib pre-loaded somehow. Multiple options were discussed, but as far as I know no one actually prototyped any of them. But it looks like you've done that. My question is this: Can you use PyOxidizer partway -- that is, bundle up some modules, while keeping the regular module loading system for everything else. If so, then one could build an executable with all the modules that always get loaded. It's quite a list judging from: $ python -c "import sys; print(len(sys.modules))" 55 How much faster is the start up time when you make an exe that does, well, nothing. Also -- I have some vague memory of there being a mailing list for the various "bundlers": py2exe, py2app, PyInstaller, etc... it would be good to engage that community, it really is a bit different than the usual "packaging" community, which is primarily focused on python packages themselves rather than applications. -CHB On Mon, Jun 24, 2019 at 11:06 AM Gregory Szorc wrote: > Hey Python developers, > > I just published the initial release of PyOxidizer - a utility for > producing self-contained, potentially single file executable Python > applications. You can read more about it at > https://gregoryszorc.com/blog/2019/06/24/building-standalone-python-applications-with-pyoxidizer/ > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ 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/QU6D62Q2XMYENKBLMBB6SNSSBIZWSUZV/
[Python-Dev] Annoying user on GitHub
There's a user on GitHub ('experimentalles') who has created random PRs on
several projects (e.g. https://github.com/python/peps/pull/1116). Can we
ban them? The PRs look the work of a vandal or a bot, not of a clueless
human.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*
[Python-Dev] Re: Annoying user on GitHub
I've reported the user to GitHub. Ticket ID: 297185
On Mon, Jul 1, 2019, 5:40 PM Guido van Rossum wrote:
> There's a user on GitHub ('experimentalles') who has created random PRs on
> several projects (e.g. https://github.com/python/peps/pull/1116). Can we
> ban them? The PRs look the work of a vandal or a bot, not of a clueless
> human.
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him/his **(why is my pronoun here?)*
>
[Python-Dev] Re: strip behavior provides inconsistent results with certain strings
On 7/1/2019 1:57 PM, Chris Barker via Python-Dev wrote: This was quite extensively discussed on python-ideas recently: https://mail.python.org/archives/list/[email protected]/thread/RJARZSUKCXRJIP42Z2YBBAEN5XA7KEC3/#WIRID57ESUFUAQQQ6ZUY2RK5PKQQYSJ3 The claim of 'inconsistent results' is based on not reading the doc. (I'm finding it hard to find a good thread view in the new interface -- but that will get you started) My memory of that thread is that there was a lot of bike shedding, and quite a lot of resistance to adding a couple new methods, which I personally never understood (Not why we don't want to add methods willy-nilly, but why there was this much resistance to what seems like an low-disruption, low maintenance, and helpful addition) I did not read much of the thread, but the proposal is to wrap a near-trivial expression (2 operations) or replace a current method call with a method call than is more or less the same len as what it replaces. >>> 'prefix_more_suffix'[len('prefix'):] # if know s begins with p '_more_suffix' >>> 'prefix_more_suffix'.replace('prefix', '') '_more_suffix' >>> 'prefix_more_suffix'.strip_pre('prefix') # proposed A method could raise instead of returning the string as-is if the prefix is not really a prefix. How often is this needed? The most common end deletions are whitespace, which the current .strip handles correctly. -- Terry Jan Reedy ___ 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/XG7GKASUSTVJPNOVMUNNDBUDEJFLYBT3/
[Python-Dev] Re: strip behavior provides inconsistent results with certain strings
On 7/1/2019 8:28 PM, Terry Reedy wrote: On 7/1/2019 1:57 PM, Chris Barker via Python-Dev wrote: This was quite extensively discussed on python-ideas recently: https://mail.python.org/archives/list/[email protected]/thread/RJARZSUKCXRJIP42Z2YBBAEN5XA7KEC3/#WIRID57ESUFUAQQQ6ZUY2RK5PKQQYSJ3 The claim of 'inconsistent results' is based on not reading the doc. (I'm finding it hard to find a good thread view in the new interface -- but that will get you started) My memory of that thread is that there was a lot of bike shedding, and quite a lot of resistance to adding a couple new methods, which I personally never understood (Not why we don't want to add methods willy-nilly, but why there was this much resistance to what seems like an low-disruption, low maintenance, and helpful addition) I did not read much of the thread, but the proposal is to wrap a near-trivial expression (2 operations) or replace a current method call with a method call than is more or less the same len as what it replaces. >>> 'prefix_more_suffix'[len('prefix'):] # if know s begins with p '_more_suffix' >>> 'prefix_more_suffix'.replace('prefix', '') '_more_suffix' >>> 'prefix_more_suffix'.strip_pre('prefix') # proposed Your example isn't equivalent: .replace would replace multiple instances of prefix, not necessarily at the beginning. The .strip_pre (however spelled) would strip one instance, only if it is at the beginning. The more I thought about this, the more I think a more functional goal is a variation of replace that works only on one end or the other, rather than a variation of strip. I outlined that in a different branch in this thread. The other documentation issue I noticed is that the 2nd and 3rd parameters to startswith and endswith are not fully documented. Typically startswith and endswitch are in the logic prior to the strip/replace operation, and typically only use the first parameter, but looking at their documentation as part of this discussion, I found it lacking. A method could raise instead of returning the string as-is if the prefix is not really a prefix. How often is this needed? The most common end deletions are whitespace, which the current .strip handles correctly. raising wouldn't be helpful in most of the situations where I use this logic... it would require a more complex flow control than the if startswith path in the current situation. Yes, I use strip more frequently, but if startswith: chop_prefix operation (and the other end too) happens an awful lot. ___ 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/BKRBB3HESKT7N7QL66R7UVUYXOBUAQQO/
[Python-Dev] 3.7.3 Compile error on CentOS 7 (but 3.6.8 Compiles OK)
I am trying to compile Python 3 on Centos7 and I am getting "ModuleNotFoundError: No module named '_ctypes'" Context: Centos7 uses Python 2.7.5 for its routines, so it is need to leave original Python 2.7.5 untouched. Python 3 (in case 3.7.3) needs to be compiled for alternate install. I am downloading source from python.org and using verbatin instructions from https://danieleriksson.net/2017/02/08/how-to-install-latest-python-on-centos/. I just changed version to 3.7.3. The compilation of 3.7.3, 3.7.2, 3.7.1 fails with following msgs: # make && make altinstall . . File "/root/Python-3.7.3/Lib/ensurepip/__init__.py", line 27, in _run_pip import pip._internal File "/tmp/tmp8h0mvcgm/pip-19.0.3-py2.py3-none-any.whl/pip/_internal/__init__.py", line 40, in File "/tmp/tmp8h0mvcgm/pip-19.0.3-py2.py3-none-any.whl/pip/_internal/cli/autocompletion.py", line 8, in File "/tmp/tmp8h0mvcgm/pip-19.0.3-py2.py3-none-any.whl/pip/_internal/cli/main_parser.py", line 12, in File "/tmp/tmp8h0mvcgm/pip-19.0.3-py2.py3-none-any.whl/pip/_internal/commands/__init__.py", line 6, in File "/tmp/tmp8h0mvcgm/pip-19.0.3-py2.py3-none-any.whl/pip/_internal/commands/completion.py", line 6, in File "/tmp/tmp8h0mvcgm/pip-19.0.3-py2.py3-none-any.whl/pip/_internal/cli/base_command.py", line 20, in File "/tmp/tmp8h0mvcgm/pip-19.0.3-py2.py3-none-any.whl/pip/_internal/download.py", line 37, in File "/tmp/tmp8h0mvcgm/pip-19.0.3-py2.py3-none-any.whl/pip/_internal/utils/glibc.py", line 3, in File "/root/Python-3.7.3/Lib/ctypes/__init__.py", line 7, in from _ctypes import Union, Structure, Array ModuleNotFoundError: No module named '_ctypes' make: *** [altinstall] Error 1 = But Python 3.6.8 compiles OK: changing mode of /usr/local/bin/idle3.6 to 755 changing mode of /usr/local/bin/2to3-3.6 to 755 changing mode of /usr/local/bin/pyvenv-3.6 to 755 rm /usr/local/lib/python3.6/lib-dynload/_sysconfigdata_m_linux_x86_64-linux-gnu.py rm -r /usr/local/lib/python3.6/lib-dynload/__pycache__ /bin/install -c -m 644 ./Misc/python.man \ /usr/local/share/man/man1/python3.6.1 if test "xupgrade" != "xno" ; then \ case upgrade in \ upgrade) ensurepip="--altinstall --upgrade" ;; \ install|*) ensurepip="--altinstall" ;; \ esac; \ LD_LIBRARY_PATH=/root/Python-3.6.8 ./python -E -m ensurepip \ $ensurepip --root=/ ; \ fi Looking in links: /tmp/tmpwmo1o05a Collecting setuptools Collecting pip Installing collected packages: setuptools, pip Successfully installed pip-18.1 setuptools-40.6.2 Thanks for your attention. Carlos ___ 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/MTIRNYFAZTQQPHKAQXXREP33NYV2TW2J/
[Python-Dev] Re: strip behavior provides inconsistent results with certain strings
On Tue, Jul 2, 2019 at 2:28 PM Glenn Linderman wrote: > >> A method could raise instead of returning the string as-is if the prefix is >> not really a prefix. How often is this needed? The most common end >> deletions are whitespace, which the current .strip handles correctly. > > raising wouldn't be helpful in most of the situations where I use this > logic... it would require a more complex flow control than the if startswith > path in the current situation. > > Yes, I use strip more frequently, but if startswith: chop_prefix operation > (and the other end too) happens an awful lot. If the method accepts a tuple of prefixes and will remove the first one found (or the longest, or whatever) and raises if none found, you could get the "chop only if present" behaviour by including an empty string as one of the possible prefixes. ChrisA ___ 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/EZGHKWSW22X6A3ULBAEE77VDPV2D65RP/
[Python-Dev] Re: PyAPI_FUNC() is needed to private APIs?
On Sun, Jun 30, 2019 at 12:26 AM Nick Coghlan wrote: > > > Hence Jeroen's point: if something is useful enough for Cython to want to use > it, it makes to provide a public API for it that hides any internal > implementation details that may not remain stable across releases. > I wanted to discuss about only when PyAPI_FUNC() is needed, not about which function should be public. But FYI, we have moved _PyObject_GetMethod to private to cpython API already. > We don't expect most Cython code to be regenerated for different versions - > we only expect it to be recompiled, as with any other extension. > We don't make some unstable API public to avoid breaking packages. But it seems Cython choose performance over stable source code. It seems "regenerate source code when it broken" is Cython policy. It is out of our control. For example, FastCall APIs were not public because we don't think it's not stable yet and it can be changed in future versions. But Cython used it. Luckily, it isn't broken so much. But it is just lucky. I hope Cython provides option to produce more stable source code for projects distributing generated C source code instead of a binary wheel or Cython source code. Regards, -- Inada Naoki ___ 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/FJ5TDFJLWZ4SRB7IYFUBKTYBI525NUIK/
