I've run into the necessity of implementing chunks() again. Here is
the code I've made from scratch.
def chunks(seq, size):
'''Cut sequence into chunks of given size. If `seq` length is
not divisible by `size` without reminder, last chunk will
have length less than size.
>>> list
"Martin v. Löwis" writes:
> Unfortunately, this conflicts with the desire to use UTF-8 in attribute
> values - RFC 822 (and also 2822) don't support this, but require the
> use oF MIME instead (Q or B encoding).
This can be achieved simply by extending the set of characters
permitted, as MIME
On Fri, Aug 31, 2012 at 12:49 PM, Antoine Pitrou wrote:
> On Fri, 31 Aug 2012 17:52:38 +0200 (CEST)
> brett.cannon wrote:
> > http://hg.python.org/benchmarks/rev/873baf08045e
> > changeset: 162:873baf08045e
> > user:Brett Cannon
> > date:Fri Aug 31 11:52:30 2012 -0400
> > summa
On Fri, Aug 31, 2012 at 12:53 PM, R. David Murray wrote:
> On Fri, 31 Aug 2012 12:18:05 -0400, Daniel Holth wrote:
>> Some edits to include / and remove rfc822 again. What is the right
>> email.policy.Policy()?
>
> When I discussed using email to parse metadata with Tarek a long time
> ago, I tho
On Fri, 31 Aug 2012 17:52:38 +0200 (CEST)
brett.cannon wrote:
> http://hg.python.org/benchmarks/rev/873baf08045e
> changeset: 162:873baf08045e
> user:Brett Cannon
> date:Fri Aug 31 11:52:30 2012 -0400
> summary:
> Pathlib works under Python 3.
... but therefore you shouldn't
On Fri, 31 Aug 2012 12:18:05 -0400, Daniel Holth wrote:
> Some edits to include / and remove rfc822 again. What is the right
> email.policy.Policy()?
When I discussed using email to parse metadata with Tarek a long time
ago, I thought he was going to move to using a delimiter-substitution
algorit
Some edits to include / and remove rfc822 again. What is the right
email.policy.Policy()?
https://bitbucket.org/dholth/python-peps/changeset/8ec6dd453ccbde6d34c63d2d2a18393bc70cf115
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
ACTIVITY SUMMARY (2012-08-24 - 2012-08-31)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3653 (+13)
closed 23955 (+41)
total 27608 (+54)
Open issues wit
Am 31.08.12 15:57, schrieb Nick Coghlan:
However, also +1 on using "/" as the extension separator to avoid
ambiguity in field names, as well as restoring the explicit
requirement that metadata entries use valid RFC 822 metasyntax.
Unfortunately, this conflicts with the desire to use UTF-8 in at
On Fri, Aug 31, 2012 at 10:41 PM, R. David Murray wrote:
> It also allows for typo detection, which automatically interpreting
> prefix strings as extensions names would not.
+1 on retaining the explicit extension field, mainly for the
cross-validation benefits (including easily checking which ex
On Fri, Aug 31, 2012 at 8:24 PM, "Martin v. Löwis" wrote:
> So by default, all new functions should be internal API (static if
> possible), until somebody has explicitly considered use cases and
> considered what kind of stability can be guaranteed for the API.
The other aspect we're conscious of
On Fri, 31 Aug 2012 07:01:17 -0400, Daniel Holth wrote:
> On Aug 31, 2012, at 6:54 AM, Donald Stufft wrote:
> > Unless i'm mistaken (which I may be!) I believe that a / can be used as
> > the separator between the namespace and the "real" key.
> >
> > Home-page: http://www.python.org
> > Extensi
On Fri, Aug 31, 2012 at 3:43 AM, Gregory P. Smith wrote:
> We have use for _PyBytes_Join in an extension module but technically it
> isn't a public Python C API... anyone know why?
>
> PyUnicode_Join is.
>
> Looking up the bytes 'join' method and using the C API to call that method
> object with
Am 31.08.12 12:56, schrieb Daniel Holth:
1. -1 on "tolerant decoding". I think the format should clearly specify
what fields are text (I think most of them are), and mandate that
they be in UTF-8. If there is a need for binary data, they should be
specified to be in base64 encoding (but
Am 31.08.12 12:54, schrieb Donald Stufft:
On Friday, August 31, 2012 at 6:48 AM, "Martin v. Löwis" wrote:
3. There should be a specification of how collisions between extension
fields and standard fields are resolved. E.g. if I have
Extension: Home
Home-page:http://www.python.org
is Home-page
On Aug 31, 2012, at 6:54 AM, Donald Stufft wrote:
> On Friday, August 31, 2012 at 6:48 AM, "Martin v. Löwis" wrote:
>> 3. There should be a specification of how collisions between extension
>> fields and standard fields are resolved. E.g. if I have
>>
>> Extension: Home
>> Home-page: http://ww
On Aug 31, 2012, at 6:48 AM, "Martin v. Löwis" wrote:
> Am 31.08.12 05:16, schrieb Daniel Holth:
>> After this discussion it seemed wiser to submit my proposed 1.2 edits
>> as Metadata 1.3, adding Provides-Extra, Setup-Requires-Dist, and
>> Extension (with no defined registration procedure).
>
On Friday, August 31, 2012 at 6:48 AM, "Martin v. Löwis" wrote:
> 3. There should be a specification of how collisions between extension
> fields and standard fields are resolved. E.g. if I have
>
> Extension: Home
> Home-page: http://www.python.org
>
> is Home-page the extension field or the P
Am 31.08.12 05:16, schrieb Daniel Holth:
After this discussion it seemed wiser to submit my proposed 1.2 edits
as Metadata 1.3, adding Provides-Extra, Setup-Requires-Dist, and
Extension (with no defined registration procedure).
Thanks for doing this. A few comments:
1. -1 on "tolerant decoding
Am 31.08.12 03:43, schrieb Gregory P. Smith:
We have use for _PyBytes_Join in an extension module but technically it
isn't a public Python C API... anyone know why?
API minimalism. No API should be public unless somebody can demonstrate
an actual use case.
The Unicode API of Python 2.0 had a s
20 matches
Mail list logo
