A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/attachments/20120828/8088f146/attachment.html below:


                <div><span style="color: rgb(160, 160, 168); ">On Tuesday, August 28, 2012 at 10:43 AM, "Martin v. Löwis" wrote:</span></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><br></div><div>I'm happy for PyPI to host such a registry. A specificaion for the </div><div>registry should be part of the PEP for the 1.3 format, but I would </div><div>propose this structure (without having researched in detail what</div><div>other registries feature, but with a rough idea what IANA registries</div><div>typically include):</div></span></blockquote><div>PyPI packages itself could serve as a registry, but I like the idea of</div><div>a separate registry better in many ways because it lets you divorce</div><div>the namespace from the package. The question being would this</div><div>be a x-registered-name type system or a registered-namespace-*</div><div>type system?</div><div><br></div><div>It occurs to me one problem with arbitrary namespaces is there</div><div>is a unintended collision problem. e.g. you have the foo-bar namespace</div><div>and the foo namespace, what happens if you have a test key inside of</div><div>foo-bar and a bar-test inside of the foo namepspace. They'll both end</div><div>up being foo-bar-test. This makes me think that we need a seperate</div><div>registry and that if we go the namespace route it should be limited to</div><div>alphanumerics only so that you don't have the foo/foo-bar collision problem.</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><br></div><div>- name of metadata field</div><div>- name of registrant (individual or PyPI package)</div><div>- contact email address (published)</div><div>- expiration date; by default, extensions expire 1 month after</div><div>   their registration, unless renewed; maximum expiration time is</div><div>   5 years</div><div>- English description of the field</div><div>- regular expression to validate the field</div></span></blockquote><div>What happens when it expires? Is that name freed up for future use? I</div><div>think that freeing up the name is likely to be a bad idea since we can't go</div><div>backwards in time (as you alluded to later about not deleting them), so</div><div>what does expiration do?&nbsp;</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><br></div><div>Deleting undesired extensions would not be possible, instead, one</div><div>would have to create another extension if the syntax or semantics</div><div>changes</div></span></blockquote><div><br>
                </div>
            

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4