[Python-Dev] Buildslave kloth-win64 maintenance
All, Just letting python-dev know that my buildslave will be down for a peroid of time due to a failed PSU. Currently awaiting RMA confirmation and I will post an update when the machine will be able to be back online. Sorry for the inconvenience. The builders hosted are the AMD64 Windows 7 ones. -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.4): - Issue #22966: Fix __pycache__ pyc file name clobber when pyc_compile is
On Mon, Dec 1, 2014 at 4:17 PM, barry.warsaw wrote:
> summary:
> - Issue #22966: Fix __pycache__ pyc file name clobber when pyc_compile is
> asked to compile a source file containing multiple dots in the source file
> name.
>
> diff --git a/Lib/test/test_py_compile.py b/Lib/test/test_py_compile.py
> --- a/Lib/test/test_py_compile.py
> +++ b/Lib/test/test_py_compile.py
> @@ -99,5 +99,21 @@
> self.assertFalse(os.path.exists(
> importlib.util.cache_from_source(bad_coding)))
>
> +def test_double_dot_no_clobber(self):
> +# http://bugs.python.org/issue22966
> +# py_compile foo.bar.py -> __pycache__/foo.cpython-34.pyc
> +weird_path = os.path.join(self.directory, 'foo.bar.py')
> +cache_path = importlib.util.cache_from_source(weird_path)
> +pyc_path = weird_path + 'c'
> +self.assertEqual(
> +'/'.join(cache_path.split('/')[-2:]),
> +'__pycache__/foo.bar.cpython-34.pyc')
> +with open(weird_path, 'w') as file:
> +file.write('x = 123\n')
> +py_compile.compile(weird_path)
> +self.assertTrue(os.path.exists(cache_path))
> +self.assertFalse(os.path.exists(pyc_path))
> +
> +
This test is failing on the Windows buildbots due to the hard-coded
path separator. Using `os.pathsep` should work assuming that
importlib returns normalized paths.
--
Jeremy Kloth
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The history of PyXML
On Mon, May 28, 2018 at 2:11 PM, Jeremy Kloth wrote: > Here you go! > > https://github.com/jkloth/pyxml I did forget to mention that I was one of the prior maintainers on the PyXML project as well. -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The history of PyXML
On Thu, May 17, 2018 at 6:18 AM, Serhiy Storchaka wrote: > Does anyone has the full copy of the PyXML repository, with the complete > history? > > This library was included in Python 2.1 as the xml package and is not > maintained as a separate project since 2004. It's home on SourceForge was > removed. I have found sources of the last PyXML version (0.8.4), but without > history. > > I'm trying to figure out some intentions and fix possible bugs in the xml > package. The history of all commits could help. Here you go! https://github.com/jkloth/pyxml -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The history of PyXML
On Mon, May 28, 2018 at 9:53 PM, Serhiy Storchaka wrote: > 28.05.18 23:11, Jeremy Kloth пише: >> >> On Thu, May 17, 2018 at 6:18 AM, Serhiy Storchaka >> wrote: >>> >>> Does anyone has the full copy of the PyXML repository, with the complete >>> history? >>> >> >> Here you go! >> >> https://github.com/jkloth/pyxml > > > Great! Thank you, this is what I needed! I had also contacted SourceForge prior to me uploading a Github repo. They have just restored the project files for PyXML as well (CVS, downloads, ...). -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Close #20053: ignore default pip config settings
On Tue, Feb 4, 2014 at 6:03 AM, nick.coghlan wrote: > http://hg.python.org/cpython/rev/1b8ba1346e67 > changeset: 88955:1b8ba1346e67 > user:Nick Coghlan > date:Tue Feb 04 23:02:36 2014 +1000 > summary: > Close #20053: ignore default pip config settings > > ensurepip now sets PIP_CONFIG_FILE to os.devnull before > import pip from the wheel file. This also ensures venv > ignores the default settings when bootstrapping pip. > > files: > Lib/ensurepip/__init__.py | 9 -- > Lib/test/test_ensurepip.py | 16 +++ > Lib/test/test_venv.py | 37 +++-- > Misc/NEWS | 3 ++ > 4 files changed, 53 insertions(+), 12 deletions(-) This changeset caused the Windows buildbots to go red. Excerpt from one of the logs: == FAIL: test_with_pip (test.test_venv.EnsurePipTest) -- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_venv.py", line 349, in test_with_pip self.assertEqual(err, "") AssertionError: 'C:\\Users\\Buildbot\\AppData\\Local\\Temp[57 chars]\r\n' != '' - C:\Users\Buildbot\AppData\Local\Temp\tmpkwelerus\Scripts\python_d.exe: No module named pip -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: Requesting pronouncement on PEP 463: Exception-catching expressions
[resending to list] -- Forwarded message -- From: Jeremy Kloth Date: Wed, Mar 12, 2014 at 10:27 AM Subject: Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions To: Chris Angelico On Wed, Mar 12, 2014 at 10:05 AM, Chris Angelico wrote: > Tooling issues should already have been solved for lambda, but if you > don't like the colon, go with one of the other options - Brett > expressed support for 'then', which makes very good sense (it does > require creating a new keyword, but it's a fairly safe one). Just to note, if a token is desired, it could be treated as a pseudo-keyword much like 'as' was prior to 2.6 (or 2.5 with future 'with_statement'). That is, it is only treated as a keyword when parsing the expression defining its use. With that, the list of available "keywords" becomes much broader. -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tests failing on Windows with TESTFN
On Sat, Jul 28, 2018 at 8:41 AM Tim Golden wrote: > 1) Why are these errors occurring? ie are we dodging a root cause issue The root cause is how Windows handles file deletions. When a file is removed, it is not immediately removed from the directory, instead, it is simply marked for deletion. Only once all open handles to the file are closed, is it removed from the directory. The most common cause of additional open handles to a file is a antivirus scanner. > 2) Isn't this what test.support.unlink is there to solve? Yes. If test.support.unlink doesn't succeed in removing the file, a RuntimeWarning will be emitted. > For (1) I'm putting together a test run using code which I originally > wrote for https://bugs.python.org/issue7443 to force the issues out into > the open. These intermittent errors are tough as it is really just a matter of timing. The faster the disk and the more loaded the CPU, the more often these can occur, however. > For (2), yes: test.support.unlink is supposed to solve that. But it's > either not doing enough retries etc. or it's missing a trick. If you are not seeing the RuntimeWarnings, then something else is amiss. -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tests failing on Windows with TESTFN
On Sat, Jul 28, 2018 at 11:20 AM Tim Golden wrote: > Although things have moved on since that discussion and > test.support.unlink has grown some extra legs, all it's done really is > to push the bump along the carpet for a bit. I've got a newly-installed > Win10 machine with the typical MS Antivirus & TortoiseGitCache vying for > locks with every other process. I've just done a full test run: > > python -mtest -j0 -v > test.log I, for one, would like to see that log. The issues you are have are fairly unique. Just check out the buildbot status page. I know that some of the workers are somewhat limited, but my worker (https://buildbot.python.org/all/#/workers/12) is running on dedicated hardware. Before https://bugs.python.org/issue15496 was applied, the errors you describe were indeed happening, but no longer. > Here's the thing. The TESTFN approach creates a directory per process > test_python_ and some variant of @test__tmp inside that > directory. But the same filename in the same directory is used for every > test in that process. Now, leaving aside the particular mechanism by > which Windows processes might be holding locks which prevent removal or > re-addition, that already seems like an odd choice. Well, since every test (well, test file) is run in its own process, a directory per process doesn't seem that odd. You seem to be focusing on 2 tests in particular, both of which have not been converted to use test.support.unlink for removing. The "trick" with test.support.unlink now is that it waits until the file has truly removed from the directory before continuing. Using this, in turn, would mean that following create *should* succeed without error. If test.support.unlink returns without warning, the removed file is really gone. > I think that was my starting point: rather than develop increasingly > involved and still somewhat brittle mechanisms, why not do what you'd > naturally do with a new test and use tempfile? I was expecting someone > to come forward to highlight some particular reason why the TESTFN > approach is superior, but apart from a reference to the possibly cost of > creating a new temporary file per test, no-one really has. *PLEASE*, don't use tempfile to create files/directories in tests. It is unfriendly to (Windows) buildbots. The current approach of directory-per-process ensures no test turds are left behind, whereas the tempfile solution slowly fills up my buildbot. Windows doesn't natively clean out the temp directory. Additionally, I'm working on a solution to allow the test machinery to use a given directory for test outputs to allow for a RAM-backed filesystem for temporary files. With this, I've had the full test suite (with -uall including bigmem) take ~5min. Having some tests use the Windows default test directory would break this. It is simply not feasible to have the entire Windows TEMP in RAM, but just Python's test suite usage is small enough (<6Gb). Another point, some tests require that the temporary filename resides on the same drive as the source directory (discovered in developing the above). This means that, Windows development would be restricted to the same drive as the user directory, if the per-directory approach isn't used. -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tests failing on Windows with TESTFN
On Sat, Jul 28, 2018 at 6:43 PM Brett Cannon wrote: > If Windows doesn't clean up its temp directory on a regular basis then that > doesn't suggest to me not to use tempfile, but instead that the use of > tempfile still needs to clean up after itself. And if there is a lacking > feature in tempfile then we should add it instead of a avoiding the module. Mind you, this is mentioned in the confines of the test harness where just about anything can happen (and usually does!). Something that cannot be coded against using just tempfile is cleanup on process abort. The per-process-directory approach handles this case. I would think it is desired to have no leftovers after running the test harness (especially in regards to the buildbots). Now, I'm not sure the exact cause of all of the leftovers in the TEMP directory, but it is definitely something that is currently happening (and shouldn't be). It is not exactly the easiest of tasks to track the file usage of every test in the test suite. It is certainly easier to replace usages of os.unlink with test.support.unlink within the test suite. -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tests failing on Windows with TESTFN
On Sat, Jul 28, 2018 at 7:15 PM Chris Jerdonek wrote: > Regardless of whether the tempfile or TESTFN approach is used, I think it > would be best for a few reasons if the choice is abstracted behind a uniquely > named test function (e.g. make_test_file if not already used). +1, although my particular choice of color would be to add a pair of functions, mkstemp and mkdtemp, to match the style of test.support-wrapped library functions for use in the test harness. -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tests failing on Windows with TESTFN
On Sun, Jul 29, 2018 at 3:13 AM Tim Golden wrote:
> For an example:
>
> http://tjg.org.uk/test.log
Thank you! After inspecting all the errors, it does seem that they
are ALL caused by "bare" os.unlink/rmdir calls. So it seems that a
massive undertaking of ferreting out these locations and replacing
them with their support equivalents would be needed to have a passing
test suite for you.
Unfortunately, test_mailbox is failing due to the same fate, but
within the stdlib itself. The fix for that will probably need to be a
rename/delete dance.
diff --git a/Lib/mailbox.py b/Lib/mailbox.py
index 056251d..23662f2 100644
--- a/Lib/mailbox.py
+++ b/Lib/mailbox.py
@@ -701,8 +701,10 @@ class _singlefileMailbox(Mailbox):
try:
os.rename(new_file.name, self._path)
except FileExistsError:
-os.remove(self._path)
+temp_name = _create_temporary_name(self._path)
+os.rename(self._path, temp_name)
os.rename(new_file.name, self._path)
+os.remove(temp_name)
self._file = open(self._path, 'rb+')
self._toc = new_toc
self._pending = False
@@ -2112,11 +2114,14 @@ def _create_carefully(path):
finally:
os.close(fd)
+def _create_temporary_name(path):
+"""Create a temp filename based on path."""
+return '%s.%s.%s.%s' % (path, int(time.time()), socket.gethostname(),
+os.getpid())
+
def _create_temporary(path):
"""Create a temp file based on path and open for reading and writing."""
-return _create_carefully('%s.%s.%s.%s' % (path, int(time.time()),
- socket.gethostname(),
- os.getpid()))
+return _create_carefully(_create_temporary_name(path))
def _sync_flush(f):
"""Ensure changes to file f are physically on disk."""
--
Jeremy Kloth
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tests failing on Windows with TESTFN
On Sun, Jul 29, 2018 at 9:34 AM Tim Golden wrote:
> For test_mailbox I've experimentally implemented a hybrid tempfile /
> local directory solution. ie I've created a new file on each run, but
> only within the python_ folder which already exists. As long as the
> directory cleans up there should be no leftovers. That's certainly
> helped although my re-run harness has provoked at least one error.
As Eryk noted, the fix for mailbox.py (yes, the stdlib needs fixing in
this case) is quite simple:
diff --git a/Lib/mailbox.py b/Lib/mailbox.py
index 056251d..eb85df1 100644
--- a/Lib/mailbox.py
+++ b/Lib/mailbox.py
@@ -701,8 +701,7 @@ class _singlefileMailbox(Mailbox):
try:
os.rename(new_file.name, self._path)
except FileExistsError:
-os.remove(self._path)
-os.rename(new_file.name, self._path)
+os.replace(new_file.name, self._path)
self._file = open(self._path, 'rb+')
self._toc = new_toc
self._pending = False
--
Jeremy Kloth
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] bpo-34171: Prevent creating Lib/trace.cover when run the trace module. (GH-8841)
On Sat, Aug 25, 2018 at 1:28 AM Serhiy Storchaka wrote: > > https://github.com/python/cpython/commit/c406d5cd74002964a64c3eb7d9e2445a7fd3a03f > commit: c406d5cd74002964a64c3eb7d9e2445a7fd3a03f > branch: master > author: Serhiy Storchaka > committer: GitHub > date: 2018-08-25T10:27:55+03:00 > summary: > > bpo-34171: Prevent creating Lib/trace.cover when run the trace module. > (GH-8841) > > files: > A Misc/NEWS.d/next/Library/2018-08-21-00-29-01.bpo-34171.6LkWav.rst > M Lib/test/test_trace.py > M Lib/trace.py This change seems to have caused most buildbots to go red. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] bpo-34171: Prevent creating Lib/trace.cover when run the trace module. (GH-8841)
On Mon, Aug 27, 2018 at 7:26 AM Victor Stinner wrote: > > Jemery: would you mind to revert this commit since nobody fixed the > buildbot since 2 days? > https://pythondev.readthedocs.io/ci.html#revert-on-fail I think you meant Serhiy :) Anyway, a commit has finally landed that addresses the buildbot failures, at least for master. -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I reverted "Add Windows App Store package" change
> On 07Dec2018 0716, Steve Dower wrote: > > It didn't break all Windows buildbots. > > > > That said, it's totally my fault for merging and then not watching. Also > > for not submitting custom builds to all the buildbots (Can we still do > > that? I'm not seeing any UI right now... I did run a number of test > > release builds on the release machine, so I knew that was going to be okay.) As to the breakage on my buildbot (https://buildbot.python.org/all/#/workers/12), it seems to be caused by not having VS2017 (my guess due to missing C++ headers). Unless something has changed recently, the guides still state the building with VS2015 is OK and I would like to keep my buildbot testing at the *minimum* required components for building (hence the VS9.0 builder) to keep us honest with any changes. I have no problem adding VS2017 for newer Python versions, but I think is build scripts always chose the latest version of the build tools thus making testing with older toolsets impossible. -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.3): ctypes: AIX needs an explicit #include to get alloca()
On Mon, Jun 17, 2013 at 2:02 PM, victor.stinner wrote: > diff --git a/Modules/_ctypes/callproc.c b/Modules/_ctypes/callproc.c > --- a/Modules/_ctypes/callproc.c > +++ b/Modules/_ctypes/callproc.c > @@ -70,6 +70,7 @@ > > #include > #include "ctypes.h" > +#include This header is not present on Windows, thus breaking all the Windows buildbots. Perhaps it should be wrapped in an AIX-specific #ifdef? -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #9566: Fix a compiler warning in tupleiter_setstate() on Windows x64
On Mon, Jun 24, 2013 at 3:33 PM, victor.stinner
wrote:
> http://hg.python.org/cpython/rev/6b4d279508a3
> changeset: 84325:6b4d279508a3
> user:Victor Stinner
> date:Mon Jun 24 23:31:48 2013 +0200
> summary:
> Issue #9566: Fix a compiler warning in tupleiter_setstate() on Windows x64
>
> files:
> Objects/tupleobject.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> diff --git a/Objects/tupleobject.c b/Objects/tupleobject.c
> --- a/Objects/tupleobject.c
> +++ b/Objects/tupleobject.c
> @@ -997,7 +997,7 @@
> static PyObject *
> tupleiter_setstate(tupleiterobject *it, PyObject *state)
> {
> -long index = PyLong_AsLong(state);
> +Py_ssize_t index = PyLong_AsLong(state);
Actually, this will still lose data when state > MAX_INT (on Windows).
It should be changed to PyLong_AsSssize_t(state) to ensure consistent
behavior on all platforms.
--
Jeremy Kloth
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #9566: recv(), recvfrom(), send(), sendall() and sendto() methods
On Mon, Jun 24, 2013 at 3:48 PM, victor.stinner wrote: > +#if defined(MS_WIN64) || defined(MS_WINDOWS) This test could be reduced to simply `#ifdef MS_WINDOWS`. See PC\pyconfig.h ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.5): remove extra PyErr_Format arguments (closes #28454)
On Sun, Oct 16, 2016 at 4:42 PM, benjamin.peterson wrote: > --- a/Objects/unicodeobject.c > +++ b/Objects/unicodeobject.c > @@ -3009,7 +3009,7 @@ > "'%.400s' decoder returned '%.400s' instead of 'str'; " > "use codecs.decode() to decode to arbitrary types", > encoding, > - Py_TYPE(unicode)->tp_name, Py_TYPE(unicode)->tp_name); > + Py_TYPE(unicode)->tp_name); > Py_DECREF(unicode); > goto onError; > } Um, isn't that now an error? There are 2 format sequences, but only 1 argument. -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.5): remove extra PyErr_Format arguments (closes #28454)
Oops, you are right. Silly little comma... -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "make touch" replaced with "make regen-all"
On Tue, May 9, 2017 at 5:20 AM, Victor Stinner wrote:
> This change broke the Coverage job on Travis CI, because sysconfig.py
> uses get_config_var('AST_H_DIR') to build sysconfig.get_python_inc():
> http://bugs.python.org/issue30273
>
> sysconfig was modified in 2012. "Include" was replaced with
> get_config_var('AST_H_DIR') by:
> https://hg.python.org/cpython/rev/998c8a8f2aea
> => see http://bugs.python.org/issue15366
>
> To fix the Coverage job, I reverted this change:
> https://github.com/python/cpython/commit/b109a1d3360fc4bb87b9887264e3634632d392ca
>
> I'm unable to reproduce http://bugs.python.org/issue15366 bug: "venv
> assumes header files in sys._home + '/Include' ".
To reproduce, Python need to be compiled {builddir} != {srcdir} as
noted in the README.
I've submitted a PR that fixes this (previous?) regression and still
permits the Makefile changes.
> It seems like venv and virtualend have been updated in the meanwhile
> to add ${venv}/include to the include directories when building an
> extension.
Yes, http://bugs.python.org/issue16116
--
Jeremy Kloth
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Defining tiered platform support
On Fri, Mar 11, 2022 at 6:21 PM Victor Stinner wrote: > But I don't know how to get this info from the Microsoft > documentation. I usually dig into Wikipedia articles to check which > Windows version is still supported or not, but I'm confused between > "mainstream support" and "extended support". As PEP 11 states, it is the extended support time-frame that is of interest. > For example, which Python version still support Windows 7? Wikipedia > says that Windows 7 mainstream support ended in 2015, and extended > support ended in 2020. But Python still has a Windows 7 SP1 buildbot > for Python 3.8: https://buildbot.python.org/all/#/builders/60 Python 3.8.0 was release when Windows 7 SP1 was within the extended support time-frame. Therefore, Win7 is supported (and tested) until 3.8 reaches EOL. > What is the minimum Windows supported by Python 3.10? >From the link listed in PEP 11, Windows 8.1 does not leave extended support until Jan 10, 2023. So it seems that 3.10 and 3.11 will need to support Windows 8.1. -- Jeremy Kloth ___ 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/NFPSZD44DLFJS7CFGT2SVX3CSK7H5VRJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]
h Modules/_sqlite/connection.c Modules/_sqlite/connection.h Modules/_sqlite/cursor.c Modules/_sqlite/module.c Modules/_sqlite/named_row.c Modules/_sqlite/named_row.h Modules/_sre.c Modules/_ssl.c Modules/_ssl_data.h Modules/_stat.c Modules/_struct.c Modules/_testcapimodule.c Modules/_threadmodule.c Modules/_tkinter.c Modules/_tracemalloc.c Modules/_uuidmodule.c Modules/_winapi.c Modules/_xxsubinterpretersmodule.c Modules/_zoneinfo.c Modules/arraymodule.c Modules/audioop.c Modules/cjkcodecs/clinic/multibytecodec.c.h Modules/cjkcodecs/multibytecodec.c Modules/errnomodule.c Modules/fcntlmodule.c Modules/getpath.c Modules/grapheme_cluster_break_automaton.h Modules/main.c Modules/makesetup Modules/mmapmodule.c Modules/nismodule.c Modules/ossaudiodev.c Modules/overlapped.c Modules/posixmodule.c Modules/pyexpat.c Modules/selectmodule.c Modules/signalmodule.c Modules/socketmodule.c Modules/socketmodule.h Modules/sre.h Modules/sre_constants.h Modules/sre_lib.h Modules/unicodedata.c Modules/unicodedata_db.h Modules/unicodename_db.h Modules/xxsubtype.c Modules/zlibmodule.c Programs/_testembed.c Tools/c-analyzer/c_parser/_state_machine.py Tools/c-analyzer/c_parser/preprocessor/__init__.py Tools/c-analyzer/cpython/_parser.py Tools/ccbench/ccbench.py Tools/clinic/clinic.py Tools/gdb/libpython.py Tools/i18n/msgfmt.py Tools/scripts/README Tools/scripts/deepfreeze.py Tools/scripts/eptags.py Tools/scripts/generate_global_objects.py Tools/scripts/generate_opcode_h.py Tools/scripts/ptags.py Tools/scripts/win_add2path.py Tools/ssl/multissltests.py Tools/unicode/Makefile Tools/unicode/makeunicodedata.py abc_bench.py aclocal.m4 configure configure.ac m4/ax_pthread.m4 pyconfig.h.in setup.py test.py -- Jeremy Kloth ___ 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/GIJ4SWF6ATKPZ6VOAOPKPKS7SMAONBCU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Migration plan for the distutils removal in Python 3.12
On Tue, May 10, 2022 at 9:34 AM Christian Heimes wrote: > We can easily take care of test_cppext and add the build step to > Makefile. How does test_peg_generator depend on distutils? I don't see > an import of distutils in the directory. You need to look at the files in the Tools directory. That is where c-analyzer and peg_generator live. The peg_generator tests depend on Tools/peg_generator/pegen/build.py which uses distutils to build multiple extensions to test the grammar generator. -- Jeremy Kloth ___ 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/7WMU6N6XGHLSO2FFSTXEFZC6UDPMNOB3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [Python-checkins] bpo-9949: Enable symlink traversal for ntpath.realpath (GH-15287)
On Wed, Aug 21, 2019 at 2:43 PM Steve Dower wrote: > > https://github.com/python/cpython/commit/75e064962ee0e31ec19a8081e9d9cc957baf6415 > commit: 75e064962ee0e31ec19a8081e9d9cc957baf6415 > branch: master > author: Steve Dower > committer: GitHub > date: 2019-08-21T13:43:06-07:00 > summary: > > bpo-9949: Enable symlink traversal for ntpath.realpath (GH-15287) > > files: > A Misc/NEWS.d/next/Windows/2019-08-14-13-40-15.bpo-9949.zW45Ks.rst > M Doc/library/os.path.rst > M Doc/whatsnew/3.8.rst > M Lib/ntpath.py > M Lib/test/test_ntpath.py > M Lib/test/test_os.py > M Lib/test/test_shutil.py > M Lib/unittest/test/test_discovery.py > This change seems to have broken the windows buildbots. -- Jeremy Kloth ___ 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/LUFONBYB3B2A7Q6RR7CCYO7PVMPOHLNE/
[Python-Dev] Python-checkins mailing list broken?
It seems that python-checkins isn't receiving any new commits since the 8th of September. A quick check of the github page shows activity since then, as do the buildbots. Just a heads up. -- Jeremy Kloth ___ 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/NLLZVN7GBRVN3UCK7AORNSUFWQCOJX67/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] [4suite] cDomlette deallocation bug?
I'm CC python-dev as this may be a bug in the gc module. Although this may be
more of a c.l.p. post, I think that this usage shouldn't cause segfaults
regardless.
On Tuesday 22 August 2006 3:06 pm, Robert Fleming wrote:
> [step 1 unnecessary]
> 2. test program (test.c):
> / snip /
> #include
>
> #include
>
> int main(int argc, char* argv[])
> {
> int i;
> for (i = 0; i<10; i++)
> {
> printf("%d\n", i);
>
> Py_Initialize();
> (void)PyRun_SimpleString("import sys\n"
>"sys.path.append('.')\n"
>"import cDomlettec");
Change the string to just "import gc" and the segfault still happens.
> Py_Finalize();
> }
>
> return EXIT_SUCCESS;
> }
> /** snip /
>
> 3. compile with:
> gcc -I/usr/include/python2.4 test.c -lpython2.4
>
> 4. run program; output is:
> 0
> 1
> Segmentation fault
>
> Am I doing something wrong? I'm pretty new to embedding Python, but I'm
> hoping to be able to cleanly load and unload 4Suite this way
It just so happens that cDomlettec imports gc internally which, by the change
above shows, causes the segfault. Hopefully someone with more knowledge of
GC internals can comment on this.
--
Jeremy Kloth
http://4suite.org/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Need help with C - problem in sqlite3 module
On Saturday, September 23, 2006 11:31 am, Gerhard Häring wrote: > Looks like I don't know C so well after all ... > > Apparently at least gcc on Linux exports all symbols by default that are > not static. This creates problems with Python extensions that export > symbols that are also used in other contexts. For example some people use > Python and the sqlite3 module under Apache, and the sqlite3 module exports > a symbol cache_init, but cache_init is also used by Apache's mod_cache > module. Thus there are crashes when using the sqlite3 module that only > occur in the mod_python context. > > Can somebody with more knowledge about C tell me how to fix the sqlite3 > module or compiler settings for distutils so that this does not happen? > > Of course this only happens because the sqlite3 module is distributed among > multiple .c files and thus I couldn't make everything "static". GCC's symbol visibility is supposed to address this exact problem. It would be nice if -fvisibility=hidden was used to build Python (and its extensions) by default on supported platforms/compilers. It shouldn't be much of an issue wrt. exported symbols as they already need to be tracked for Windows where symbols are hidden by default (unlike traditional *nix). -- Jeremy Kloth http://4suite.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] multiple interpreters and extension modules
[[ This may be somewhat c.l.p.-ish but I feel that this crossed into CPython development enough to merit posting here ]] I have received a bug report for 4Suite that involves a PyObject_IsInstance check failing for what appears to be the correct class, that is, the class names match. With some investigating, I have found that the true problem is with multiple interpreters. The reason for this is that each sub-interpreter has a "new" copy of any pure Python module. The following issues are also true for modules that have been reloaded, but I think that is common knowledge. I mention it only for completeness. Here is where it crosses into CPython development. Now extension modules do not get reloaded into each sub-interpreter, but a copy of the module's dict from when it was first loaded. This particular extension, when initialized, loads the class in question from the pure Python module and stores in in a global variable for quick access. I know I can change this specific case to reload the class each time and for this exact case, it is most likely what I'll do. However, we have other extensions that make use of this same technique and their performance would suffer greatly by doing the lookup for each use of the class. Also performance isn't the only issue here as we also have C types that inherit from a Python class and those types will obviously fail an isinstance() check in Python code run in different interpreters as the base class is "frozen" at the first import. So I guess the questions are: 1) is subclassing Python classes in C as a static type supported? Even if they would be declared on the heap, they would be bound to the first loaded Python class. 2) would it be worthwhile to have an extension loading function similar to DllMain() for Windows' DLLs which is called multiple times with a flag stating the reason for the call? For reference, see: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dllmain.asp I envision the reasons as: 'module init', 'module fini', 'interpreter init', 'interpreter fini'. I see no current need for special treatment of threads as they share the same interpreter space. As to question 2, I'm in the process of prototyping that approach to see if it is feasible in our code and if so, (and people find it useful) I'll attempt to write a PEP for that feature. My current thoughts on that are instead of the current init entry point in C modules, a new entry point is defined, and if found, used in its place. That way, this proposal would be optional for extension writers and existing modules would continue to work without change. Feedback appreciated. -- Jeremy Kloth http://4suite.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiple interpreters and extension modules
On Friday 22 December 2006 5:02 pm, Josiah Carlson wrote: > Jeremy Kloth <[EMAIL PROTECTED]> wrote: > > [[ This may be somewhat c.l.p.-ish but I feel that this crossed into > > CPython development enough to merit posting here ]] > > > > I have received a bug report for 4Suite that involves a > > PyObject_IsInstance check failing for what appears to be the correct > > class, that is, the class names match. With some investigating, I have > > found that the true problem is with multiple interpreters. The reason > > for this is that each sub-interpreter has a "new" copy of any pure Python > > module. The following issues are also true for modules that have been > > reloaded, but I think that is common knowledge. I mention it only for > > completeness. > > If I remember correctly, Python allows you to use multiple interpreters > in the same process, but it makes no guarantees as to their correctness > when running. > > See this post for further discussion on the issue: > http://mail.python.org/pipermail/python-list/2004-January/244343.html > > You can also search for 'multiple python interpreters single process' in > google without quotes to hear people lament over the (generally broken) > multiple Python interpreter support. The problem here is that it is mod_python using the multiple interpreters. We have no control over that. What I'm proposing is fixing the extension module support for multiple interpreters with the bonus of adding extension module finalization which I've seen brought up here before. Fixing this does require support by the extension module author, but if that author doesn't feel the need to work in mod_python (if, of course, they load module level constants), that is their loss. Is 4Suite that different in its use of hybrid Python and C extensions? There is lots of back and forth between the two layers and performance is critical. I really don't feel like recoding thousands of lines of Python code into C just to get 4Suite to work in mod_python without error. -- Jeremy Kloth http://4suite.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiple interpreters and extension modules
On Friday 22 December 2006 7:54 pm, Bob Ippolito wrote: > It's a whole lot more practical to just stop using mod_python and go > for one of the other ways of exposing Python code to the internet. I > bet you can get the same or better performance out of another solution > anyway, and you'd save deployment headaches. I have no control over end-users choice of Python/webserver integration, I just end up making it possible to run our software in the environment of *their* choice. If it is the opinion that it is mod_python that is broken, I'd gladly point the users to the location stating that fact/belief. It would make my life easier. -- Jeremy Kloth http://4suite.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiple interpreters and extension modules
On Friday 22 December 2006 7:16 pm, Guido van Rossum wrote: > I think you understand exactly what is happening. It is happening for > good reasons. Rather than asking for a change in semantics, I > recommend that you deal with it, either in your Python code, or in > your extension. It's not likely to change. I don't believe I was asking for a change in semantics, rather an additional, optional interface for extension module writers. > > 2) would it be worthwhile to have an extension loading function similar > > to DllMain() for Windows' DLLs which is called multiple times with a flag > > stating the reason for the call? For reference, see: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ > >base/dllmain.asp I envision the reasons as: 'module init', 'module fini', > > 'interpreter init', 'interpreter fini'. I see no current need for special > > treatment of threads as they share the same interpreter space. > > > > As to question 2, I'm in the process of prototyping that approach to see > > if it is feasible in our code and if so, (and people find it useful) I'll > > attempt to write a PEP for that feature. I'll add here that it has been brought up here before that extension module finalization is a feature that would be appreciated. With that, it is not that far to add support for initialization/finalization for each interpreter. That is, of course, using a DllMain-like solution. > > My current thoughts on that are instead of the current init > > entry point in C modules, a new entry point is defined, and if found, > > used in its place. That way, this proposal would be optional for > > extension writers and existing modules would continue to work without > > change. With that approach in mind, I will be making changes so 4Suite will work in a production mod_python deployment (where the aforementioned error occurred). When that works, I'll come back with a proper PEP *and* patches against Python SVN to support its use. I hope no one was thinking I wanted someone else to do the work. -- Jeremy Kloth http://4suite.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
On Monday 12 March 2007 4:50:17 pm Martin v. Löwis wrote: > Does distutils support this kind of setup? Yes, and it has since its introduction. Just use the dotted name for the extension name. > IOW, I would expect that there are sooo many places where extension > modules in packages are not supported that it is just a tiny detail > that they don't work in builtin modules (which, as I said, only have > top-level modules, anyway). 4Suite has many extension modules that are part of packages and never once has there been a problem reported due to extension modules. The thought that extension modules cannot be in a package has never even cross my mind. I would have thought it a bug if they didn't, FWIW. -- Jeremy Kloth http://4suite.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions for Python 3.3
On Tuesday, October 11, 2011 01:59:45 AM Vinay Sajip wrote: > I looked at the dialog resources for wininst-x.y.exe and noticed that there > is a "Find other ..." button which is hidden, and its handler (in > PC\bdist_wininst\install.c) is commented out. However, the code called by > the handler - GetOtherPythonVersion - is still there. Does anyone here > know why the button has been made unavailable? This "feature" has never been active. It has been commented out since before Distutils was imported into Python proper. -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions for Python 3.3
On Thursday, October 13, 2011 01:42:13 PM Paul Moore wrote: > Maybe the wininst and MSI installers should ultimately become simple > UIs around a zipfile and an invocation of the packaging APIs? Not that > I'm offering to do that work, I'm afraid... The bdist_wininst/_msi installers cannot use any of the packaging.* code *runtime* as packaging (or distutils2) isn't necessarily installed on the target machine. I would think that having it as a prerequisite to actually running the installers is a bad thing. Including the required support files within the installers may be doable but could add too much complexity and possibly lead to stale code issues (for the support files). That said, I have been working on a drop-in replacement for the current bdist_wininst executable stub with the following features: - install to 32- or 64-bit Python installations from a single installer; currently one installer for each architechure is required - install to any Python from version 2.4 to the latest; currently one installer is needed for each major version - updated look and feel (Wizard97) with the new (as of Python 2.5!) logo; for some screen shots see: http://www.flickr.com/photos/67460826@N04/sets/72157627653603530/ - unicode metadata support (name, summary, description) - runs on Win95 through Win7 (that is, all support platforms for the supported Python versions for packaging) - per-user installs (as in, setup.py install --user); currently only system-wide or per-user based on permissions and how Python itself was installed Planned Features: - multi-version extension module support; one installer that can install the precompiled extensions to different Python versions - prefix installs (as in, setup.py install --prefix) for virtual environments or other non-standard locations. Current thinking is to *not* track these installations in the Add/Remove programs. -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions for Python 3.3
On Thursday, October 13, 2011 04:02:27 PM Jeremy Kloth wrote: > That said, I have been working on a drop-in replacement for the current > bdist_wininst executable stub with the following features: > - install to 32- or 64-bit Python installations from a single installer; > currently one installer for each architechure is required > - install to any Python from version 2.4 to the latest; > currently one installer is needed for each major version > - updated look and feel (Wizard97) with the new (as of Python 2.5!) logo; > for some screen shots see: > http://www.flickr.com/photos/67460826@N04/sets/72157627653603530/ > - unicode metadata support (name, summary, description) > - runs on Win95 through Win7 (that is, all support platforms for the > supported Python versions for packaging) > - per-user installs (as in, setup.py install --user); > currently only system-wide or per-user based on permissions and how > Python itself was installed I missed a few additional features: - UAC (Vista, Win7) is handled at the install phase depending on the selected Python target (system or user installed Python or user site-packages); currently just at the running of the installer - pre-/post- install and remove script support with the scripts no longer needing to be installed with the distribution - MSVCRT agnostic; built completely with the Windows API meaning only one stub EXE required; currently there is one stub per MSVCRT version -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions for Python 3.3
On Sunday, October 16, 2011 02:24:58 PM Vinay Sajip wrote: > Jeremy Kloth gmail.com> writes: > > That said, I have been working on a drop-in replacement for the current > > > bdist_wininst executable stub with the following features: > [snip] > > > http://www.flickr.com/photos/67460826 N04/sets/72157627653603530/ > > [snip] > > Sounds interesting, but your flickr link did not work for me, even after I > tried replacing "" with "@". Care to post a shortened link? Hmm, clicking the link in the email works here. but just to be safe: http://goo.gl/pC48e Thanks -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #15102: find python.exe in OutDir, not SolutionDir.
> --- a/PCbuild/pyproject.props > +++ b/PCbuild/pyproject.props > @@ -2,7 +2,7 @@ > xmlns="http://schemas.microsoft.com/developer/msbuild/2003";> > > python33$(PyDebugExt) > - $(SolutionDir)python$(PyDebugExt).exe > + $(OutDir)python$(PyDebugExt).exe > $(OutDir)kill_python$(PyDebugExt).exe > ..\.. > $(externalsDir)\sqlite-3.7.12 In order for this change to accurately reflect the OutDir in the x64 builds, all imports of x64.props need to be moved to be before the pyproject.props import statements. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #15478: Fix test_os on Windows (os.chown is missing)
On Tue, Oct 30, 2012 at 6:07 PM, victor.stinner wrote: > http://hg.python.org/cpython/rev/01cc9fb52887 > changeset: 80068:01cc9fb52887 > user:Victor Stinner > date:Wed Oct 31 01:04:10 2012 +0100 > summary: > Issue #15478: Fix test_os on Windows (os.chown is missing) > > files: > Lib/test/test_os.py | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > > diff --git a/Lib/test/test_os.py b/Lib/test/test_os.py > --- a/Lib/test/test_os.py > +++ b/Lib/test/test_os.py > @@ -2069,7 +2069,6 @@ > funcs = [ > (os.chdir,), > (os.chmod, 0o777), > -(os.chown, 0, 0), > (os.lchown, 0, 0), > (os.listdir,), > (os.lstat,), > @@ -2081,6 +2080,8 @@ > (os.truncate, 0), > (os.unlink,), > ] > +if hasattr(os, "chown"): > +funcs.append((os.chown, 0, 0)) > if sys.platform == "win32": > funcs.extend(( > (os._getfullpathname,), Also missing on Windows is os.lchown. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Use OESeeror instead of os.error (#16720)
On Mon, Dec 24, 2012 at 11:00 AM, andrew.svetlov wrote: > http://hg.python.org/cpython/rev/6cfe2982de42 > changeset: 81017:6cfe2982de42 > parent: 81011:a7c9869a5114 > user:Andrew Svetlov > date:Mon Dec 24 19:58:48 2012 +0200 > summary: > Use OESeeror instead of os.error (#16720) > > diff --git a/Lib/os.py b/Lib/os.py > --- a/Lib/os.py > +++ b/Lib/os.py > @@ -275,7 +275,7 @@ > while head and tail: > try: > rmdir(head) > -except error: > +except OSrror: > break > head, tail = path.split(head) > Shouldn't that be OSError? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a quit that actually quits
Ka-Ping Yee wrote: > I'd be happy with having Python exit when the user types just plain > 'exit' without parentheses, but only in that case, not others. > However, i'm starting to think that may be impossible to implement. > I can't think of any way to make 'print exit' not exit, for example. OK, here's one: def quithook(obj, _exit=__builtins__.exit, _displayhook=sys.displayhook): if obj is _exit: raise SystemExit _displayhook(obj) sys.displayhook = quithook It does, however, fall into the whole issue of chaining that Skip brought up earlier. -- Jeremy Kloth Fourthought, Inc. http://fourthought.com/ http://4suite.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
