Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 10/11/2013 12:09 PM, Zero Piraeus wrote: with blithe_disdain_concerning(...): +1 :) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
On Sat, 12 Oct 2013 14:04:48 +1000 Nick Coghlan wrote: > On 12 Oct 2013 11:15, "Victor Stinner" wrote: > > > > 2013/10/12 Ethan Furman : > > >> What do you propose in cases like this? Should the keyword always refer > > >> to the same PEP it did in the past, even when that PEP is no longer as > > >> relevant given later PEPs? Or should the keyword reach a different, > > >> newer PEP if that newer PEP becomes a “more relevant” PEP for the > > >> keyword? > > > > > > Heh, that was the same example I was going to use. :) > > > > > > Another question: if the later PEP gets the appropriate name, what name > > > then gets applied to the older one(s)? > > > > As I wrote in my first message, if changing identifier for draft PEP > > is an issue, an option is to only add a textual identifier to accepted > > PEPs. > > RFCs are referenced by number. Standards are referenced by number. > Nicknames are simply too ambiguous to be scalable. Indeed. One reason is that several RFCs or PEPs may be issued for a single topic. Which RFC gets to be called "http"? Probably the first one, but then when you type "http" you get the HTTP 1.0 RFC. You'd rather have the HTTP 1.1 RFC, I think. Or perhaps a further clarification RFC. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEPs shouldn't be considered docs
On 12 October 2013 00:29, Nick Coghlan wrote: > There's no grand policy change or clarification needed here, it's just > another consequence of the fact that the import system isn't documented > properly in versions prior to 3.3. And my personal apology for that. I knew when we wrote PEP 302 that it needed proper documentation, but I couldn't find a good way to include it in the docs and I couldn't face rewriting the import docs in a way that would allow me to include it. Many thanks to Brett for ultimately doing it for me. Paul ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
On 12 October 2013 01:53, Victor Stinner wrote: > t's easy to mix up PEP numbers. For example, Martin von Loewis wrote > two major PEP related to Unicode: 383 and 393. These numbers are > close, only one digit is different. It's worse when you discuss recent > PEPs: PEP 445 or PEP 454? Oops, no it was the PEP 455. I think that the real issue is that people expect others to remember numbers as easily as they do while writing emails, etc. If in email people refer to PEPs as PEP 302 (Import Hooks) or PEP 3156 (Tulip) or PEP 435 (Enum) etc, there would be a lot less issue. We're all guilty of it, and context is often enough to clarify, but IMO this is more about thinking of your audience when writing. Paul ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support keyword in PEP URL?
On Sat, Oct 12, 2013 at 10:48:41AM +0100, Paul Moore wrote: > On 12 October 2013 01:53, Victor Stinner wrote: > > t's easy to mix up PEP numbers. For example, Martin von Loewis wrote > > two major PEP related to Unicode: 383 and 393. These numbers are > > close, only one digit is different. It's worse when you discuss recent > > PEPs: PEP 445 or PEP 454? Oops, no it was the PEP 455. > > I think that the real issue is that people expect others to remember > numbers as easily as they do while writing emails, etc. If in email > people refer to PEPs as PEP 302 (Import Hooks) or PEP 3156 (Tulip) or > PEP 435 (Enum) etc, there would be a lot less issue. +1 -- Steven ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #19209: Remove import of copyreg from the os module to speed up
Am 12.10.2013 01:32, schrieb Nick Coghlan:
>> diff --git a/Lib/test/test_site.py b/Lib/test/test_site.py
>> --- a/Lib/test/test_site.py
>> +++ b/Lib/test/test_site.py
>> @@ -431,10 +431,13 @@
>> modules = eval(stdout.decode('utf-8'))
>> self.assertIn('site', modules)
>>
>> +# http://bugs.python.org/issue19205
>> re_mods = {'re', '_sre', 'sre_compile', 'sre_constants',
> 'sre_parse'}
>> self.assertFalse(modules.intersection(re_mods))
>> -
>> +# http://bugs.python.org/issue9548
>> self.assertNotIn('locale', modules)
>
> This looks like it snuck in from a separate patch.
No harm done. It seems like a good idea to document the reason for the
test cases so I added links the links at the same time.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] bugs.python.org not reachable in IPv6?
Hi, The DNS server of python.org announce the IP address 2a01:4f8:131:2480::3: $ host -t bugs.python.org bugs.python.org has IPv6 address 2a01:4f8:131:2480::3 The problem is that I cannot connect to this IP address: $ ping6 -c 4 2a01:4f8:131:2480::3 PING 2a01:4f8:131:2480::3(2a01:4f8:131:2480::3) 56 data bytes --- 2a01:4f8:131:2480::3 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 2999ms Do you have a the same issue, or is it just me? Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Infrastructure] bugs.python.org not reachable in IPv6?
Opened issue at http://psf.upfronthosting.co.za/roundup/meta/issue528 Regards Antoine. Le samedi 12 octobre 2013 à 14:40 +0200, Victor Stinner a écrit : > Hi, > > The DNS server of python.org announce the IP address 2a01:4f8:131:2480::3: > > $ host -t bugs.python.org > bugs.python.org has IPv6 address 2a01:4f8:131:2480::3 > > > The problem is that I cannot connect to this IP address: > > $ ping6 -c 4 2a01:4f8:131:2480::3 > PING 2a01:4f8:131:2480::3(2a01:4f8:131:2480::3) 56 data bytes > > --- 2a01:4f8:131:2480::3 ping statistics --- > 4 packets transmitted, 0 received, 100% packet loss, time 2999ms > > > Do you have a the same issue, or is it just me? > > Victor > > Infrastructure mailing list > [email protected] > https://mail.python.org/mailman/listinfo/infrastructure > Unsubscribe: > https://mail.python.org/mailman/options/infrastructure/solipsis%40pitrou.net > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change PEP 399 import recommendation (was: C extension import time)
Nick Coghlan wrote: > On 12 Oct 2013 05:49, "Eric Snow" wrote: > > > > On Fri, Oct 11, 2013 at 1:41 PM, Stefan Krah wrote: > > > Antoine Pitrou wrote: > > >> Just create a _pydecimal module (like _pyio). > > > > > > That's very fast indeed. There's one minor problem: For backwards > compatibility > > > and pickling [1] I'd need to add > > > > > > __module__ = 'decimal' > > > > > > to every class of the Python version. Are there any reasons not to do > > > that? > > > > Try just putting "__name__ = 'decimal'" at the top of the source file. > > In this case the fixup needs to be conditional on the absence of "_decimal". > Aside from that, yes, lying about name is the easiest way to preserve pickle > compatibility while still moving code around. Thanks Eric and Nick. The setup pretty much works (see issue #19232) and the import speedup is quite large. I wonder if Cpython's startup time could be reduced if this strategy was applied to other modules as well (see #19229). There are some concerns whether the change would impact other Python implementations, so I changed the subject (hoping for feedback). Stefan Krah ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change PEP 399 import recommendation
Stefan Krah, 12.10.2013 15:41: > Nick Coghlan wrote: >> On 12 Oct 2013 05:49, "Eric Snow" wrote: >>> On Fri, Oct 11, 2013 at 1:41 PM, Stefan Krah wrote: Antoine Pitrou wrote: > Just create a _pydecimal module (like _pyio). That's very fast indeed. There's one minor problem: For backwards >> compatibility and pickling [1] I'd need to add __module__ = 'decimal' to every class of the Python version. Are there any reasons not to do that? >>> >>> Try just putting "__name__ = 'decimal'" at the top of the source file. >> >> In this case the fixup needs to be conditional on the absence of "_decimal". >> Aside from that, yes, lying about name is the easiest way to preserve pickle >> compatibility while still moving code around. > > Thanks Eric and Nick. The setup pretty much works (see issue #19232) and the > import speedup is quite large. I wonder if Cpython's startup time could be > reduced if this strategy was applied to other modules as well (see #19229). > > There are some concerns whether the change would impact other Python > implementations, so I changed the subject (hoping for feedback). FWIW, I think this definitely makes sense in cases where the C implementation is essentially a complete replacement of the original module, such as in this case. I even sometimes suggest compiling Python modules with Cython if the import time matters. For "normal" accelerator modules that only replace a part of a Python module with a native implementation, this is less likely to make a large enough difference to make up for the additional complexity due to the code split. Stefan ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change PEP 399 import recommendation
On Sat, 12 Oct 2013 16:04:23 +0200, Stefan Behnel wrote: > Stefan Krah, 12.10.2013 15:41: > > Nick Coghlan wrote: > >> On 12 Oct 2013 05:49, "Eric Snow" wrote: > >>> On Fri, Oct 11, 2013 at 1:41 PM, Stefan Krah wrote: > Antoine Pitrou wrote: > > Just create a _pydecimal module (like _pyio). > > That's very fast indeed. There's one minor problem: For backwards > >> compatibility > and pickling [1] I'd need to add > > __module__ = 'decimal' > > to every class of the Python version. Are there any reasons not to do > that? > >>> > >>> Try just putting "__name__ = 'decimal'" at the top of the source file. > >> > >> In this case the fixup needs to be conditional on the absence of > >> "_decimal". > >> Aside from that, yes, lying about name is the easiest way to preserve > >> pickle > >> compatibility while still moving code around. > > > > Thanks Eric and Nick. The setup pretty much works (see issue #19232) and the > > import speedup is quite large. I wonder if Cpython's startup time could be > > reduced if this strategy was applied to other modules as well (see #19229). > > > > There are some concerns whether the change would impact other Python > > implementations, so I changed the subject (hoping for feedback). > > FWIW, I think this definitely makes sense in cases where the C > implementation is essentially a complete replacement of the original > module, such as in this case. I even sometimes suggest compiling Python > modules with Cython if the import time matters. > > For "normal" accelerator modules that only replace a part of a Python > module with a native implementation, this is less likely to make a large > enough difference to make up for the additional complexity due to the code > split. The impact on other implementations is: what if they write an accelerator that only replaces part of the module, whereas CPython's replaces the whole thing? But I think we could just postpone dealing with that until it actually comes up, just as we would if some other implementation writes an accelerator for a module for which CPython doesn't have one. --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEPs shouldn't be considered docs
On Sat, Oct 12, 2013 at 5:38 AM, Paul Moore wrote: > On 12 October 2013 00:29, Nick Coghlan wrote: > > There's no grand policy change or clarification needed here, it's just > > another consequence of the fact that the import system isn't documented > > properly in versions prior to 3.3. > > And my personal apology for that. I knew when we wrote PEP 302 that it > needed proper documentation, but I couldn't find a good way to include > it in the docs and I couldn't face rewriting the import docs in a way > that would allow me to include it. > > Many thanks to Brett for ultimately doing it for me. > Actually thanks should go to Barry who rewrote the language ref docs for import. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEPs shouldn't be considered docs
On 12 Oct 2013 19:38, "Paul Moore" wrote: > > On 12 October 2013 00:29, Nick Coghlan wrote: > > There's no grand policy change or clarification needed here, it's just > > another consequence of the fact that the import system isn't documented > > properly in versions prior to 3.3. > > And my personal apology for that. I knew when we wrote PEP 302 that it > needed proper documentation, but I couldn't find a good way to include > it in the docs and I couldn't face rewriting the import docs in a way > that would allow me to include it. You were *far* from the only one to contemplate documenting the old import system and then decide we had more edifying things to do with our time ;) > Many thanks to Brett for ultimately doing it for me. Barry actually did the bulk of the initial writing for that, although Brett did the preceding work to make it feasible to document by ensuring the default import system was registered on sys.meta_path. And yes, it was a very happy day when that commit landed :) Cheers, Nick. > Paul ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEPs shouldn't be considered docs
On Oct 12, 2013, at 11:19 AM, Brett Cannon wrote: >Actually thanks should go to Barry who rewrote the language ref docs for >import. I can actually say it was fun due to all the great work on importlib. :) -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change PEP 399 import recommendation
On 13 Oct 2013 00:47, "R. David Murray" wrote: > > On Sat, 12 Oct 2013 16:04:23 +0200, Stefan Behnel wrote: > > Stefan Krah, 12.10.2013 15:41: > > > Nick Coghlan wrote: > > >> On 12 Oct 2013 05:49, "Eric Snow" wrote: > > >>> On Fri, Oct 11, 2013 at 1:41 PM, Stefan Krah wrote: > > Antoine Pitrou wrote: > > > Just create a _pydecimal module (like _pyio). > > > > That's very fast indeed. There's one minor problem: For backwards > > >> compatibility > > and pickling [1] I'd need to add > > > > __module__ = 'decimal' > > > > to every class of the Python version. Are there any reasons not to do that? > > >>> > > >>> Try just putting "__name__ = 'decimal'" at the top of the source file. > > >> > > >> In this case the fixup needs to be conditional on the absence of "_decimal". > > >> Aside from that, yes, lying about name is the easiest way to preserve pickle > > >> compatibility while still moving code around. > > > > > > Thanks Eric and Nick. The setup pretty much works (see issue #19232) and the > > > import speedup is quite large. I wonder if Cpython's startup time could be > > > reduced if this strategy was applied to other modules as well (see #19229). > > > > > > There are some concerns whether the change would impact other Python > > > implementations, so I changed the subject (hoping for feedback). > > > > FWIW, I think this definitely makes sense in cases where the C > > implementation is essentially a complete replacement of the original > > module, such as in this case. I even sometimes suggest compiling Python > > modules with Cython if the import time matters. > > > > For "normal" accelerator modules that only replace a part of a Python > > module with a native implementation, this is less likely to make a large > > enough difference to make up for the additional complexity due to the code > > split. > > The impact on other implementations is: what if they write an > accelerator that only replaces part of the module, whereas CPython's > replaces the whole thing? > > But I think we could just postpone dealing with that until it actually > comes up, just as we would if some other implementation writes an > accelerator for a module for which CPython doesn't have one. I think the default recommendation in PEP 399 still makes sense - 2 modules are easy to manage than three and the idiom allows for easy partial replacement. If the module is complex enough (and keep in mind that Brett used decimal.py as a data point in import benchmarking due to its sheer size meaning execution time was actually significant, even relative to IO time), or implicitly imported at startup, then the more complex 3 module setup may be worthwhile. If other implementations only provide partial acceleration, they can import the pure Python implementation as part of their accelerator implementation. Cheers, Nick. > > --David > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change PEP 399 import recommendation
Am 12.10.2013 17:37, schrieb Nick Coghlan: > I think the default recommendation in PEP 399 still makes sense - 2 > modules are easy to manage than three and the idiom allows for easy > partial replacement. We could ues yet another approach and put the pure Python implementation of modules into another directory (e.g. Lib/pystdlib or Lib/purepython). This directory is appended to sys.path. Alternative implementations of Python or platforms without the necessary bits and pieces would import the Python-only version from that directory. C modules can be renamed so CPython picks them up in favor of the pure Python modules. No hacks, no facade module, no slow down and it's easy to understand, too. The approach can be used for stat, operator, decimal and perhaps other modules, too. Christian ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change PEP 399 import recommendation
On Sat, 12 Oct 2013 18:55:42 +0200 Christian Heimes wrote: > Am 12.10.2013 17:37, schrieb Nick Coghlan: > > I think the default recommendation in PEP 399 still makes sense - 2 > > modules are easy to manage than three and the idiom allows for easy > > partial replacement. > > We could ues yet another approach and put the pure Python implementation > of modules into another directory (e.g. Lib/pystdlib or Lib/purepython). > This directory is appended to sys.path. Alternative implementations of > Python or platforms without the necessary bits and pieces would import > the Python-only version from that directory. C modules can be renamed so > CPython picks them up in favor of the pure Python modules. No hacks, no > facade module, no slow down and it's easy to understand, too. If you grow sys.path, imports get slower. (IMHO it also makes the source tree more cumbersome to navigate) Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 12/10/2013 05:05, Ethan Furman wrote: On 10/11/2013 07:47 PM, Stephen J. Turnbull wrote: Nick Coghlan writes: > (RDM is also right that the exception still has the effect of > terminating the block early, but I view names as mnemonics rather > than necessarily 100% accurate descriptions of things). This is just way too ambiguous for my taste. I can't help reading [snippers] How about with contextlib.break_on(ExceptionIDontFeelLikeHandlingProperly): stmt1 stmt2 stmt3 This is not 100% accurate Pythonically (there's no loop to break here), but it does describe what the context manager does more accurately, and it does effectively break out of the 'with' control structure. +1 (if we have to have it) While I agree that mnemonics are helpful in the right circumstances, these aren't them, not for this name. We aren't /just/ ignoring the exception, the exception is having a very real effect -- it's terminating the with block. Perhaps "leave_on" would be more accurate. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Right place for PBKDF2 wrapper
Hi, I have written a interface to OpenSSL's PKCS5_PBKDF2_HMAC() function. It implements PKCS#5's password based key derivation function 2 with HMAC as pseudo-random function. It supports any digest that is supported by OpenSSL, e.g. SHA-1, SHA-256 and SHA-512. It's a low level inteface that takes the digest as unicode name, password and salt as bytes/buffer, keylen and rounds as int. I'd like to add the feature to Python 3.4. Now I'm looking for a good place to put it and some high level functions. In the future I like to add scrypt and bcrypt key stretching and key derivation functions, too. What's a good place for them?? * add a new ``kdf`` module (key derivation function) * add PBKDF2 to ``hashlib`` * make ``hashlib`` a package and add PBKDF2 to a new ``hashlib.kdf`` module * make ``hashlib`` a package and add PBKDF2 to a new ``hashlib.pbkdf2`` module * make ``crypt`` work under Windows and add PKBDF2 to it The patch is available at http://bugs.python.org/issue18582 Regards, Christian ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Right place for PBKDF2 wrapper
On Sat, 12 Oct 2013 19:19:44 +0200 Christian Heimes wrote: > Hi, > > I have written a interface to OpenSSL's PKCS5_PBKDF2_HMAC() function. It > implements PKCS#5's password based key derivation function 2 with HMAC > as pseudo-random function. It supports any digest that is supported by > OpenSSL, e.g. SHA-1, SHA-256 and SHA-512. It's a low level inteface that > takes the digest as unicode name, password and salt as bytes/buffer, > keylen and rounds as int. > > I'd like to add the feature to Python 3.4. Now I'm looking for a good > place to put it and some high level functions. In the future I like to > add scrypt and bcrypt key stretching and key derivation functions, too. > What's a good place for them?? > > * add a new ``kdf`` module (key derivation function) > * add PBKDF2 to ``hashlib`` > * make ``hashlib`` a package and add PBKDF2 to a new ``hashlib.kdf`` module > * make ``hashlib`` a package and add PBKDF2 to a new ``hashlib.pbkdf2`` > module > * make ``crypt`` work under Windows and add PKBDF2 to it Putting it in "hashlib" sounds fine. There's no reason to create a myriad of small separate modules. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change PEP 399 import recommendation
Stefan Behnel wrote: > FWIW, I think this definitely makes sense in cases where the C > implementation is essentially a complete replacement of the original > module, such as in this case. I even sometimes suggest compiling Python > modules with Cython if the import time matters. > > For "normal" accelerator modules that only replace a part of a Python > module with a native implementation, this is less likely to make a large > enough difference to make up for the additional complexity due to the code > split. I wonder how big the cumulative effect is (yes, I should really measure instead of wondering ;)). Anyhow, to measure the effect for decimal in a real world application, these are the startup times of Python if decimal is imported at startup: diff --git a/Lib/site.py b/Lib/site.py --- a/Lib/site.py +++ b/Lib/site.py @@ -72,6 +72,7 @@ import os import builtins import _sitebuiltins +import decimal # Prefixes for site-packages; add additional prefixes like /usr/local here PREFIXES = [sys.prefix, sys.exec_prefix] With the current scheme: $ time ./python -c "pass" real0m0.040s user0m0.036s sys 0m0.004s With the patch for #19232: == $ time ./python -c "pass" real0m0.023s user0m0.016s sys 0m0.004s But I agree that decimal.py is a special case, since it's very large *and* imports many other modules. Stefan Krah ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Support for marking limited API elements in C API docs
Hi, in light of the recent thread about PEPs not forming part of the docs, I've just pushed a change that allows to document C API elements not part of the limited API as such. It is done like this: .. c:function:: int _PyTuple_Resize(PyObject **p, Py_ssize_t newsize) :notlimited: I have not yet begun adding these to the documents; if someone wants to help with this I am glad for volunteers. cheers, Georg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Right place for PBKDF2 wrapper
Am 12.10.2013 19:37, schrieb Antoine Pitrou: > On Sat, 12 Oct 2013 19:19:44 +0200 > Christian Heimes wrote: >> Hi, >> >> I have written a interface to OpenSSL's PKCS5_PBKDF2_HMAC() function. It >> implements PKCS#5's password based key derivation function 2 with HMAC >> as pseudo-random function. It supports any digest that is supported by >> OpenSSL, e.g. SHA-1, SHA-256 and SHA-512. It's a low level inteface that >> takes the digest as unicode name, password and salt as bytes/buffer, >> keylen and rounds as int. >> >> I'd like to add the feature to Python 3.4. Now I'm looking for a good >> place to put it and some high level functions. In the future I like to >> add scrypt and bcrypt key stretching and key derivation functions, too. >> What's a good place for them?? >> >> * add a new ``kdf`` module (key derivation function) >> * add PBKDF2 to ``hashlib`` >> * make ``hashlib`` a package and add PBKDF2 to a new ``hashlib.kdf`` module >> * make ``hashlib`` a package and add PBKDF2 to a new ``hashlib.pbkdf2`` >> module >> * make ``crypt`` work under Windows and add PKBDF2 to it > > Putting it in "hashlib" sounds fine. There's no reason to create a > myriad of small separate modules. Maybe it's a good idea to expose HMAC through hashlib as well, and deprecate the standalone module at some point? Georg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for marking limited API elements in C API docs
12.10.13 21:04, Georg Brandl написав(ла): in light of the recent thread about PEPs not forming part of the docs, I've just pushed a change that allows to document C API elements not part of the limited API as such. It is done like this: ... c:function:: int _PyTuple_Resize(PyObject **p, Py_ssize_t newsize) :notlimited: I have not yet begun adding these to the documents; if someone wants to help with this I am glad for volunteers. Why this is needed? The limited API is unstable and only developers of CPython can use it (but they can look in headers). ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for marking limited API elements in C API docs
Am 12.10.2013 20:20, schrieb Serhiy Storchaka: > 12.10.13 21:04, Georg Brandl написав(ла): >> in light of the recent thread about PEPs not forming part of the docs, >> I've just pushed a change that allows to document C API elements >> not part of the limited API as such. It is done like this: >> >> ... c:function:: int _PyTuple_Resize(PyObject **p, Py_ssize_t newsize) >> :notlimited: >> >> I have not yet begun adding these to the documents; if someone wants to >> help with this I am glad for volunteers. > > Why this is needed? The limited API is unstable and only developers of > CPython can use it (but they can look in headers). Well, I may be reading PEP 384 wrongly, but the point is exactly to have a *stable* API for *non-core* developers to rely upon, so that they can build extensions that don't need to be recompiled for every version of Python. The core and standard library extensions do not use the limited API. Georg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for marking limited API elements in C API docs
On Sat, 12 Oct 2013 21:19:16 +0200
Georg Brandl wrote:
> Am 12.10.2013 20:20, schrieb Serhiy Storchaka:
> > 12.10.13 21:04, Georg Brandl написав(ла):
> >> in light of the recent thread about PEPs not forming part of the docs,
> >> I've just pushed a change that allows to document C API elements
> >> not part of the limited API as such. It is done like this:
> >>
> >> ... c:function:: int _PyTuple_Resize(PyObject **p, Py_ssize_t newsize)
> >> :notlimited:
> >>
> >> I have not yet begun adding these to the documents; if someone wants to
> >> help with this I am glad for volunteers.
> >
> > Why this is needed? The limited API is unstable and only developers of
> > CPython can use it (but they can look in headers).
>
> Well, I may be reading PEP 384 wrongly, but the point is exactly to have a
> *stable* API for *non-core* developers to rely upon, so that they can build
> extensions that don't need to be recompiled for every version of Python.
This is true.
However, I find the proposed markup not very enlightening :-)
I would prefer if "limited" APIs where marked with a :stableabi: tag.
("limited API" is really a bad synonym for "stable ABI" IMO)
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for marking limited API elements in C API docs
12.10.13 22:19, Georg Brandl написав(ла): Am 12.10.2013 20:20, schrieb Serhiy Storchaka: 12.10.13 21:04, Georg Brandl написав(ла): in light of the recent thread about PEPs not forming part of the docs, I've just pushed a change that allows to document C API elements not part of the limited API as such. It is done like this: ... c:function:: int _PyTuple_Resize(PyObject **p, Py_ssize_t newsize) :notlimited: I have not yet begun adding these to the documents; if someone wants to help with this I am glad for volunteers. Why this is needed? The limited API is unstable and only developers of CPython can use it (but they can look in headers). Well, I may be reading PEP 384 wrongly, but the point is exactly to have a *stable* API for *non-core* developers to rely upon, so that they can build extensions that don't need to be recompiled for every version of Python. Sorry, I meant notlimited API. It can vary from version to version and can disappear. For example _PyUnicodeWriter was changed many times (and I suppose it will be changed many times). ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for marking limited API elements in C API docs
Am 12.10.2013 21:56, schrieb Antoine Pitrou:
> On Sat, 12 Oct 2013 21:19:16 +0200
> Georg Brandl wrote:
>> Am 12.10.2013 20:20, schrieb Serhiy Storchaka:
>> > 12.10.13 21:04, Georg Brandl написав(ла):
>> >> in light of the recent thread about PEPs not forming part of the docs,
>> >> I've just pushed a change that allows to document C API elements
>> >> not part of the limited API as such. It is done like this:
>> >>
>> >> ... c:function:: int _PyTuple_Resize(PyObject **p, Py_ssize_t newsize)
>> >> :notlimited:
>> >>
>> >> I have not yet begun adding these to the documents; if someone wants to
>> >> help with this I am glad for volunteers.
>> >
>> > Why this is needed? The limited API is unstable and only developers of
>> > CPython can use it (but they can look in headers).
>>
>> Well, I may be reading PEP 384 wrongly, but the point is exactly to have a
>> *stable* API for *non-core* developers to rely upon, so that they can build
>> extensions that don't need to be recompiled for every version of Python.
>
> This is true.
>
> However, I find the proposed markup not very enlightening :-)
> I would prefer if "limited" APIs where marked with a :stableabi: tag.
The way I did it was based on the expected number of changes, which would
be lower with the "not-limited" elements being labeled. But changing it
around is trivial.
> ("limited API" is really a bad synonym for "stable ABI" IMO)
It's not a synonym: to get a stable ABI, you use the limited API. Of course
Martin should confirm that this terminology matches his intentions.
cheers,
Georg
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for marking limited API elements in C API docs
On Sat, 12 Oct 2013 22:04:57 +0200
Georg Brandl wrote:
> Am 12.10.2013 21:56, schrieb Antoine Pitrou:
> > On Sat, 12 Oct 2013 21:19:16 +0200
> > Georg Brandl wrote:
> >> Am 12.10.2013 20:20, schrieb Serhiy Storchaka:
> >> > 12.10.13 21:04, Georg Brandl написав(ла):
> >> >> in light of the recent thread about PEPs not forming part of the docs,
> >> >> I've just pushed a change that allows to document C API elements
> >> >> not part of the limited API as such. It is done like this:
> >> >>
> >> >> ... c:function:: int _PyTuple_Resize(PyObject **p, Py_ssize_t newsize)
> >> >> :notlimited:
> >> >>
> >> >> I have not yet begun adding these to the documents; if someone wants to
> >> >> help with this I am glad for volunteers.
> >> >
> >> > Why this is needed? The limited API is unstable and only developers of
> >> > CPython can use it (but they can look in headers).
> >>
> >> Well, I may be reading PEP 384 wrongly, but the point is exactly to have a
> >> *stable* API for *non-core* developers to rely upon, so that they can build
> >> extensions that don't need to be recompiled for every version of Python.
> >
> > This is true.
> >
> > However, I find the proposed markup not very enlightening :-)
> > I would prefer if "limited" APIs where marked with a :stableabi: tag.
>
> The way I did it was based on the expected number of changes, which would
> be lower with the "not-limited" elements being labeled. But changing it
> around is trivial.
Well, tagging things which are "not something" feels weird IMHO.
> > ("limited API" is really a bad synonym for "stable ABI" IMO)
>
> It's not a synonym: to get a stable ABI, you use the limited API.
I still don't like that name, because it doesn't convey any interesting
information. "Stable ABI" is immediately informative.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for marking limited API elements in C API docs
12.10.13 22:56, Antoine Pitrou написав(ла):
On Sat, 12 Oct 2013 21:19:16 +0200
Georg Brandl wrote:
Am 12.10.2013 20:20, schrieb Serhiy Storchaka:
12.10.13 21:04, Georg Brandl написав(ла):
in light of the recent thread about PEPs not forming part of the docs,
I've just pushed a change that allows to document C API elements
not part of the limited API as such. It is done like this:
... c:function:: int _PyTuple_Resize(PyObject **p, Py_ssize_t newsize)
:notlimited:
I have not yet begun adding these to the documents; if someone wants to
help with this I am glad for volunteers.
Why this is needed? The limited API is unstable and only developers of
CPython can use it (but they can look in headers).
Well, I may be reading PEP 384 wrongly, but the point is exactly to have a
*stable* API for *non-core* developers to rely upon, so that they can build
extensions that don't need to be recompiled for every version of Python.
This is true.
However, I find the proposed markup not very enlightening :-)
I would prefer if "limited" APIs where marked with a :stableabi: tag.
("limited API" is really a bad synonym for "stable ABI" IMO)
Why not limited private API should be documented at all besides sources?
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for marking limited API elements in C API docs
On 10/12/2013 4:04 PM, Georg Brandl wrote: > Am 12.10.2013 21:56, schrieb Antoine Pitrou: >> On Sat, 12 Oct 2013 21:19:16 +0200 >> Georg Brandl wrote: >>> Am 12.10.2013 20:20, schrieb Serhiy Storchaka: 12.10.13 21:04, Georg Brandl написав(ла): > in light of the recent thread about PEPs not forming part of the docs, > I've just pushed a change that allows to document C API elements > not part of the limited API as such. It is done like this: > > ... c:function:: int _PyTuple_Resize(PyObject **p, Py_ssize_t newsize) > :notlimited: > > I have not yet begun adding these to the documents; if someone wants to > help with this I am glad for volunteers. Why this is needed? The limited API is unstable and only developers of CPython can use it (but they can look in headers). >>> >>> Well, I may be reading PEP 384 wrongly, but the point is exactly to have a >>> *stable* API for *non-core* developers to rely upon, so that they can build >>> extensions that don't need to be recompiled for every version of Python. >> >> This is true. >> >> However, I find the proposed markup not very enlightening :-) >> I would prefer if "limited" APIs where marked with a :stableabi: tag. > > The way I did it was based on the expected number of changes, which would > be lower with the "not-limited" elements being labeled. But changing it > around is trivial. I'm not sure I understand what's being labeled "notlimited". But it seems to be a tautology that the stable API/ABI is not changing. So I think it makes more sense to label those as "stableabi" and be finished with this task, rather than trying to remember to add some markup every time we add a new function. -- Eric. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for marking limited API elements in C API docs
Am 12.10.2013 22:16, schrieb Antoine Pitrou:
>> >> Well, I may be reading PEP 384 wrongly, but the point is exactly to have a
>> >> *stable* API for *non-core* developers to rely upon, so that they can
>> >> build
>> >> extensions that don't need to be recompiled for every version of Python.
>> >
>> > This is true.
>> >
>> > However, I find the proposed markup not very enlightening :-)
>> > I would prefer if "limited" APIs where marked with a :stableabi: tag.
>>
>> The way I did it was based on the expected number of changes, which would
>> be lower with the "not-limited" elements being labeled. But changing it
>> around is trivial.
>
> Well, tagging things which are "not something" feels weird IMHO.
Sorry, that seems like arbitrary bike-shedding. It's like saying you don't
want to document that pickle, shelve and marshal are not safe against
untrusted data, but rather document that all other modules are.
>> > ("limited API" is really a bad synonym for "stable ABI" IMO)
>>
>> It's not a synonym: to get a stable ABI, you use the limited API.
>
> I still don't like that name, because it doesn't convey any interesting
> information. "Stable ABI" is immediately informative.
It can be changed, but we document the C API, not an ABI.
cheers,
Georg
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for marking limited API elements in C API docs
On Sat, 12 Oct 2013 22:25:36 +0200
Georg Brandl wrote:
> >> > ("limited API" is really a bad synonym for "stable ABI" IMO)
> >>
> >> It's not a synonym: to get a stable ABI, you use the limited API.
> >
> > I still don't like that name, because it doesn't convey any interesting
> > information. "Stable ABI" is immediately informative.
>
> It can be changed, but we document the C API, not an ABI.
This is a rather mistaken statement. The only point of using the
"limited API" is because it provides the stable ABI. There is *zero*
other reason of caring about it.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Right place for PBKDF2 wrapper
On Sat, Oct 12, 2013 at 1:19 PM, Christian Heimes wrote: > Hi, > > I have written a interface to OpenSSL's PKCS5_PBKDF2_HMAC() function. It > implements PKCS#5's password based key derivation function 2 with HMAC > as pseudo-random function. It supports any digest that is supported by > OpenSSL, e.g. SHA-1, SHA-256 and SHA-512. It's a low level inteface that > takes the digest as unicode name, password and salt as bytes/buffer, > keylen and rounds as int. > > I'd like to add the feature to Python 3.4. Now I'm looking for a good > place to put it and some high level functions. In the future I like to > add scrypt and bcrypt key stretching and key derivation functions, too. > What's a good place for them?? > > [SNIP] > * add PBKDF2 to ``hashlib`` > * make ``hashlib`` a package and add PBKDF2 to a new ``hashlib.kdf`` module > * make ``hashlib`` a package and add PBKDF2 to a new ``hashlib.pbkdf2`` > module > One of these three depending on how bug the new API is (smaller the less need to add new modules). ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for marking limited API elements in C API docs
On Sat, Oct 12, 2013 at 3:17 PM, Serhiy Storchaka wrote:
> 12.10.13 22:56, Antoine Pitrou написав(ла):
>
>> On Sat, 12 Oct 2013 21:19:16 +0200
>> Georg Brandl wrote:
>>>
>>> Am 12.10.2013 20:20, schrieb Serhiy Storchaka:
12.10.13 21:04, Georg Brandl написав(ла):
>
> in light of the recent thread about PEPs not forming part of the docs,
> I've just pushed a change that allows to document C API elements
> not part of the limited API as such. It is done like this:
>
> ... c:function:: int _PyTuple_Resize(PyObject **p, Py_ssize_t newsize)
> :notlimited:
>
> I have not yet begun adding these to the documents; if someone wants to
> help with this I am glad for volunteers.
Why this is needed? The limited API is unstable and only developers of
CPython can use it (but they can look in headers).
>>>
>>>
>>> Well, I may be reading PEP 384 wrongly, but the point is exactly to have
>>> a
>>> *stable* API for *non-core* developers to rely upon, so that they can
>>> build
>>> extensions that don't need to be recompiled for every version of Python.
>>
>>
>> This is true.
>>
>> However, I find the proposed markup not very enlightening :-)
>> I would prefer if "limited" APIs where marked with a :stableabi: tag.
>>
>> ("limited API" is really a bad synonym for "stable ABI" IMO)
>
>
> Why not limited private API should be documented at all besides sources?
Code is not documentation.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for marking limited API elements in C API docs
Am 12.10.2013 22:09, schrieb Eric V. Smith: > On 10/12/2013 4:04 PM, Georg Brandl wrote: >> Am 12.10.2013 21:56, schrieb Antoine Pitrou: >>> On Sat, 12 Oct 2013 21:19:16 +0200 >>> Georg Brandl wrote: Am 12.10.2013 20:20, schrieb Serhiy Storchaka: > 12.10.13 21:04, Georg Brandl написав(ла): >> in light of the recent thread about PEPs not forming part of the docs, >> I've just pushed a change that allows to document C API elements >> not part of the limited API as such. It is done like this: >> >> ... c:function:: int _PyTuple_Resize(PyObject **p, Py_ssize_t newsize) >> :notlimited: >> >> I have not yet begun adding these to the documents; if someone wants to >> help with this I am glad for volunteers. > > Why this is needed? The limited API is unstable and only developers of > CPython can use it (but they can look in headers). Well, I may be reading PEP 384 wrongly, but the point is exactly to have a *stable* API for *non-core* developers to rely upon, so that they can build extensions that don't need to be recompiled for every version of Python. >>> >>> This is true. >>> >>> However, I find the proposed markup not very enlightening :-) >>> I would prefer if "limited" APIs where marked with a :stableabi: tag. >> >> The way I did it was based on the expected number of changes, which would >> be lower with the "not-limited" elements being labeled. But changing it >> around is trivial. > > I'm not sure I understand what's being labeled "notlimited". But it > seems to be a tautology that the stable API/ABI is not changing. So I > think it makes more sense to label those as "stableabi" and be finished > with this task, rather than trying to remember to add some markup every > time we add a new function. This is true. I've inverted the logic now. Volunteers still welcome :) Georg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for marking limited API elements in C API docs
Am 12.10.2013 22:30, schrieb Antoine Pitrou:
> On Sat, 12 Oct 2013 22:25:36 +0200
> Georg Brandl wrote:
>> >> > ("limited API" is really a bad synonym for "stable ABI" IMO)
>> >>
>> >> It's not a synonym: to get a stable ABI, you use the limited API.
>> >
>> > I still don't like that name, because it doesn't convey any interesting
>> > information. "Stable ABI" is immediately informative.
>>
>> It can be changed, but we document the C API, not an ABI.
>
> This is a rather mistaken statement. The only point of using the
> "limited API" is because it provides the stable ABI. There is *zero*
> other reason of caring about it.
Well, I tried to follow PEP 384 wording.
Georg
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 10/11/2013 09:05 PM, Ethan Furman wrote: On 10/11/2013 07:47 PM, Stephen J. Turnbull wrote: Nick Coghlan writes: > (RDM is also right that the exception still has the effect of > terminating the block early, but I view names as mnemonics rather > than necessarily 100% accurate descriptions of things). While I agree that mnemonics are helpful in the right circumstances, these aren't them, not for this name. We aren't /just/ ignoring the exception, the exception is having a very real effect -- it's terminating the with block. In case it wasn't clear (and it wasn't to me on rereading it ;) this comment was towards Nick, not Stephen. break_on reads just fine to me, although leave_on is probably better. -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Right place for PBKDF2 wrapper
On Sat, Oct 12, 2013 at 11:06 AM, Georg Brandl wrote: > Am 12.10.2013 19:37, schrieb Antoine Pitrou: > > On Sat, 12 Oct 2013 19:19:44 +0200 > > Christian Heimes wrote: > ... > >> * add PBKDF2 to ``hashlib`` > >> * make ``hashlib`` a package and add PBKDF2 to a new ``hashlib.kdf`` > module > >> * make ``hashlib`` a package and add PBKDF2 to a new ``hashlib.pbkdf2`` > >> module > agreed with any of these three. > > Putting it in "hashlib" sounds fine. There's no reason to create a > > myriad of small separate modules. > > Maybe it's a good idea to expose HMAC through hashlib as well, and > deprecate > the standalone module at some point? > that also makes sense... I'd leave hmac.py around through at least 3.6 but going ahead and moving the implementation into hashlib in 3.4 makes sense. -gps ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Right place for PBKDF2 wrapper
Am 12.10.2013 23:04, schrieb Gregory P. Smith: > agreed with any of these three. I'm going for hashlib.pbkdf2_hmac() for now. Right now it's just one function. We can always add a new module for a high level interface later. > that also makes sense... > > I'd leave hmac.py around through at least 3.6 but going ahead and moving > the implementation into hashlib in 3.4 makes sense. That gives us the opportunity th provide a faster implementation based on OpenSSL's HMAC API http://www.openssl.org/docs/crypto/hmac.html . I'm also tempted to provide a fast one-shot-wonder function that returns the MAC as bytes: hmac(name, key, value) -> result Christian ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change PEP 399 import recommendation
Am 12.10.2013 19:02, schrieb Antoine Pitrou: > If you grow sys.path, imports get slower. > (IMHO it also makes the source tree more cumbersome to navigate) It shouldn't slow down successful imports. The module finder stops at first hit. A directory with pure Python modules is less cumbersome than a couple of facade modules or intended code in try/except ImportError blocks. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change PEP 399 import recommendation
On Sat, 12 Oct 2013 23:35:23 +0200 Christian Heimes wrote: > Am 12.10.2013 19:02, schrieb Antoine Pitrou: > > If you grow sys.path, imports get slower. > > (IMHO it also makes the source tree more cumbersome to navigate) > > It shouldn't slow down successful imports. The module finder stops at > first hit. You're forgetting that *other* directories can be appended to sys.path (e.g. the site-packages directories), or any of setuptools' magic things. > A directory with pure Python modules is less cumbersome than a couple > of facade modules or intended code in try/except ImportError blocks. I don't find it cumbersome to be explicit here. It makes it obvious what happens. It also makes it extra easy to import the pure Python if desired (for example for unit tests, or for benchmarking). Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] __objclass__ documentation
It was pointed in Issue16938[1] that __objclass__ is not documented anywhere. Is the following an appropriate description? (in Doc/reference/datamodel.rst in user-defined functions) +-+---+---+ | :attr:`__objclass__`| The class this object belongs | | | | to; useful when the object is | | | | a descriptor, or a virtual or | | | | dynamic class attribute, and | | | | it's __class__ attribute does | | | | not match the class it is | | | | associated with, or it is not | | | | in that class' ``__dict__``. | | +-+---+---+ [1] http://bugs.python.org/issue16938 -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Right place for PBKDF2 wrapper
On Sat, Oct 12, 2013 at 2:31 PM, Christian Heimes wrote: > Am 12.10.2013 23:04, schrieb Gregory P. Smith: > > agreed with any of these three. > > I'm going for hashlib.pbkdf2_hmac() for now. Right now it's just one > function. We can always add a new module for a high level interface later. > > > that also makes sense... > > > > I'd leave hmac.py around through at least 3.6 but going ahead and moving > > the implementation into hashlib in 3.4 makes sense. > > That gives us the opportunity th provide a faster implementation based > on OpenSSL's HMAC API http://www.openssl.org/docs/crypto/hmac.html . I'm > also tempted to provide a fast one-shot-wonder function that returns the > MAC as bytes: hmac(name, key, value) -> result > It'd be more consistent with the other hashlib constructors if the one liner was: hashlib.hmac(hash_name_or_func, key, initial_data).digest() (or .hexdigest() for people who want str rather than bytes). -gps ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 12, 2013, at 1:41 PM, Ethan Furman wrote: > . break_on reads just fine to me, although leave_on is probably better. Sorry, these are both really bad. I've user tested ignore() and had good results. It makes the intention of the code very clear. When you ask someone to describe what "try: f() except SomeException: pass" does, they will say that it ignores the exception. FWIW, I presented this to 2500+ people in the keynote at the 2013 U.S. Pycon and have received favorable feedback. Please don't join Antoine's opposition to my every contribution. The incessant sniping is demoralizing. The module maintainer (Nick) approved the name change from his original preference for ignored(). That should had been the end of it. Now, this thread has 40+ emails and it will probably go on for days. Raymond ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 10/12/2013 6:27 PM, Raymond Hettinger wrote: On Oct 12, 2013, at 1:41 PM, Ethan Furman mailto:[email protected]>> wrote: . break_on reads just fine to me, although leave_on is probably better. Sorry, these are both really bad. I've user tested ignore() and had good results. It makes the intention of the code very clear. I'm curious what your users think this will do print("start listing") with ignore(ZeroDivisionError): for i in range(0, 4): inv = 1 / i print("1 over {} is {}".format(i, inv)) print("finished") I think there's a decent chance I'd get it wrong if I was scanning through code with that construct in the midst of it. Janzert ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 10/12/2013 03:27 PM, Raymond Hettinger wrote: When you ask someone to describe what "try: f() except SomeException: pass" does, they will say that it ignores the exception. And they would be right in that case. FWIW, I presented this to 2500+ people in the keynote at the 2013 U.S. Pycon and have received favorable feedback. Were you only displaying the same short form above? Or did you show some with many lines of code inside the with block? If you didn't, is that because it's a bad idea? Compare: try: f() g() h() except SomeException: pass and with contextlib.ignore(SomeException): f() g() h() What's the difference? The difference is that it is far less obvious that g() and h() may never run. And if SomeException is stopping g() and h() from running, it is most certainly *not* being ignored. For the record, I am no longer opposed to this context manager, only to its name. Please don't join Antoine's opposition to my every contribution. Don't worry, I argue with him, too. ;) And I don't oppose your every contribution (nor his), and I'm pretty sure he doesn't either. The incessant sniping is demoralizing. You mean like having you state your opposition to a PEP, then having you request to be the PEP delegate, and then having your first few comments show clearly that you have neither followed the thread very closely to that point nor even read the PEP? All that aside, Python is a group project. It's as good as it is because when someone sees something that doesn't make sense, (s)he asks about it. So it seems there are two good courses of action in these situations: 1) realize something is not as clear as it could be, so make a code change and/or a doc change; or 2) take a moment and share your knowledge so others can learn. Complaining is not productive. -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] inspect() and dir()
On 10/10/2013 02:25 AM, Nick Coghlan wrote: On 10 Oct 2013 14:32, "Ethan Furman" wrote: That makes sense. So what should the new functions be called? get_all_members and classify_all_class_attrs ? Yeah, those work for me. The only way they should miss anything is if attribute lookup is customised to offer extra dynamic attributes without implementing custom dir support. http://bugs.python.org/issue19239 ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 11Oct2013 13:51, Mark Lawrence wrote: > On 11/10/2013 11:33, Eric V. Smith wrote: > >And Antoine has again taught me a new word: > >polysemic: having more than one meaning; having multiple meanings > > IMHO a poor word to use. I'm a middle aged Brit who's never heard > of it so people who have English as a second language have little or > no chance :( IMO a fine word. New to me, but perfectly clear and memorable once explained. People with English as a second language might do better than us if they've cottoned onto the patterns arising from the root languages, versus a native speaker basing things entirely on memory. Cheers, -- Cameron Simpson The engine purrs beneath me with a purpose, ready for the pleasure of my hand upon the throttle. - Peter Smith ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 12, 2013, at 4:30 PM, Ethan Furman wrote: >> >> When you ask someone to describe what >> "try: f() except SomeException: pass" does, >> they will say that it ignores the exception. > > And they would be right in that case. > > >> FWIW, I presented this to 2500+ people in the keynote >> at the 2013 U.S. Pycon and have received favorable feedback. > > Were you only displaying the same short form above? Yes. The specific example given was: with ignore(OSError): os.remove(somefile) The intended use for the context manager is for the common cases like these: try: os.mkdir(dirname) except OSError: pass def discard(self, key): """If the keyed message exists, remove it.""" try: self.remove(key) except KeyError: pass Most cases of try/except/pass that I see span only one or two lines in the try-block. > Or did you show some with many lines of code inside the with block? If you > didn't, is that because it's a bad idea? > > Compare: > >try: >f() >g() >h() >except SomeException: >pass > Yes, that is usually a bad idea. We don't recommend code like that with try/except. Using a context manager in this case wouldn't make it better. > For the record, I am no longer opposed to this context manager, only to its > name. It just like the old days where there were 100+ emails suggesting other names for enumerate() before agreeing that it had been right to begin with. Raymond___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 10/12/2013 06:50 PM, Raymond Hettinger wrote: On Oct 12, 2013, at 4:30 PM, Ethan Furman wrote: Were you only displaying the same short form above? Yes. The specific example given was: with ignore(OSError): os.remove(somefile) That is certainly nicer than the multi-line form. Argh. Okay, okay, I'm +1. If they're not gonna read the docs it doesn't matter what we name it, and in it's proper setting it certainly reads well. Now, if you'll pardon me, I need to go add that to my 2.x collection of goodies. ;) -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
Cameron Simpson wrote: >> >polysemic: having more than one meaning; having multiple meanings >> >> IMHO a poor word to use. I'm a middle aged Brit who's never heard >> of it so people who have English as a second language have little or >> no chance :( > > IMO a fine word. New to me, but perfectly clear and memorable once > explained. > > People with English as a second language might do better than us > if they've cottoned onto the patterns arising from the root languages, > versus a native speaker basing things entirely on memory. just as a data point: polysemic (from my italian native language) it's pretty "self-explanatory": "poly-" it's a very common prefix for "many", and "semic" has the same root of "semantic". Btw the italian version (polisemia) it's pronounced almost the same, so it's "an easy one" to translate. -- By ZeD ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 12Oct2013 15:27, Raymond Hettinger wrote: > On Oct 12, 2013, at 1:41 PM, Ethan Furman wrote: > . break_on reads just fine to me, although leave_on is probably better. > > Sorry, these are both really bad. I agree. > I've user tested ignore() and had good results. > It makes the intention of the code very clear. I think it is good also. I would also be happy with: ignore_exception for greater explicitness or, perhaps better for Ethan's camp: discard_exception But we've got "ignore" in play already. Can't we accept that it is somewhat evocative though clearly not perfect for everyone, and move on? Cheers, -- Cameron Simpson Once a Junior Programmer interrupted a Great Guru of the Sun to ask a Question of no importance. The Great Guru replied in words which the Junior Programmer did not understand. The Junior Programmer sought to rephrase the Question, saying, "Stop me if I appear stupid." The great Guru, without speaking, reached over and pressed L1-A. The Junior Programmer achieved Enlightenment. - Jon Green ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __objclass__ documentation
On 12Oct2013 15:03, Ethan Furman wrote: > It was pointed in Issue16938[1] that __objclass__ is not documented anywhere. > > Is the following an appropriate description? (in Doc/reference/datamodel.rst > in user-defined functions) > +-+---+---+ > | :attr:`__objclass__`| The class this object belongs | | > | | to; useful when the object is | | > | | a descriptor, or a virtual or | | > | | dynamic class attribute, and | | > | | it's __class__ attribute does | | "its" please. Like "his", "her", "their". > | | not match the class it is | | > | | associated with, or it is not | | > | | in that class' ``__dict__``. | | > +-+---+---+ > [1] http://bugs.python.org/issue16938 I'd make this two sentences. Just turn the semicolon into a full stop, and commence "This is useful when". I had trouble with the end. How about: or it is not in __class__.__dict__ Do I misunderstand? Cheers, -- Cameron Simpson Trust the computer... the computer is your friend. - Richard Dominelli ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Right place for PBKDF2 wrapper
On 13 Oct 2013 06:34, "Brett Cannon" wrote: > > > > > On Sat, Oct 12, 2013 at 1:19 PM, Christian Heimes wrote: >> >> Hi, >> >> I have written a interface to OpenSSL's PKCS5_PBKDF2_HMAC() function. It >> implements PKCS#5's password based key derivation function 2 with HMAC >> as pseudo-random function. It supports any digest that is supported by >> OpenSSL, e.g. SHA-1, SHA-256 and SHA-512. It's a low level inteface that >> takes the digest as unicode name, password and salt as bytes/buffer, >> keylen and rounds as int. >> >> I'd like to add the feature to Python 3.4. Now I'm looking for a good >> place to put it and some high level functions. In the future I like to >> add scrypt and bcrypt key stretching and key derivation functions, too. >> What's a good place for them?? >> >> [SNIP] >> >> * add PBKDF2 to ``hashlib`` >> * make ``hashlib`` a package and add PBKDF2 to a new ``hashlib.kdf`` module >> * make ``hashlib`` a package and add PBKDF2 to a new ``hashlib.pbkdf2`` >> module > > > One of these three depending on how bug the new API is (smaller the less need to add new modules). +1 to hashlib from me (especially since we used that as the best available home for compare_digest). Cheers, Nick. > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
Cameron Simpson writes: > But we've got "ignore" in play already. Can't we accept that it is > somewhat evocative though clearly not perfect for everyone, and > move on? No, that is *way* out. We can overrule the objections, recognizing that sometimes compromise is the worst of the four possible actions (this, that, mix, wait). But don't ask me to "accept" what I consider to be an idea that admits a *lot* of improvement.[1] Let time prove me wrong, please. Footnotes: [1] I've said my piece about "with contextlib.ignore()"; this is not a reiteration. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On 13 Oct 2013 16:37, "Stephen J. Turnbull" wrote: > > Cameron Simpson writes: > > > But we've got "ignore" in play already. Can't we accept that it is > > somewhat evocative though clearly not perfect for everyone, and > > move on? > > No, that is *way* out. We can overrule the objections, recognizing > that sometimes compromise is the worst of the four possible actions > (this, that, mix, wait). Right. For the record, this thread did prompt me to consider the new construct anew, but on reflection, I still consider it a reasonable addition to contextlib. It substantially improves the simple cases it is intended to help with, and, if anything, makes overly broad exception suppression *more* obviously dubious (because the name of the construct doesn't match the consequences for multi-line suites). Cheers, Nick. > > But don't ask me to "accept" what I consider to be an idea that admits > a *lot* of improvement.[1] Let time prove me wrong, please. > > > Footnotes: > [1] I've said my piece about "with contextlib.ignore()"; this is not > a reiteration. > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
