Re: [Python-Dev] [Catalog-sig] accept the wheel PEPs 425, 426, 427

[Martin v. Löwis]

Am 13.11.12 03:04, schrieb Nick Coghlan:

On Mon, Oct 29, 2012 at 4:47 AM, Daniel Holth mailto:dho...@gmail.com>> wrote:

I think Metadata 1.3 is done. Who would like to czar?

(Apologies for the belated reply, it's been a busy few weeks)

I'm happy to be BDFL delegate for these. I'd like to see PEP 425 updated
with some additional rationale based on Ronald's comments later in this
thread, though.


For the record, I'm still -1 on PEP 427, because of the signature issues.

The FAQ in the PEP is incorrect in claiming PGP or X.509 cannot
readily be used to verify the integrity of an archive - the whole
point of these technologies is to do exactly that.

The FAQ is entirely silent on why it is not using a more standard
signature algorithm such as ECDSA. It explains why it uses Ed25519,
but ignores that the very same rationale would apply to ECDSA as well;
plus that would be one of the standard JWS algorithms.

In addition, the FAQ claims that the format is designed to introduce
cryptopgraphy that is actually used, yet leaves the issue of key
distribution alone (except that pointing out that you can put them
into requires.txt - a file that doesn't seem to be specified anywhere).

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] [Catalog-sig] accept the wheel PEPs 425, 426, 427

[M.-A. Lemburg]

On 13.11.2012 10:51, "Martin v. Löwis" wrote:
> Am 13.11.12 03:04, schrieb Nick Coghlan:
>> On Mon, Oct 29, 2012 at 4:47 AM, Daniel Holth > > wrote:
>>
>> I think Metadata 1.3 is done. Who would like to czar?
>>
>> (Apologies for the belated reply, it's been a busy few weeks)
>>
>> I'm happy to be BDFL delegate for these. I'd like to see PEP 425 updated
>> with some additional rationale based on Ronald's comments later in this
>> thread, though.
> 
> For the record, I'm still -1 on PEP 427, because of the signature issues.
> 
> The FAQ in the PEP is incorrect in claiming PGP or X.509 cannot
> readily be used to verify the integrity of an archive - the whole
> point of these technologies is to do exactly that.
> 
> The FAQ is entirely silent on why it is not using a more standard
> signature algorithm such as ECDSA. It explains why it uses Ed25519,
> but ignores that the very same rationale would apply to ECDSA as well;
> plus that would be one of the standard JWS algorithms.
> 
> In addition, the FAQ claims that the format is designed to introduce
> cryptopgraphy that is actually used, yet leaves the issue of key
> distribution alone (except that pointing out that you can put them
> into requires.txt - a file that doesn't seem to be specified anywhere).

I agree with Martin. If the point is to "to protect against cryptography
that is not used", then not using the de-facto standard in signing
open source distribution files, which today is PGP/GPG, misses that
point :-)

Note that signing such distribution files can be handled outside
of the wheel format PEP. It just way to complex and out of scope
for the wheel format itself. Also note that PGP/GPG and the other
signing tools work well on any distribution file. There's really no
need to build these into the format itself.

It's a good idea to check integrity, but that can be done using
hashes.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 13 2012)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.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] [Distutils] [Catalog-sig] accept the wheel PEPs 425, 426, 427

[Paul Moore]

On 13 November 2012 10:26, M.-A. Lemburg  wrote:

> I agree with Martin. If the point is to "to protect against cryptography
> that is not used", then not using the de-facto standard in signing
> open source distribution files, which today is PGP/GPG, misses that
> point :-)
>

I agree as well. For me, the main reason for cryptography not being used is
key distribution. Sure, I have a signed file, but without a key what's the
point? And if I'm creating a file, why sign it if I don't know how to
securely publish my key? So inventing a new signing infrastructure without
a key distribution process doesn't encourage me to use crypto at all...


> It's a good idea to check integrity, but that can be done using
> hashes.
>

+1 hashing is fine, and I don't have any problem with the hashing aspects
of the PEP.

Maybe the signing aspects could be deferred to a subsequent PEP, to be
thrashed out separately? I know Daniel has a strong interest in the signing
aspect, so I'm reluctant to suggest just dropping it, but I'd rather it not
be a showstopper for the rest of the current proposal.

Paul.
___
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] externals?

[Kristján Valur Jónsson]

This may be a silly question, but haven't the python externals been moved to HG 
yet?
I usually work on cpython without bothering with the externals, but I found 
today that I needed them.  On Windows this is a bit of a bother.  And I've 
thrown away all my SVN stuff...
K
___
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] [Distutils] [Catalog-sig] accept the wheel PEPs 425, 426, 427

[Daniel Holth]

On Tue, Nov 13, 2012 at 5:26 AM, M.-A. Lemburg  wrote:

> On 13.11.2012 10:51, "Martin v. Löwis" wrote:
> > Am 13.11.12 03:04, schrieb Nick Coghlan:
> >> On Mon, Oct 29, 2012 at 4:47 AM, Daniel Holth  >> > wrote:
> >>
> >> I think Metadata 1.3 is done. Who would like to czar?
> >>
> >> (Apologies for the belated reply, it's been a busy few weeks)
> >>
> >> I'm happy to be BDFL delegate for these. I'd like to see PEP 425 updated
> >> with some additional rationale based on Ronald's comments later in this
> >> thread, though.
> >
> > For the record, I'm still -1 on PEP 427, because of the signature issues.
> >
> > The FAQ in the PEP is incorrect in claiming PGP or X.509 cannot
> > readily be used to verify the integrity of an archive - the whole
> > point of these technologies is to do exactly that.
> >
> > The FAQ is entirely silent on why it is not using a more standard
> > signature algorithm such as ECDSA. It explains why it uses Ed25519,
> > but ignores that the very same rationale would apply to ECDSA as well;
> > plus that would be one of the standard JWS algorithms.
> >
> > In addition, the FAQ claims that the format is designed to introduce
> > cryptopgraphy that is actually used, yet leaves the issue of key
> > distribution alone (except that pointing out that you can put them
> > into requires.txt - a file that doesn't seem to be specified anywhere).
>
> I agree with Martin. If the point is to "to protect against cryptography
> that is not used", then not using the de-facto standard in signing
> open source distribution files, which today is PGP/GPG, misses that
> point :-)
>
> Note that signing such distribution files can be handled outside
> of the wheel format PEP. It just way to complex and out of scope
> for the wheel format itself. Also note that PGP/GPG and the other
> signing tools work well on any distribution file. There's really no
> need to build these into the format itself.
>
> It's a good idea to check integrity, but that can be done using
> hashes.


PGP-on-pypi is the very definition of cryptography that isn't used.

I'm willing to go ahead and move any mention of signing algorithms into a
separate PEP, leaving only the basic manifest hash vs. file contents
verification under the auspices of this PEP.

Is the rest of the wheel specification, explaining how packages are
actually produced and installed, clear?


I want to remove distutils from the standard library. If that happens then
we might want a secure way to install it from pypi. One way would be to
include the public key used to sign distutils in Python's own
signature-verifying bootstrap wheel installer, never mind whether it used
ECDSA or RSA or Ed25519. Do you have a better idea? TUF?
https://www.updateframework.com/wiki/SecuringPythonPackageManagement
___
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] externals?

[Benjamin Peterson]

Their still in svn as far I know.

2012/11/13 Kristján Valur Jónsson :
> This may be a silly question, but haven‘t the python externals been moved to
> HG yet?
>
> I usually work on cpython without bothering with the externals, but I found
> today that I needed them.  On Windows this is a bit of a bother.  And I‘ve
> thrown away all my SVN stuff...
>
> K
>
>
> ___
> 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/benjamin%40python.org
>



-- 
Regards,
Benjamin
___
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] [Distutils] [Catalog-sig] accept the wheel PEPs 425, 426, 427

[Dirkjan Ochtman]

On Tue, Nov 13, 2012 at 4:00 PM, Daniel Holth  wrote:
> I'm willing to go ahead and move any mention of signing algorithms into a
> separate PEP, leaving only the basic manifest hash vs. file contents
> verification under the auspices of this PEP.

>From the discussion so far, that seems like the smart thing to do.

Cheers,

Dirkjan
___
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] externals?

[Benjamin Peterson]

2012/11/13 Benjamin Peterson :
> Their still in svn as far I know.

s/Their/They're


-- 
Regards,
Benjamin
___
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] [Distutils] [Catalog-sig] accept the wheel PEPs 425, 426, 427

[Ronald Oussoren]

On 13 Nov, 2012, at 16:00, Daniel Holth  wrote:
> 
> I want to remove distutils from the standard library.

Why? Distutils may not be perfect, but is usable for basic packages. It could 
even be enhanced to support these peps and be even more useable, although 
patches for that would run into the self-imposed freeze of distutils 
development.

Ronald
___
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] [Distutils] [Catalog-sig] accept the wheel PEPs425, 426, 427

[Daniel Holth]

Setuptools! You would avoid 75% of pypi. It is nonsense to pretend that
setuptools is not a significant packaging innovation. Its main flaw is that
it is based on distutils, a non-extensible design. distutils2 is a lot of
setuptools and distutils code with the plug-ability taken out.

Perhaps I should say that I would like distutils to become as relevant to
packaging as the cgi module is to web development. It is not a short-term
goal.
___
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] [Distutils] [Catalog-sig] accept the wheel PEPs 425, 426, 427

[Daniel Holth]

The signatures section is now just:

+If JSON web signatures are used, one or more JSON Web Signature JSON
+Serialization (JWS-JS) signatures may be stored in a file RECORD.jws
+adjacent to RECORD.  JWS is used to sign RECORD by including the SHA-256
+hash of RECORD as the JWS payload::

 { "hash": "sha256=ADD-r2urObZHcxBW3Cr-vDCu5RJwT4CaRTHiFmbcIYY" }

+If RECORD.p7s is used, it must contain a PKCS#7 format signature of
+RECORD.
+
+A wheel installer may assume that the signature has already been checked
+against RECORD, and only must verify the hashes in RECORD against the
+extracted file contents.

FAQ

+Why does wheel include attached signatures?
+Attached signatures are more convenient than detached signatures
+because they travel with the archive.  Since only the individual files
+are signed, the archive can be recompressed without invalidating
+the signature, or individual files can be verified without having
+to download the whole archive.
___
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] [Distutils] [Catalog-sig] accept the wheel PEPs425, 426, 427

[a.cavallo]

+1 
Distutils is good enough: it could be better but for what is required
(essentially copying files and creating packages installers) is fine. The only
corner case is an absolute pain in the neck is in the cross compile scenario.

Currently I don't have *any* need for "auto" tools (setuptools and descendants).
As an example I always advice to avoid like a plague anything that depends on
setuptools... with all the due respect I think is the poor's developer attempt 
to
play the sys admin game.

Even virtual env is a poor work around on the python interpreter not being
relocatable (as in a portable app fashion).

thanks


On Tue 13/11/12 16:10, "Ronald Oussoren" ronaldousso...@mac.com wrote:
> 
> On 13 Nov, 2012, at 16:00, Daniel Holth  .com> wrote:
> 
> > I want to remove distutils from the standard
> library.
> Why? Distutils may not be perfect, but is usable for basic packages. It
> could even be enhanced to support these peps and be even more useable,
> although patches for that would run into the self-imposed freeze of
> distutils development.
> Ronald
> ___
> Distutils-SIG maillist  -  distutils-...@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
> 
> 


___
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] [Distutils] [Catalog-sig] accept the wheel PEPs425, 426, 427

[a.cavallo]

I'll give you that number(?) but ...

mercurial, docutils, jinjia2 pygments, sphinx, lxml, nose, cherrypy, django, 
pyqt ...
all they don't need/use setuptools: that 25% left is quite an interesting field
to play in.

If setuptools was "significant packaging innovation" do you think people 
wouldn't
have embraced already?
Allow me to call *that* a nonsense.

thanks 

ps. my experience is on the field, so please give me the credit of many years of
experience if I'm say I'm not that keen on "auto" tools: in this kiss rules.


On Tue 13/11/12 17:35, "Daniel Holth" dho...@gmail.com wrote:
> Setuptools! You would avoid 75% of pypi. It is nonsense to pretend
> that setuptools is not a significant packaging innovation. Its main
> flaw is that it is based on distutils, a non-extensible design.
> distutils2 is a lot of setuptools and distutils code with the
> plug-ability taken out.
> 
> Perhaps I should say that I would like distutils to become as
> relevant to packaging as the cgi module is to web development. It is
> not a short-term goal.
> 
> 


___
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] [Distutils] [Catalog-sig] accept the wheel PEPs425, 426, 427

[Maciej Fijalkowski]

On Tue, Nov 13, 2012 at 5:31 PM,   wrote:
>
> +1
> Distutils is good enough: it could be better but for what is required
> (essentially copying files and creating packages installers) is fine. The only
> corner case is an absolute pain in the neck is in the cross compile scenario.

I think you should qualify all such statements like "distutils is good
enough for *me*" and ideally also describe why exactly it's good
enough for you. Such blank statement does not bring anything to the
discussion (for example I could reply with "distutils is clearly not
good enough" and we're both right and we did not get anywhere).

For example distutils is absolutely *untestable* which makes it very
far from good enough for me.

Cheers,
fijal
___
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] [Distutils] [Catalog-sig] accept the wheel PEPs425, 426, 427

[Donald Stufft]

Distutils is not good enough for the vast majority of people. Even for what it 
does, it does not do it well. It is a library that is user hostile and buggy. 
It was
a fine first revision of packaging, but the Python community needs something
better.


On Tuesday, November 13, 2012 at 11:31 AM, a.cava...@cavallinux.eu wrote:

> 
> +1 
> Distutils is good enough: it could be better but for what is required
> (essentially copying files and creating packages installers) is fine. The only
> corner case is an absolute pain in the neck is in the cross compile scenario.
> 
> Currently I don't have *any* need for "auto" tools (setuptools and 
> descendants).
> As an example I always advice to avoid like a plague anything that depends on
> setuptools... with all the due respect I think is the poor's developer 
> attempt to
> play the sys admin game.
> 
> Even virtual env is a poor work around on the python interpreter not being
> relocatable (as in a portable app fashion).
> 
> thanks
> 
> 
> On Tue 13/11/12 16:10, "Ronald Oussoren" ronaldousso...@mac.com 
> (mailto:ronaldousso...@mac.com) wrote:
> > 
> > On 13 Nov, 2012, at 16:00, Daniel Holth  > .com> wrote:
> > 
> > > I want to remove distutils from the standard
> > library.
> > Why? Distutils may not be perfect, but is usable for basic packages. It
> > could even be enhanced to support these peps and be even more useable,
> > although patches for that would run into the self-imposed freeze of
> > distutils development.
> > Ronald
> > ___
> > Distutils-SIG maillist - distutils-...@python.org 
> > (mailto:distutils-...@python.org)
> > http://mail.python.org/mailman/listinfo/distutils-sig
> > 
> 
> 
> 
> ___
> Distutils-SIG maillist - distutils-...@python.org 
> (mailto:distutils-...@python.org)
> http://mail.python.org/mailman/listinfo/distutils-sig
> 
> 


___
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] [Catalog-sig] accept the wheel PEPs 425, 426, 427

[Martin v. Löwis]

Am 13.11.12 11:26, schrieb M.-A. Lemburg:

Note that signing such distribution files can be handled outside
of the wheel format PEP. It just way to complex and out of scope
for the wheel format itself. Also note that PGP/GPG and the other
signing tools work well on any distribution file. There's really no
need to build these into the format itself.


And even if the desire is to include the signature in the distribution
(as is common for code-signing - you want the signature in the 
executable, the jar file, etc), then it's still possible to include,

say, a PGP signature inside the file, which may well be a signature
to the manuscript, preserving the rest of the signing procedure.

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] [Catalog-sig] [Distutils] accept the wheel PEPs 425, 426, 427

[Martin v. Löwis]

I want to remove distutils from the standard library. If that happens
then we might want a secure way to install it from pypi. One way would
be to include the public key used to sign distutils in Python's own
signature-verifying bootstrap wheel installer, never mind whether it
used ECDSA or RSA or Ed25519. Do you have a better idea? TUF?
https://www.updateframework.com/wiki/SecuringPythonPackageManagement


It depends on the threat model - whose definition is key to any security
discussion.

I'd say that providing the CA certificate of the CA, and to use https
for downloading, should be enough.

Alternatively, if the threat is that somebody may have hacked PyPI,
then hard-code the hash (SHA-3 if you are paranoid) in the Python
distribution, and rely on downloading a specific version from PyPI.

OTOH, I'm -1 on removing the code from Python in a way that it may
come back through downloading. Instead, it is much easier to keep
it included.

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] [Distutils] [Catalog-sig] accept the wheel PEPs425, 426, 427

[Martin v. Löwis]

Am 13.11.12 17:45, schrieb Maciej Fijalkowski:

For example distutils is absolutely *untestable* which makes it very
far from good enough for me.


I never had issues with testing distutils applications. I use
"python setup.py sdist", then unpack the resulting source package,
install it, and run its test - if that passes, the packaging was
successful.

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] [Catalog-sig] [Distutils] accept the wheel PEPs 425, 426, 427

[Daniel Holth]

On Tue, Nov 13, 2012 at 12:23 PM, "Martin v. Löwis" wrote:

> I want to remove distutils from the standard library. If that happens
>> then we might want a secure way to install it from pypi. One way would
>> be to include the public key used to sign distutils in Python's own
>> signature-verifying bootstrap wheel installer, never mind whether it
>> used ECDSA or RSA or Ed25519. Do you have a better idea? TUF?
>> https://www.updateframework.**com/wiki/**SecuringPythonPackageManagemen**
>> t 
>>
>
> It depends on the threat model - whose definition is key to any security
> discussion.
>
> I'd say that providing the CA certificate of the CA, and to use https
> for downloading, should be enough.
>
> Alternatively, if the threat is that somebody may have hacked PyPI,
> then hard-code the hash (SHA-3 if you are paranoid) in the Python
> distribution, and rely on downloading a specific version from PyPI.
>
> OTOH, I'm -1 on removing the code from Python in a way that it may
> come back through downloading. Instead, it is much easier to keep
> it included.
>

It is a long term goal. It would be more practical to discourage distutils
and encourage users to look elsewhere (Bento) for a beautifully designed
build system.

The short term goal is just to standardize a way to install packages
without having a build system, which is what wheel is for apart from the
practical goal of simply installing lxml in a reasonable amount of time.

I think Metadata 1.2 (PEP 426) is ready to be accepted. The compatibility
tags (PEP 425) need some additional text in the discussion section, any
contributors for https://bitbucket.org/dholth/pep425tags/ ? Wheel (PEP 427)
might mention that version 1.0 of the spec is only concerned with
losslessly representing existing (setuptools & distutils) packages without
trying to add too many new features apart from a standardized .egg
substitute.

distutils itself is not testable.

Daniel Holth
___
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] [Distutils] accept the wheel PEPs 425, 426, 427

[Barry Warsaw]

I'm just beginning to review these PEPs and the threads, with an OS vendor
packager's eye.  Let me start with one small suggestion for PEP 425.

From the FAQ:

Q. Who will maintain the registry of abbreviated implementations?

A. New two-letter abbreviations can be requested on the python-dev mailing
   list. As a rule of thumb, abbreviations are reserved for the current 4 most
   prominent implementations.

I think the PEP should explicitly say that it will be the definitive keeper of
the abbreviations.  The request can be made on python-dev, and once approved,
PEP 425 will be updated with the new abbreviation.

Cheers,
-Barry


signature.asc
Description: 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] cpython (3.2): add gc_collects to weakref tests

[Antoine Pitrou]

On Tue, 13 Nov 2012 21:26:51 +0100 (CET)
philip.jenvey  wrote:
> http://hg.python.org/cpython/rev/a580cf4ab940
> changeset:   80418:a580cf4ab940
> branch:  3.2
> parent:  80397:8a28c974f903
> user:Philip Jenvey 
> date:Tue Nov 13 12:26:31 2012 -0800
> summary:
>   add gc_collects to weakref tests
> 
> files:
>   Lib/test/test_exceptions.py |  3 +++
>   1 files changed, 3 insertions(+), 0 deletions(-)

While this is necessary for non-refcounted implementations, it does
relax the requirement quite a bit for CPython (absence of reference
cycles can be a significant feature). I think perhaps gc_collect()
should be called only for non-CPython implementations.

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] [Catalog-sig] [Distutils] accept the wheel PEPs 425, 426, 427

[Ronald Oussoren]

On 13 Nov, 2012, at 17:21, Antoine Pitrou  wrote:

> Le Tue, 13 Nov 2012 16:10:30 +0100,
> Ronald Oussoren  a écrit :
>> 
>> On 13 Nov, 2012, at 16:00, Daniel Holth  wrote:
>>> 
>>> I want to remove distutils from the standard library.
>> 
>> Why? Distutils may not be perfect, but is usable for basic packages.
>> It could even be enhanced to support these peps and be even more
>> useable, although patches for that would run into the self-imposed
>> freeze of distutils development.
> 
> It wouldn't be totally unreasonable to start a project named
> "distutils2" to build the next-generation distutils library.
> 
> Oops :-)

Or carefully enhance distutils itself.  Rewriting distutils in one go seems
to be too ambitious with the limited resources available to do so. 

Ronald

___
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] [Distutils] [Catalog-sig] accept the wheel PEPs425, 426, 427

[Ronald Oussoren]

On 13 Nov, 2012, at 18:32, Martin v. Löwis  wrote:

> Am 13.11.12 17:45, schrieb Maciej Fijalkowski:
>> For example distutils is absolutely *untestable* which makes it very
>> far from good enough for me.
> 
> I never had issues with testing distutils applications. I use
> "python setup.py sdist", then unpack the resulting source package,
> install it, and run its test - if that passes, the packaging was
> successful.

I'm pretty sure he means testing distutils itself.  

I'm not convinced that distutils is untestable. A major problem with
distutils is that its API is barely documented, which effectly makes
all of it public API (simular to asyncore).  IIRC that's the main reason
why distutils is frozen right now: with a lot of changes to distutils people
started to complain that this could break there there distutils scripts.

The lack of a specification also makes testing harder, as it is unclear
what should be tested.

Ronald

___
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