Le 07/11/2013 22:42, Christian Heimes a écrit :
Am 07.11.2013 21:45, schrieb Antoine Pitrou:
I'm in favour but I think 3.5 is too early. Keep in mind SSLContext is
quite young.
It's available since 3.3
3.2 actually, while many code bases are still 2.x-compatible.
There's no need to make migr
On Thu, Nov 7, 2013 at 4:55 PM, Victor Stinner wrote:
> About the 72523 functions PyRun_xxx(), I don't understand something.
> The PyRun_FileEx() is documented in the Python "very high" C API to
> use Python. But this function is not part of the stable ABI. So there
> is no "very high" function in
Somehow your mail didn't end up on Python-dev
Am 08.11.2013 00:38, schrieb Nick Coghlan:
> In that case, it sounds like you need *two* new options rather than
> one. "verify_hostname", with the None/True/False behaviour and a
> separate postverify hook.
Mmmh, yes, you are making an intriguing poi
2013/11/8 Victor Stinner :
> Another question: it's not documented if a function is part or not
> part of the stable ABI. So as an user of the API, it is hard to check
> if a function is part of the stable ABI or not.
A solution for that it maybe to split the documentation of the C API
in two part
2013/11/8 Nick Coghlan :
>> [PyRun_InteractiveOneObject()]
>> (...)
>> > Also, if they're part of the stable ABI, they need a version guard.
>>
>> As most PyRun_xxx() functions, the function is declared in a "#ifndef
>> Py_LIMITED_API" block. It means that it is not part of the stable ABI,
>> is th
Am 08.11.2013 00:09, schrieb Barry Warsaw:
> I'm sure you're considering this, but I want to explicitly preserve the
> ability to register self-signed certificates. It's often necessary in
> practice, but very useful for testing purposes.
>
> ssl.SSLContext.load_cert_chain() is the way to do this
On 8 Nov 2013 09:45, "Victor Stinner" wrote:
>
> Hi,
>
> [PyRun_InteractiveOneObject()]
>
> 2013/11/8 Nick Coghlan :
> > New C APIs should either be documented or have an underscore prefix.
>
> I created the issue #19518 to add documentation (but also to add even
> more functions :-)).
>
> > Also,
2013/11/8 Nick Coghlan :
>> http://hg.python.org/cpython/rev/69071054b42f
>> changeset: 86968:69071054b42f
>> user:Victor Stinner
>> date:Wed Nov 06 18:58:22 2013 +0100
>> summary:
>> Issue #19512: Add a new _PyDict_DelItemId() function, similar to
>> PyDict_DelItemString() but
Hi,
[PyRun_InteractiveOneObject()]
2013/11/8 Nick Coghlan :
> New C APIs should either be documented or have an underscore prefix.
I created the issue #19518 to add documentation (but also to add even
more functions :-)).
> Also, if they're part of the stable ABI, they need a version guard.
As
Am 07.11.2013 23:25, schrieb Nick Coghlan:
> Change this to create_default_context() (to make it clearer there is no
> global context object) and I'm generally +1.
Good idea!
> This overlaps confusingly with "verify_mode". Perhaps just offer a
> module level "verify_hostname" API that adapts betw
On 7 Nov 2013 04:06, "victor.stinner" wrote:
>
> http://hg.python.org/cpython/rev/69071054b42f
> changeset: 86968:69071054b42f
> user:Victor Stinner
> date:Wed Nov 06 18:58:22 2013 +0100
> summary:
> Issue #19512: Add a new _PyDict_DelItemId() function, similar to
> PyDict_Del
New C APIs should either be documented or have an underscore prefix.
Also, if they're part of the stable ABI, they need a version guard.
Wishlist item: an automated ABI checker that can diff the exported symbols
against a reference list (Could ctypes or cffi be used for that?)
As long as this ki
On Nov 07, 2013, at 10:42 PM, Christian Heimes wrote:
>You misunderstood me. I'm not proposing a global SSLContext object but a
>factory function that creates a context for Python stdlib modules. Right
>now every urllib, http.client, nntplib, asyncio, ftplib, poplib and
>imaplib have duplicated co
2013/11/7 Victor Stinner :
> Calling strlen() at runtime may slow-down a function in the fast-path
> of PyUnicode_Decode() and PyUnicode_AsEncodedString() which are
> important functions. I know that some developers can execute strlen()
> during compilation, but I don't see the need of replacing 6
On 8 Nov 2013 04:18, "Christian Heimes" wrote:
>
> Hi,
>
> I'd like to simplify, unify and tighten SSL handling and verification
> code in Python 3.5. Therefore I propose to deprecate some features for
> Python 3.4. SSLContext objects are going to be the central instance for
> configuration.
>
> I
On 11/7/2013 5:13 PM, Victor Stinner wrote:
> 2013/11/7 Eric V. Smith :
>> Then how about at least a comment about how 6 is derived?
>>
>> if (lower_len < 6) /* 6 == strlen("utf-8") + 1 */
>> return 0;
>
> Ok, I added the comment in changeset 9c929b9e0a2a.
Thanks!
Eric.
2013/11/7 Eric V. Smith :
> Then how about at least a comment about how 6 is derived?
>
> if (lower_len < 6) /* 6 == strlen("utf-8") + 1 */
> return 0;
Ok, I added the comment in changeset 9c929b9e0a2a.
Victor
___
Python-Dev mail
On 8 Nov 2013 04:44, "Brett Cannon" wrote:
> On Thu, Nov 7, 2013 at 7:41 AM, Nick Coghlan wrote:
>>
>> The bigger problem is you can't change the constructor signature in a
backwards incompatible way. You would need a new class method as an
alternative constructor instead, or else use optional pa
On 11/7/2013 4:38 PM, Victor Stinner wrote:
> 2013/11/7 Benjamin Peterson :
>> 2013/11/7 victor.stinner :
>>> http://hg.python.org/cpython/rev/99afa4c74436
>>> changeset: 86995:99afa4c74436
>>> user:Victor Stinner
>>> date:Thu Nov 07 13:33:36 2013 +0100
>>> summary:
>>> Fix _Py
On Nov 7, 2013, at 4:42 PM, Christian Heimes wrote:
>>>
>>> - deprecate implicit verify_mode=CERT_NONE. Python 3.5 will default
>>> to CERT_REQUIRED.
>>
>> -0.9. This breaks compatibility and doesn't achieve anything, since
>> there's no reliable story for CA certs.
>
> I'd like to move to
Am 07.11.2013 21:45, schrieb Antoine Pitrou:
> I'm in favour but I think 3.5 is too early. Keep in mind SSLContext is
> quite young.
It's available since 3.3
>> - deprecate implicit verify_mode=CERT_NONE. Python 3.5 will default
>>to CERT_REQUIRED.
>
> -0.9. This breaks compatibility and doe
2013/11/7 Benjamin Peterson :
> 2013/11/7 victor.stinner :
>> http://hg.python.org/cpython/rev/99afa4c74436
>> changeset: 86995:99afa4c74436
>> user:Victor Stinner
>> date:Thu Nov 07 13:33:36 2013 +0100
>> summary:
>> Fix _Py_normalize_encoding(): ensure that buffer is big enou
On 8 Nov 2013 04:42, Martin v. Löwis wrote:
>
> Am 07.11.13 13:44, schrieb Thomas Heller:
>
> > I thought that the stable API would keep exactly the same across
> > releases - is this expectation wrong or is this a bug?
>
> Oscar is right - this change doesn't affect the ABI, just the API.
>
> Tha
2013/11/7 victor.stinner :
> http://hg.python.org/cpython/rev/99afa4c74436
> changeset: 86995:99afa4c74436
> user:Victor Stinner
> date:Thu Nov 07 13:33:36 2013 +0100
> summary:
> Fix _Py_normalize_encoding(): ensure that buffer is big enough to store
> "utf-8"
> if the input
Le 07/11/2013 19:13, Christian Heimes a écrit :
Hi,
I'd like to simplify, unify and tighten SSL handling and verification
code in Python 3.5.
Therefore I propose to deprecate some features for
Python 3.4. SSLContext objects are going to be the central instance for
configuration.
In order to ar
On Thu, Nov 7, 2013 at 2:20 PM, Eric Snow wrote:
> On Thu, Nov 7, 2013 at 11:44 AM, Brett Cannon wrote:
> > Lazy message creation through
> > __str__ does leave the message out of `args`, though.
>
> If that's an issue you could make args a (settable) property that
> dynmically returns str(self)
On Thu, Nov 7, 2013 at 11:44 AM, Brett Cannon wrote:
> Lazy message creation through
> __str__ does leave the message out of `args`, though.
If that's an issue you could make args a (settable) property that
dynmically returns str(self) if appropriate:
@property
def args(self):
ac
On Thu, Nov 7, 2013 at 7:41 AM, Nick Coghlan wrote:
>
> On 7 Nov 2013 21:34, "Victor Stinner" wrote:
> >
> > 2013/11/7 Steven D'Aprano :
> > > My initial instinct here was to say that sounded like premature
> > > optimization, but to my surprise the overhead of generating the error
> > > message
Am 07.11.13 13:44, schrieb Thomas Heller:
> I thought that the stable API would keep exactly the same across
> releases - is this expectation wrong or is this a bug?
Oscar is right - this change doesn't affect the ABI, just the API.
That said, please file an issue reporting what change you see i
Hi,
I'd like to simplify, unify and tighten SSL handling and verification
code in Python 3.5. Therefore I propose to deprecate some features for
Python 3.4. SSLContext objects are going to be the central instance for
configuration.
In order to archive the goal I propose to
- deprecate the key_fi
On 7 November 2013 12:44, Thomas Heller wrote:
> PEP 384 describes the stable Python api, available when
> Py_LIMITED_API is defined.
>
> However, there are some (small) changes in the function prototypes
> available, one example is (in Python 3.3):
> PyObject* PyObject_CallFunction(PyObject *cal
PEP 384 describes the stable Python api, available when
Py_LIMITED_API is defined.
However, there are some (small) changes in the function prototypes
available, one example is (in Python 3.3):
PyObject* PyObject_CallFunction(PyObject *callable, char *format, ...)
which changed in Python 3.4 to
On 7 Nov 2013 21:34, "Victor Stinner" wrote:
>
> 2013/11/7 Steven D'Aprano :
> > My initial instinct here was to say that sounded like premature
> > optimization, but to my surprise the overhead of generating the error
> > message is actually significant -- at least from pure Python 3.3 code.
>
>
On 7 Nov 2013 03:18, "Antoine Pitrou" wrote:
>
> Le 06/11/2013 06:41, Nick Coghlan a écrit :
>
>>
>> The behaviour of mutating builtin containers while iterating over them
>> is formally undefined beyond "it won't segfault" (one of the few such
>> undefined behaviours in Python). The associated ex
07.11.13 00:32, Victor Stinner написав(ла):
I'm trying to avoid unnecessary temporary Unicode strings when
possible (see issue #19512). While working on this, I saw that Python
likes preparing an user friendly message to explain why getting an
attribute failed. The problem is that in most cases,
2013/11/7 Steven D'Aprano :
> My initial instinct here was to say that sounded like premature
> optimization, but to my surprise the overhead of generating the error
> message is actually significant -- at least from pure Python 3.3 code.
I ran a quick and dirty benchmark by replacing the error me
36 matches
Mail list logo
