On 31 August 2016 at 00:55, Gregory P. Smith wrote:
> I find that users of such systems either use only what their distro itself
> supplies (ie: ancient versions at that point) or are fully comfortable
> building any dependencies their own software needs. If they are comfortable
> building a CPyth
The PEP 445, C API for malloc, allows to plug multiple wrappers and each
wrapper has its own "void* context" data. When you register a new wrapper,
you store the current context and function to later chain it.
See the hooks example:
https://www.python.org/dev/peps/pep-0445/#use-case-3-setup-hooks-
On Tuesday, August 30, 2016, Nick Coghlan wrote:
> On 31 August 2016 at 13:37, Jack Diederich > wrote:
> > On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum > wrote:
> >> But myfunc.__annotations__ already exists -- PEP 3107 puts the
> >> signature annotations there. The problem with co_annota
On 31 August 2016 at 13:37, Jack Diederich wrote:
> On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum wrote:
>> But myfunc.__annotations__ already exists -- PEP 3107 puts the
>> signature annotations there. The problem with co_annotations is that
>> annotations are evaluated (they can be quite c
On 31 August 2016 at 10:27, Steve Dower wrote:
> On 30Aug2016 1702, Victor Stinner wrote:
>> I can try to run more tests if you know some other major Python
>> applications (modules?) working on Windows/Python 3.
>
> The major ones aren't really the concern. I'd be interested to see where
> numpy
On 31 August 2016 at 09:55, Gregory P. Smith wrote:
> On Tue, Aug 30, 2016 at 1:08 PM M.-A. Lemburg wrote:
>> Yet, a move to require OpenSSL 1.0.2 for Python 3.7 will make
>> it impossible to run such apps on systems that still use OpenSSL
>> 1.0.1, e.g. Ubuntu 14.04 or CentOS 7.
>
> Not importan
On 31 August 2016 at 04:55, Serhiy Storchaka wrote:
> On 30.08.16 21:20, Antoine Pitrou wrote:
>> But the performance overhead of iterating over a 1-element list
>> is small enough (it's just an array access after a pointer dereference)
>> that it may not be larger than the overhead of the multipl
On 31 August 2016 at 07:11, Chris Angelico wrote:
> Didn't all this kind of thing come up when function annotations were
> discussed? Insane schemes like dictionaries with UUID keys and so on.
> The decision then was YAGNI. The decision now, IMO, should be the
> same. Keep things simple.
Differen
On 31 August 2016 at 05:06, Serhiy Storchaka wrote:
> On 30.08.16 20:42, Nick Coghlan wrote:
>> Given Serhiy's clarification that this is primarily a thread safety
>> problem, I'm more supportive of the "PySlice_GetIndicesForObject"
>> approach (since that can call all the __index__ methods first,
On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum wrote:
> On Tue, Aug 30, 2016 at 7:44 PM, Jack Diederich
> wrote:
> > +0. We should try and be consistent even if this is a thing I don't want.
> > And trust me, I don't!
>
> No problem. You won't have to!
>
>
Yes! I don't have to want it, it is
On Tue, Aug 30, 2016 at 7:44 PM, Jack Diederich wrote:
> +0. We should try and be consistent even if this is a thing I don't want.
> And trust me, I don't!
No problem. You won't have to!
> That said, as long as pro-mypy people are willing to make everyone else pay
> a mypy reading tax for code l
+0. We should try and be consistent even if this is a thing I don't
want. And trust me, I don't!
That said, as long as pro-mypy people are willing to make everyone else pay
a mypy reading tax for code let's try and reduce the cognitive burden.
* Duplicate type annotations should be a syntax error
On Tue, Aug 30, 2016 at 6:00 PM, Steven D'Aprano wrote:
> On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote:
>> I'm happy to present PEP 526 for your collective review:
>
> Are you hoping to get this in before 3.6 beta? Because I'm not sure I
> can give this much attention before th
On 30 August 2016 at 13:41, Ivo Bellin Salarin
wrote:
> While using requests to tunnel a request via a proxy requiring user
> authentication, I have seen that httplib
> (https://hg.python.org/cpython/file/3.5/Lib/http/client.py#l831) raises the
> message returned by the proxy, along with its statu
On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote:
> I'm happy to present PEP 526 for your collective review:
Are you hoping to get this in before 3.6 beta? Because I'm not sure I
can give this much attention before then, but I really want to.
--
Steve
__
On 30Aug2016 1702, Victor Stinner wrote:
I made another quick&dirty test on Django 1.10 (I ran Django test
suite on my modified Python raising exception on bytes path): I didn't
notice any exception related to bytes path.
Django seems to only use Unicode for paths.
I can try to run more tests i
I made another quick&dirty test on Django 1.10 (I ran Django test
suite on my modified Python raising exception on bytes path): I didn't
notice any exception related to bytes path.
Django seems to only use Unicode for paths.
I can try to run more tests if you know some other major Python
applicat
On Tue, Aug 30, 2016 at 1:08 PM M.-A. Lemburg wrote:
> On 29.08.2016 22:16, Christian Heimes wrote:
> > On 2016-08-29 21:31, M.-A. Lemburg wrote:
> >> On 29.08.2016 18:33, Cory Benfield wrote:
> >>>
> On 29 Aug 2016, at 04:09, M.-A. Lemburg wrote:
>
> On 28.08.2016 22:40, Christia
On 30Aug2016 1611, Victor Stinner wrote:
2016-08-30 23:51 GMT+02:00 Victor Stinner :
As I already wrote once, my problem is also tjat I simply have no idea how
much Python 3 code uses bytes filename. For example, does it concern more
than 25% of py3 modules on PyPi, or less than 5%?
I made a v
2016-08-30 23:51 GMT+02:00 Victor Stinner :
> As I already wrote once, my problem is also tjat I simply have no idea how
> much Python 3 code uses bytes filename. For example, does it concern more
> than 25% of py3 modules on PyPi, or less than 5%?
I made a very quick test on Windows using a modif
On Tue, 30 Aug 2016 at 14:21 Guido van Rossum wrote:
> I'm happy to present PEP 526 for your collective review:
> https://www.python.org/dev/peps/pep-0526/ (HTML)
> https://github.com/python/peps/blob/master/pep-0526.txt (source)
>
> There's also an implementation ready:
> https://github.com/ilev
Thanks Guido, also to the rest of the PEP team (4 people) :)
On 30.08.2016 23:20, Guido van Rossum wrote:
I'm happy to present PEP 526 for your collective review:
https://www.python.org/dev/peps/pep-0526/ (HTML)
https://github.com/python/peps/blob/master/pep-0526.txt (source)
There's also an i
> On 30 Aug 2016, at 16:07, M.-A. Lemburg wrote:
>
> That was not my point. It's unfortunate that Python depends on
> a library which is inevitably going to need updates frequently,
> and which then may have the implication that Python won't compile on
> systems which don't ship with more recent
Le 30 août 2016 8:05 PM, "Nick Coghlan" a écrit :
> This seems to be the crux of the disagreement: our perceptions of the
> relative risks to native Windows Python applications that currently
> work properly on Python 3.5 vs the potential compatibility benefits to
> primarily *nix applications tha
I'm happy to present PEP 526 for your collective review:
https://www.python.org/dev/peps/pep-0526/ (HTML)
https://github.com/python/peps/blob/master/pep-0526.txt (source)
There's also an implementation ready:
https://github.com/ilevkivskyi/cpython/tree/pep-526
I don't want to post the full text h
On Wed, Aug 31, 2016 at 4:55 AM, Serhiy Storchaka wrote:
> On 30.08.16 21:20, Antoine Pitrou wrote:
>>
>> On Tue, 30 Aug 2016 18:12:01 +
>> Brett Cannon wrote:
Why not make it always a list? List objects are reasonably cheap in
memory and access time... (unlike dicts)
>>>
>>>
On Tue, 30 Aug 2016 at 11:56 Serhiy Storchaka wrote:
> On 30.08.16 21:20, Antoine Pitrou wrote:
> > On Tue, 30 Aug 2016 18:12:01 +
> > Brett Cannon wrote:
> >>> Why not make it always a list? List objects are reasonably cheap in
> >>> memory and access time... (unlike dicts)
> >>
> >> Becau
On 29.08.2016 22:16, Christian Heimes wrote:
> On 2016-08-29 21:31, M.-A. Lemburg wrote:
>> On 29.08.2016 18:33, Cory Benfield wrote:
>>>
On 29 Aug 2016, at 04:09, M.-A. Lemburg wrote:
On 28.08.2016 22:40, Christian Heimes wrote:
> ...
> I like to reduce the maintenance burd
On 30.08.16 20:42, Nick Coghlan wrote:
On 28 August 2016 at 08:25, Terry Reedy wrote:
Slicing can be made to malfunction and even crash with an 'evil' __index__
method. https://bugs.python.org/issue27867
The crux of the problem is this: PySlice_GetIndicesEx
receives a slice object and a sequen
On 30.08.16 21:20, Antoine Pitrou wrote:
On Tue, 30 Aug 2016 18:12:01 +
Brett Cannon wrote:
Why not make it always a list? List objects are reasonably cheap in
memory and access time... (unlike dicts)
Because I would prefer to avoid any form of unnecessary performance
overhead for the co
On Tue, 30 Aug 2016 18:12:01 +
Brett Cannon wrote:
> > Why not make it always a list? List objects are reasonably cheap in
> > memory and access time... (unlike dicts)
>
> Because I would prefer to avoid any form of unnecessary performance
> overhead for the common case.
But the performance
On 30Aug2016 1108, Guido van Rossum wrote:
Is this thread something I need to follow closely?
I have PEPs coming, and I'll distil the technical parts of the
discussion into those.
We may need you to impose an opinion on whether 3.6 is an appropriate
time for the change or it should wait for
On 31 August 2016 at 01:06, Victor Stinner wrote:
> 2016-08-30 16:31 GMT+02:00 Steve Dower :
>> Any system that requires communication between two different versions of
>> Python must have install instructions (if it's public) or someone who
>> maintains it. It won't magically break without an upg
On Tue, 30 Aug 2016 at 10:49 Antoine Pitrou wrote:
> On Tue, 30 Aug 2016 17:35:35 +
> Brett Cannon wrote:
> > >
> > > Perhaps a list would work indeed. Realistically, if there are at most
> > > 2-3 users of the field at any given time (and most probably only one or
> > > zero), a simple typ
Is this thread something I need to follow closely?
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pyth
On 30Aug2016 0806, Victor Stinner wrote:
2016-08-30 16:31 GMT+02:00 Steve Dower :
It's the
random user on Windows who installed their library that has the problem.
They don't know the fix, and may not know how to apply it (e.g. if it's
their Jupyter notebook that won't find one of their files -
After a long discussion on python-ideas (starting at
https://mail.python.org/pipermail/python-ideas/2016-August/041727.html)
I'm proposing the following change to PEP 498: backslashes inside
brackets will be disallowed. The point of this is to disallow convoluted
code like:
>>> d = {'a': 4}
>>> f'
On Tue, 30 Aug 2016 17:35:35 +
Brett Cannon wrote:
> >
> > Perhaps a list would work indeed. Realistically, if there are at most
> > 2-3 users of the field at any given time (and most probably only one or
> > zero), a simple type check (by pointer equality) on each list item may
> > be suffic
On 28 August 2016 at 08:25, Terry Reedy wrote:
> Slicing can be made to malfunction and even crash with an 'evil' __index__
> method. https://bugs.python.org/issue27867
>
> The crux of the problem is this: PySlice_GetIndicesEx
> receives a slice object and a sequence length. Calling __index__ on
On Tue, 30 Aug 2016 at 10:32 Antoine Pitrou wrote:
> On Tue, 30 Aug 2016 17:14:31 +
> Brett Cannon wrote:
> >
> > Depends on what vmprof chooses to do. Since the data is designed to be
> > disposable it could decide it should always take precedence and overwrite
> > the data if someone beat
On Tue, 30 Aug 2016 17:14:31 +
Brett Cannon wrote:
>
> Depends on what vmprof chooses to do. Since the data is designed to be
> disposable it could decide it should always take precedence and overwrite
> the data if someone beat it to using the field. Basically I don't think we
> want co_extr
On Tue, 30 Aug 2016 at 01:20 Maciej Fijalkowski wrote:
> On Tue, Aug 30, 2016 at 3:00 AM, Brett Cannon wrote:
> >
> >
> > On Mon, Aug 29, 2016, 17:06 Terry Reedy wrote:
> >>
> >> On 8/29/2016 5:38 PM, Brett Cannon wrote:
> >>
> >> > who objected to the new field did either for memory ("it adds
On Tue, 30 Aug 2016 at 09:08 Antoine Pitrou wrote:
> On Mon, 29 Aug 2016 21:38:19 +
> Brett Cannon wrote:
> > For quick background for those that don't remember, part of PEP 523
> > proposed adding a co_extra field to code objects along with making the
> > frame evaluation function pluggable
On Mon, 29 Aug 2016 21:38:19 +
Brett Cannon wrote:
> For quick background for those that don't remember, part of PEP 523
> proposed adding a co_extra field to code objects along with making the
> frame evaluation function pluggable (
> https://www.python.org/dev/peps/pep-0523/#expanding-pycode
On Sun, 28 Aug 2016 22:40:11 +0200
Christian Heimes wrote:
>
> Here is the deal for 2.7 to 3.5:
>
> 1) All versions older than 0.9.8 are completely out-of-scope and no
> longer supported.
>
> 2) 0.9.8 is semi-support. Python will still compile and work with 0.9.8.
> However we do NOT promise th
If you can do it without breaking existing code that doesn't expect
the extra information, please go ahead! For things like this it is
typically best to go straight to the bug tracker (bugs.python.org)
rather than asking the list first -- if the issue turns out to be
controversial or mysterious it'
Hi everybody,
Sorry for bothering you, this is my first post to the python-dev ML.
While using requests to tunnel a request via a proxy requiring user
authentication, I have seen that httplib (
https://hg.python.org/cpython/file/3.5/Lib/http/client.py#l831) raises the
message returned by the prox
2016-08-30 16:31 GMT+02:00 Steve Dower :
> It's the
> random user on Windows who installed their library that has the problem.
> They don't know the fix, and may not know how to apply it (e.g. if it's
> their Jupyter notebook that won't find one of their files - no obvious
> command line options he
On 30.08.16 15:31, Dima Tisnek wrote:
On 30 August 2016 at 14:13, Serhiy Storchaka wrote:
1. Detect length change and raise.
It would be simpler solution. But I afraid that this can break third-party
code that "just works" now. For example slicing a list "just works" if step
is 1. It can ret
As I've said before, on Windows this is a compatibility hack to make code
written for other platforms work. Making the user opt in is not fair, and does
not help improve the libraries that need it, because few people will change
their library to work with a non default option.
The "developer" I
On Tue, Aug 30, 2016 at 03:11:25PM +0200, Maciej Fijalkowski wrote:
> It's more complicated - if the third party rely on the code working
> when one thread slices while the other thread modifies that gives
> implicit atomicity requirements. Those specific requirements are very
> hard to maintain ac
On Tue, Aug 30, 2016 at 2:31 PM, Dima Tisnek wrote:
> On 30 August 2016 at 14:13, Serhiy Storchaka wrote:
>>> 1. Detect length change and raise.
>>
>>
>> It would be simpler solution. But I afraid that this can break third-party
>> code that "just works" now. For example slicing a list "just work
On 30 August 2016 at 14:13, Serhiy Storchaka wrote:
>> 1. Detect length change and raise.
>
>
> It would be simpler solution. But I afraid that this can break third-party
> code that "just works" now. For example slicing a list "just works" if step
> is 1. It can return not what the author expecte
On 28.08.16 01:25, Terry Reedy wrote:
0. Do nothing.
The problem is not in pathological __index__. The problem is in
executing Python code and releasing GIL. In multithread production code
one thread can read a slice when other thread modifies a collection. In
very very rare case it causes a
On 2016-08-30 01:14, Brett Cannon wrote:
> So the struct in question can be found at
> https://github.com/python/cpython/blob/2d264235f6e066611b412f7c2e1603866e0f7f1b/Include/code.h#L10
> .
> The official docs say the fields can be changed at any time, so
> re-arranging them shouldn't break any AB
On 8/30/2016 4:20 AM, Maciej Fijalkowski wrote:
On Tue, Aug 30, 2016 at 3:00 AM, Brett Cannon wrote:
On Mon, Aug 29, 2016, 17:06 Terry Reedy wrote:
On 8/29/2016 5:38 PM, Brett Cannon wrote:
who objected to the new field did either for memory ("it adds another
pointer to the struct that w
On 8/29/2016 10:59 PM, Nick Coghlan wrote:
By contrast (and assuming I understand the situation correctly), the
Windows build is already set up around the assumption that you'll need
to build OpenSSL yourself.
If one installs a minimal svn client and passes -e to Zack's wonderful
built.bat, c
Le 30 août 2016 03:10, "Nick Coghlan" a écrit :
> However, this view is also why I don't agree with being aggressive in
> making this behaviour the default on Windows - I think we should make
> it readily available as a provisional feature through a single
> cross-platform command line switch and
On Tue, Aug 30, 2016 at 3:00 AM, Brett Cannon wrote:
>
>
> On Mon, Aug 29, 2016, 17:06 Terry Reedy wrote:
>>
>> On 8/29/2016 5:38 PM, Brett Cannon wrote:
>>
>> > who objected to the new field did either for memory ("it adds another
>> > pointer to the struct that won't be typically used"), or for
59 matches
Mail list logo
