On Tue, Dec 7, 2010 at 12:06 AM, Nick Coghlan wrote:
> On Tue, Dec 7, 2010 at 2:46 PM, Alexander Belopolsky
> wrote:
>> Having all encodings accessible in a str method only promotes a
>> programming style where bytes objects can contain differently encoded
>> strings in different parts of the pro
On Tue, Dec 7, 2010 at 2:46 PM, Alexander Belopolsky
wrote:
> Having all encodings accessible in a str method only promotes a
> programming style where bytes objects can contain differently encoded
> strings in different parts of the program. Instead, well-written
> programs should decode bytes o
On Sun, Dec 5, 2010 at 5:25 PM, Victor Stinner
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 argument and
>> > just do
On Sat, Dec 4, 2010 at 5:58 PM, "Martin v. Löwis" 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?
http://bugs.python.org/issue1528154#msg54864
On Mon, 06 Dec 2010 13:02:41 -0800, Raymond Hettinger
wrote:
> On Dec 6, 2010, at 11:40 AM, Fred Drake wrote:
> > On Mon, Dec 6, 2010 at 2:21 PM, Raymond Hettinger
> > wrote:
> >> We really ought to stop with the SafeFoo naming convention.
> >> It is only descriptive to the person who wrote the
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 multipl
On 06/12/2010 21:02, Raymond Hettinger wrote:
On Dec 6, 2010, at 11:40 AM, Fred Drake wrote:
On Mon, Dec 6, 2010 at 2:21 PM, Raymond Hettinger
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 u
>> 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
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.
>
> 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
http://mail.python
-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, the
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
On Mon, Dec 6, 2010 at 4:02 PM, Raymond Hettinger
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.
string.Template.safe_substitute
Agree o
Hi,
2010/12/6 "Martin v. Löwis"
> 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 have to step for
On Dec 6, 2010, at 11:40 AM, Fred Drake wrote:
> On Mon, Dec 6, 2010 at 2:21 PM, Raymond Hettinger
> 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, "saf
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. Howeve
On Mon, Dec 6, 2010 at 2:21 PM, Raymond Hettinger
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 vampire movies, of course!
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 it
> 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: codec
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 poli
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 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 en
Am 06.12.2010 14:40, schrieb Floris Bruynooghe:
> On 6 December 2010 09:18, "Martin v. Löwis" 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)? Tha
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,
On 6 December 2010 09:18, "Martin v. Löwis" 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.
(Personally
-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 g
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 wan
Guido van Rossum wrote:
> On Fri, Dec 3, 2010 at 9:58 AM, R. David Murray wrote:
>> On Fri, 03 Dec 2010 11:14:56 -0500, Alexander Belopolsky
>> wrote:
>>> On Fri, Dec 3, 2010 at 10:11 AM, R. David Murray
>>> wrote:
>>> ..
Please also recall that transform/untransform was discussed before
"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.
Nick Coghlan 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.
___
Python-Dev mai
On Sat, Dec 4, 2010 at 8:43 PM, "Martin v. Löwis" wrote:
...
> Now, distutils2 is different: it's *not* new functionality. So perhaps
> yes: I disagree with the principle that bold rewrites should be
> developed independently. Such work would be much better carried out in a
> branch - it will neve
> 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
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
-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 on the BSD platforms of what
is currently in use, EO
34 matches
Mail list logo
