Re: [Python-Dev] doctest and pickle
On 08/06/13 15:18, Stephen J. Turnbull wrote: Ethan Furman writes: Enumerations can be pickled and unpickled:: from enum import Enum class Fruit(Enum): ... tomato = 1 ... banana = 2 ... cherry = 3 ... from pickle import dumps, loads Fruit.tomato is loads(dumps(Fruit.tomato)) True [...] Still, it would be nice if this could work. Well, you could cheat and reverse the test. ;-) I assume the problem is that loads proceeds to recreate the Fruit enum, rather than checking if there already is one? I don't believe so. I understand that the problem is that pickle cannot find the Fruit enum in the __main__ module. Untested, but adding this before the call to dumps might work: import __main__ __main__.Fruit = Fruit although that's the sort of thing that makes me think it's time to turn this into a unittest rather than a doctest. -- Steven ___ 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] doctest and pickle
On 06/07/2013 11:45 PM, Steven D'Aprano wrote: On 08/06/13 15:18, Stephen J. Turnbull wrote: Ethan Furman writes: Enumerations can be pickled and unpickled:: from enum import Enum class Fruit(Enum): ... tomato = 1 ... banana = 2 ... cherry = 3 ... from pickle import dumps, loads Fruit.tomato is loads(dumps(Fruit.tomato)) True [...] Still, it would be nice if this could work. Well, you could cheat and reverse the test. ;-) I assume the problem is that loads proceeds to recreate the Fruit enum, rather than checking if there already is one? I don't believe so. I understand that the problem is that pickle cannot find the Fruit enum in the __main__ module. Untested, but adding this before the call to dumps might work: import __main__ __main__.Fruit = Fruit although that's the sort of thing that makes me think it's time to turn this into a unittest rather than a doctest. Indeed, and it is already in several different ways. But it would be nice to have a pickle example in the docs that worked with doctest. I ended up doing what Barry did: from test.test_enum import Fruit from pickle import dumps, loads Fruit.tomato is loads(dumps(Fruit.tomato)) True -- ~Ethan~ ___ 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] Obsoleted RFCs
Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs. For example for updating RFC3548 to RFC4648 there is an issue #16995. 821: Simple Mail Transfer Protocol. (Obsoleted by RFC2821) Lib/smtpd.py Lib/smtplib.py 822: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES. (Obsoleted by RFC2822) Doc/library/email-examples.rst Doc/library/email.rst Doc/library/imaplib.rst Lib/configparser.py Lib/email/_header_value_parser.py Lib/email/_parseaddr.py Lib/email/header.py Lib/imaplib.py Lib/test/test_email/data/msg_16.txt Lib/test/test_email/test_email.py Lib/test/test_http_cookiejar.py 850: Standard for interchange of USENET messages. (Obsoleted by RFC1036) Lib/email/_parseaddr.py 977: Network News Transfer Protocol. (Obsoleted by RFC3977) Lib/nntplib.py Lib/test/test_nntplib.py 1036: Standard for interchange of USENET messages. (Obsoleted by RFC5536, RFC5537) rfcuse.txt 1521: MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. (Obsoleted by RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) Lib/base64.py Lib/quopri.py 1522: MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text. (Obsoleted by RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) Doc/library/binascii.rst Lib/quopri.py 1738: Uniform Resource Locators (URL). (Obsoleted by RFC4248, RFC4266) Lib/urllib/parse.py 1750: Randomness Recommendations for Security. (Obsoleted by RFC4086) Doc/library/ssl.rst Modules/_ssl.c 1766: Tags for the Identification of Languages. (Obsoleted by RFC3066, RFC3282) Lib/locale.py 1808: Relative Uniform Resource Locators. (Obsoleted by RFC3986) Lib/test/test_urlparse.py Lib/urllib/parse.py 1869: SMTP Service Extensions. (Obsoleted by RFC2821) Lib/smtpd.py Lib/smtplib.py 1894: An Extensible Message Format for Delivery Status Notifications. (Obsoleted by RFC3464) Lib/test/test_email/test_email.py 2048: Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. (Obsoleted by RFC4288, RFC4289) rfcuse.txt 2060: Internet Message Access Protocol - Version 4rev1. (Obsoleted by RFC3501) Lib/imaplib.py 2068: Hypertext Transfer Protocol -- HTTP/1.1. (Obsoleted by RFC2616) Lib/http/cookies.py Lib/urllib/request.py 2069: An Extension to HTTP : Digest Access Authentication. (Obsoleted by RFC2617) Lib/urllib/request.py 2070: Internationalization of the Hypertext Markup Language. (Obsoleted by RFC2854) Lib/html/entities.py 2109: HTTP State Management Mechanism. (Obsoleted by RFC2965) Doc/library/http.cookiejar.rst Lib/http/cookiejar.py Lib/http/cookies.py Lib/test/test_http_cookiejar.py 2133: Basic Socket Interface Extensions for IPv6. (Obsoleted by RFC2553) Modules/getaddrinfo.c Modules/getnameinfo.c 2292: Advanced Sockets API for IPv6. (Obsoleted by RFC3542) Modules/socketmodule.c 2373: IP Version 6 Addressing Architecture. (Obsoleted by RFC3513) Lib/ipaddress.py 2396: Uniform Resource Identifiers (URI): Generic Syntax. (Obsoleted by RFC3986) Lib/http/cookiejar.py Lib/test/test_urllib.py Lib/test/test_urlparse.py Lib/urllib/parse.py 2434: Guidelines for Writing an IANA Considerations Section in RFCs. (Obsoleted by RFC5226) rfc3454.txt 2440: OpenPGP Message Format. (Obsoleted by RFC4880) Lib/test/test_email/data/msg_45.txt 2487: SMTP Service Extension for Secure SMTP over TLS. (Obsoleted by RFC3207) Lib/smtplib.py 2518: HTTP Extensions for Distributed Authoring -- WEBDAV. (Obsoleted by RFC4918) Doc/library/http.client.rst 2553: Basic Socket Interface Extensions for IPv6. (Obsoleted by RFC3493) Modules/addrinfo.h Modules/socketmodule.c rfcuse.txt 2554: SMTP Service Extension for Authentication. (Obsoleted by RFC4954) Lib/smtplib.py 2718: Guidelines for new URL Schemes. (Obsoleted by RFC4395) Lib/http/cookiejar.py 2732: Format for Literal IPv6 Addresses in URL's. (Obsoleted by RFC3986) Lib/test/test_urlparse.py Lib/urllib/parse.py 2821: Simple Mail Transfer Protocol. (Obsoleted by RFC5321) Lib/smtplib.py rfcuse.txt 2822: Internet Message Format. (Obsoleted by RFC5322) Doc/tutorial/stdlib.rst Lib/email/_header_value_parser.py Lib/email/_parseaddr.py Lib/email/feedparser.py Lib/email/generator.py Lib/email/header.py Lib/email/message.py Lib/email/mime/message.py Lib/email/parser.py Lib/email/utils.py Lib/http/client.py Lib/smtplib.py Lib/test/test_email/data/msg_35.txt Lib/test/test_email/test_email.py rfcuse.txt 3066: Tags for the Identification of Languages. (Obsoleted by RFC4646, RFC4647) rfcuse.txt 3171: IANA Guidelines for IPv4 Multicast Address
Re: [Python-Dev] doctest and pickle
08.06.13 10:03, Ethan Furman написав(ла): Indeed, and it is already in several different ways. But it would be nice to have a pickle example in the docs that worked with doctest. I ended up doing what Barry did: from test.test_enum import Fruit from pickle import dumps, loads Fruit.tomato is loads(dumps(Fruit.tomato)) True I think that the documentation is there for people. If you need tests, add them separately, but the documentation should be clear and understandable. In this case it is better to exclude a code example from doctests or add auxiliary code (i.e. as Steven suggested) to pass the doctest. ___ 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] Obsoleted RFCs
2013/6/8 Serhiy Storchaka storch...@gmail.com: Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs. Just because you change the reference, doesn't mean the code is automatically compliant with the updated RFC. :) For example for updating RFC3548 to RFC4648 there is an issue #16995. -- 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] Obsoleted RFCs
On 08.06.2013 09:45, Serhiy Storchaka wrote: Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs. Thanks for creating such a list. BTW: What is rfcuse.txt that's mentioned several times in the list ? For example for updating RFC3548 to RFC4648 there is an issue #16995. Given that more recent RFCs tend to introduce new functionality and sometimes backwards incompatible changes, I think each RFC update would need to be handled in a separate ticket. Some updates could probably be done in one go, e.g. RFC 821 - 2821 - 5321 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 08 2013) 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/ 2013-07-01: EuroPython 2013, Florence, Italy ... 23 days to go 2013-07-16: Python Meeting Duesseldorf ... 38 days to go : Try our 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] Obsoleted RFCs
08.06.13 11:23, Benjamin Peterson написав(ла): 2013/6/8 Serhiy Storchaka storch...@gmail.com: Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs. Just because you change the reference, doesn't mean the code is automatically compliant with the updated RFC. :) Of course. Maintainers should review his modules and conclude what should be made for supporting more modern RFCs. I'm surprised that even new ipaddress module uses obsoleted RFC. ___ 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] doctest and pickle
On 06/08/2013 01:07 AM, Serhiy Storchaka wrote: 08.06.13 10:03, Ethan Furman написав(ла): Indeed, and it is already in several different ways. But it would be nice to have a pickle example in the docs that worked with doctest. I ended up doing what Barry did: from test.test_enum import Fruit from pickle import dumps, loads Fruit.tomato is loads(dumps(Fruit.tomato)) True I think that the documentation is there for people. I agree. If you need tests, add them separately, I have. but the documentation should be clear and understandable. And the example code should be testable. In this case it is better to exclude a code example from doctests or add auxiliary code (i.e. as Steven suggested) to pass the doctest. Are you saying there is something wrong about what I have in place now? I would think that one line showing something you might actually do (importing an Enum from another module) is better than two lines showing esoteric workarounds (importing __main__ and setting an attribute on it). Apologies if I sound gruff -- it's way past my bedtime. In fact, I'll think I'll go sleep now. :) -- ~Ethan~ ___ 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] Obsoleted RFCs
08.06.13 11:42, M.-A. Lemburg написав(ла): On 08.06.2013 09:45, Serhiy Storchaka wrote: Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs. Thanks for creating such a list. BTW: What is rfcuse.txt that's mentioned several times in the list ? Oh, sorry. It is here by mistake. Just ignore it. For example for updating RFC3548 to RFC4648 there is an issue #16995. Given that more recent RFCs tend to introduce new functionality and sometimes backwards incompatible changes, I think each RFC update would need to be handled in a separate ticket. Some updates could probably be done in one go, e.g. RFC 821 - 2821 - 5321 Of course. This list is only a start point. ___ 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] Obsoleted RFCs
By mistake some local files were added to the list. Here's an updated list. It now also contains low-case references. Attached also a script used to generate this list. 3: Documentation conventions. (Obsoleted by RFC0010) Lib/test/math_testcases.txt 10: Documentation conventions. (Obsoleted by RFC0016) Lib/test/math_testcases.txt 11: Implementation of the Host - Host Software Procedures in GORDO. (Obsoleted by RFC0033) Lib/test/math_testcases.txt 821: Simple Mail Transfer Protocol. (Obsoleted by RFC2821) Lib/smtpd.py Lib/smtplib.py 822: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES. (Obsoleted by RFC2822) Doc/distutils/apiref.rst Doc/library/email-examples.rst Doc/library/email.iterators.rst Doc/library/email.message.rst Doc/library/email.mime.rst Doc/library/email.parser.rst Doc/library/email.rst Doc/library/imaplib.rst Doc/whatsnew/2.2.rst Doc/whatsnew/2.4.rst Lib/configparser.py Lib/distutils/dist.py Lib/distutils/tests/test_util.py Lib/distutils/util.py Lib/email/_header_value_parser.py Lib/email/_parseaddr.py Lib/email/feedparser.py Lib/email/generator.py Lib/email/header.py Lib/email/message.py Lib/email/mime/message.py Lib/email/utils.py Lib/imaplib.py Lib/mimetypes.py Lib/test/test_email/data/msg_05.txt Lib/test/test_email/data/msg_06.txt Lib/test/test_email/data/msg_11.txt Lib/test/test_email/data/msg_16.txt Lib/test/test_email/data/msg_25.txt Lib/test/test_email/data/msg_28.txt Lib/test/test_email/data/msg_42.txt Lib/test/test_email/data/msg_43.txt Lib/test/test_email/data/msg_46.txt Lib/test/test_email/test_defect_handling.py Lib/test/test_email/test_email.py Lib/test/test_email/torture_test.py Lib/test/test_http_cookiejar.py Tools/scripts/mailerdaemon.py 850: Standard for interchange of USENET messages. (Obsoleted by RFC1036) Lib/email/_parseaddr.py Lib/http/cookiejar.py Lib/test/test_http_cookiejar.py 931: Authentication server. (Obsoleted by RFC1413) Lib/http/server.py 977: Network News Transfer Protocol. (Obsoleted by RFC3977) Lib/nntplib.py Lib/test/test_nntplib.py 1521: MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. (Obsoleted by RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) Lib/base64.py Lib/quopri.py Modules/binascii.c 1522: MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text. (Obsoleted by RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) Doc/library/binascii.rst Lib/quopri.py 1738: Uniform Resource Locators (URL). (Obsoleted by RFC4248, RFC4266) Lib/urllib/parse.py 1750: Randomness Recommendations for Security. (Obsoleted by RFC4086) Doc/library/ssl.rst Modules/_ssl.c 1766: Tags for the Identification of Languages. (Obsoleted by RFC3066, RFC3282) Lib/locale.py 1808: Relative Uniform Resource Locators. (Obsoleted by RFC3986) Lib/test/test_urlparse.py Lib/urllib/parse.py 1869: SMTP Service Extensions. (Obsoleted by RFC2821) Lib/smtpd.py Lib/smtplib.py 1894: An Extensible Message Format for Delivery Status Notifications. (Obsoleted by RFC3464) Lib/test/test_email/test_email.py 2060: Internet Message Access Protocol - Version 4rev1. (Obsoleted by RFC3501) Lib/imaplib.py 2068: Hypertext Transfer Protocol -- HTTP/1.1. (Obsoleted by RFC2616) Lib/http/cookies.py Lib/urllib/request.py 2069: An Extension to HTTP : Digest Access Authentication. (Obsoleted by RFC2617) Lib/urllib/request.py 2070: Internationalization of the Hypertext Markup Language. (Obsoleted by RFC2854) Lib/html/entities.py 2109: HTTP State Management Mechanism. (Obsoleted by RFC2965) Doc/library/http.cookiejar.rst Lib/http/cookiejar.py Lib/http/cookies.py Lib/test/test_http_cookiejar.py 2133: Basic Socket Interface Extensions for IPv6. (Obsoleted by RFC2553) Modules/getaddrinfo.c Modules/getnameinfo.c 2279: UTF-8, a transformation format of ISO 10646. (Obsoleted by RFC3629) Lib/test/test_unicode.py 2292: Advanced Sockets API for IPv6. (Obsoleted by RFC3542) Modules/socketmodule.c 2368: The mailto URL scheme. (Obsoleted by RFC6068) Lib/test/test_urlparse.py Lib/urllib/parse.py 2373: IP Version 6 Addressing Architecture. (Obsoleted by RFC3513) Lib/ipaddress.py 2396: Uniform Resource Identifiers (URI): Generic Syntax. (Obsoleted by RFC3986) Lib/http/cookiejar.py Lib/test/test_urllib.py Lib/test/test_urlparse.py Lib/urllib/parse.py 2440: OpenPGP Message Format. (Obsoleted by RFC4880) Lib/test/test_email/data/msg_45.txt 2487: SMTP Service Extension for Secure SMTP over TLS. (Obsoleted by RFC3207) Lib/smtplib.py 2518: HTTP Extensions for Distributed Authoring -- WEBDAV. (Obsoleted by RFC4918) Doc/library/http.client.rst 2553: Basic Socket
Re: [Python-Dev] doctest and pickle
08.06.13 11:47, Ethan Furman написав(ла): In this case it is better to exclude a code example from doctests or add auxiliary code (i.e. as Steven suggested) to pass the doctest. Are you saying there is something wrong about what I have in place now? I would think that one line showing something you might actually do (importing an Enum from another module) is better than two lines showing esoteric workarounds (importing __main__ and setting an attribute on it). test.test_enum is not here. The reader should look into the external test module (which may not be supplied along with the module and documentation) to understand the example. Or rely on assumptions. Is it possible to add invisible code which doesn't displayed in the resulting documentation, but taken into account by doctest? ___ 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] Obsoleted RFCs
On 2013-06-08 10:59, Serhiy Storchaka wrote:
08.06.13 11:23, Benjamin Peterson ... :
2013/6/8 Serhiy Storchaka ... :
Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt,
*.py, *.c and *.h files. I think it would be worthwhile to update the
source
code and documentation for more modern RFCs.
Just because you change the reference, doesn't mean the code is
automatically compliant with the updated RFC. :)
Of course. Maintainers should review his modules and conclude what
should be made for supporting more modern RFCs.
I'm surprised that even new ipaddress module uses obsoleted RFC.
I for one am not :-) Let's pick that one ... as it seems to depend on
the perspective chosen (web docs vs. python code comments) (cf. Details)
Summary:
Besides the magic, that lies in the process that transforms the
documentation inside the python source into the web presented form, it
should be easy and semantically correct, to simply replace the two
occurences of RFC 3513 2.5.6 with RFC 4291 2.5.7.
Details:
The current web doc (3.4.0a0) at
http://docs.python.org/dev/library/ipaddress#ipaddress.IPv6Address
only shows this (no RFC3513 in sight):
The following constitutes a valid IPv6 address:
1. A string consisting of ... See RFC 4291 for details. ...
the current source at Lib/ipaddress.py you checked has:
# --- 8 - -- --- -- --- - --
class IPv6Network(_BaseV6, _BaseNetwork):
# ... snipped methods, reformatted, shortened ...
@property
def is_site_local(self):
Test if the address is reserved for site-local.
Note that the site-local address space has been
deprecated by RFC 3879.
Use is_private to test if this address is in the
space of unique local addresses as defined by RFC 4193.
Returns:
A boolean, True if the ad... is res... per RFC 3513 2.5.6.
sitelocal_network = IPv6Network('fec0::/10')
return self in sitelocal_network
# --- 8 - -- --- -- --- - --
and later:
# --- 8 - -- --- -- --- - --
class IPv6Network(_BaseV6, _BaseNetwork):
# ... again snipped methods, reformatted, shortened ...
@property
def is_site_local(self):
Test if the address is reserved for site-local.
Note that the site-local address space has been
deprecated by RFC 3879.
Use is_private to test if this address is in the
space of unique local addresses as defined by RFC 4193.
Returns:
A boolean, True if the ad... is res... per RFC 3513 2.5.6.
return (self.network_address.is_site_local and
self.broadcast_address.is_site_local)
# --- 8 - -- --- -- --- - --
The RFC 3513 (April 2003) has been obsoleted by RFC 4291 (February 2006)
and the latter has been updated by RFC 5952 (August 2010) and RFC 6052
(October 2010).
The given motivation for referencing inside the python source file is in
both cases the detailed specification of what a reserved address
actaully is.
Looking at RFC 3513 has at section 2.5.6 (the referenced one):
# --- 8 - -- --- -- --- - --
2.5.6 Local-Use IPv6 Unicast Addresses
There are two types of local-use unicast addresses defined. These
are Link-Local and Site-Local. The Link-Local is for use on a single
link and the Site-Local is for use in a single site. Link-Local
addresses have the following format:
| 10 |
| bits| 54 bits | 64 bits |
+--+-++
|111010| 0 | interface ID |
+--+-++
Link-Local addresses are designed to be used for addressing on a
single link for purposes such as automatic address configuration,
neighbor discovery, or when no routers are present.
Routers must not forward any packets with link-local source or
destination addresses to other links.
Site-Local addresses have the following format:
| 10 |
| bits| 54 bits | 64 bits|
+--+-++
|111011|subnet ID| interface ID |
+--+-++
Site-local addresses are designed to be used for addressing inside of
a site without the need for a global prefix. Although a subnet ID
may be up to 54-bits long, it is expected that globally-connected
sites will use the same subnet IDs for site-local and global
prefixes.
Routers must not forward any packets with site-local source or
destination addresses outside of the site.
# --- 8 - -- --- --
Re: [Python-Dev] Obsoleted RFCs
On Sat, 08 Jun 2013 12:51:23 +0300, Serhiy Storchaka storch...@gmail.com wrote: 08.06.13 11:42, M.-A. Lemburg напиÑав(ла): On 08.06.2013 09:45, Serhiy Storchaka wrote: Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs. Given that more recent RFCs tend to introduce new functionality and sometimes backwards incompatible changes, I think each RFC update would need to be handled in a separate ticket. Some updates could probably be done in one go, e.g. RFC 821 - 2821 - 5321 Of course. This list is only a start point. We've already done some (most?) of the work for the smtplib update. A thorough review is needed to make sure there aren't any leftovers and to update any comments and docs that haven't been fixed yet. For the email package, the support for RFC 5322 is mostly done, in the new policies. The legacy policies will continue to only support the older RFCs formally, though in many cases the code is also conformant with the newer RFCs because the relevant details have not changed. --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] doctest and pickle
On 06/08/2013 03:09 AM, Serhiy Storchaka wrote: 08.06.13 11:47, Ethan Furman написав(ла): In this case it is better to exclude a code example from doctests or add auxiliary code (i.e. as Steven suggested) to pass the doctest. Are you saying there is something wrong about what I have in place now? I would think that one line showing something you might actually do (importing an Enum from another module) is better than two lines showing esoteric workarounds (importing __main__ and setting an attribute on it). test.test_enum is not here. The reader should look into the external test module (which may not be supplied along with the module and documentation) to understand the example. Or rely on assumptions. Fair point. But I suppose that if the end-user is running a doc test, it is not too much to require that the other tests be installed as well. Plus, we definitely have the other tests. :) Is it possible to add invisible code which doesn't displayed in the resulting documentation, but taken into account by doctest? I have no idea. This is my first time using doctest. -- ~Ethan~ ___ 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] Obsoleted RFCs
Serhiy Storchaka writes: 08.06.13 11:23, Benjamin Peterson написав(ла): 2013/6/8 Serhiy Storchaka storch...@gmail.com: Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs. Just because you change the reference, doesn't mean the code is automatically compliant with the updated RFC. :) Of course. Maintainers should review his modules and conclude what should be made for supporting more modern RFCs. I suspect in many cases the answer is going to be nothing. Grepping out the references and checking for obsoleted RFCs is useful information, of course. Good GSoC fodder, for one thing. But I'd be cautious about even creating an issue without consideration of each case individually. This can be a *lot* of work, for very little gain. In the case of mail, consider that STD 11 still points to RFC 822![1] Also, even the most modern RFC 5322 REQUIREs parsers to accept the obsolete syntax of section 4, which I believe is that of RFC 822. In any case, it's pretty close. So you wouldn't want to change the parser anyway. Whether it would be worth auditing the generative functions for 5322 conformance, and creating tests, is a more difficult question, but it still sounds like much work for little gain. The analysis is surely different for other RFCs, but for this particular series I see little harm in letting each component of the email module continue to explicitly target whichever of the RFCs happened to be current when its author started coding. Footnotes: [1] http://tools.ietf.org/html/std11 ___ 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] doctest and pickle
On 6/8/13, Ethan Furman et...@stoneleaf.us wrote: On 06/08/2013 03:09 AM, Serhiy Storchaka wrote: 08.06.13 11:47, Ethan Furman написав(ла): [...] Fair point. But I suppose that if the end-user is running a doc test, it is not too much to require that the other tests be installed as well. Plus, we definitely have the other tests. :) Is it possible to add invisible code which doesn't displayed in the resulting documentation, but taken into account by doctest? I have no idea. This is my first time using doctest. ot No ... if using doctest . To get such things done you'll need something like dutest [1]_ [2]_ , but that's not an option for testing docs in stdlib . /ot .. [1] dutest @ PyPI (https://pypi.python.org/pypi/dutest) .. [2] Purpose of Doctests [Was: Best practices for Enum] (http://goo.gl/F7Afy) -- Regards, Olemis. Apache™ Bloodhound contributor http://issues.apache.org/bloodhound Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: ___ 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] doctest and pickle
On 8 June 2013 17:41, Ethan Furman et...@stoneleaf.us wrote: On 06/08/2013 03:09 AM, Serhiy Storchaka wrote: Is it possible to add invisible code which doesn't displayed in the resulting documentation, but taken into account by doctest? I have no idea. This is my first time using doctest. AFAIK, stdlib uses Sphinx, so you can provide a testsetup block[1]. At least if you're running them via Sphinx. [1]: http://sphinx-doc.org/ext/doctest.html -- Łukasz Rekucki ___ 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] doctest and pickle
On Sat, 08 Jun 2013 19:54:18 +0200, =?UTF-8?Q?=C5=81ukasz_Rekucki?= lreku...@gmail.com wrote: On 8 June 2013 17:41, Ethan Furman et...@stoneleaf.us wrote: On 06/08/2013 03:09 AM, Serhiy Storchaka wrote: Is it possible to add invisible code which doesn't displayed in the resulting documentation, but taken into account by doctest? I have no idea. This is my first time using doctest. AFAIK, stdlib uses Sphinx, so you can provide a testsetup block[1]. At least if you're running them via Sphinx. Running the doctests via Sphinx is still, I believe a Future Objective :). I think we are getting close to being able to do that, though. (Well, you already can for Python2; but not, I think, for Python3). If the test module from which you are importing is short, you could use the Sphinx literalinclude directive to include the contents of the file in the docs just before you show the 'is' example. You could also explain (briefly) *why* it is necessary to use an imported class for this example, which IMO is useful information. --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
[Python-Dev] Unicode minus sign in numeric conversions
Expected behaviour:
float('\N{MINUS SIGN}12.34')
-12.34
Current behaviour:
Traceback (most recent call last):
...
ValueError: could not convert string to float: '−12.34'
Please note: '\N{MINUS SIGN}' == '\u2212'
--
Best regards,
Łukasz Langa
WWW: http://lukasz.langa.pl/
Twitter: @llanga
IRC: ambv on #python-dev
___
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] Unicode minus sign in numeric conversions
[Diverting to python-ideas, since this isn't as clear-cut as you think.]
Why exactly is that expected behavior? What's the use case? (Surely
you don't have a keyboard that generates \u2212 when you hit the minus
key? :-)
Is there a Unicode standard for parsing numbers? IIRC there are a
variety of other things marked as digits in the Unicode standard --
do we do anything with those? If we do anything we should be
consistent. For now, I think we *are* consistent -- we only support
the ASCII representation of numbers. (And that's the only
representation we generate as output as well -- think about symmetry
too.)
This page scares me: http://en.wikipedia.org/wiki/Numerals_in_Unicode
--Guido
On Sat, Jun 8, 2013 at 2:49 PM, Łukasz Langa luk...@langa.pl wrote:
Expected behaviour:
float('\N{MINUS SIGN}12.34')
-12.34
Current behaviour:
Traceback (most recent call last):
...
ValueError: could not convert string to float: '−12.34'
Please note: '\N{MINUS SIGN}' == '\u2212'
--
Best regards,
Łukasz Langa
WWW: http://lukasz.langa.pl/
Twitter: @llanga
IRC: ambv on #python-dev
___
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/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
___
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] Unicode minus sign in numeric conversions
On 08/06/2013 23:30, Guido van Rossum wrote:
[Diverting to python-ideas, since this isn't as clear-cut as you think.]
Why exactly is that expected behavior? What's the use case? (Surely
you don't have a keyboard that generates \u2212 when you hit the minus
key? :-)
Is there a Unicode standard for parsing numbers? IIRC there are a
variety of other things marked as digits in the Unicode standard --
do we do anything with those? If we do anything we should be
consistent. For now, I think we *are* consistent -- we only support
the ASCII representation of numbers. (And that's the only
representation we generate as output as well -- think about symmetry
too.)
We already recognise at least some of the digits:
float(\N{ARABIC-INDIC DIGIT ONE})
1.0
(I haven't check all of them!)
This page scares me: http://en.wikipedia.org/wiki/Numerals_in_Unicode
--Guido
On Sat, Jun 8, 2013 at 2:49 PM, Łukasz Langa luk...@langa.pl wrote:
Expected behaviour:
float('\N{MINUS SIGN}12.34')
-12.34
Current behaviour:
Traceback (most recent call last):
...
ValueError: could not convert string to float: '−12.34'
Please note: '\N{MINUS SIGN}' == '\u2212'
___
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] Unicode minus sign in numeric conversions
On Sun, 09 Jun 2013 01:39:59 +0100, MRAB pyt...@mrabarnett.plus.com wrote:
On 08/06/2013 23:30, Guido van Rossum wrote:
[Diverting to python-ideas, since this isn't as clear-cut as you think.]
Why exactly is that expected behavior? What's the use case? (Surely
you don't have a keyboard that generates \u2212 when you hit the minus
key? :-)
Is there a Unicode standard for parsing numbers? IIRC there are a
variety of other things marked as digits in the Unicode standard --
do we do anything with those? If we do anything we should be
consistent. For now, I think we *are* consistent -- we only support
the ASCII representation of numbers. (And that's the only
representation we generate as output as well -- think about symmetry
too.)
We already recognise at least some of the digits:
float(\N{ARABIC-INDIC DIGIT ONE})
1.0
(I haven't check all of them!)
This page scares me: http://en.wikipedia.org/wiki/Numerals_in_Unicode
http://bugs.python.org/issue6632 contains a bunch of good information
relevant to this discussion. It looks like the argument there was
that there is no standard for the signs, therefore we should not
support them.
As Guido said, the issue is non-trivial.
--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] doctest and pickle
On 9 June 2013 04:17, R. David Murray rdmur...@bitdance.com wrote: On Sat, 08 Jun 2013 19:54:18 +0200, =?UTF-8?Q?=C5=81ukasz_Rekucki?= lreku...@gmail.com wrote: On 8 June 2013 17:41, Ethan Furman et...@stoneleaf.us wrote: On 06/08/2013 03:09 AM, Serhiy Storchaka wrote: Is it possible to add invisible code which doesn't displayed in the resulting documentation, but taken into account by doctest? I have no idea. This is my first time using doctest. AFAIK, stdlib uses Sphinx, so you can provide a testsetup block[1]. At least if you're running them via Sphinx. Running the doctests via Sphinx is still, I believe a Future Objective :). I think we are getting close to being able to do that, though. (Well, you already can for Python2; but not, I think, for Python3). If the test module from which you are importing is short, you could use the Sphinx literalinclude directive to include the contents of the file in the docs just before you show the 'is' example. You could also explain (briefly) *why* it is necessary to use an imported class for this example, which IMO is useful information. Right - for the singleton behaviour of enums to be honoured by pickle, the enum definition *must* be reachable through the import system based on its __name__ and __module__ attributes (PEP 3154 will eventually change that limitation to __qualname__ and __module__). The temporary namespaces created to run doctests generally aren't reachable that way, so the unpickling either fails or creates a new instance (depending on the details of the situation). Using the test suite in the enum docstrings initially is fine. In the future, once we migrate a module like socket to using enum.IntEnum instead of bare integers, it would be appropriate to change the enum docs to reference that rather than the test suite. 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] doctest and pickle
On 06/08/2013 09:21 PM, Nick Coghlan wrote: Using the test suite in the enum docstrings initially is fine. In the future, once we migrate a module like socket to using enum.IntEnum instead of bare integers, it would be appropriate to change the enum docs to reference that rather than the test suite. Good point. I'll keep that in mind. -- ~Ethan~ ___ 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
