Am 06.12.2010 09:36, schrieb Jeroen Ruigrok van der Werven:
-On [20101206 08:30], Martin v. Löwis (mar...@v.loewis.de) wrote:
As a counter-example, I think the only way to phase out support
for old OpenBSD releases is that we set a date.
If you want, I can provide you with specifics
EOL dates of prominent Linux distribution :
I think I would need more information than that. Nick's proposal was
more specific: when does the vendor stop producing patches? This is
a clear criterion, and one that I support.
RHEL:
https://access.redhat.com/support/policy/updates/errata/
My
Nick Coghlan ncoghlan at gmail.com writes:
I would be fine with an EOL based policy for single-vendor platforms
(specifically Solaris and Windows) and a date-based policy for
everything else.
+1
I also think this would be for the best.
___
Martin v. Löwis wrote:
[...]
Ubuntu:
http://en.wikipedia.org/wiki/List_of_Ubuntu_releases#Version_timeline
(http://www.ubuntu.com/products/ubuntu/release-cycle seems to be down)
I'd prefer something more official than Wikipedia, though.
https://wiki.ubuntu.com/Releases
-Andrew.
Guido van Rossum wrote:
On Fri, Dec 3, 2010 at 9:58 AM, R. David Murray rdmur...@bitdance.com wrote:
On Fri, 03 Dec 2010 11:14:56 -0500, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Fri, Dec 3, 2010 at 10:11 AM, R. David Murray rdmur...@bitdance.com
wrote:
..
Please also
On Saturday 04 December 2010, Antoine Pitrou wrote:
Perhaps SVN doesn't get timestamps right.
SVN doesn't touch timestamps explicitly, it just writes the files as they come
and the system gives them the timestamps. This also makes sense, because the
build system depends on them - you don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/06/2010 07:18 AM, Ulrich Eckhardt wrote:
On Saturday 04 December 2010, Antoine Pitrou wrote:
Perhaps SVN doesn't get timestamps right.
SVN doesn't touch timestamps explicitly, it just writes the files as they
come
and the system gives
On 6 December 2010 09:18, Martin v. Löwis mar...@v.loewis.de wrote:
Also, it is not clear what to do about distributions/OSs
without any official EOL or life cycles.
Here my proposal stands: 10 years, by default.
How about max(EOL, 10years)? That sounds like it could be a useful guideline.
Am 06.12.2010 13:18, schrieb Ulrich Eckhardt:
On Saturday 04 December 2010, Antoine Pitrou wrote:
Perhaps SVN doesn't get timestamps right.
SVN doesn't touch timestamps explicitly, it just writes the files as they
come
and the system gives them the timestamps. This also makes sense,
Am 06.12.2010 14:40, schrieb Floris Bruynooghe:
On 6 December 2010 09:18, Martin v. Löwis mar...@v.loewis.de wrote:
Also, it is not clear what to do about distributions/OSs
without any official EOL or life cycles.
Here my proposal stands: 10 years, by default.
How about max(EOL, 10years)?
On Dec 3, 2010, at 10:05 AM, Guido van Rossum wrote:
Regardless of what I or others may have said before, I am not
currently a fan of adding transform() to either str or bytes.
Just to clarify, is your preference to go back to the Python 2.x way
and use encode()/decode() for both unicode
On Dec 5, 2010, at 3:36 AM, Vinay Sajip wrote:
I've just been notified via being added to the nosy list of
http://bugs.python.org/issue10627
about the deprecation of ConfigParser for 3.2. I presume I was added to this
list because logging.config uses ConfigParser, but logging.config
On 12/6/2010 4:08 AM, Martin v. Löwis wrote:
For Windows and Solaris, it seems that some users continue to use the
system after the vendor stops producing patches, and dislike the
prospect of not having Python releases for it anymore. However, they
are in clear minority, so by our current
FWIW, transform()/untransform() are already in the 3.2 beta.
Do you want them taken out? If so, do you want the codecs
made accessible with encode/decode or have them continue
to be inaccessible in 3.x?
Notice that they wouldn't be inaccessible even if transform
is taken out again:
On 12/6/10 10:55 AM, Martin v. Löwis wrote:
Of course, with these old systems, I really wonder: why do they need
current Python releases? 2.7 will remain available and maintained for
some time, and 3.1 will at least see security fixes for some more time -
something that the base system itself
On Mon, Dec 6, 2010 at 2:21 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
We really ought to stop with the SafeFoo naming convention.
It is only descriptive to the person who wrote the class or function,
not to the user who will immediately wonder, safe from what?
Safe from bad
Am 06.12.2010 20:25, schrieb Terry Reedy:
On 12/6/2010 4:08 AM, Martin v. Löwis wrote:
For Windows and Solaris, it seems that some users continue to use the
system after the vendor stops producing patches, and dislike the
prospect of not having Python releases for it anymore. However, they
On Dec 6, 2010, at 11:40 AM, Fred Drake wrote:
On Mon, Dec 6, 2010 at 2:21 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
We really ought to stop with the SafeFoo naming convention.
It is only descriptive to the person who wrote the class or function,
not to the user who will
Hi,
2010/12/6 Martin v. Löwis mar...@v.loewis.de
In my original posting, I proposed a clause where support could be
extended as long as an individual steps forward to provide that support.
So if XP remains popular by the time Microsoft stops providing patches
for it, some volunteer would
On Mon, Dec 6, 2010 at 4:02 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
IIRC, pprint has a safe_repr() and string.Template has safe_substitute()
and pydoc has a safe import.
pprint.saferepr
Ok, this one's my fault as well. Probably should just be named repr.
On 12/6/2010 3:46 PM, Martin v. Löwis wrote:
Am 06.12.2010 20:25, schrieb Terry Reedy:
I quite suspect that XP will be in major use (more than say, current
BSD) for some years after MS stops official support. Why rush to drop
it?
What rush to drop it,
On the day MS stops support. But it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Python development team, I'm happy to announce the
first of two beta preview releases of Python 3.2.
Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line. Since the final release of Python 2.7,
Development efforts concentrated on the standard library and support for
porting code to Python 3. Highlights are:
[snip]
* ...a much improved ssl module
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
On Mon, 2010-12-06 at 10:18 +0100, Martin v. Löwis wrote:
EOL dates of prominent Linux distribution :
I think I would need more information than that. Nick's proposal was
more specific: when does the vendor stop producing patches? This is
a clear criterion, and one that I support.
RHEL:
So by this policy, RHEL and SuSE users would be off worse than with
my original proposal (10 years).
Red Hat continues to provide patches for RHEL within the Extended Life
Cycle (years 8, 9 and 10), but it's an optional add-on.
My understanding is that you keep the patches available - but
I previously wrote:
I suspect the problem may be on the identify which process to kill
rather than the kill it part, but it's definitely going to take time
to figure that out for sure. While the approach kill_python takes is
much more appropriate, since we don't currently have multiple
On Mon, 06 Dec 2010 13:02:41 -0800, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Dec 6, 2010, at 11:40 AM, Fred Drake wrote:
On Mon, Dec 6, 2010 at 2:21 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
We really ought to stop with the SafeFoo naming convention.
It is
On Sat, Dec 4, 2010 at 5:58 PM, Martin v. Löwis mar...@v.loewis.de wrote:
I actually wonder if Python's re module can claim to provide even
Basic Unicode Support.
Do you really wonder? Most definitely it does not.
Were you more optimistic four years ago?
On Sun, Dec 5, 2010 at 5:25 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
On Saturday 04 December 2010 09:31:04 you wrote:
Alexander Belopolsky writes:
In fact, once the language moratorium is over, I will argue that
str.encode() and byte.decode() should deprecate encoding
On Tue, Dec 7, 2010 at 12:06 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Dec 7, 2010 at 2:46 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
Having all encodings accessible in a str method only promotes a
programming style where bytes objects can contain differently
30 matches
Mail list logo
