Re: [Python-Dev] Did I miss the decision to untabify all of the C code?
Le jeudi 06 mai 2010 08:17:14, Alexandre Vassalotti a écrit : > On Wed, May 5, 2010 at 8:52 PM, Joao S. O. Bueno wrote: > > Python 2.7 is in beta, but not applying such a fix now would probably > > mean that python 2.x would forever remain with the mixed tabs, since > > it would make much less sense for such a change in a minor revision > > (although I'd favor it even there). > > Since 2.7 is likely the last release of the 2.x series, wouldn't it > more productive to spend time improving it instead of wasting time on > minor details like indentation? Because "2.7 is likely the last release of the 2.x series", I think that it will maintained more longer than any other 2.x release. If we change the indentation in 3.x but not in 2.x, it will be harder to port the commits from 3.x to 2.7. I consider that the maintenance is very important for this last release, more important than "improving it". I prefer to work on new features on 3.x and keep 2.7 as stable as we can. -- Victor Stinner http://www.haypocalc.com/ ___ 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 Clang 2.7's static analyzer over the code base
Le mardi 04 mai 2010 07:12:32, Martin v. Löwis a écrit : > > Will changing the indentation of source files to 4 space indents break > > patches on the bug tracker? > > Plain patch will choke, but "patch -l" might accept them. Tested on posixmodule.c: it works :-) -- Victor Stinner http://www.haypocalc.com/ ___ 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] Did I miss the decision to untabify all of the C code?
Alexandre Vassalotti peadrop.com> writes: > > Since 2.7 is likely the last release of the 2.x series, wouldn't it > more productive to spend time improving it instead of wasting time on > minor details like indentation? We occasionally waste time on minor details such as code indentation, documentation wording and punctuation, distinguishing "built-in" vs "builtin", etc. :) I don't think it prevents anyone from doing productive work. (besides, my own bug queue for 2.x currently appears to be empty) Then, as pointed out by Victor, if we want to solve the current indentation mixup, we have to do it in all branches so as to avoid making backports more difficult. Regards Antoine. ___ 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] Did I miss the decision to untabify all of the C code?
Le jeudi 06 mai 2010 02:59:26, Eric Smith a écrit :
> I grant you that it's a largely a mechanized change (except for the "a
> posteriori manual intervention" part), but still.
Attached patches are the "manual interventation" parts. 99% of the whole patch
only changes the indentation. There is just *two* changes not related directly
to indentation:
- I moved rc and buffer variable (specific to OS/2) at the beginning of the
function to avoid { and }.
- I added a newline in "static PyObject * os2_error(int code)"
The manual editions is mostly to "fix" the indentation.
Diff on Python trunk (diff -uw):
---
--- Modules/posixmodule.c.r808432010-05-06 10:18:47.0 +0200
+++ Modules/posixmodule.c 2010-05-06 10:18:51.0 +0200
@@ -470,6 +470,10 @@
{
PyObject *d;
char **e;
+#if defined(PYOS_OS2)
+APIRET rc;
+char buffer[1024]; /* OS/2 Provides a Documented Max of 1024 Chars */
+#endif
d = PyDict_New();
if (d == NULL)
return NULL;
@@ -505,10 +509,6 @@
Py_DECREF(v);
}
#if defined(PYOS_OS2)
-{
-APIRET rc;
-char buffer[1024]; /* OS/2 Provides a Documented Max of 1024 Chars
*/
-
rc = DosQueryExtLIBPATH(buffer, BEGIN_LIBPATH);
if (rc == NO_ERROR) { /* (not a type, envname is NOT 'BEGIN_LIBPATH')
*/
PyObject *v = PyString_FromString(buffer);
@@ -521,7 +521,6 @@
PyDict_SetItemString(d, "ENDLIBPATH", v);
Py_DECREF(v);
}
-}
#endif
return d;
}
@@ -662,7 +661,8 @@
errors are not in a global variable e.g. 'errno' nor are
they congruent with posix error numbers. */
-static PyObject * os2_error(int code)
+static PyObject *
+os2_error(int code)
{
char text[1024];
PyObject *v;
---
Diff on Python py3k (diff -uw):
---
--- Modules/posixmodule.c.r808452010-05-06 10:36:27.0 +0200
+++ Modules/posixmodule.c 2010-05-06 10:36:32.0 +0200
@@ -445,6 +445,11 @@
#else
char **e;
#endif
+#if defined(PYOS_OS2)
+APIRET rc;
+char buffer[1024]; /* OS/2 Provides a Documented Max of 1024 Chars */
+#endif
+
d = PyDict_New();
if (d == NULL)
return NULL;
@@ -515,10 +520,6 @@
}
#endif
#if defined(PYOS_OS2)
-{
-APIRET rc;
-char buffer[1024]; /* OS/2 Provides a Documented Max of 1024 Chars
*/
-
rc = DosQueryExtLIBPATH(buffer, BEGIN_LIBPATH);
if (rc == NO_ERROR) { /* (not a type, envname is NOT 'BEGIN_LIBPATH') */
PyObject *v = PyBytes_FromString(buffer);
@@ -531,7 +532,6 @@
PyDict_SetItemString(d, "ENDLIBPATH", v);
Py_DECREF(v);
}
-}
#endif
return d;
}
@@ -672,7 +672,8 @@
errors are not in a global variable e.g. 'errno' nor are
they congruent with posix error numbers. */
-static PyObject * os2_error(int code)
+static PyObject *
+os2_error(int code)
{
char text[1024];
PyObject *v;
---
--
Victor Stinner
http://www.haypocalc.com/
--- Modules/posixmodule.c 2010-05-06 02:16:46.0 +0200
+++ Modules/posixmodule.c 2010-05-06 02:16:15.0 +0200
@@ -470,6 +470,10 @@
{
PyObject *d;
char **e;
+#if defined(PYOS_OS2)
+APIRET rc;
+char buffer[1024]; /* OS/2 Provides a Documented Max of 1024 Chars */
+#endif
d = PyDict_New();
if (d == NULL)
return NULL;
@@ -505,10 +509,6 @@
Py_DECREF(v);
}
#if defined(PYOS_OS2)
-{
-APIRET rc;
-char buffer[1024]; /* OS/2 Provides a Documented Max of 1024 Chars */
-
rc = DosQueryExtLIBPATH(buffer, BEGIN_LIBPATH);
if (rc == NO_ERROR) { /* (not a type, envname is NOT 'BEGIN_LIBPATH') */
PyObject *v = PyString_FromString(buffer);
@@ -521,7 +521,6 @@
PyDict_SetItemString(d, "ENDLIBPATH", v);
Py_DECREF(v);
}
-}
#endif
return d;
}
@@ -607,22 +606,22 @@
/**
* Helper Function to Trim and Format OS/2 Messages
**/
-static void
+static void
os2_formatmsg(char *msgbuf, int msglen, char *reason)
{
msgbuf[msglen] = '\0'; /* OS/2 Doesn't Guarantee a Terminator */
if (strlen(msgbuf) > 0) { /* If Non-Empty Msg, Trim CRLF */
-char *lastc = &msgbuf[ strlen(msgbuf)-1 ];
+char *lastc = &msgbuf[ strlen(msgbuf)-1 ];
-while (lastc > msgbuf && isspace(Py_CHARMASK(*lastc)))
-*lastc-- = '\0'; /* Trim Trailing Whitespace (CRLF) */
+while (lastc > msgbuf && isspace(Py_CHARMASK(*lastc)))
+*lastc-- = '\0'; /* Trim Trailing Whitespace (CRLF) */
}
/* Add Optional Reason Text */
if (reason) {
-strcat(msgbuf, " : ");
-strcat(msgbuf, reason);
+strcat(
Re: [Python-Dev] Fwd: broken mailing list links in PEP(s?)
On May 05, 2010, at 11:35 AM, James Y Knight wrote: >And of course if you're paying attention, you can fix the mbox file >(quoting "From" etc) such that it generates the same numbers as it did >the first time. Mailman even has a command for this (I feel like an Apple commercial). You should check things though because it's based on heuristics that can sometimes be fooled. -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
[Python-Dev] audience-instructors for Teach Me Python Bugfixing needed
Hey, everybody... I'm Catherine, a database administrator who makes up
excuses to write Python instead.
I'm not actually here as a core developer, but as somebody who hopes to
become a developer and recruit some more, which brings me to my question:
Who lives close enough to Ohio to make it to PyOhio this summer? I want to
use PyOhio to create new Python devs (including myself), but I need some
existing ones to seed the process.
I need a few veterans (3?) who can commit to come to PyOhio and take part as
audience/instructors in a "Teach Me [Python core / standard library]
Bugfixing" session. (See
http://catherinedevlin.blogspot.com/2010/04/bugfixing-at-pyohio.html.) The
PyOhio Call for Proposals is up May 10 so I'd better find you quick!
I'm pretty much ignorant enough to lead a Teach Me session. In a Teach Me
session, the person at the projector *doesn't* know the material. Instead,
she asks the audience questions ("How do I find a bug to work on?"), and
they talk her through it. It's based on Teach Me Twisted, a mind-blowing
session Steve Holden led at PyCon 2008 (
http://catherinedevlin.blogspot.com/2008/03/teach-me-twisted.html). I think
it's a fantastic way to teach, but it depends on some veterans being in the
audience. There are folks in the greater Python community eager to get hold
of a video of such a session... if we do this well, it could become an
important tool in keeping the quality of core Python code high.
And all I need from you, my audience-instructors, is a promise to show up
(no preparation necessary). Can you make it? Can you pass the appeal on to
others you know of?
Thanks! Hope to see you in July!
--
- Catherine
http://catherinedevlin.blogspot.com/
*** PyOhio 2010 * July 31 - Aug 1 * Columbus, OH * pyohio.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] audience-instructors for Teach Me Python Bugfixing needed
What an excellent idea! We should have these at *every* regional
conference.
Doug
On May 6, 2010, at 10:47 AM, Catherine Devlin wrote:
Hey, everybody... I'm Catherine, a database administrator who makes
up excuses to write Python instead.
I'm not actually here as a core developer, but as somebody who hopes
to become a developer and recruit some more, which brings me to my
question:
Who lives close enough to Ohio to make it to PyOhio this summer? I
want to use PyOhio to create new Python devs (including myself), but
I need some existing ones to seed the process.
I need a few veterans (3?) who can commit to come to PyOhio and take
part as audience/instructors in a "Teach Me [Python core / standard
library] Bugfixing" session. (See http://catherinedevlin.blogspot.com/2010/04/bugfixing-at-pyohio.html.)
The PyOhio Call for Proposals is up May 10 so I'd better find you
quick!
I'm pretty much ignorant enough to lead a Teach Me session. In a
Teach Me session, the person at the projector *doesn't* know the
material. Instead, she asks the audience questions ("How do I find
a bug to work on?"), and they talk her through it. It's based on
Teach Me Twisted, a mind-blowing session Steve Holden led at PyCon
2008 (http://catherinedevlin.blogspot.com/2008/03/teach-me-twisted.html
). I think it's a fantastic way to teach, but it depends on some
veterans being in the audience. There are folks in the greater
Python community eager to get hold of a video of such a session...
if we do this well, it could become an important tool in keeping the
quality of core Python code high.
And all I need from you, my audience-instructors, is a promise to
show up (no preparation necessary). Can you make it? Can you pass
the appeal on to others you know of?
Thanks! Hope to see you in July!
--
- Catherine
http://catherinedevlin.blogspot.com/
*** PyOhio 2010 * July 31 - Aug 1 * Columbus, OH * pyohio.org ***
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/doug.hellmann%40gmail.com
___
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 Clang 2.7's static analyzer over the code base
On 5 May, 2010, at 22:56, Brett Cannon wrote: > I am done running the analysis over trunk. I will not svnmerge these changes > into py3k as the amount of time and effort that would take equates to running > the static analyzer again just before 3.2 is released and possibly catching > more changes (and maybe even a newer version of Clang at that point). Have you looked into teaching clang's static analyser about Python's refcounting rules? Clang's analyser can tell you about problems related to reference count management for Objective-C code and doing the same for code using the CPython API would be usefull. Ronald > > On Mon, May 3, 2010 at 15:37, Brett Cannon wrote: > Since 2.7 is probably going to exist for a while, I am running Clang 2.7's > static analyzer (``clang --static``) over trunk. It's mostly just finding > stuff like unneeded variable initialization or variables that are never used > (compilation is picking up unused returned values, almost all from > PyObject_INIT). > > When I check in these changes I will do it file by file, but my question is > how to handle Misc/NEWS. I have gone through the underscores and the 'a's in > Modules and already have six modified files, so the final count might be a > little high. Do people want individual entries per file, or simply a single > entry that lists each file modified? > > We should probably go through the C code and fix the whitespace before we hit > 2.7 final (there is a ton of lines with extraneous spaces). > > -Brett > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com smime.p7s Description: S/MIME cryptographic 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] audience-instructors for Teach Me Python Bugfixing needed
Hello, > Who lives close enough to Ohio to make it to PyOhio this summer? I want > to use PyOhio to create new Python devs (including myself), but I need > some existing ones to seed the process. I'm not really answering your question (I'm very far from Ohio), but a good way to start up without physically meeting a core dev in your area would be to look for bugs in the issue tracker and start tackling those that tickle your interest. "Tackling" here can mean proposing a patch, or giving advice, or asking for guidance on how to produce a patch for that particular issue, or even reviewing an existing patch. You don't have to be a CPython expert to try this; just be prepared to spend some time exchanging with other people who will point out possible mistakes, or teach you some of the annoying idiosyncrasies. Scanning through open issues will also give you a general idea of what kind of functionalities are looking for improvement, or need fixing. (you can create a new issue and start tackling it yourself, too) Also, if you have enough free time, you can hang out on #python-dev, which can speed up the process, but it's not required. You can also find formal information about the development process here: http://www.python.org/dev/faq/ Regards Antoine. ___ 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 Clang 2.7's static analyzer over the code base
On Thu, May 6, 2010 at 08:09, Ronald Oussoren wrote: > > On 5 May, 2010, at 22:56, Brett Cannon wrote: > > I am done running the analysis over trunk. I will not svnmerge these > changes into py3k as the amount of time and effort that would take equates > to running the static analyzer again just before 3.2 is released and > possibly catching more changes (and maybe even a newer version of Clang at > that point). > > > Have you looked into teaching clang's static analyser about Python's > refcounting rules? Clang's analyser can tell you about problems related to > reference count management for Objective-C code and doing the same for code > using the CPython API would be usefull. > That's a thought, but I have not looked into it yet. As of right now the first thing I would do is fix its NULL de-reference analysis as it had a bunch of false-positives on that (I don't think it handles `!ptr` as equivalent to `ptr == NULL`). -Brett > > Ronald > > > On Mon, May 3, 2010 at 15:37, Brett Cannon wrote: > >> Since 2.7 is probably going to exist for a while, I am running Clang 2.7's >> static analyzer (``clang --static``) over trunk. It's mostly just finding >> stuff like unneeded variable initialization or variables that are never used >> (compilation is picking up unused returned values, almost all from >> PyObject_INIT). >> >> When I check in these changes I will do it file by file, but my question >> is how to handle Misc/NEWS. I have gone through the underscores and the 'a's >> in Modules and already have six modified files, so the final count might be >> a little high. Do people want individual entries per file, or simply a >> single entry that lists each file modified? >> >> We should probably go through the C code and fix the whitespace before we >> hit 2.7 final (there is a ton of lines with extraneous spaces). >> >> -Brett >> > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com > > > ___ 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] What's New text on future maintenance
FYI: I've just added the text below to the "What's New" document for
2.7. I wanted to describe how 2.7 will probably be maintained, but
didn't want to write anything that sounded like an iron-clad guarantee
of a maintenance timespan. Does this text seem like a reasonable set
of statements?
--amk
Python 2.7 is intended to be the last major release in the 2.x series.
Though more major releases have not been absolutely ruled out, the
Python maintainers are planning to focus their efforts on Python 3.x.
This means that 2.7 will remain in place for a long time, running
production systems that have not been ported to Python 3.x.
Two consequences of the long-term significance of 2.7 are:
* It's very likely the 2.7 release will have a longer period of
maintenance compared to earlier 2.x versions. Python 2.7 will
continue to be maintained while the transition to 3.x is in
progress, and that transition will itself be lengthy. Most 2.x
versions are maintained for about 4 years, from the first to the
last bugfix release; patchlevel releases for Python 2.7 will
probably be made for at least 6 years.
* Because 2.7 will be running production applications, a policy
decision was made to silence warnings only of interest to developers
by default. Silencing :exc:`DeprecationWarning` and its descendants
prevents users from seeing warnings triggered by an application.
(Carried out in :issue:`7319`.)
You can re-enable display of :exc:`DeprecationWarning` messages by
running Python with the :option:`-Wdefault` (short form:
:option:`-Wd`) switch, or you can add
``warnings.simplefilter('default')`` to your code.
___
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] What's New text on future maintenance
On Thu, May 6, 2010 at 6:50 PM, A.M. Kuchling wrote:
> FYI: I've just added the text below to the "What's New" document for
> 2.7. I wanted to describe how 2.7 will probably be maintained, but
> didn't want to write anything that sounded like an iron-clad guarantee
> of a maintenance timespan. Does this text seem like a reasonable set
> of statements?
>
> --amk
>
> Python 2.7 is intended to be the last major release in the 2.x series.
> Though more major releases have not been absolutely ruled out, the
I would scrap the "Though more ... ruled out" part. That just stokes
unrealistic hopes. :-)
> Python maintainers are planning to focus their efforts on Python 3.x.
>
> This means that 2.7 will remain in place for a long time, running
> production systems that have not been ported to Python 3.x.
> Two consequences of the long-term significance of 2.7 are:
>
> * It's very likely the 2.7 release will have a longer period of
> maintenance compared to earlier 2.x versions. Python 2.7 will
> continue to be maintained while the transition to 3.x is in
> progress, and that transition will itself be lengthy. Most 2.x
> versions are maintained for about 4 years, from the first to the
> last bugfix release; patchlevel releases for Python 2.7 will
> probably be made for at least 6 years.
>
> * Because 2.7 will be running production applications, a policy
> decision was made to silence warnings only of interest to developers
> by default. Silencing :exc:`DeprecationWarning` and its descendants
> prevents users from seeing warnings triggered by an application.
> (Carried out in :issue:`7319`.)
>
> You can re-enable display of :exc:`DeprecationWarning` messages by
> running Python with the :option:`-Wdefault` (short form:
> :option:`-Wd`) switch, or you can add
> ``warnings.simplefilter('default')`` to your code.
All this sounds fine to me. Thanks for taking the time to write this!
--
--Guido van Rossum (python.org/~guido)
___
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] What's New text on future maintenance
"A.M. Kuchling" writes: > FYI: I've just added the text below to the "What's New" document for > 2.7. I wanted to describe how 2.7 will probably be maintained, but > didn't want to write anything that sounded like an iron-clad guarantee > of a maintenance timespan. Does this text seem like a reasonable set > of statements? If you give an actual time period, that's all that will actually be communicated to most people. This text will be read by a few people, and communicated as simply “six years” to everyone else. It doesn't matter how many caveats and qualifiers you surround that with; those will all be lost in transmission from person to person. Would it make more sense to, instead of giving a time period, rather describe the *circumstances* that will determine when maintenance releases will cease for 2.7? -- \ “Religious faith is the one species of human ignorance that | `\ will not admit of even the *possibility* of correction.” —Sam | _o__) Harris, _The End of Faith_, 2004 | Ben Finney ___ 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] What's New text on future maintenance
2010/5/6 A.M. Kuchling : > FYI: I've just added the text below to the "What's New" document for > 2.7. I wanted to describe how 2.7 will probably be maintained, but > didn't want to write anything that sounded like an iron-clad guarantee > of a maintenance timespan. Does this text seem like a reasonable set > of statements? > > --amk > > Python 2.7 is intended to be the last major release in the 2.x series. > Though more major releases have not been absolutely ruled out, the > Python maintainers are planning to focus their efforts on Python 3.x. > > This means that 2.7 will remain in place for a long time, running > production systems that have not been ported to Python 3.x. > Two consequences of the long-term significance of 2.7 are: > > * It's very likely the 2.7 release will have a longer period of > maintenance compared to earlier 2.x versions. Python 2.7 will > continue to be maintained while the transition to 3.x is in > progress, and that transition will itself be lengthy. Most 2.x > versions are maintained for about 4 years, from the first to the > last bugfix release; patchlevel releases for Python 2.7 will > probably be made for at least 6 years. I don't think there's any point in being hypothetical about. I believe we've already said that maintence for 2.7 will last for at least 5 years, so let's proclaim it. -- 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] What's New text on future maintenance
On 5/6/2010 9:50 PM, A.M. Kuchling wrote:
FYI: I've just added the text below to the "What's New" document for
2.7. I wanted to describe how 2.7 will probably be maintained, but
didn't want to write anything that sounded like an iron-clad guarantee
of a maintenance timespan. Does this text seem like a reasonable set
of statements?
--amk
Python 2.7 is intended to be the last major release in the 2.x series.
Though more major releases have not been absolutely ruled out, the
Python maintainers are planning to focus their efforts on Python 3.x.
This means that 2.7 will remain in place for a long time, running
production systems that have not been ported to Python 3.x.
Two consequences of the long-term significance of 2.7 are:
* It's very likely the 2.7 release will have a longer period of
maintenance compared to earlier 2.x versions. Python 2.7 will
continue to be maintained while the transition to 3.x is in
progress, and that transition will itself be lengthy. Most 2.x
versions are maintained for about 4 years, from the first to the
last bugfix release; patchlevel releases for Python 2.7 will
probably be made for at least 6 years.
Actually, bugfix releases generally stop with the next major release,
with about a 2 year interval. I agree with others about condensing, to
something like:
"Python 2.7 is intended to be the last major release in the 2.x series.
Python core developers plan to focus future efforts on Python 3.x.
This means that 2.7 will remain in place for a long time, running
production systems that have not been ported to Python 3.x. Bugfix
releases will likely continue for 5 years."
Then the warnings stuff
* Because 2.7 will be running production applications, a policy
Every major version (xcept 3.0) has run production application, and 3.1
may be and 3.2 certainly will be. So this reasoning is not clear to me.
decision was made to silence warnings only of interest to developers
by default.
I believe this is meant to say "Warnings aimed only at those porting
code to 3.x are silenced by default."
>Silencing :exc:`DeprecationWarning` and its descendants
prevents users from seeing warnings triggered by an application.
(Carried out in :issue:`7319`.)
You can re-enable display of :exc:`DeprecationWarning` messages by
running Python with the :option:`-Wdefault` (short form:
:option:`-Wd`) switch, or you can add
``warnings.simplefilter('default')`` to your code.
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
