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] Why is documentation not inline?
On 20.05.13 14:37, Serhiy Storchaka wrote: 20.05.13 01:33, Benjamin Peterson написав(ла): 2013/5/19 Demian Brecht demianbre...@gmail.com: It seems like external docs is standard throughout the stdlib. Is there an actual reason for this? ernal One is legacy. It certainly wasn't possible with the old LaTeX doc system. Do you know that TeX itself written using a literate programming. TeX binary and the TeXbook are compiled from the same source. Separation of concerns and DRY - tension rising: Who wants to tangle and weave? Anyone :-?) All the best, Stefan ___ 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] More compact dictionaries with faster iteration
Hi Chris, On 15.05.13 13:32 Christian Tismer wrote: Hi Raymond, On 08.01.13 15:49, Maciej Fijalkowski wrote: On Mon, Dec 10, 2012 at 3:44 AM, Raymond Hettinger raymond.hettin...@gmail.com wrote: The current memory layout for dictionaries is unnecessarily inefficient. It has a sparse table of 24-byte entries containing the hash value, key pointer, and value pointer. ... What is the current status of this discussion? I'd like to know whether it is a considered alternative implementation. There is also a discussion in python-ideas right now where this alternative is mentioned, and I think especially for small dicts as **kwargs, it could be a cheap way to introduce order. Is this going on, somewhere? I'm quite interested on that. +1 I am also interested on the status. Many people seemed to have copied the recipe from the activestate site (was it?) but I wonder if it maybe was to cool to be progressed into the field or simply some understandable lack of resources? All the best, Stefan ___ 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] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info
Hi Ben, Am 13.05.13 14:25, schrieb Ben Hoyt: ...It's not yet production-ready, and is basically still in API and performance testing stage. ... In any case, I really like the API (thanks mostly to Nick Coghlan), and performance is great, even with DirEntry being written in Python. PERFORMANCE: On Windows I'm seeing that scandir.walk() on a large test tree (see benchmark.py) is 8-9 times faster than os.walk(), and on Linux it's 3-4 times faster. Yes, it is that much faster, and yes, those numbers are real. :-) Please critique away. At this stage it'd be most helpful to critique any API or performance-related issues ... you asked for critique, but the performance seems to be also 2-3 times speedup (as stated by benchmark.py) on mac osx 10.8.3 (on MacBook Pro 13 inch, start of 2011, solid state disk) with python 2.7.4 (the homebrew one): $ git clone git://github.com/benhoyt/scandir.git $ cd scandir python setup.py install $ python benchmark.py USING FAST C version Creating tree at benchtree: depth=4, num_dirs=5, num_files=50 Priming the system's cache... Benchmarking walks on benchtree, repeat 1/3... Benchmarking walks on benchtree, repeat 2/3... Benchmarking walks on benchtree, repeat 3/3... os.walk took 0.104s, scandir.walk took 0.031s -- 3.3x as fast $ python benchmark.py -s USING FAST C version Priming the system's cache... Benchmarking walks on benchtree, repeat 1/3... Benchmarking walks on benchtree, repeat 2/3... Benchmarking walks on benchtree, repeat 3/3... os.walk size 226395000, scandir.walk size 226395000 -- equal os.walk took 0.246s, scandir.walk took 0.125s -- 2.0x as fast So for now, all well and thank you. All the best, Stefan. ___ 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
