On Thu, Oct 11, 2012 at 1:36 PM, Vinay Sajip wrote:
> Daniel Holth gmail.com> writes:
>
>> How does this compare to the markerlib approach? In markerlib you just
>> make sure all the AST nodes are in a set of allowed nodes, currently
>> (Compare, BoolOp, Attribute, Name, Load, Str, cmpop, boolop)
On 10/18/2012 03:16 PM, Daniel Holth wrote:
> On Thu, Oct 11, 2012 at 1:36 PM, Vinay Sajip wrote:
>> Daniel Holth gmail.com> writes:
>>
>>> How does this compare to the markerlib approach? In markerlib you just
>>> make sure all the AST nodes are in a set of allowed nodes, currently
>>> (Compare,
I'd like to submit the Wheel PEPs 425 (filename metadata), 426
(Metadata 1.3), and 427 (wheel itself) for acceptance. The format has
been stable since May and we are preparing a patch to support it in
pip, but we need to earn consensus before including it in the most
widely used installer.
Wheel i
I'm -1 on the usage of ed25519 in PEP 427. While the PEP proposes to use JSON
Web signatures, this algorithm is not supported by the current JWS draft [1].
Instead, I suggest to use the ES256 algorithm from JWS, i.e. ECDSA with the
NIST P-256 curve and SHA-256. This has the advantage of using sta
2012/10/18 Daniel Holth :
> Let me know what I need to do to get it accepted, if anything needs to
> be added or revised, or, preferably, that it is awesome and you want
> to use it ASAP.
Traditionally, you send the peps to python-dev, so people can bikeshed inline.
--
Regards,
Benjamin
ISTM that some important information and some elaboration is missing
from PEP 425.
The PEP is currently silent on how exactly these "compatibility tags"
are combined
with the package name, and the file extension. This should be
specified, and preferably
some examples be given.
Regards,
Ma
I'd like to request that PEP 426 is extended to talk about the order
of fields.
In particular, for the Extension field, is it necessary that all
"additional tags"
follow immediately the respective Extension field?
I also request that RFC 2119 terminology is followed strictly. In particular,
t
Will add that the order is not significant. It is essentially a multidict.
On Thu, Oct 18, 2012 at 2:45 PM, wrote:
> I'd like to request that PEP 426 is extended to talk about the order of
> fields.
> In particular, for the Extension field, is it necessary that all "additional
> tags"
> follow i
On Thu, 18 Oct 2012 14:35:19 -0400
Benjamin Peterson wrote:
> 2012/10/18 Daniel Holth :
> > Let me know what I need to do to get it accepted, if anything needs to
> > be added or revised, or, preferably, that it is awesome and you want
> > to use it ASAP.
>
> Traditionally, you send the peps to p
On Thu, Oct 18, 2012 at 2:36 PM, wrote:
> ISTM that some important information and some elaboration is missing from
> PEP 425.
>
> The PEP is currently silent on how exactly these "compatibility tags" are
> combined
> with the package name, and the file extension. This should be specified, and
>
Zitat von Daniel Holth :
On Thu, Oct 18, 2012 at 2:36 PM, wrote:
ISTM that some important information and some elaboration is missing from
PEP 425.
The PEP is currently silent on how exactly these "compatibility tags" are
combined
with the package name, and the file extension. This should b
On Thu, Oct 18, 2012 at 2:21 PM, wrote:
> I'm -1 on the usage of ed25519 in PEP 427. While the PEP proposes to use
> JSON
> Web signatures, this algorithm is not supported by the current JWS draft
> [1].
>
> Instead, I suggest to use the ES256 algorithm from JWS, i.e. ECDSA with the
> NIST P-256
On Thu, Oct 18, 2012 at 3:10 PM, Antoine Pitrou wrote:
> On Thu, 18 Oct 2012 14:35:19 -0400
> Benjamin Peterson wrote:
>> 2012/10/18 Daniel Holth :
>> > Let me know what I need to do to get it accepted, if anything needs to
>> > be added or revised, or, preferably, that it is awesome and you want
On Thu, Oct 18, 2012 at 3:23 PM, wrote:
>
> Zitat von Daniel Holth :
>
>
>> On Thu, Oct 18, 2012 at 2:36 PM, wrote:
>>>
>>> ISTM that some important information and some elaboration is missing from
>>> PEP 425.
>>>
>>> The PEP is currently silent on how exactly these "compatibility tags" are
>>
2012/10/18 Daniel Holth :
> On Thu, Oct 18, 2012 at 3:10 PM, Antoine Pitrou wrote:
>> On Thu, 18 Oct 2012 14:35:19 -0400
>> Benjamin Peterson wrote:
>>> 2012/10/18 Daniel Holth :
>>> > Let me know what I need to do to get it accepted, if anything needs to
>>> > be added or revised, or, preferably
PEP: 425
Title: Compatibility Tags for Built Distributions
Version: $Revision$
Last-Modified: 07-Aug-2012
Author: Daniel Holth
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 27-Jul-2012
Python-Version: 3.4
Post-History: 8-Aug-2012
Abstract
This PEP specifies a ta
PEP: 426
Title: Metadata for Python Software Packages 1.3
Version: $Revision$
Last-Modified: $Date$
Author: Daniel Holth
Discussions-To: Distutils SIG
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 30 Aug 2012
Abstract
This PEP describes a mechanism for adding me
PEP: 427
Title: The Wheel Binary Package Format 0.1
Version: $Revision$
Last-Modified: $Date$
Author: Daniel Holth
Discussions-To:
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 20-Sep-2012
Post-History:
Abstract
This PEP describes a built-package format for Pyt
Hi,
I would like to know if there a reason for not using the hash of
(bytes or unicode) strings when comparing two objects and the hash of
the two objects was already been computed. Using the hash would speed
up comparaison of long strings when the two strings are different.
Something like:
On 19/10/12 12:03, Victor Stinner wrote:
Hi,
I would like to know if there a reason for not using the hash of
(bytes or unicode) strings when comparing two objects and the hash of
the two objects was already been computed. Using the hash would speed
up comparaison of long strings when the two st
2012/10/18 Victor Stinner :
> Hi,
>
> I would like to know if there a reason for not using the hash of
> (bytes or unicode) strings when comparing two objects and the hash of
> the two objects was already been computed. Using the hash would speed
> up comparaison of long strings when the two string
Added some notes about the (lack of) ordering.
The email module provides an ordered multidict interface to the data.
The first tag wins (if you improperly define Name: twice for example),
but the order of everything is preserved. We just don't need it,
except that it might be surprising to see you
On 2012-10-19 02:03, Victor Stinner wrote:
Hi,
I would like to know if there a reason for not using the hash of
(bytes or unicode) strings when comparing two objects and the hash of
the two objects was already been computed. Using the hash would speed
up comparaison of long strings when the two
Executive summary:
You probably should include a full ABNF grammar
Daniel Holth writes:
> To support empty lines and lines with indentation with respect to
> the RFC 822 format, any CRLF character has to be suffixed by 7 spaces
> followed by a pipe ("|") char. [...]
> This encoding impli
With the 3.4 release PEP published using a traditional schedule,
perhaps MvL would care to do the honours as BDFL-Delegate in rejecting
the two "faster release cycle for the standard library" PEPs?
(I know I asked to hold off on that when MvL last brought it up, but
I've since realised that "do th
On Thu, Oct 18, 2012 at 10:55 PM, Stephen J. Turnbull
wrote:
> Executive summary:
>
> You probably should include a full ABNF grammar
>
> Daniel Holth writes:
>
> > To support empty lines and lines with indentation with respect to
> > the RFC 822 format, any CRLF character has to be suffixed
26 matches
Mail list logo
