On Oct 4, 2017, at 21:52, Nick Coghlan wrote:
>
>> Unfortunately we probably won’t really get a good answer in practice until
>> Python 3.7 is released, so maybe I just choose one and document that the
>> behavior of PYTHONBREAKPOINT under -E is provision for now. If that’s
>> acceptable, the
Yarko, there's one thing I don't understand. Maybe you can enlighten me.
Why would you prefer
breakpoint(x >= 1000)
over
if x >= 1000: breakpoint()
?
The latter seems unambiguous and requires thinking all around. Is there
something in iPython that makes this impractical?
--
--Guido van Rossu
On 5 October 2017 at 10:28, Barry Warsaw wrote:
>> """Special cases aren't special enough to break the rules."""
>>
>> People expect -E to disable envvar-driven overrides, so just treat it
>> like that and don't try to second-guess the user.
>
> And of course "Although practicality beats purity.”
On 4 October 2017 at 23:51, Eric Snow wrote:
> On Tue, Oct 3, 2017 at 11:36 PM, Nick Coghlan wrote:
>> The problem relates to the fact that there aren't any memory barriers
>> around CPython's INCREF operations (they're implemented as an ordinary
>> C post-increment operation), so you can get the
On Wed, Oct 4, 2017 at 7:50 PM, Barry Warsaw wrote:
> On Oct 4, 2017, at 20:22, Yarko Tymciurak wrote:
>
> > I've recently started using a simple conditional breakpoint in ipython,
> and wonder if - in addition to Nick Coghlan's request for the env
> 'PYTHONBREAKPOINT' (boolean?), it would mak
On 10/4/2017 5:22 PM, Yarko Tymciurak wrote:
Barry suggested I bring this up here.
It seems the right time to at least discuss this:
RE: PEP 553 enabling / disabling breakpoints ---
I've recently started using a simple conditional breakpoint in
ipython, and wonder if - in addition to Nick C
On Oct 4, 2017, at 20:22, Yarko Tymciurak wrote:
> I've recently started using a simple conditional breakpoint in ipython, and
> wonder if - in addition to Nick Coghlan's request for the env
> 'PYTHONBREAKPOINT' (boolean?), it would make sense (I _think_ so) to add a
> condition parameter to
> """Special cases aren't special enough to break the rules."""
>
> People expect -E to disable envvar-driven overrides, so just treat it
> like that and don't try to second-guess the user.
And of course "Although practicality beats purity.” :)
So while I agree that the consistency argument make
Barry suggested I bring this up here.
It seems the right time to at least discuss this:
RE: PEP 553 enabling / disabling breakpoints ---
I've recently started using a simple conditional breakpoint in ipython, and
wonder if - in addition to Nick Coghlan's request for the env
'PYTHONBREAKPOINT'
On Wed, Oct 04, 2017 at 03:56:14PM -0700, VERY ANONYMOUS wrote:
> i want to learn
Start by learning to communicate in full sentences. You want to learn
what? Core development? Python? How to program? English?
This is not a mailing list for Python beginners. Try the "tutor" or
"python-list" mai
i want to learn
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Well that also makes sense.
On Wed, Oct 4, 2017 at 1:52 PM, Antoine Pitrou wrote:
> On Wed, 4 Oct 2017 14:06:48 -0400
> Barry Warsaw wrote:
> > Victor brings up a good question in his review of the PEP 553
> implementation.
> >
> > https://github.com/python/cpython/pull/3355
> > https://bugs.py
On Wed, 4 Oct 2017 14:06:48 -0400
Barry Warsaw wrote:
> Victor brings up a good question in his review of the PEP 553 implementation.
>
> https://github.com/python/cpython/pull/3355
> https://bugs.python.org/issue31353
>
> The question is whether $PYTHONBREAKPOINT should be ignored if -E is give
Treating -E as PYTHONBREAKPOINT=0 makes sense.
On Wed, Oct 4, 2017 at 11:06 AM, Barry Warsaw wrote:
> Victor brings up a good question in his review of the PEP 553
> implementation.
>
> https://github.com/python/cpython/pull/3355
> https://bugs.python.org/issue31353
>
> The question is whether $
Victor brings up a good question in his review of the PEP 553 implementation.
https://github.com/python/cpython/pull/3355
https://bugs.python.org/issue31353
The question is whether $PYTHONBREAKPOINT should be ignored if -E is given?
I think it makes sense for $PYTHONBREAKPOINT to be sensitive to
On Wed, Oct 4, 2017, at 07:14, Barry Warsaw wrote:
> On Oct 3, 2017, at 13:29, Benjamin Peterson wrote:
>
> > I'm not sure turning the implementation details of our internal formats
> > into APIs is the way to go.
>
> I still think an API in the stdlib would be useful and appropriate, but
> it
On Wed, 4 Oct 2017 17:50:33 +0200
Antoine Pitrou wrote:
> On Mon, 2 Oct 2017 21:31:30 -0400
> Eric Snow wrote:
> >
> > > By contrast, if we allow an actual bytes object to be shared, then
> > > either every INCREF or DECREF on that bytes object becomes a
> > > synchronisation point, or else we
On Wed, 4 Oct 2017 09:39:21 -0400
Barry Warsaw wrote:
> On Oct 4, 2017, at 05:52, Victor Stinner wrote:
>
> > My problem is that almost all changes go into "Library" category. When
> > I read long changelogs, it's sometimes hard to identify quickly the
> > context (ex: impacted modules) of a cha
On Wed, 4 Oct 2017 15:22:48 +0200
Victor Stinner wrote:
> 2017-10-04 14:36 GMT+02:00 Antoine Pitrou :
> > If there's a crash in socket.sendmsg() that affects mainly
> > multiprocessing, should it be in "Networking", "Security" or
> > "Parallelism"?
>
> bugs.python.org allows you to select zero
On Wed, 4 Oct 2017 10:14:22 -0400
Barry Warsaw wrote:
> On Oct 3, 2017, at 13:29, Benjamin Peterson wrote:
>
> > I'm not sure turning the implementation details of our internal formats
> > into APIs is the way to go.
>
> I still think an API in the stdlib would be useful and appropriate, but
On Wed, Oct 4, 2017 at 4:51 PM, Eric Snow
wrote:
> On Tue, Oct 3, 2017 at 11:36 PM, Nick Coghlan wrote:
> > The problem relates to the fact that there aren't any memory barriers
> > around CPython's INCREF operations (they're implemented as an ordinary
> > C post-increment operation), so you can
On Mon, 2 Oct 2017 21:31:30 -0400
Eric Snow wrote:
>
> > By contrast, if we allow an actual bytes object to be shared, then
> > either every INCREF or DECREF on that bytes object becomes a
> > synchronisation point, or else we end up needing some kind of
> > secondary per-interpreter refcount whe
On Oct 3, 2017 9:55 AM, "Serhiy Storchaka" wrote:
While PEP 552 is accepted, I would want to see some changes.
1. Increase the size of the constant part of the signature to at least 32
bits. Currently only the third and forth bytes are constant, and they are
'\r\n', that is often occurred in tex
On Oct 3, 2017, at 13:29, Benjamin Peterson wrote:
> I'm not sure turning the implementation details of our internal formats
> into APIs is the way to go.
I still think an API in the stdlib would be useful and appropriate, but it’s
not like this couldn’t be done as a 3rd party module.
-Barry
On Wed, Oct 4, 2017 at 4:04 PM, Nick Coghlan wrote:
> On 4 October 2017 at 22:45, Koos Zevenhoven wrote:
> > On Wed, Oct 4, 2017 at 3:33 PM, Nick Coghlan wrote:
> >> That's not a backwards compatibility problem, because the only way to
> >> encounter it is to update your code to rely on the new
On Tue, Oct 3, 2017 at 11:36 PM, Nick Coghlan wrote:
> The problem relates to the fact that there aren't any memory barriers
> around CPython's INCREF operations (they're implemented as an ordinary
> C post-increment operation), so you can get the following scenario:
>
> * thread on CPU A has the
On Oct 4, 2017, at 05:52, Victor Stinner wrote:
> My problem is that almost all changes go into "Library" category. When
> I read long changelogs, it's sometimes hard to identify quickly the
> context (ex: impacted modules) of a change.
>
> It's also hard to find open bugs of a specific module o
2017-10-04 14:36 GMT+02:00 Antoine Pitrou :
> If there's a crash in socket.sendmsg() that affects mainly
> multiprocessing, should it be in "Networking", "Security" or
> "Parallelism"?
bugs.python.org allows you to select zero or *multiple* categories :-)
It's common that categories of a bug evol
On 4 October 2017 at 22:45, Koos Zevenhoven wrote:
> On Wed, Oct 4, 2017 at 3:33 PM, Nick Coghlan wrote:
>> That's not a backwards compatibility problem, because the only way to
>> encounter it is to update your code to rely on the new extended
>> protocol - your *existing* code will continue to
On Wed, Oct 4, 2017 at 3:33 PM, Nick Coghlan wrote:
> On 4 October 2017 at 20:22, Koos Zevenhoven wrote:
> > On Wed, Oct 4, 2017 at 8:07 AM, Nick Coghlan wrote:
> >>
> >> On 3 October 2017 at 03:13, Koos Zevenhoven wrote:
> >> > Well, it's not completely unrelated to that. The problem I'm talk
On Wed, 4 Oct 2017 11:52:32 +0200
Victor Stinner wrote:
>
> It's also hard to find open bugs of a specific module on
> bugs.python.org, since almost all bugs are in the very generic
> "Library" category. Using full text returns "false positives".
>
> I would prefer to see more specific categorie
On 4 October 2017 at 20:22, Koos Zevenhoven wrote:
> On Wed, Oct 4, 2017 at 8:07 AM, Nick Coghlan wrote:
>>
>> On 3 October 2017 at 03:13, Koos Zevenhoven wrote:
>> > Well, it's not completely unrelated to that. The problem I'm talking
>> > about
>> > is perhaps most easily seen from a simple co
On Wed, Oct 4, 2017 at 5:52 AM, Victor Stinner
wrote:
> Hi,
>
> Python uses a few categories to group bugs (on bugs.python.org) and
> NEWS entries (in the Python changelog). List used by the blurb tool:
>
> #.. section: Security
> #.. section: Core and Builtins
> #.. section: Library
> #.. sectio
On Wed, Oct 4, 2017 at 8:07 AM, Nick Coghlan wrote:
> On 3 October 2017 at 03:13, Koos Zevenhoven wrote:
> > Well, it's not completely unrelated to that. The problem I'm talking
> about
> > is perhaps most easily seen from a simple context manager wrapper that
> uses
> > composition instead of i
Hi,
Python uses a few categories to group bugs (on bugs.python.org) and
NEWS entries (in the Python changelog). List used by the blurb tool:
#.. section: Security
#.. section: Core and Builtins
#.. section: Library
#.. section: Documentation
#.. section: Tests
#.. section: Build
#.. section: Wind
35 matches
Mail list logo
