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, re
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 possi
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 fun
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)
> +-+---
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 intenti
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 perfec
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
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
>
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 hav
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 cu
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
On 10/12/2013 6:27 PM, Raymond Hettinger wrote:
On Oct 12, 2013, at 1:41 PM, Ethan Furman mailto:et...@stoneleaf.us>> 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 th
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
"t
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.
>
> >
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__`|
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
>
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
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 leas
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
> >>
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 descript
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, becau
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 написав(ла)
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
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
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.
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.
>> >
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 no
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 all
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
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 push
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
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
>
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:
>>
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_ssiz
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.
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
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"
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
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
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 description
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 ano
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 ano
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 Pit
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
Python-Dev@
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 pers
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
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
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 b
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
> compatibili
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
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:
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)
>>
>> +
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 w
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
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
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
> >
On 10/11/2013 12:09 PM, Zero Piraeus wrote:
with blithe_disdain_concerning(...):
+1 :)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pyt
57 matches
Mail list logo
