[Python-Dev] Raise OSError or RuntimeError in the OS module?
Hi, I introduced recently the signal.pthread_sigmask() function (issue #8407). pthread_sigmask() (the C function) returns an error code using errno codes. I choosed to raise a RuntimeError using this error code, but I am not sure that RuntimeError is the best choice. It is more an OS error than a runtime error: should signal.pthread_sigmask() raise an OSError instead? signal.signal() raises a RuntimeError if setting the signal handler failed. signal.siginterrupt() raises also a RuntimeError on error. signal.setitimer() and signal.getitimer() have their own exception class: signal.ItimerError, raised on setimer() and getitimer() error. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.settrace: behavior doesn't match docs
Indeed, the 2.0 code is very different, and got this case right.
I'm a little surprised no one is arguing that changing this code now
could break some applications. Maybe the fact no one noticed the docs
were wrong proves that no one ever tried returning None from a local
trace function.
--Ned.
On 4/30/2011 8:43 PM, Guido van Rossum wrote:
I think you need to go back farther in time. :-) In Python 2.0 the
call_trace function in ceval.c has a completely different signature
(but the docs are the same). I haven't checked all history but
somewhere between 2.0 and 2.3, SET_LINENO-less tracing was added, and
that's where the implementation must have gone wrong. So I think we
should fix the code.
--Guido
On Sat, Apr 30, 2011 at 3:49 PM, Ned Batchelder wrote:
This week I learned something new about trace functions (how to write a C
trace function that survives a sys.settrace(sys.gettrace()) round-trip), and
while writing up what I learned, I was surprised to discover that trace
functions don't behave the way I thought, or the way the docs say they
behave.
The docs say:
The trace function is invoked (with event set to 'call') whenever a new
local scope is entered; it should return a reference to a local trace
function to be used that scope, or None if the scope shouldn’t be traced.
The local trace function should return a reference to itself (or to another
function for further tracing in that scope), or None to turn off tracing in
that scope.
It's that last part that's wrong: returning None from the trace function
only has an effect on the first call in a new frame. Once the trace
function returns a function for a frame, returning None from subsequent
calls is ignored. A "local trace function" can't turn off tracing in its
scope.
To demonstrate:
import sys
UPTO_LINE = 1
def t(frame, event, arg):
num = frame.f_lineno
print("line %d" % num)
if num< UPTO_LINE:
return t
def try_it():
print("twelve")
print("thirteen")
print("fourteen")
print("fifteen")
UPTO_LINE = 1
sys.settrace(t)
try_it()
UPTO_LINE = 13
sys.settrace(t)
try_it()
Produces:
line 11
twelve
thirteen
fourteen
fifteen
line 11
line 12
twelve
line 13
thirteen
line 14
fourteen
line 15
fifteen
line 15
The first call to try_it() returns None immediately, preventing tracing for
the rest of the function. The second call returns None at line 13, but the
rest of the function is traced anyway. This behavior is the same in all
versions from 2.3 to 3.2, in fact, the 100 lines of code in sysmodule.c
responsible for Python tracing functions are completely unchanged through
those versions. (A deeper mystery that I haven't looked into yet is why
Python 3.x intersperses all of these lines with "line 18" interjections.)
I'm writing this email because I'm not sure whether this is a behavior bug
or a doc bug. One of them is wrong, since they disagree. The documented
behavior makes sense, and is what people have all along thought the trace
function did. The actual behavior is a bit more complicated to explain, but
is what people have actually been experiencing. FWIW, PyPy implements the
documented behavior.
Should we fix the code or the docs? I'd be glad to supply a patch for
either.
--Ned.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.settrace: behavior doesn't match docs
On 2/05/2011 9:27 PM, Ned Batchelder wrote: ... Maybe the fact no one noticed the docs were wrong proves that no one ever tried returning None from a local trace function. Or if they did, they should have complained by now. IMO, if the behaviour regresses from how it is documented and how it previously worked and no reports of the regression exist, we should just fix it without regard to people relying on the "new" functionality... Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.settrace: behavior doesn't match docs
On Mon, May 2, 2011 at 10:47 PM, Mark Hammond wrote: > On 2/05/2011 9:27 PM, Ned Batchelder wrote: > ... >> >> Maybe the fact no one noticed the docs >> were wrong proves that no one ever tried returning None from a local >> trace function. > > Or if they did, they should have complained by now. IMO, if the behaviour > regresses from how it is documented and how it previously worked and no > reports of the regression exist, we should just fix it without regard to > people relying on the "new" functionality... +1 Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Socket servers in the test suite
Nick Coghlan gmail.com> writes:
> sure the urllib tests already fire up a local server). Starting down
> the path of standardisation of that test functionality would be good.
I've made a start with test_logging.py by implementing some potential server
classes for use in tests: in the latest test_logging.py, the servers are between
comments containing the text "server_helper".
The basic approach for implementing socket servers is traditionally to use a
request handler class which implements the custom logic, but for some testing
applications this is overkill - you just want to be able to pass a handling
callable which is, say, a test case method. So the signatures of the servers are
all like this:
__init__(self, listen_addr, handler, poll_interval ...)
Initialise using the specified listen address and handler callable. Internally,
a RequestHandler subclass will be used whose handle() delegates to the handler
callable passed in.
A zero port number can be passed in, and a port attribute will (after binding)
have the actual port number used, so that clients can connect on that port.
start()
Start the server on a separate thread, using the poll_interval specified in the
underlying poll()/select() call. Before this is called, the request handler
class could be replaced with a subclass if need be.
stop(timeout=None)
Ask the server to stop and wait for the server thread to terminate.
The server also has a ready attribute which is a threading.Event, set just when
the server is entering its service loop. Typical mode of use would be:
class ClientTestCase(unittest.TestCase):
def setUp(self):
self.server = TheAppropriateServerClass(('localhost', 0),
self.handle_request, 0.01, ...)
self.server.start()
self.server.ready.wait()
self.handled = threading.Event()
def tearDown(self):
self.server.stop(1.0) # wait up to 1 sec for thread to stop
def handle_request(self, request):
# Handle the request, e.g. by setting some attributes based on what
# was received at the server
# Set the flag to say we finished handling
self.handled.set()
def test_xxx(self):
# set up client and send stuff to server
# Wait for server to finish doing stuff
self.handled.wait()
# make assertions based on the attributes
# set during request handling
The server classes provided are TestSMTPServer, TestTCPServer, TestUDPServer and
TestHTTPServer. There are examples of actual usage in test_logging.py:
SMTPHandlerTest, SocketHandlerTest, DatagramHandlerTest, SysLogHandlerTest,
HTTPHandlerTest.
I'd like some comments on this suggested API. I have not yet looked at how to
adapt other stdlib code than test_logging to use these classes, but the above
usage mode seems convenient and sufficient for testing applications. No doubt
people will be able to suggest problems with/improvements to the approach
outlined above.
Regards,
Vinay Sajip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue Tracker
On Sun, May 1, 2011 at 7:31 PM, Georg Brandl wrote: > On 30.04.2011 16:53, anatoly techtonik wrote: >> On Tue, Mar 29, 2011 at 4:37 AM, R. David Murray >> wrote: >>> >>> The hardest part is debugging the TAL when you make a mistake, but >>> even that isn't a whole lot worse than any other templating language. >> >> How much in % is it worse than Django templating language? > > I'm just guessing here, but I'd say 47.256 %. That means switching to Django templates will make Roundup design plumbing work 47.256% more attractive for potential contributors. -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue Tracker
2011/5/2 anatoly techtonik : > On Sun, May 1, 2011 at 7:31 PM, Georg Brandl wrote: >> On 30.04.2011 16:53, anatoly techtonik wrote: >>> On Tue, Mar 29, 2011 at 4:37 AM, R. David Murray >>> wrote: The hardest part is debugging the TAL when you make a mistake, but even that isn't a whole lot worse than any other templating language. >>> >>> How much in % is it worse than Django templating language? >> >> I'm just guessing here, but I'd say 47.256 %. > > That means switching to Django templates will make Roundup design > plumbing work 47.256% more attractive for potential contributors. Perhaps some of those eager contributors would like to volunteer for the task. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue Tracker
On Mon, May 2, 2011 at 11:06, anatoly techtonik wrote: > On Sun, May 1, 2011 at 7:31 PM, Georg Brandl wrote: > > On 30.04.2011 16:53, anatoly techtonik wrote: > >> On Tue, Mar 29, 2011 at 4:37 AM, R. David Murray > wrote: > >>> > >>> The hardest part is debugging the TAL when you make a mistake, but > >>> even that isn't a whole lot worse than any other templating language. > >> > >> How much in % is it worse than Django templating language? > > > > I'm just guessing here, but I'd say 47.256 %. > > That means switching to Django templates will make Roundup design > plumbing work 47.256% more attractive for potential contributors. What if these "potential contributors" never surface? Then we've made a 47.256% change in attractiveness, which is a 1423.843% waste of time. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 386 and dev repository versions workflow
http://guide.python-distribute.org/quickstart.html proposes suffixing version of a module in repository with 'dev' in a way that after release of '1.0' version, the repository version is changed to '2.0dev'. This makes sense, but it is not compatible with PEP 386, which suggests using 2.0.devN, where N is a repository revision number. I'd expand PEP 386 to include 2.0dev use case. -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 386 and dev repository versions workflow
On Mon, May 2, 2011 at 7:14 PM, anatoly techtonik wrote: > http://guide.python-distribute.org/quickstart.html proposes suffixing > version of a module in repository with 'dev' in a way that after > release of '1.0' version, the repository version is changed to > '2.0dev'. This makes sense, but it is not compatible with PEP 386, > which suggests using 2.0.devN, where N is a repository revision > number. I'd expand PEP 386 to include 2.0dev use case. This is a typo I'll fix, thanks for noticing > -- > anatoly t. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com > -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue Tracker
2011/4/30 anatoly techtonik : > On Tue, Mar 29, 2011 at 4:37 AM, R. David Murray > wrote: >> >> The hardest part is debugging the TAL when you make a mistake, but >> even that isn't a whole lot worse than any other templating language. > > How much in % is it worse than Django templating language? > -- > anatoly t. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com > Knowing both of them I can say ZPT is one of the few things I like about Zope and I find it a lot more powerful than Django templating system. Other than that, I don't see how changing the templating language can make any difference. If one does not contribute something because of the language used in templates... well, I think it wouldn't have been a particular good contribution anyway. =) --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue Tracker
On 02.05.2011 18:06, anatoly techtonik wrote: > On Sun, May 1, 2011 at 7:31 PM, Georg Brandl wrote: >> On 30.04.2011 16:53, anatoly techtonik wrote: >>> On Tue, Mar 29, 2011 at 4:37 AM, R. David Murray >>> wrote: The hardest part is debugging the TAL when you make a mistake, but even that isn't a whole lot worse than any other templating language. >>> >>> How much in % is it worse than Django templating language? >> >> I'm just guessing here, but I'd say 47.256 %. > > That means switching to Django templates will make Roundup design > plumbing work 47.256% more attractive for potential contributors. That's not true actually. It'll be 89.595 % more attractive. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] running/stepping python backwards
This may seem like an odd question, but I’m intrigued by the idea of using Python as a data definition language with “undo” support. If I were to try and instrument the Python interpreter to be able to step backwards, would that be an unduly difficult or inefficient thing to do? (Please reply to me directly.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Convert Py_Buffer to Py_UNICODE
Hi - I am working on a patch where I have an argument that can either be a
unicode string or binary data, I parse the argument using the
PyArg_ParseTuple method using the s* format specification and get a
Py_Buffer.
I now need to convert this Py_Buffer object to a Py_Unicode and pass it into
a function. What is the best way to do this? If I determine that the passed
argument was binary using another flag parameter then I am passing
Py_Buffer->buf as a pointer to the start of the data.
This is in winsound module, here's the relevant code snippet
sound_playsound(PyObject *s, PyObject *args)
{
Py_buffer *buffer;
int flags;
int ok;
LPCWSTR pszSound;
if (PyArg_ParseTuple(args, "s*i:PlaySound", &buffer, &flags)) {
if (flags & SND_ASYNC && flags & SND_MEMORY) {
/* Sidestep reference counting headache; unfortunately this also
prevent SND_LOOP from memory. */
PyBuffer_Release(buffer);
PyErr_SetString(PyExc_RuntimeError, "Cannot play asynchronously
from memory");
return NULL;
}
if(flags & SND_MEMORY) {
pszSound = buffer->buf;
}
else {
/* pszSound = ; */
}
-- Sijin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Convert Py_Buffer to Py_UNICODE
Sijin Joseph wrote:
> Hi - I am working on a patch where I have an argument that can either be a
> unicode string or binary data, I parse the argument using the
> PyArg_ParseTuple method using the s* format specification and get a
> Py_Buffer.
>
> I now need to convert this Py_Buffer object to a Py_Unicode and pass it into
> a function. What is the best way to do this? If I determine that the passed
> argument was binary using another flag parameter then I am passing
> Py_Buffer->buf as a pointer to the start of the data.
I don't understand why you'd want to convert PyUnicode to PyBytes
(encoded as UTF-8), only to decode it again afterwards in order
to pass it to some other PyUnicode API.
It'd be more efficient to use the "O" parser marker and then
use PyObject_GetBuffer() to convert non-PyUnicode objects to
a Py_buffer.
> This is in winsound module, here's the relevant code snippet
>
> sound_playsound(PyObject *s, PyObject *args)
> {
> Py_buffer *buffer;
> int flags;
> int ok;
> LPCWSTR pszSound;
>
> if (PyArg_ParseTuple(args, "s*i:PlaySound", &buffer, &flags)) {
> if (flags & SND_ASYNC && flags & SND_MEMORY) {
> /* Sidestep reference counting headache; unfortunately this also
>prevent SND_LOOP from memory. */
> PyBuffer_Release(buffer);
> PyErr_SetString(PyExc_RuntimeError, "Cannot play asynchronously
> from memory");
> return NULL;
> }
>
> if(flags & SND_MEMORY) {
> pszSound = buffer->buf;
> }
> else {
> /* pszSound = ; */
> }
>
> -- Sijin
>
>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/mal%40egenix.com
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, May 02 2011)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2011-06-20: EuroPython 2011, Florence, Italy 49 days to go
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue Tracker
2011/5/2 Georg Brandl : > On 02.05.2011 18:06, anatoly techtonik wrote: >> On Sun, May 1, 2011 at 7:31 PM, Georg Brandl wrote: >>> On 30.04.2011 16:53, anatoly techtonik wrote: On Tue, Mar 29, 2011 at 4:37 AM, R. David Murray wrote: > > The hardest part is debugging the TAL when you make a mistake, but > even that isn't a whole lot worse than any other templating language. How much in % is it worse than Django templating language? >>> >>> I'm just guessing here, but I'd say 47.256 %. >> >> That means switching to Django templates will make Roundup design >> plumbing work 47.256% more attractive for potential contributors. > > That's not true actually. > > It'll be 89.595 % more attractive. I don't understand why you're truncating to 3 digits. Let's be honest in that it will be sqrt(2)^(13e/2) % more attractive. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] running/stepping python backwards
On 4/29/2011 10:13 PM, Adrian Johnston wrote: This may seem like an odd question, but I’m intrigued by the idea of using Python as a data definition language with “undo” support. If I were to try and instrument the Python interpreter to be able to step backwards, would that be an unduly difficult or inefficient thing to do? The pydev list is for development of the next version of Python. Please direct your question to a more appropriate forum such as python-list. > (Please reply to me directly.) I did this time, but you should not expect that when posting to a public list. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows 2000 Support
Am 01.05.2011 22:51, schrieb Brian Curtin: > I'm currently writing a post about the process of removing OS/2 and VMS > support and thought about a discussion of Windows 2000 some time > back. http://mail.python.org/pipermail/python-dev/2010-March/098074.html makes > a proposal for beginning to walk away from 2000, but doesn't appear to > come to any conclusion. > > Was anything decided off the list? I don't see anything in PEP-11 and > don't see any changes in the installer made around Windows 2000. That's what you get for not following your own processes. It seems the discussion just stopped, with no action. I vaguely recall having made changes to the installer to produce a warning, but apparently never got to commit these changes. > If nothing was decided, should anything be done for 3.3? Most certainly. It seems we missed the chance of dropping support for W2k, so we still can't actively remove any code. However, I'd a) add it to PEP 11, and b) add a warning to the installer I stand by http://mail.python.org/pipermail/python-dev/2010-March/098101.html i.e. if there are patches that happen not to work on W2k, I'd accept them anyway - anybody interested in W2k would then have to provide fixes before 3.3rc1. So please go ahead and change PEP 11. While you are at it, also threaten to remove support for systems where the COMSPEC points to command.com (#2405). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] running/stepping python backwards
On Mon, May 2, 2011 at 1:49 PM, Terry Reedy wrote: > > (Please reply to me directly.) > > I did this time, but you should not expect that when posting to a public > list. Actually, this is not only appropriate on some lists, on some lists one is actually strongly discouraged from doing anything else. EG: sun-managers, where replies are expected to be private, and the originator of the thread is expected to collect all (private) replies and summarize them, to keep the list traffic low and the S/N ratio high. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 2.6.7 schedule
I'd like to make a Python 2.6.7 release candidate this Friday, May 6, with a final release scheduled for May 20. I've put these dates on the Python Release Schedule calendar. This will be a source-only security release. I see no release blockers for Python 2.6, so if you know of anything that must go into 2.6.7, please be sure there is a tracker issue for it, that 2.6 is marked as being affected, and with a release blocker priority. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: viewVC shows traceback on non utf-8 module markup
Am 29.04.2011 22:03, schrieb Michael Foord: > I know that the svn repo is now for legacy purposes only, but I doubt it > is intended that the online source browser should raise exceptions. It's certainly not. However, I don't plan to do anything about it, either (nor would I know that anybody else would). To view the source code of the file, use http://svn.python.org/view/python/trunk/Lib/heapq.py?view=co&content-type=text/plain Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows 2000 Support
On Mon, May 2, 2011 at 16:14, "Martin v. Löwis" wrote: > Am 01.05.2011 22:51, schrieb Brian Curtin: > > I'm currently writing a post about the process of removing OS/2 and VMS > > support and thought about a discussion of Windows 2000 some time > > back. > > http://mail.python.org/pipermail/python-dev/2010-March/098074.htmlmakes > > a proposal for beginning to walk away from 2000, but doesn't appear to > > come to any conclusion. > > > > Was anything decided off the list? I don't see anything in PEP-11 and > > don't see any changes in the installer made around Windows 2000. > > That's what you get for not following your own processes. It seems the > discussion just stopped, with no action. I vaguely recall having made > changes to the installer to produce a warning, but apparently never > got to commit these changes. > > > If nothing was decided, should anything be done for 3.3? > > Most certainly. It seems we missed the chance of dropping support for > W2k, so we still can't actively remove any code. However, I'd > > a) add it to PEP 11, and > b) add a warning to the installer > > I stand by > > http://mail.python.org/pipermail/python-dev/2010-March/098101.html > > i.e. if there are patches that happen not to work on W2k, I'd accept > them anyway - anybody interested in W2k would then have to provide > fixes before 3.3rc1. > > So please go ahead and change PEP 11. While you are at it, also threaten > to remove support for systems where the COMSPEC points to command.com > (#2405). > Done and done - http://hg.python.org/peps/rev/b9390aa12855 I'll have a look at the installer and add some type of message. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
