Re: [Python-Dev] why is _PyBytes_Join not public but PyUnicode_Join is?
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 serious mistake in making dozens of functions public in the API. This broke twice in Python's history: once when UCS-4 became supported, and again for PEP 393. For the former, a work-around was possible by introducing macros, to support API compatibility while breaking ABI compatibility. For PEP 393, huge efforts were necessary to even preserve the API (and this only worked with limitations). 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. > Looking up the bytes 'join' method and using the C API to call that > method object with proper parameters seems like overkill in the case > where we're not dealing with user supplied byte strings at all. It's not really that difficult. Instead of r = PyBytes_Join(sep, x); you write r = PyObject_CallMethod(sep, "join", "O", x); This is just a few more letters to type. Or are you concerned with the runtime overhead that this causes? Don't be: the cost of actually joining is much higher than the cost of making the call. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
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". 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 I don't think any of the fields really are binary data). 2. The extensions section should discuss order. E.g. is it ok to write Chili-Type: Poblano Extension: Chili Platform: Basmati Extension: Garlic Chili-Heat: Mild Garlic-Size: 1tsp 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 PEP 345 field? There are several ways to resolve this; I suggest giving precedence to the standard field (unless you specify that extensions must follow all standard fields, in which case you can drop the extension prefix from the extension keys). 4. There needs to be a discusion of the meta-syntax. PEP 314 still mentioned that this is RFC 822; PEP 345 dropped that and didn't say anything about the syntax of fields (i.e. not even that they are key-value, that the colon is a separator, that the keys are case-insensitive, etc). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional ependencies)
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 PEP 345 field? There are > several ways to resolve this; I suggest giving precedence to the > standard field (unless you specify that extensions must follow all > standard fields, in which case you can drop the extension prefix > from the extension keys). > 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 Extension: Home Home/other-thing: Foo Doing this is the "Extension" field required?___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
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). > > Thanks for doing this. A few comments: > > 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 I don't think any of the > fields really are binary data). > Ok. If you want you can check the version to decide how strict you want to be. > 2. The extensions section should discuss order. E.g. is it ok to write > >Chili-Type: Poblano >Extension: Chili >Platform: Basmati >Extension: Garlic >Chili-Heat: Mild >Garlic-Size: 1tsp Ordering doesn't matter and collisions with existing tags are not allowed. > > 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 PEP 345 field? There are > several ways to resolve this; I suggest giving precedence to the > standard field (unless you specify that extensions must follow all > standard fields, in which case you can drop the extension prefix > from the extension keys). > > 4. There needs to be a discusion of the meta-syntax. PEP 314 still > mentioned that this is RFC 822; PEP 345 dropped that and didn't > say anything about the syntax of fields (i.e. not even that they > are key-value, that the colon is a separator, that the keys > are case-insensitive, etc). > I think the new profile support for email Parser will handle this perfectly. > Regards, > Martin > > > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional ependencies)
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://www.python.org >> >> is Home-page the extension field or the PEP 345 field? There are >> several ways to resolve this; I suggest giving precedence to the >> standard field (unless you specify that extensions must follow all >> standard fields, in which case you can drop the extension prefix >> from the extension keys). >> > 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 > Extension: Home > Home/other-thing: Foo > Not bad. > Doing this is the "Extension" field required? Yes it is required. A simple lookup for data ['extension'] tells you what to expect.___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional ependencies)
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 the extension field or the PEP 345 field? There are several ways to resolve this; I suggest giving precedence to the standard field (unless you specify that extensions must follow all standard fields, in which case you can drop the extension prefix from the extension keys). 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. What do you mean by "can be"? In RFC 822, a slash can be in a field-name, yes, but the PEPs recently became silent on the meta-syntax. Home-page: http://www.python.org Extension: Home Home/other-thing: Foo Doing this is the "Extension" field required? Well, in my example it would then be Home-page: http://www.python.org Home/page: Foo I don't think the Extension field is necessary if there is a promise that standard fields won't ever include slashes. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
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 I don't think any of the fields really are binary data). Ok. If you want you can check the version to decide how strict you want to be. Thanks for the offer - I'd prefer to remain as a reader, not an author of the PEP. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why is _PyBytes_Join not public but PyUnicode_Join is?
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 proper parameters seems like overkill in the case where we're > not dealing with user supplied byte strings at all. > > I wondered about the same thing a month ago - http://mail.python.org/pipermail/python-dev/2012-July/121031.html Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional ependencies)
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 > > Extension: Home > > Home/other-thing: Foo > > > > Not bad. > > > Doing this is the "Extension" field required? > > Yes it is required. A simple lookup for data ['extension'] tells you what to > expect. It also allows for typo detection, which automatically interpreting prefix strings as extensions names would not. -- R. David Murray If you like the work I do for Python, you can enable me to spend more time doing it by supporting me here: http://gittip.com/bitdancer ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why is _PyBytes_Join not public but PyUnicode_Join is?
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 these days is that folks like the IronClad and cpyext developers *are* making a concerted effort to emulate the full C API of CPython-the-runtime, not just implementing Python-the-language. External tools like Dave Malcolm's static analyser for gcc also need to be taught the refcounting semantics of any new API additions. So, unless there's a compelling reason for direct public access from C, the preferred option is to only expose the corresponding Python API via the general purpose APIs for calling back into Python from C extensions. This minimises the induced workload on other groups, as well as making future maintenance easier for CPython itself. New additions are still possible - they're just not the default any more. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional ependencies)
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 extension syntax is used by a module). 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. If the precise rules can be articulated as a 3.3 email module policy, so much the better. I've now pushed Daniel's latest draft as PEP 426. I added the following section on "Metadata Files", which restores some background info on the overall file format that went AWOL in v1.2: --- Metadata Files == The syntax defined in this PEP is for use with Python distribution metadata files. This file format is a single set of RFC-822 headers parseable by the ``rfc822`` or ``email`` modules. The field names listed in the `Fields`_ section are used as the header names. There are two standard locations for these metadata files: * the ``PKG-INFO`` file included in the base directory of Python source distribution archives (as created by the distutils ``sdist`` command) * the ``dist-info/METADATA`` files in a Python installation database, as described in PEP 376. Other tools involved in Python distribution may choose to record this metadata in additional tool-specific locations (e.g. as part of a binary distribution archive format). --- As far as I know, the sdist archive format isn't actually defined anywhere beyond "archives like those created by the distutils sdist command". Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional ependencies)
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 attribute values - RFC 822 (and also 2822) don't support this, but require the use oF MIME instead (Q or B encoding). RFC 2822 also has a continuation line semantics which traditionally conflicts with the metadata; in particular, line breaks cannot be represented (but are interpreted as continuation lines instead). OTOH, several of the metadata fields do require line breaks, in particular those formatted as ReST. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
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 with patches: 1621 Issues opened (37) == #15780: IDLE (windows) with PYTHONPATH and multiple python versions http://bugs.python.org/issue15780 opened by Jimbofbx #15782: Compile error for a number of Mac modules with recent Xcode http://bugs.python.org/issue15782 opened by ronaldoussoren #15783: decimal.localcontext(None) fails when using the C accelerator http://bugs.python.org/issue15783 opened by ncoghlan #15784: OSError.__str__() should distinguish between errno and winerro http://bugs.python.org/issue15784 opened by sbt #15785: curses.get_wch() returns keypad codes incorrectly http://bugs.python.org/issue15785 opened by simpkins #15786: IDLE code completion window does not scoll/select with mouse http://bugs.python.org/issue15786 opened by suddha.sourav #15787: PEP 3121 Refactoring http://bugs.python.org/issue15787 opened by belopolsky #15789: mention shell-like parts of the std lib in the subprocess docs http://bugs.python.org/issue15789 opened by cvrebert #15792: Fix compiler options for x64 builds on Windows http://bugs.python.org/issue15792 opened by jkloth #15793: Stack corruption in ssl.RAND_egd() http://bugs.python.org/issue15793 opened by storchaka #15795: Zipfile.extractall does not preserve file permissions http://bugs.python.org/issue15795 opened by uruz #15796: Fix readline() docstrings http://bugs.python.org/issue15796 opened by storchaka #15797: bdist_msi does not pass -install/remove flags to install_scrip http://bugs.python.org/issue15797 opened by braudel #15798: subprocess.Popen() fails if 0, 1 or 2 descriptor is closed http://bugs.python.org/issue15798 opened by sarum9in #15799: httplib client and statusline http://bugs.python.org/issue15799 opened by karlcow #15802: Nonsensical test for mailbox http://bugs.python.org/issue15802 opened by storchaka #15803: Incorrect docstring on ConfigParser.items() http://bugs.python.org/issue15803 opened by nbtrap #15805: Add stdout redirection tool to contextlib http://bugs.python.org/issue15805 opened by rhettinger #15806: Add context manager for the "try: ... except: pass" pattern http://bugs.python.org/issue15806 opened by rhettinger #15808: Possibility of setting custom key bindings for "Additional hel http://bugs.python.org/issue15808 opened by Rostyslav.Dzinko #15809: IDLE console uses incorrect encoding. http://bugs.python.org/issue15809 opened by alex.hartwig #15810: assertSequenceEqual should be fired when comparing sequence su http://bugs.python.org/issue15810 opened by flox #15811: ElementTree.write() raises TypeError when xml_declaration = Tr http://bugs.python.org/issue15811 opened by David.Buxton #15812: inspect.getframeinfo() cannot show first line http://bugs.python.org/issue15812 opened by sbt #15814: memoryview: equality-hash invariant http://bugs.python.org/issue15814 opened by skrah #15815: Add numerator to ZeroDivisionError messages http://bugs.python.org/issue15815 opened by terry.reedy #15817: Misc/gdbinit: Expose command documentation to gdb help http://bugs.python.org/issue15817 opened by belopolsky #15818: multiprocessing documentation of Process.exitcode http://bugs.python.org/issue15818 opened by schmiddy #15819: Unable to build Python out-of-tree when source tree is readonl http://bugs.python.org/issue15819 opened by trent #15820: Add additional info to Resources area on Dev Guide http://bugs.python.org/issue15820 opened by mikehoy #15821: Improve docs for PyMemoryView_FromBuffer() http://bugs.python.org/issue15821 opened by skrah #15822: Python 3.3 creates lib2to3 grammar in wrong order http://bugs.python.org/issue15822 opened by tpievila #15826: Increased test coverage of test_glob.py http://bugs.python.org/issue15826 opened by eng793 #15828: imp.load_module doesn't support C_EXTENSION type http://bugs.python.org/issue15828 opened by metolone #15829: Threading Lock - Wrong Exception Name http://bugs.python.org/issue15829 opened by mikehoy #15830: make -s no longer silences output from setup.py http://bugs.python.org/issue15830 opened by brett.cannon #15831: comma after leading optional argument is after bracket in docs http://bugs.python.org/issue15831 opened by cjerdonek Most recent 15 issues with no replies (15) == #15831: comma after leading optional argument is after bracket in docs http://bugs.python.org/issue15831 #15830: make -s no longer silences output from setup.py http://bugs.python.org/issue15830 #15826: Increased test coverage of test_glob.py http://bugs.python.org/issue15826 #15818: multiprocessing documentation of Process.exitcode http://bugs.python.org/issue15818 #15817
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional ependencies)
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional ependencies)
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 algorithm to encode and recover the line breaks. Perhaps that discussion wasn't in this same context, but I thought it was. If you did that, then 'SMTP' would be the correct policy for RFC2822/5322. But that isn't really going to work for this use case, even with the above hack. As Martin pointed out, RFC2822 does not allow utf-8 in the values. RFC 5335, which is Experimental, does. A medium term goal of the email package is to support that RFC, so this might be a motivation to move that higher in my feature priority list. (Support mostly involves switches to allow unicode/utf8 to be *written*; the parsing side works already, though it is not thoroughly tested.) However, all that aside, to answer your question you are really going to want to define a custom policy that derives from email.policy.Policy. Especially if you want to not follow the email RFCs and do want to assign meaning to the line separators. You can do that with a custom policy and thus still be able the use the email parsing infrastructure to read and write the files. I'll be glad to help out with creating the custom policy once we've reached that stage of the process. -- R. David Murray If you like the work I do for Python, you can enable me to spend more time doing it by supporting me here: http://gittip.com/bitdancer ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] benchmarks: Pathlib works under Python 3.
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 run it under 2to3 (which may pessimize the code). Benchmarks with a 3.x-compatible code base are listed under the "2n3" meta-benchmark name in perf.py: http://hg.python.org/benchmarks/file/873baf08045e/perf.py#l2000 Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional ependencies)
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 thought he was going to move to using a delimiter-substitution > algorithm to encode and recover the line breaks. Perhaps that discussion > wasn't in this same context, but I thought it was. If you did that, > then 'SMTP' would be the correct policy for RFC2822/5322. > > But that isn't really going to work for this use case, even with the above > hack. As Martin pointed out, RFC2822 does not allow utf-8 in the values. Thanks. For the time being I am happily using the surrogateescape/bytesgenerator hack and it preserves UTF-8 and linebreaks. I don't have a strong opinion about the line continuation policy; I do not have code that relies on parsing the long description from PKG-INFO files. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] benchmarks: Pathlib works under Python 3.
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 > > summary: > > Pathlib works under Python 3. > > ... but therefore you shouldn't run it under 2to3 (which may pessimize > the code). Benchmarks with a 3.x-compatible code base are listed under > the "2n3" meta-benchmark name in perf.py: > > http://hg.python.org/benchmarks/file/873baf08045e/perf.py#l2000 Right, but the code still needs to get copied over (which it wasn't). I'll start a new entry for code that needs to be copied but not translated. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional ependencies)
"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 did for message bodies. I'd be cautious about RFC 5335, not just because it's experimental, but because there may be other requirements we don't want to mess with. (If RDM says otherwise, listen to him. I just know the RFC exists.) > RFC 2822 also has a continuation line semantics which traditionally > conflicts with the metadata; in particular, line breaks cannot be > represented (but are interpreted as continuation lines instead). Of course line breaks can be represented, without any further change to RFC 2822. Just use Unicode LINE SEPARATOR. You could even do it within ASCII by adhering strictly to RFC 2822 syntax which interprets continuation lines by removing exactly the CRLF pair. Just use ASCII TAB as the field separator. There's a final dodge that occurs to me: the semantics you're talking about are *lexical* semantics in the RFC 2822 context (line unfolding and RFC 2047 decoding). We could possibly in the context of the email module treat Metadata as an intermediate post-lexical-decoding pre-syntactic-analysis representation. I don't know if that makes sense in the context of using email module facilities to parse Metadata. Steve ___ Python-Dev mailing list [email protected] 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-ideas] itertools.chunks(iterable, size, fill=None)
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( chunks([1,2,3,4,5,6,7], 3) ) [[1, 2, 3], [4, 5, 6], [7]] ''' endlen = len(seq)//size for i in range(endlen): yield [seq[i*size+n] for n in range(size)] if len(seq) % size: yield seq[endlen*size:] -- anatoly t. On Fri, Jun 29, 2012 at 11:32 PM, Georg Brandl wrote: > On 26.06.2012 10:03, anatoly techtonik wrote: >> >> Now that Python 3 is all about iterators (which is a user killer >> feature for Python according to StackOverflow - >> http://stackoverflow.com/questions/tagged/python) would it be nice to >> introduce more first class functions to work with them? One function >> to be exact to split string into chunks. >> >> itertools.chunks(iterable, size, fill=None) >> >> Which is the 33th most voted Python question on SO - >> >> http://stackoverflow.com/questions/312443/how-do-you-split-a-list-into-evenly-sized-chunks-in-python/312464 >> >> P.S. CC'ing to python-dev@ to notify about the thread in python-ideas. >> > > Anatoly, so far there were no negative votes -- would you care to go > another step and propose a patch? > > > Georg > > ___ > Python-ideas mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-ideas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
