Re: [Python-Dev] PEP 11: Dropping support for ten year old systems

[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 on the BSD platforms of what
is currently in use, EOL and the future.

Also, with regard to Windows 2000, XP and its APIs. Didn't XP already switch
a bunch of APIs around that 2000 doesn't use? (Need to find that migration
document.)

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Nothing is more honorable than enlightenment, nothing is more beautiful
than virtue...
___
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] PEP 11: Dropping support for ten year old systems

[Martin v. Löwis]

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 on the BSD platforms of what
> is currently in use, EOL and the future.

If that's publicly documented from a single starting page, having the
URL of that page would be appreciated. Also, do users accept that
policy? (i.e. would they feel sad if Python releases don't support BSD
releases anymore that don't get patches?)

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 policy for minority platforms
(no need to support them), that's fine. This really triggered the "ten
years" proposal: for quite some time now (20 years) people stop losing
interest in operating systems after ten years.

> Also, with regard to Windows 2000, XP and its APIs. Didn't XP already switch
> a bunch of APIs around that 2000 doesn't use? (Need to find that migration
> document.)

I don't understand the question: what does it meant to switch an API
around? XP has added new API that wasn't available in 2000, if that's
what you are asking.

Regards,
Martin

___
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] PEP 11: Dropping support for ten year old systems

[Martin v. Löwis]

> 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 interpretation: Python support until end of production phase 3 (7 years).

> 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.

> SuSe
> http://support.novell.com/lifecycle/

My interpretation: Python support until end of Extended support phase
(7 years).

So by this policy, RHEL and SuSE users would be off worse than with
my original proposal (10 years).

> Considering the nature of the Fedora project, dropping unsupported fedora 
> distributions may or may not be helpful for Pyhton and it's users.

Again, for Linux, I think the issue is somewhat less critical: in terms
of portability and ABI stability, it seems like they manage best (i.e.
we have least version-dependent code for Linux in Python, probably
because a "Linux version" doesn't exist in the first place, so
distributions must provide source and binary compatibility even
across vendors, making such support across versions more easy).

> 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.

Regards,
Martin
___
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] PEP 384 accepted

[Tarek Ziadé]

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 never stand on its own.

So we had several +1 on James' idea to bring back distutils2 to the
trunk after 3.2 final, and it seems that you are not against this
idea.

So we will do this unless you object

Regards
Tarek

-- 
Tarek Ziadé | http://ziade.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] PEP 11: Dropping support for ten year old systems

[Seung Soo , Ha]

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 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] PEP 11: Dropping support for ten year old systems

[Andrew Bennetts]

"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.

___
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] transform() and untransform() methods, and the codec registry

[M.-A. Lemburg]

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
 the release of Python 3.0 and was approved at the time, but it just
 did not get implemented before the 3.0 release.

>>>
>>> Can you provide a link?  My search for transform on python-dev came out with
>>
>> It was linked from the issue, if I recall correctly.  I do remember
>> reading the thread from the python-3000 list, linked by someone
>> somewhere :)
>>
>>> http://mail.python.org/pipermail/python-dev/2010-June/100564.html
>>>
>>> where you seem to oppose these methods.  Also, new methods to builtins
>>
>> It looks to me like I was agreeing that transform/untrasnform should
>> do only bytes->bytes or str->str regardless of what codec name you
>> passed them.
>>
>>> fall under the language moratorium (but can be approved on a
>>> case-by-case basis):
>>>
>>> http://www.python.org/dev/peps/pep-3003/#case-by-case-exemptions
>>>
>>> Is there an effort to document these exceptions?  I expected such
>>> approvals to be added to PEP 3003, but apparently this was not the
>>> case.
>>
>> I believe MAL's thought was that the addition of these methods had
>> been approved pre-moratorium, 

Indeed.

>> but I don't know if that is a
>> sufficient argument or not.
> 
> It is not.
> 
> The moratorium is intended to freeze the state of the language as
> implemented, not whatever was discussed and approved but didn't get
> implemented (that'd be a hole big enough to drive a truck through, as
> the saying goes :-).

Sure, but those two particular methods only provide interfaces
to the codecs sub-system without actually requiring any major
implementation changes.

Furthermore, they "help ease adoption of Python 3.x" (quoted from
PEP 3003), since the functionality they add back was removed from
Python 3.0 in a way that makes it difficult to port Python2
applications to Python3.

> Regardless of what I or others may have said before, I am not
> currently a fan of adding transform() to either str or bytes.

How should I read this ? Do want the methods to be removed again
and added back in 3.3 ?

Frankly, I'm a bit tired of constantly having to argue against
cutting down the Unicode and codec support in Python3.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 06 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: 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
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 2 for building python 3

[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, because the 
build system depends on them - you don't want the build to skip compiling 
files after rewinding your working copy to an older version.

That said, you can tell SVN to do something with timestamps, I'd have to 
search a bit in order to find out what exactly that is.

Uli

**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**


___
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 2 for building python 3

[Tres Seaver]

-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 them the timestamps. This also makes sense, because the 
> build system depends on them - you don't want the build to skip compiling 
> files after rewinding your working copy to an older version.
> 
> That said, you can tell SVN to do something with timestamps, I'd have to 
> search a bit in order to find out what exactly that is.

If you set the 'use-commit-times' config flag, subversion will keep
timestamps in sync with the repository commit times during 'checkout',
'update', 'switch', etc. operations (it does this by default during
'export', which is likekt why the tarball process works):

http://svnbook.red-bean.com/en/1.1/ch07.html


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkz822EACgkQ+gerLs4ltQ5tdwCfV/iScJcoxymb/REIBm6VFcbK
TUIAoNl5LLaFgifdV8BjiuOIw5YmnaqR
=H7+7
-END PGP SIGNATURE-

___
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] PEP 11: Dropping support for ten year old systems

[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)?  That sounds like it could be a useful guideline.

(Personally I'd be sad to see Solaris 8 go in the next few years)

Regards
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.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] python 2 for building python 3

[Martin v. Löwis]

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, because the 
> build system depends on them - you don't want the build to skip compiling 
> files after rewinding your working copy to an older version.
> 
> That said, you can tell SVN to do something with timestamps, I'd have to 
> search a bit in order to find out what exactly that is.

What you can ask it to is to use commit times. As you say, this is risky
because it may cause build steps to be skipped.

What I'm asking for is that the version control gives the files new time
stamps, but still imposes a timestamp order, at least on modern
file systems (and, as an option, also on old ones).

Suppose you do an update spanning 20 revisions. The update should:
1. get the current time T at the beginning of the update
2. fetch all files, and update the contents
3. Touch all files, in the order of the revisions, using microsecond
   steps (i.e. the oldest file gets T, the next revision T+1µs, the
   next one T+2µs).
As the update probably takes longer than 20µs, all files will have
timestamps in the past when the update is done.

If the file system does not support subsecond timestamps, you can do
the same in second resolution, but that might give you files dated
in the future (which make complains about - but you'ld get over with
that after 20s). ms might offer some middle ground (but I think all
filesystems supporting ms resolution will also support µs).

Regards,
Martin
___
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] PEP 11: Dropping support for ten year old systems

[Martin v. Löwis]

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)?  That sounds like it could be a useful guideline.
> 
> (Personally I'd be sad to see Solaris 8 go in the next few years)

I guess we'll be sorry, then: under that policy, max(EOL, 10years) comes
out as "not supported" (not sure whether you were aware of that).

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 doesn't receive anymore. So
if you needed a Python release for Solaris 8, you could just use Python
2.3, no? We are not going to take the sources of old releases offline.

Regards,
Martin
___
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] transform() and untransform() methods, and the codec registry

[Raymond Hettinger]

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 encodings and other
other transformations (uu, zlib, bz2, quopri, etc)?

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?


Raymond

___
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] Repo frozen for 3.2

[Raymond Hettinger]

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 doesn't use
> any interpolation features so I could easily change all usages to
> SafeConfigParser; should I do it now (before the 3.2 beta is cut) or hold off
> for now?

+1 for doing the update now.   There's no advantage in continuing to use
the old ConfigParser.

With respect to beta feature freeze, that should really just mean not adding
prominent new major features.  We're still free to implement bug fixes,
make the language more consistent, propagate the existing changes
(such as SafeConfigParser), tweak any of the new APIs, and reconsider or
rework some of the new features (such as transform/untransform). 


Raymond


P.S.  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 can mean "sanitized", "won't raise an error", "has a default value",
"doesn't use eval/exec", "is secure", "has a known encoding", etc.
___
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] PEP 11: Dropping support for ten year old systems

[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
are in clear minority, so by our current policy for minority platforms


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? Is there much XP specific stuff in the current xp/vista/7 code?


It seems to me that the rule should be something like "around 10 years 
or end of support, as modified by popularity, the burden of continued 
support, the availability of test machines, and the availability of people".


--
Terry Jan Reedy


___
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] transform() and untransform() methods, and the codec registry

[Martin v. Löwis]

> 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: codecs.lookup would still find them.

Regards,
Martin
___
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] PEP 11: Dropping support for ten year old systems

[Stephen Hansen]

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 doesn't receive anymore. So
> if you needed a Python release for Solaris 8, you could just use Python
> 2.3, no? We are not going to take the sources of old releases offline.

For things like Solaris 8, I have no thoughts one way or the other-- but
considering Windows XP is hitting 10 years next year-- Personally? My
entirely theoretical timetable for when I think I'll be able to finally
upgrade to Python 3 (where I'll skip to whatever the latest Python 3
is), is actually shorter by at least a few years then my timetable of
when I think I'll be able to drop support of Windows XP. Unfortunately.

WinXP is old but *pervasive* still in my experience with small
businesses / customers. Many aren't even considering making a plan for
Win7 yet.

So if two years rolls around and Python 3.x (where 'x' is 'whatever is
current') isn't supported on Windows XP, I'll be very sad, and will have
to be stuck on Python 3.x-1 for .. awhile, where "awhile" is out of my
control and up to the Masses who are unable or can't be bothered with
fixing what works for them w/ WinXP.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
___
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] Repo frozen for 3.2

[Fred Drake]

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!

I'd not recognize the current Safe* class names as a pattern; there
are currently two in the py3k trunk:

configparser.SafeConfigParser
-- very much a poor name

xmlrpc.client.SafeTransport
-- perhaps should have been SSLTransport or HTTPSTransport

I agree the "Safe" prefix isn't meaningful.  SafeConfigParser might
even be my fault.

Michael Foord has lobbied to end up with the "preferred" configparser
class to be named (eventually) ConfigParser, with good reason.  It's
not clear to me that we want to do that for backward compatibility
reasons (as I've argued elsewhere).  Were it not for that issue, I'd
be in favor of using different/better names.  (And there's still space
for better names, if we can create new names that avoid the b/w
compatibility issues.)


  -Fred

--
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
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] PEP 11: Dropping support for ten year old systems

[Martin v. Löwis]

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
>> are in clear minority, so by our current policy for minority platforms
> 
> 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, specifically? It will be supported as long as
Microsoft provides patches, as per Nick's amendment. For Windows XP,
the extended lifecycle support (end of security patches) will be on
April 8, 2014. I wouldn't call that "rushing", at this point in time.
By our current release pace, Python 3.5 might be the first release
to not support XP anymore.

> Is there much XP specific stuff in the current xp/vista/7 code?

I don't know; I haven't investigated unsupporting XP yet. I'm concerned
about Windows 2000, at the moment.

> It seems to me that the rule should be something like "around 10 years
> or end of support, as modified by popularity, the burden of continued
> support, the availability of test machines, and the availability of
> people".

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 forward.

Regards,
Martin
___
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] Repo frozen for 3.2

[Raymond Hettinger]

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, "safe from what?"
> 
> Safe from bad vampire movies, of course!
> 
> I'd not recognize the current Safe* class names as a pattern; there
> are currently two in the py3k trunk:
> 
>configparser.SafeConfigParser
>-- very much a poor name
> 
>xmlrpc.client.SafeTransport
>-- perhaps should have been SSLTransport or HTTPSTransport
> 
> I agree the "Safe" prefix isn't meaningful. 

IIRC, pprint has a safe_repr() and string.Template has safe_substitute()
and pydoc has a safe import.

Never new there was so much danger in the standard library :-)


Raymond
___
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] PEP 11: Dropping support for ten year old systems

[Amaury Forgeot d'Arc]

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 forward.
>

+1. Such a clause is already used to keep supporting the old VC6.0 compiler
(a.k.a VC98!)

-- 
Amaury Forgeot d'Arc
___
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] Repo frozen for 3.2

[Fred Drake]

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 on this as well.

pydoc.safeimport
Not documented, so I don't really care what it's called.

> Never new there was so much danger in the standard library :-)

You should have known this, Raymond!  It's software.


  -Fred

--
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
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] PEP 11: Dropping support for ten year old systems

[Terry Reedy]

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 is a moot support until them.

--
Terry Jan Reedy


___
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] [RELEASED] Python 3.2 beta 1

[Georg Brandl]

-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 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* PEP 3148, a new futures library for concurrent programming
* PEP 384, a stable ABI for extension modules
* PEP 391, dictionary-based logging configuration
* an overhauled GIL implementation that reduces contention
* an extended email package that handles bytes messages
* countless fixes regarding bytes/string issues; among them full
  support for a bytes environment (filenames, environment variables)
* many consistency and behavior fixes for numeric operations
* a sysconfig module to access configuration information
* a pure-Python implementation of the datetime module
* additions to the shutil module, among them archive file support
* improvements to pdb, the Python debugger

For a more extensive list of changes in 3.2, see

http://docs.python.org/3.2/whatsnew/3.2.html

To download Python 3.2 visit:

http://www.python.org/download/releases/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkz9WcgACgkQN9GcIYhpnLBRYwCeMmH1GMmKOx9fVk8a/F0/TOzj
Vp0AoIHYBNcxV/U0AXIwMGWFHi1bAB+a
=KBam
-END PGP SIGNATURE-
___
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-committers] [RELEASED] Python 3.2 beta 1

[Antoine Pitrou]

> 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.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 11: Dropping support for ten year old systems

[David Malcolm]

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:
> > https://access.redhat.com/support/policy/updates/errata/
> 
> My interpretation: Python support until end of production phase 3 (7 years).

(...)

> 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.

So another interpretation of the above with Nick's proposal could be 10
years on RHEL.  (though obviously I'm biased in favor of RHEL)

Approaching this from another angle: please do add me to the "nosy" on
any compatibility bugs with running latest python code on RHEL.  I'm
also looking into getting RHEL buildbot machines, FWIW.


> > Considering the nature of the Fedora project, dropping unsupported fedora 
> > distributions may or may not be helpful for Pyhton and it's users.
> 
> Again, for Linux, I think the issue is somewhat less critical: in terms
> of portability and ABI stability, it seems like they manage best (i.e.
> we have least version-dependent code for Linux in Python, probably
> because a "Linux version" doesn't exist in the first place, so
> distributions must provide source and binary compatibility even
> across vendors, making such support across versions more easy).

The other compat issues are in the toolchain: e.g. very recent versions
of gcc .  In downstream Fedora, we tend to be amongst the first to run
into new compilation warnings (and, occasionally, "exciting"
code-generation bugs...)

But this tends to be the opposite kind of problem: beginning of life,
rather than end-of-life, and these sorts of things will need fixing for
every Linux build eventually.

FWIW, I'm trying to keep Fedora's "system" python 2 and python 3 builds
as up-to-date as reasonable, so Fedora users will (I hope) be running
fairly recent code python as is.  We have 2.7 as /usr/bin/python as of
F14, for instance.


Hope this is helpful
Dave

___
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] PEP 11: Dropping support for ten year old systems

[Martin v. Löwis]

>> 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 you
don't produce any new ones, right?

> So another interpretation of the above with Nick's proposal could be 10
> years on RHEL.  (though obviously I'm biased in favor of RHEL)

I wouldn't count mere availability of old patches on the server as
"support".

> Approaching this from another angle: please do add me to the "nosy" on
> any compatibility bugs with running latest python code on RHEL.

I'll try to remember, but really can't promise. But then, as I said
before: I think Linux support in Python is particularly easy. For
example, there isn't a single distribution-specific test in
configure.in.

> The other compat issues are in the toolchain: e.g. very recent versions
> of gcc .  In downstream Fedora, we tend to be amongst the first to run
> into new compilation warnings (and, occasionally, "exciting"
> code-generation bugs...)

Dropping support for old gcc versions (or other old compiler versions)
is probably an issue on its own. It will be difficult to figure out
what work-arounds are in place for what particular compiler glitch.

Regards,
Martin
___
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] Repo frozen for 3.2

[Michael Foord]

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 user who will immediately wonder, "safe from what?"

Safe from bad vampire movies, of course!

I'd not recognize the current Safe* class names as a pattern; there
are currently two in the py3k trunk:

configparser.SafeConfigParser
-- very much a poor name

xmlrpc.client.SafeTransport
-- perhaps should have been SSLTransport or HTTPSTransport

I agree the "Safe" prefix isn't meaningful.

IIRC, pprint has a safe_repr() and string.Template has safe_substitute()
and pydoc has a safe import.

Never new there was so much danger in the standard library :-)


What would you name those functions instead?

(SafeConfigParser is a naff name and only needed because ConfigParser is 
broken.)


Michael



Raymond
___
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/fuzzyman%40voidspace.org.uk



--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
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] kill_python on windows buildbots (was Re: Stable buildbots)

[David Bolen]

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 builds
> running simultaneously (and for me the machines are dedicated as build
> slaves, so I won't be having my own python_d), a more blanket kill
> operation is safe enough.

For anyone interested, I caught (well, Georg Brandl caught it first) a
case on Saturday with some hung processes on the Win7 buildbot that I
was able to verify kill_python failed to kill.  This was after having
a few instances where it did work fine.

I've created issue 10641 to track.  I also noticed another recent
issue (10136) that is also related to kill_python missing processes,
but given that it works in my case some of the time, and is always
called via the same path, not sure if that can be my problem.

I also realized that some fraction of the other cases I have seen
might not have truly been an issue, since from what I can see
kill_python is only run at the start of a build process, so hung
processes (even killable ones) from a prior build hang around until
the next build takes place.  They can however, interfere with the svn
checkout so things never get to the point of using kill_python.  So
maybe kill_python's use should be moved to the clean stage?

-- David

___
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] Repo frozen for 3.2

[R. David Murray]

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 class or function,
> >> not to the user who will immediately wonder, "safe from what?"
> > 
> > Safe from bad vampire movies, of course!
> > 
> > I'd not recognize the current Safe* class names as a pattern; there
> > are currently two in the py3k trunk:
> > 
> >configparser.SafeConfigParser
> >-- very much a poor name
> > 
> >xmlrpc.client.SafeTransport
> >-- perhaps should have been SSLTransport or HTTPSTransport
> > 
> > I agree the "Safe" prefix isn't meaningful. 
> 
> IIRC, pprint has a safe_repr() and string.Template has safe_substitute()
> and pydoc has a safe import.
> 
> Never new there was so much danger in the standard library :-)

unittest has an (internal) safe_repr, too.  I understand all four
of these to be "versions of xxx that won't raise".  I think that's
a reasonable use of the word 'safe', but perhaps there is something
better.

SafeConfigParser doesn't follow that pattern, of course, though it
is perhaps true that it would raise errors a bit less often... :)

--
R. David Murray  www.bitdance.com
___
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 and the Unicode Character Database

[Alexander Belopolsky]

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

I was hoping that regex syntax would be useful in
explaining/documenting Python text processing routines (including
string to number conversions) without a heavy dose of Unicode
terminology.
___
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] transform() and untransform() methods, and the codec registry

[Alexander Belopolsky]

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 UTF-8 encoding/decoding.  Hopefully by that time most people
>>  > will forget that other encodings exist.  (I can dream, right?)
>>
>> It's just a dream.  There's a pile of archival material, often on R/O
>> media, out there that won't be transcoded any more quickly than the
>> inscriptions on Tutankhamun's tomb.
>
> Not only, many libraries expect use bytes arguments encoded to a specific
> encoding (eg. locale encoding). Said differenlty, only few libraries written 
> in
> C accept wchar* strings.
>

My proposal has nothing to do with C-API.  It only concerns Python API
of the builtin str type.

> The Linux kernel (or many, or all, UNIX/BSD kernels) only manipulate byte
> strings. The libc only accept wide characters for a few operations. I don't
> know how to open a file with an unicode path with the Linux libc: you have to
> encode it...
>

Yes, but hopefully the encoding used by the filesystem will be UTF-8.
For Python users, however, encoding details will hopefully be hidden
by the open() call.   Yes, I am aware of the many problems with
divining the filesystem encoding, but instructing application
developers to supply their own fsencoding in
open(filepath.encode(fsencoding)) calls is not very helpful.

> Alexander: you should first patch all UNIX/BSD kernels to use unicode
> everywhere, then patch all libc implementations, and then all libraries
> (written in C). After that, you can have a break.
>

As Martin explained later in this thread with respect to the
transform() method, removing codec argument from str.encode() method
does not imply removing the codecs themselves.If I need a method
to encode strings to say koi8_r encoding, I can easily access it
directly:

>>> from encodings import koi8_r
>>> to_koi8_r = koi8_r.Codec().encode
>>> to_koi8_r('код')
(b'\xcb\xcf\xc4', 3)

More likely, however, I will only need en/decoding to read/write
legacy files and rather than encoding the strings explicitly before
writing into a file, I will just open that file with the correct
encoding.

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 on input, do all processing with str type
and decode on output.  When strings need to be passed to char* C APIs,
they should be encoded in UTF-8.  Many C APIs originally designed for
ASCII actually produce meaningful results when given  UTF-8 bytes.
(Supporting such usage was one of the design goals of UTF-8.)
___
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] transform() and untransform() methods, and the codec registry

[Nick Coghlan]

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 on input, do all processing with str type
> and decode on output.  When strings need to be passed to char* C APIs,
> they should be encoded in UTF-8.  Many C APIs originally designed for
> ASCII actually produce meaningful results when given  UTF-8 bytes.
> (Supporting such usage was one of the design goals of UTF-8.)

This world sounds nice, but it isn't the one that exists right now.
Practicality beats purity and all that :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] transform() and untransform() methods, and the codec registry

[Alexander Belopolsky]

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 program.  Instead, well-written
>> programs should decode bytes on input, do all processing with str type
>> and decode on output.  When strings need to be passed to char* C APIs,
>> they should be encoded in UTF-8.  Many C APIs originally designed for
>> ASCII actually produce meaningful results when given  UTF-8 bytes.
>> (Supporting such usage was one of the design goals of UTF-8.)
>
> This world sounds nice, but it isn't the one that exists right now.
> Practicality beats purity and all that :)

.. and default encoding being fixed as UTF-8 already goes 99% of the
way to that world.  As long as I can use encode/decode without an
argument, it does not bother me much that they can take one.  These
methods are also much easier to ignore than the transform/untransform
pair simply because it is only one method per class.
transform/untransform have much larger mental footprint not only
because there are two of them in both str and bytes, but also because
both str and bytes have a synonymously named translate method.  With
43 non-special methods, str interface is already huge.  The
transform() method with a suitable set of codecs could possibly
replace things like expandtabs() or swapcase(), but that would be like
writing x.transform('exp') and x.unstransform('exp') instead of
math.exp(x) and math.log(x).
___
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