Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[Jeroen Demeyer]

On 2018-10-03 23:27, Guido van Rossum wrote:

IMO changes to the C API should be taken just as seriously -- the
potential for breaking the world is just about the same (since most
serious Python applications use C extensions that risk breaking).


Of course we are taking this seriously. I want this to be taken as 
seriously as any other PEP and any other BDFL-Delegate appointment in 
the past.


To be clear: I'm not trying to rush my PEP though. It has been discussed 
and I have made changes to it based on comments. In fact, this is the 
second PEP with the same subject, I withdrew the first one, PEP 575. At 
some point in the past I asked one person to become BDFL-Delegate but he 
did not answer. And now recently Petr Viktorin made some insightful 
comments on it, so I asked him and he agreed.

___
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

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[Jeroen Demeyer]

On 2018-10-03 18:55, Barry Warsaw wrote:

Correct.  It’s entirely possible that the different governance models will have 
different ways to pick delegates.


And how does that affect *today*'s decision? The new governance model 
will only take effect 1 January (assuming that everything goes as planned).


As long as there is no new governance model yet, can't we just continue 
the PEP 1 process which has worked for many years? I know that we cannot 
literally apply PEP 1 because there is no BDFL, but we can certainly 
continue the spirit of PEP 1 if the other core developers agree with the 
BDFL-Delegate.

___
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

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[Nick Coghlan]

On Thu., 4 Oct. 2018, 4:12 am Antoine Pitrou,  wrote:

> On Wed, 3 Oct 2018 22:51:24 +0900
> INADA Naoki  wrote:
> > 2018年10月3日(水) 21:24 Jeroen Demeyer :
> >
> > > Hello,
> > >
> > >
> > > I am well aware of the current governance issues, but several people
> > > have mentioned that the BDFL-Delegate process can still continue for
> > > now.
> >
> >
> > Really?
> > I don't know process to assign BDFL-delegate without BDFL.
>
> That's probably why we should call it "PEP-delegate" :-)
>
> Consensus would obviously work (if no-one opposes the proposed person,
> then surely we don't need an elaborate governance model to decree that
> said person can become the PEP delegate, no?).
>

I was figuring we could treat it as a caretaker mode governance: anything
we do before the new governance model is formalised is subject to
ratification by the new council members (or the new BDFL if that option
ends up being chosen).

In this case, I'd consider it unlikely for either the PEP delegate
appointment or any decisions about the PEP itself to be overturned - while
it's a complex topic that definitely needs to go through the PEP process in
order to work out the technical details, it isn't especially controversial
in its own right (the most controversial aspect is whether it needs a new C
level slot or not, and the PEP should clearly lay out the pros and cons of
that)

Cheers,
Nick.



> Regards
>
> Antoine.
>
>
> ___
> 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/ncoghlan%40gmail.com
>
___
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

Re: [Python-Dev] Should assert continue to do a LOAD_GLOBAL on AssertionError?

[Benjamin Peterson]

On Wed, Oct 3, 2018, at 08:59, Steven D'Aprano wrote:
> On the bug tracker, there's a discussion about the current behaviour of 
> the assert statement, where shadowing AssertionError will change the 
> behaviour of the assertion.
> 
> https://bugs.python.org/issue34880
> 
> Currently, assert does a LOAD_GLOBAL on AssertionError, which means if 
> you shadow the name, you get a different exception. This behaviour goes 
> back to Python 1.5.
> 
> I'm looking for guidance here, is this the intended behaviour, or an 
> accident? Should it be changed to better match other builtins?

The behavior certainly has been relied on historically by py.test. By replacing 
builtins.AssertionError, you can improve the error message of the 
AssertionError by, e.g., inspecting the failing frame. py.test's code to do 
this was deleted in 2016, but other code bases may still be relying on this 
hack. It's probably okay to change the behavior in 3.8 with the understanding 
that a revert may be necessary if some clever hack surfaces.
___
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

Re: [Python-Dev] bpo-34837: Multiprocessing.Pool API Extension - Pass Data to Workers w/o Globals

[Sean Harrington]

Hi guys -

The solution to "lazily initialize" an expensive object in the worker
process (i.e. via @lru_cache) is a great solution (that I must admit I did
not think of). Additionally, in the second use case of "*passing a large
object to each worker process*", I also agree with your suggestion to
"shelter functions in a different module to avoid exposure to globals" as a
good solution if one is wary of globals.

That said, I still think "*passing a large object from parent process to
worker processes*" should be easier when using Pool. Would either of you be
open to something like the following?

   def func(x, big_cache=None):
   return big_cache[x]

   big_cache =  { str(k): k for k in range(1) }

   ls = [ i for i in range(1000) ]

with Pool(func_kwargs={"big_cache": big_cache}) as pool:

pool.map(func, ls)


It's a much cleaner interface (which presumably requires a more difficult
implementation) than my initial proposal. This also reads a lot better than
the "initializer + global" recipe (clear flow of data), and is less
constraining than the "define globals in parent" recipe. Most importantly,
when taking sequential code and parallelizing via Pool.map, this does not
force the user to re-implement "func" such that it consumes a global
(rather than a kwarg). It allows "func" to be used elsewhere (i.e. in the
parent process, from a different module, testing w/o globals, etc...)..

This would essentially be an efficient implementation of Pool.starmap(),
where kwargs are static, and passed to each application of "func" over our
iterable.

Thoughts?


On Sat, Sep 29, 2018 at 3:00 PM Michael Selik  wrote:

> On Sat, Sep 29, 2018 at 5:24 AM Sean Harrington 
> wrote:
> >> On Fri, Sep 28, 2018 at 4:39 PM Sean Harrington 
> wrote:
> >> > My simple argument is that the developer should not be constrained to
> make the objects passed globally available in the process, as this MAY
> break encapsulation for large projects.
> >>
> >> I could imagine someone switching from Pool to ThreadPool and getting
> >> into trouble, but in my mind using threads is caveat emptor. Are you
> >> worried about breaking encapsulation in a different scenario?
> >
> > >> Without a specific example on-hand, you could imagine a tree of
> function calls that occur in the worker process (even newly created
> objects), that should not necessarily have access to objects passed from
> parent -> worker. In every case given the current implementation, they will.
>
> Echoing Antoine: If you want some functions to not have access to a
> module's globals, you can put those functions in a different module.
> Note that multiprocessing already encapsulates each subprocesses'
> globals in essentially a separate namespace.
>
> Without a specific example, this discussion is going to go around in
> circles. You have a clear aversion to globals. Antoine and I do not.
> No one else seems to have found this conversation interesting enough
> to participate, yet.


>>>

>
>
___
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

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[Guido van Rossum]

Well, it's not my call any more, so I'll happily stop arguing.

On Wed, Oct 3, 2018 at 3:19 PM Terry Reedy  wrote:

> On 10/3/2018 5:27 PM, Guido van Rossum wrote:
> > On Wed, Oct 3, 2018 at 2:13 PM Terry Reedy  > > wrote:
> >
> > A language syntax-change proposal would be something else.
> >
> >
> > IMO changes to the C API should be taken just as seriously -- the
> > potential for breaking the world is just about the same (since most
> > serious Python applications use C extensions that risk breaking).
>
> I agree.  My observation is that PEP-delegates have taken their
> responsibility *very* seriously, and I think that the evidence is that
> Petr would.  If you think otherwise, please explain.  On reason for a
> serious examination to start now is to allow adequate time.
>
> The difference I was referring to is the philosophical basis of and
> technical evaluation skill needed for a decision.  I feel competent to
> opine on syntax proposals, but not on technical details of CPyython
> calls.  Moreover, as long as an internal change does not break anything,
> and at least does not hinder writing C extensions, I have little reason
> to care, whereas syntax changes will affect me, even if they are 'good'
> changes.
>
> --
> Terry Jan Reedy
>
> ___
> 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/guido%40python.org
>


-- 
--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/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[Terry Reedy]

On 10/3/2018 5:27 PM, Guido van Rossum wrote:
On Wed, Oct 3, 2018 at 2:13 PM Terry Reedy > wrote:


A language syntax-change proposal would be something else.


IMO changes to the C API should be taken just as seriously -- the 
potential for breaking the world is just about the same (since most 
serious Python applications use C extensions that risk breaking).


I agree.  My observation is that PEP-delegates have taken their 
responsibility *very* seriously, and I think that the evidence is that 
Petr would.  If you think otherwise, please explain.  On reason for a 
serious examination to start now is to allow adequate time.


The difference I was referring to is the philosophical basis of and 
technical evaluation skill needed for a decision.  I feel competent to 
opine on syntax proposals, but not on technical details of CPyython 
calls.  Moreover, as long as an internal change does not break anything, 
and at least does not hinder writing C extensions, I have little reason 
to care, whereas syntax changes will affect me, even if they are 'good' 
changes.


--
Terry Jan Reedy

___
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

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[Guido van Rossum]

On Wed, Oct 3, 2018 at 2:13 PM Terry Reedy  wrote:

> A language syntax-change proposal would be something else.
>

IMO changes to the C API should be taken just as seriously -- the potential
for breaking the world is just about the same (since most serious Python
applications use C extensions that risk breaking).

-- 
--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/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[Terry Reedy]

On 10/3/2018 8:12 AM, Jeroen Demeyer wrote:

Hello,

I would like to propose Petr Viktorin as BDFL-Delegate for PEP 580, 
titled "The C call protocol". He has co-authored several PEPs (PEP 394, 
PEP 489, PEP 534, PEP 547, PEP 573), several of which involve extension 
modules.


Petr has agreed to become BDFL-Delegate for PEP 580 if asked. Also 
Antoine Pitrou, INADA Naoki and Nick Coghlan have approved Petr being 
BDFL-Delegate.


To me, three experienced core devs approving of a 4th person as 
PEP-examiner is sufficient to proceed on a CPython implementation 
proposal.  I don't think we need to be paralyzed on this.  And indeed, 
when it comes to sub-PEP C-API changes, we seem not to be.  This change, 
if made, should be early in the cycle for the next version, rather than 
landing just before the first beta.


A language syntax-change proposal would be something else.


--
Terry Jan Reedy

___
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

Re: [Python-Dev] Should assert continue to do a LOAD_GLOBAL on AssertionError?

[Antoine Pitrou]

On Thu, 4 Oct 2018 01:59:37 +1000
Steven D'Aprano  wrote:
> On the bug tracker, there's a discussion about the current behaviour of 
> the assert statement, where shadowing AssertionError will change the 
> behaviour of the assertion.
> 
> https://bugs.python.org/issue34880
> 
> Currently, assert does a LOAD_GLOBAL on AssertionError, which means if 
> you shadow the name, you get a different exception. This behaviour goes 
> back to Python 1.5.
> 
> I'm looking for guidance here, is this the intended behaviour, or an 
> accident? Should it be changed to better match other builtins?

I would make it an implementation detail myself, i.e. any
implementation is free to make it work as it prefers.

Regards

Antoine.


___
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

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[Antoine Pitrou]

On Wed, 3 Oct 2018 22:51:24 +0900
INADA Naoki  wrote:
> 2018年10月3日(水) 21:24 Jeroen Demeyer :
> 
> > Hello,
> >
> >
> > I am well aware of the current governance issues, but several people
> > have mentioned that the BDFL-Delegate process can still continue for
> > now.  
> 
> 
> Really?
> I don't know process to assign BDFL-delegate without BDFL.

That's probably why we should call it "PEP-delegate" :-)

Consensus would obviously work (if no-one opposes the proposed person,
then surely we don't need an elaborate governance model to decree that
said person can become the PEP delegate, no?).

Regards

Antoine.


___
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

Re: [Python-Dev] dear core-devs

[Michael Felt]

On 10/3/2018 1:46 AM, Neil Schemenauer wrote:
> On 2018-10-02, Michael Felt wrote:
>> I am sorry, for myself obviously - but also for Python. Obviously, I am
>> doing it all wrong - as I see lots of other issues being picked up
>> immediately.
> I'm not sure that's the case.  There are a lot of PRs or bugs that
> sit there without getting reviews.  The problem is that few (or no)
> core developers get paid to work on Python.  So, the time they spend
> is motivated by their specific "itch".  Getting reviews on any PR is
> difficult, even for core developers.  In their case, they have to
> option of forcing the issue, I guess.
>
> This is a problem we should try to deal with somehow.  Turning off
> valuable contributors like you is bad.  I'm not sure how to do it
> though.  At the core Python sprint in September there was some talk
> about how CPython developers might get funding.  Maybe that could
> help deal with the backlog of reviews required.
>
>> And, while you may not give a damn about anything other than Windows,
>> macos and/or Linux - there are other platforms that would like a stable
>> Python.
> There is probably some truth in not caring about other platforms.
> The problem from the reviewer perspective is the question of "what
> is the potential downsides of this PR vs what are the benefits?".
> The safest thing is to not approve the PR.  No core developer wants
> to be the person who broke CPython.  You must admit, AIX is an
> extremely niche platform at this point.  I bet if you picked 1000
> software developers at random, it would be likely that zero of them
> have ever used AIX.  So, it's not that we don't care at all about
> AIX but that the cost/benefit equation makes accepting AIX specific
> changes more difficult.
Nods. However - this is a chicken/egg issue (imho). AIX is seen a weak
platform because noone has ever tackled these. When I started on this I
had never expected to have found a resolution to them all.

Platforms have differences and when the tests miss that difference that
the tests give a false result. e.g., one accepted PR was because AIX
libc printf() output for printf(NULL) is "" while other platforms output
"(null)".


>
> One specific suggestion I have about your PR is to try to make your
> changes not AIX specific.  Or at least, make the AIX checking as
> localized as possible.  So, as an example, in test_uuid you have:
>
> _notAIX = not sys.platform.startswith("aix")
a) I thought/hoped this was better practice and performance - calling 
sys.platform.startswith("aix")only once, rather than X times.
b) more maintainable (e.g., change to not platform.system()
c) iirc - this got changed to AIX = , and throughout the test is "if
not AIX"...
>
> then later in the module you check that flag.  While that is the
> most direct approach to fixing the issue and making the test pass,
> it is not good for the long term maintainability of the code.  You
> end up with boolean flags like _notAIX spread about the logic.  Over
> time, code like that becomes a nightmare to maintain.
>
> Instead, I would suggest test_uuid is making platform specific
> assumptions that are not true on AIX and possibly other platforms.
> So, do something like:
>
> 
> _IS_AIX = sys.platform.startswith("aix")
better name.
>
> _HAVE_MACADDR = (os.name == 'posix' and not _IS_AIX)
AIX has MACADDR, but formatted with '.' rather than ':' and uses a
single hex-digit when value between dots is < 16 (decimal)
>
> @unittest.skipUnless(_HAVE_MACADDR, 'requires Posix with macaddr')
> def test_arp_getnode(self):
> ...
>
> The _HAVE_MACADDR test is relatively simple and clear, does this
> platform have this capability.  Later in the code, a check for
> _HAVE_MACADDR is also quite clear.  If someone comes along with
> another platform that doesn't support macaddr, they only have to
> change one line of code.
>
> This kind of capability checking is similar to what happened with
> web browsers.  In that case, people discovered that checking the
> User Agent header was a bad idea.  Instead, you should probe for
> specific functionality and not assume based on browser IDs.  For the
> macaddr case, is there some way to you probe the arp command to see
> if supports macaddr? 
I suppose if someone had written the original test with "check program
to see if ..." it would have worked already.
I am trying to get current tests to work with minimal changes.

I am certainly not "blaming" anyone for not knowing this unique behavior
of this platform. Before debugging this I did not know of the difference
either. I agree that wherever a generic resolution is possible - it
should be done. However, as an "outsider" I do not feel empowered enough
to propose such a change to existing (and well proven for other
platforms) tests.
>  That way your test doesn't have to include any
> AIX specific check at all.  Further, it would have some hope of
> working on platforms other than AIX that also don't support mac

Re: [Python-Dev] Should assert continue to do a LOAD_GLOBAL on AssertionError?

[Guido van Rossum]

Feels like an accident to me. Generally syntactic constructs should be
unaffected by what's in any namespace except when the override is
intentional (e.g. __import__).

On Wed, Oct 3, 2018 at 9:02 AM Steven D'Aprano  wrote:

> On the bug tracker, there's a discussion about the current behaviour of
> the assert statement, where shadowing AssertionError will change the
> behaviour of the assertion.
>
> https://bugs.python.org/issue34880
>
> Currently, assert does a LOAD_GLOBAL on AssertionError, which means if
> you shadow the name, you get a different exception. This behaviour goes
> back to Python 1.5.
>
> I'm looking for guidance here, is this the intended behaviour, or an
> accident? Should it be changed to better match other builtins?
>
> (For example, shadowing iter doesn't effect for loops.)
>
>
> Thanks,
>
>
> Steve
> ___
> 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/guido%40python.org
>


-- 
--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/python-dev/archive%40mail-archive.com

Re: [Python-Dev] dear core-devs

[Michael Felt]

On 10/3/2018 2:48 AM, Terry Reedy wrote:
> On 10/2/2018 7:16 PM, Michael Felt wrote:
>>
>>
>> On 10/2/2018 11:34 PM, Terry Reedy wrote:
>>> On 10/2/2018 12:41 PM, Simon Cross wrote:
 Are there any core devs that Michael or Erik could collaborate with?
 Rather than rely on adhoc patch review from random core developers.
>>>
>>> You two might collaborate with each other to the extent of reviewing
>>> some of each other's PRs.
>
>> Might be difficult. We both, or at least I, claim ignorance of the
>> others platform.
>
> Partial reviews, short of accept/change are better than no review and
> can make a merge decision easier for a core dev.  You should each be
> or become familiar with PEP 7 and somewhat familiar with local C
> idioms. Do names follow local standards.  Do C-API calls make sense.
Sounds simple enough. The tricky part is "the details".
>
> >>  I still have a lot of PEP to learn, and my idea of a
> >> bug-fix (for Python2) was seen by core-dev as a feature change.
>
> Failures of current tests would seem to me to be bugs.  However, some
> bug fixes require a feature change.  It is an awkward situation.  We
> are increasingly reluctant to patch 2.7.
Some are quite simple to fix, even if hard to find: such as:
"elif cmd is None:" -> "elif notcmd orcmd is None:"

Some are not bugs at all - very hard to find! Instead, "textual"
differences because a library is overly optimized - the expected
exception occurs - but no error message. Linking with a less optimized
(libssl.a and libcrypto.a) resolved many reported test "failures".

Nearly three years ago I was keen to see things in Python2(.7), but not
so much now. I also feel the time is to push hard towards current
Python3 versions.
>
>>> That still leaves the issue of merging.
>> How much confidence is there in all the "CI" tests? Does that not offer
>> sufficient confidence for a core-dev to press merge.
>
> Code for new features or bugs that escaped the tests should have new
> tests.  AIX-specific code should (as in must ;-) be tested before
> being submitted, since it will not be properly tested by CI.  With CI
> now covering Windows twice, Linux twice, and Mac, I believe it has
> become rarer for buildbots to fail after CI passes.  Victor would know.
>
> I  believe that you are initially dealing with bugs that do not pass
> current tests.
I am dealing with tests that do not pass. The dilemma: what is wrong -
the test, or what it is testing? Generally speaking, I cannot call
Python3 (master) broken. So I look for a "root cause" in a test
assumption that is wrong, and find a way to correct that.

Sometimes, it is a bit of both - and those are very hard to resolve
without feedback.

See the discussion, elsewhere, regarding MACADDR. It has never been that
platform Y does not have a MACADDR - rather, platform Y formats it
differently than (all) other platforms.

>
>> How about "master" continuing to be what it is, but insert a new
>> "pre-master" branch that the buildbots actually test on (e.g., what is
>> now the 3.X) and have a 3.8 buildbot - for what is now the "master".
>>
>> PR would still be done based on master, but an "initial" merge would be
>> via the pre-master aka 3.X buildbot tests.
>>
>> How "friendly" git is - that it not become such a workload to keep it
>> clean - I cannot say. Still learning to use git. Better, but still do
>> not want to assume it would be easy.
>
> Too complicated.
>
>> My hope is that it would make it easier to consider a "merge" step that
>> gets all the buildbots involved for even broader CI tests.
>
> I considered the wider buildbot fleet to be post-merge CI ;-).
>
>>> I think for tests, a separate test_aix.py might be a good idea for
>>> aix-only tests
>
> I may be wrong on this.
>
> ___
> 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/aixtools%40felt.demon.nl

___
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

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[Barry Warsaw]

On Oct 3, 2018, at 08:06, Łukasz Langa  wrote:
> 
>> On 3 Oct 2018, at 15:51, INADA Naoki  wrote:
>> 
>> Really?
>> I don't know process to assign BDFL-delegate without BDFL.
> 
> My understand is that accepting *any* PEP by anyone is out of the question 
> until the governance situation gets resolved. That's the only reason why PEP 
> 544 is not yet accepted for example.

Correct.  It’s entirely possible that the different governance models will have 
different ways to pick delegates.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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

[Python-Dev] PEP 544 status (forked off "Petr Viktorin as BDFL-Delegate for PEP 580")

[Guido van Rossum]

The process for PEP 544 is off-topic for that thread so I'm starting a new
one.

I have promised its author to approve it after certain minor changes (that
we both agree on) have been made. It's not an example of how PEP acceptance
in general will works until governance is sorted out though -- PEP 544 is a
very unique special case. (For one, it's uncontroversial -- the reason it's
not been accepted yet is that its author is busy with other things.)

On Wed, Oct 3, 2018 at 9:12 AM Jeroen Demeyer  wrote:

> On 2018-10-03 17:06, Łukasz Langa wrote:
> > That's the only
> > reason why PEP 544 is not yet accepted for example.
>
> Did you actually try to get PEP 544 accepted or to appoint a
> BDFL-Delegate? I don't find any discussions about PEP 544 after the
> stepping down of the BDFL.
>

-- 
--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/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[Jeroen Demeyer]

On 2018-10-03 17:06, Łukasz Langa wrote:

That's the only
reason why PEP 544 is not yet accepted for example.


Did you actually try to get PEP 544 accepted or to appoint a 
BDFL-Delegate? I don't find any discussions about PEP 544 after the 
stepping down of the BDFL.

___
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

[Python-Dev] Should assert continue to do a LOAD_GLOBAL on AssertionError?

[Steven D'Aprano]

On the bug tracker, there's a discussion about the current behaviour of 
the assert statement, where shadowing AssertionError will change the 
behaviour of the assertion.

https://bugs.python.org/issue34880

Currently, assert does a LOAD_GLOBAL on AssertionError, which means if 
you shadow the name, you get a different exception. This behaviour goes 
back to Python 1.5.

I'm looking for guidance here, is this the intended behaviour, or an 
accident? Should it be changed to better match other builtins?

(For example, shadowing iter doesn't effect for loops.)


Thanks,


Steve
___
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

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[Jeroen Demeyer]

On 2018-10-03 17:12, Wes Turner wrote:
> AFAIU, there is not yet a documented process for BDFL-delegate assignment.

PEP 1 says:

"""
However, whenever a new PEP is put forward, any core developer that
believes they are suitably experienced to make the final decision on
that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for
that PEP. If their self-nomination is accepted by the other core
developers and the BDFL, then they will have the authority to approve
(or reject) that PEP.
"""

I know that it says "core developers and the BDFL". However, if the core
developers agree that Petr can become BDFL-Delegate, I don't see why
that wouldn't be possible.


Jeroen.
___
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

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[Wes Turner]

On Wednesday, October 3, 2018, INADA Naoki  wrote:

>
> 2018年10月3日(水) 21:24 Jeroen Demeyer :
>
>> Hello,
>>
>>
>> I am well aware of the current governance issues, but several people
>> have mentioned that the BDFL-Delegate process can still continue for
>> now.
>
>
> Really?
> I don't know process to assign BDFL-delegate without BDFL.
>

AFAIU, there is not yet a documented process for BDFL-delegate assignment.

There's this in the devguide; which links to PEP1:

"20.2. PEP Process¶"
https://devguide.python.org/langchanges/#pep-process
https://github.com/python/devguide/blob/master/langchanges.rst


And PEP 1:

"PEP 1 -- PEP Purpose and Guidelines"
  "PEP Workflow"
https://www.python.org/dev/peps/pep-0001/#pep-workflow
  "PEP Editors"
https://www.python.org/dev/peps/pep-0001/#pep-editors
  "PEP Editor Responsibilities & Workflow"
https://www.python.org/dev/peps/pep-0001/#pep-editor-responsibilities-workflow

https://github.com/python/peps/blob/master/pep-0001.txt

And the devguide has a list of experts:
https://devguide.python.org/experts/


Maybe PEP1 is the place to list current BDFL-Delegates
(in addition to in the PEP metadata as in the OT PR:
python/peps#797
"PEP 580: Petr Viktorin as BDFL-Delegate"
)?


Not to bikeshed, but is BDFL-Delegate still the current term because that's
what's in all the other PEPs' metadata?


>
> This PEP is mainly for third party tools.
> I want to get much feedback from them before new APIs become stable (e.g.
> 3.8b1)
>
> So I want this PEP is approved (or
> Provisionally Accepted) and reference implementation is merged as fast as
> possible.
>
> Regards,
>
>>
>>
___
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

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[Łukasz Langa]

> On 3 Oct 2018, at 17:06, Łukasz Langa  wrote:
> 
> My understand is

🤦🏻‍♂️

...and no ability to edit to correct it. It's like this forever now, my grand 
children will ridicule me for this.

- Ł


signature.asc
Description: Message signed with OpenPGP
___
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

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[Łukasz Langa]

> On 3 Oct 2018, at 15:51, INADA Naoki  wrote:
> 
> 
> 2018年10月3日(水) 21:24 Jeroen Demeyer  >:
> Hello,
> 
> 
> I am well aware of the current governance issues, but several people
> have mentioned that the BDFL-Delegate process can still continue for
> now.
> 
> Really?
> I don't know process to assign BDFL-delegate without BDFL.

My understand is that accepting *any* PEP by anyone is out of the question 
until the governance situation gets resolved. That's the only reason why PEP 
544 is not yet accepted for example.

- Ł


signature.asc
Description: Message signed with OpenPGP
___
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

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[INADA Naoki]

2018年10月3日(水) 21:24 Jeroen Demeyer :

> Hello,
>
>
> I am well aware of the current governance issues, but several people
> have mentioned that the BDFL-Delegate process can still continue for
> now.


Really?
I don't know process to assign BDFL-delegate without BDFL.


This PEP is mainly for third party tools.
I want to get much feedback from them before new APIs become stable (e.g.
3.8b1)

So I want this PEP is approved (or
Provisionally Accepted) and reference implementation is merged as fast as
possible.

Regards,

>
>
___
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

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[Wes Turner]

On Wednesday, October 3, 2018, Jeroen Demeyer  wrote:

> Hello,
>
> I would like to propose Petr Viktorin as BDFL-Delegate for PEP 580, titled
> "The C call protocol". He has co-authored several PEPs (PEP 394, PEP 489,
> PEP 534, PEP 547, PEP 573), several of which involve extension modules.
>
> Petr has agreed to become BDFL-Delegate for PEP 580 if asked. Also Antoine
> Pitrou, INADA Naoki and Nick Coghlan have approved Petr being BDFL-Delegate.
>
> I am well aware of the current governance issues, but several people have
> mentioned that the BDFL-Delegate process can still continue for now. I
> created a PR for the peps repository at https://github.com/python/peps
> /pull/797


+1. Are we doing upvotes on the mailing list or on the GitHub PR and/or
issue now?

"[Python-ideas] PEPs: Theory of operation"
https://markmail.org/thread/zr4o6l7ivnj4irtp

"""
Process suggestions that could minimize non-BDFL's BDFL legwork:

[...]

* Use GitHub reactions for voting on BDFL delegates, PEP final approval,
and PEP sub issues?
  * Specify a voting deadline?
  * How to make a quorum call?
  * Add '@core/team' as reviewers for every PEP?


* Link to the mailing list thread(s) at the top of the PR
  * [ ] Add unique message URLs to footers with mailman3


* What type of communications are better suited for mailing lists over PEP
pull-requests and PEP code reviews?
[The original thread is probably a better place to discuss PEP process
going forward]
"""


>
>
> Cheers,
> Jeroen Demeyer.
> ___
> 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/wes.
> turner%40gmail.com
>
___
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

[Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

[Jeroen Demeyer]

Hello,

I would like to propose Petr Viktorin as BDFL-Delegate for PEP 580, 
titled "The C call protocol". He has co-authored several PEPs (PEP 394, 
PEP 489, PEP 534, PEP 547, PEP 573), several of which involve extension 
modules.


Petr has agreed to become BDFL-Delegate for PEP 580 if asked. Also 
Antoine Pitrou, INADA Naoki and Nick Coghlan have approved Petr being 
BDFL-Delegate.


I am well aware of the current governance issues, but several people 
have mentioned that the BDFL-Delegate process can still continue for 
now. I created a PR for the peps repository at 
https://github.com/python/peps/pull/797



Cheers,
Jeroen Demeyer.
___
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

Re: [Python-Dev] dear core-devs

[Erik Bray]

On Tue, Oct 2, 2018 at 8:54 PM Michael Felt  wrote:
>
>
>
> On 10/2/2018 4:45 PM, Erik Bray wrote:
> > Michael, if there are any PRs you want to point me to that I might be
> > able to help review please do.
> A little trick I learned:
> https://github.com/python/cpython/pulls?q=is%3Aopen+is%3Apr+author%3Aaixtools+sort%3Aupdated-desc
> lists them all.

Cool, I'll have a look.

> What "flipped my switch" yesterday was discovering a PR that I was
> gifted (by an ex? core-dev) and put in the system back in January is now
> broken by a patch merged about two weeks ago. Worse, pieces of
> test_ctypes(bitfields) that previously worked when using __xlc__ seem to
> be broken. Which highlighted the "time pressure" of getting tests to
> pass so that regressions can be seen.

Yes, that can certainly happen.  I have many PRs floating around on
different projects that, you know, get stalled for months and months
and inevitably break.  It's extremely frustrating, but we've all been
there :)

> If you let me know what info you would need (I gave lots of debug info
> two years ago to get that initial fix).
>
> And, I guess the other "larger" change re: test_distutils. Also, some
> issues specific to xlc being different from gcc.
>
> Those two do not show on the gccfarm buildbot.
>
> Many thanks for the offer! I'll try to not take more than the hand offered!
> >   I don't know anything about AIX either
> > and am not a core dev so I can't have a final say.  But I've been
> > hacking on CPython for a long time anyways, and might be able to help
> > at least with some initial review.

I also about to ask if you have a buildbot for AIX, and I see now you
have several. So step in the right direction!
___
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

Re: [Python-Dev] dear core-devs

[Erik Bray]

On Tue, Oct 2, 2018 at 6:41 PM Simon Cross
 wrote:
>
> Are there any core devs that Michael or Erik could collaborate with?
> Rather than rely on adhoc patch review from random core developers.
>
> Michael and Eric: Question -- are you interested in becoming core
> developers at least for the purposes of maintaining these platforms in
> future?

I would be for the purposes of said platform maintenance.  I believe I
already have some maintainer permissions on bpo for exactly this
reason.

That said, while I'm sure it would help, I'm not exactly sure what it
would solve either.  I believe strongly in code review, and just
having a "core developer" status does not necessarily free one from
responsibility for obtaining code review.

It also partly depends on the issue.  If it's a change that touches
other parts of the code in ways that could impact it beyond the narrow
scope of platform support, I believe it definitely should get a second
pair of eyes.  Unfortunately many of the outstanding patches I have
for review fall in that category.  Though in the future there will be
fewer like that.  The majority of work needed for Cygwin, at least, is
tweaking some areas of the tests that make assumptions that don't
necessarily hold on that platform.*

Thanks,
E


* For example, there are some tests that assume there is a user with
UID 0.  While UID 0 is reserved for a "superuser", I don't know that
there's any requirement that such a user *must* exist (on Cygwin it
does not :)
___
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