[Python-Dev] Workflow PEP proposals are now closed

[Brett Cannon]

The PEPs under consideration are PEPs 474
 and 462
 from Nick Coghlan to use
Kallithea and do self-hosting, and PEP 481
 from Donald Stufft that
proposes using GitHub.

At this point I expect final PEPs by PyCon US so I can try and make a
decision by May 1. Longer still is to hopefully have whatever solution we
choose in place right after Python 3.5 is released.

And just a reminder to people, the lofty goal is to improve the overall
workflow for CPython itself such that our patch submission queue can
actually be cleared regularly. This not only benefits core devs by letting
us be more effective, but also contributors by making sure their hard work
gets addressed quickly and thus doesn't languish on the issue tracker for
very long.

If we can't find a solution for fixing our CPython workflow I will then be
willing to entertain these PEPs narrowing their scopes and only focus on
ancillary repos like the devguide, etc. where the workflows are simple.

I know the absolute worst case is nothing changes, but honestly I think the
worst case is Nick's work gets us off of Rietveld, the ancillary repos move
to GitHub, and we make the GitHub and Bitbucket mirrors of CPython official
ones for people to work from (bonus points if we get the issue tracker to
have push button patch pulling from GitHub; Bitbucket is already covered
thanks to our remote hg repo support). IOW I see nothing but a win for
contributors and core devs as well as everyone proposing solutions which is
a nice place to start from. =)
___
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] Workflow improvement PEPs 474 & 462 updated

[Pierre-Yves David]

On 02/02/2015 01:11 AM, Nick Coghlan wrote:


On 2 Feb 2015 04:56, "francis" mailto:franci...@email.de>> wrote:
 >
 > Hi Nick,
 >
 > On 02/01/2015 08:46 AM, Nick Coghlan wrote:
 > [...]
 > > The updates to PEP 462, which covers proposed changes to the main
 > > CPython workflow, were more significant, as I've now rewritten that to
 > > depend on PEP 474, and propose replacing the current Rietveld patch
 > > review workflow with an updated approach based on Kallithea and Zuul:
 > > https://www.python.org/dev/peps/pep-0462/
 > >
 >
 >
 > A small question on:
 > """
 > Push races would also be a thing of the past - if lots of core
 > developers are approving patches at a sprint, then that just means the
 > queue gets deeper in Zuul, rather than developers getting frustrated
 > trying to merge changes and failing.
 > """
 > How does the Tool Zuul resolve the case where the patches are not fully
 > compatible. E.g. they touch the same file and some manually merging is
 > needed? (Isn't that a push race? or I'm missing something?)

That's an actual merge conflict, the push races I'm referring to are the
ones where there's no conflict, but Mercurial objects to the non-linear
history. Zuul takes care of linearising everything and making sure the
tests pass before committing the change to the relevant branch.


On this topic, Facebook recently open-sourced a mercurial extension 
doing server side rebasing to linearise history in simple cases. special 
flag during push will get your new changes seamlessly rebased on the new 
head. This however does not run the tests so the Zuul approach is more 
complete.



 > PS: Should this be forwarded to python-workflow or is that other list to
 > be considered obsolete?

I withdrew from participating in that list when an individual banned
from the core mailing lists and the issue tracker for persistently
failing to respect other participants in those communities chose to
participate in it despite an explicit request from me that he refrain
from doing so (after wasting years trying to coach him into more
productive modes of engagement, I now just cut my losses and flat out
refuse to work in any environment where he has a significant presence).

Since our moderation practices don't currently include a way to request
transferring bans between lists, and I'm reluctant to push for that to
change when I have such a clear personal stake in the outcome (it reads
like a personal vendetta against the individual concerned), that's the
way things are likely to stay unless/until he also gets himself banned
from the core workflow list.


Without emitting any judgment on your decision, I'm deeply sad that this 
list have been "abandoned".


--
Pierre-Yves David
___
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] Workflow improvement PEPs 474 & 462 updated

[Brett Cannon]

On Mon Feb 02 2015 at 9:52:29 AM Pierre-Yves David <
pierre-yves.da...@ens-lyon.org> wrote:

>
>
> On 02/02/2015 01:11 AM, Nick Coghlan wrote:
> >
> > On 2 Feb 2015 04:56, "francis"  > > wrote:
> [SNIP]
> >  > PS: Should this be forwarded to python-workflow or is that other list
> to
> >  > be considered obsolete?
> >
> > I withdrew from participating in that list when an individual banned
> > from the core mailing lists and the issue tracker for persistently
> > failing to respect other participants in those communities chose to
> > participate in it despite an explicit request from me that he refrain
> > from doing so (after wasting years trying to coach him into more
> > productive modes of engagement, I now just cut my losses and flat out
> > refuse to work in any environment where he has a significant presence).
> >
> > Since our moderation practices don't currently include a way to request
> > transferring bans between lists, and I'm reluctant to push for that to
> > change when I have such a clear personal stake in the outcome (it reads
> > like a personal vendetta against the individual concerned), that's the
> > way things are likely to stay unless/until he also gets himself banned
> > from the core workflow list.
>
> Without emitting any judgment on your decision, I'm deeply sad that this
> list have been "abandoned".
>

Others do participate there so the list is not dead or abandoned, simply
that Nick is not participating on that list.
___
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] Workflow PEP proposals are now closed

[Donald Stufft]

> On Feb 2, 2015, at 9:35 AM, Brett Cannon  wrote:
> 
> The PEPs under consideration are PEPs 474 
>  and 462 
>  from Nick Coghlan to use 
> Kallithea and do self-hosting, and PEP 481 
>  from Donald Stufft that proposes 
> using GitHub.
> 
> At this point I expect final PEPs by PyCon US so I can try and make a 
> decision by May 1. Longer still is to hopefully have whatever solution we 
> choose in place right after Python 3.5 is released.
> 
> And just a reminder to people, the lofty goal is to improve the overall 
> workflow for CPython itself such that our patch submission queue can actually 
> be cleared regularly. This not only benefits core devs by letting us be more 
> effective, but also contributors by making sure their hard work gets 
> addressed quickly and thus doesn't languish on the issue tracker for very 
> long.
> 
> If we can't find a solution for fixing our CPython workflow I will then be 
> willing to entertain these PEPs narrowing their scopes and only focus on 
> ancillary repos like the devguide, etc. where the workflows are simple.
> 
> I know the absolute worst case is nothing changes, but honestly I think the 
> worst case is Nick's work gets us off of Rietveld, the ancillary repos move 
> to GitHub, and we make the GitHub and Bitbucket mirrors of CPython official 
> ones for people to work from (bonus points if we get the issue tracker to 
> have push button patch pulling from GitHub; Bitbucket is already covered 
> thanks to our remote hg repo support). IOW I see nothing but a win for 
> contributors and core devs as well as everyone proposing solutions which is a 
> nice place to start from. =)
> 


Is there going to be discussion between the two approaches or should the PEPs 
themselves address each other?

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
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] Workflow PEP proposals are now closed

[Brett Cannon]

On Mon Feb 02 2015 at 10:00:30 AM Donald Stufft  wrote:

>
> On Feb 2, 2015, at 9:35 AM, Brett Cannon  wrote:
>
> The PEPs under consideration are PEPs 474
>  and 462
>  from Nick Coghlan to use
> Kallithea and do self-hosting, and PEP 481
>  from Donald Stufft that
> proposes using GitHub.
>
> At this point I expect final PEPs by PyCon US so I can try and make a
> decision by May 1. Longer still is to hopefully have whatever solution we
> choose in place right after Python 3.5 is released.
>
> And just a reminder to people, the lofty goal is to improve the overall
> workflow for CPython itself such that our patch submission queue can
> actually be cleared regularly. This not only benefits core devs by letting
> us be more effective, but also contributors by making sure their hard work
> gets addressed quickly and thus doesn't languish on the issue tracker for
> very long.
>
> If we can't find a solution for fixing our CPython workflow I will then be
> willing to entertain these PEPs narrowing their scopes and only focus on
> ancillary repos like the devguide, etc. where the workflows are simple.
>
> I know the absolute worst case is nothing changes, but honestly I think
> the worst case is Nick's work gets us off of Rietveld, the ancillary repos
> move to GitHub, and we make the GitHub and Bitbucket mirrors of CPython
> official ones for people to work from (bonus points if we get the issue
> tracker to have push button patch pulling from GitHub; Bitbucket is already
> covered thanks to our remote hg repo support). IOW I see nothing but a win
> for contributors and core devs as well as everyone proposing solutions
> which is a nice place to start from. =)
>
>
>
> Is there going to be discussion between the two approaches or should the
> PEPs themselves address each other?
>

Since PEPs are meant to act as a record of what was discussed on a topic
then it probably wouldn't hurt to incorporate why your approach is better
than the other one in the PEP itself. We can obviously talk openly here
when you feel the PEP is ready for it.
___
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] Workflow PEP proposals are now closed

[Antoine Pitrou]

Hi,

What does "closed" mean in this context?

Regards

Antoine.



On Mon, 02 Feb 2015 14:35:47 +
Brett Cannon  wrote:
> The PEPs under consideration are PEPs 474
>  and 462
>  from Nick Coghlan to use
> Kallithea and do self-hosting, and PEP 481
>  from Donald Stufft that
> proposes using GitHub.
> 
> At this point I expect final PEPs by PyCon US so I can try and make a
> decision by May 1. Longer still is to hopefully have whatever solution we
> choose in place right after Python 3.5 is released.
> 
> And just a reminder to people, the lofty goal is to improve the overall
> workflow for CPython itself such that our patch submission queue can
> actually be cleared regularly. This not only benefits core devs by letting
> us be more effective, but also contributors by making sure their hard work
> gets addressed quickly and thus doesn't languish on the issue tracker for
> very long.
> 
> If we can't find a solution for fixing our CPython workflow I will then be
> willing to entertain these PEPs narrowing their scopes and only focus on
> ancillary repos like the devguide, etc. where the workflows are simple.
> 
> I know the absolute worst case is nothing changes, but honestly I think the
> worst case is Nick's work gets us off of Rietveld, the ancillary repos move
> to GitHub, and we make the GitHub and Bitbucket mirrors of CPython official
> ones for people to work from (bonus points if we get the issue tracker to
> have push button patch pulling from GitHub; Bitbucket is already covered
> thanks to our remote hg repo support). IOW I see nothing but a win for
> contributors and core devs as well as everyone proposing solutions which is
> a nice place to start from. =)
> 


___
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] cpython (merge 3.4 -> default): Merge 3.4 (asyncio)

[Antoine Pitrou]

On Mon, 02 Feb 2015 17:38:10 +
victor.stinner  wrote:

> https://hg.python.org/cpython/rev/42b376c8cf60
> changeset:   94465:42b376c8cf60
> parent:  94463:0b3bc51341aa
> parent:  94464:2cd6621a9fbc
> user:Victor Stinner 
> date:Mon Feb 02 18:36:59 2015 +0100
> summary:
>   Merge 3.4 (asyncio)

IMO it would be nice to keep the original code in the default branch,
since it helps exercise generators.

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] cpython (merge 3.4 -> default): Merge 3.4 (asyncio)

[Victor Stinner]

Hi,

The current workflow of asyncio is to first commit changes in the
external tulip project, then *copy* files to Python 3.4; to finish
with a merge from Python 3.4 into Python 3.5. To be complete, I also
merge tulip into trollius, but that's unrelated to your question :-)

To simplify the workflow, the code is currently exactly the same in
tulip, python 3.4 and python 3.5. It implies some tests on the Python
version in the code like "if _PY34: ...".

I would prefer to stick to this workflow. The code is still heavily
modified to fix issues.

The behaviour of generators in already tested in test_generators and
test_exceptions.

Victor

2015-02-02 20:41 GMT+01:00 Antoine Pitrou :
> On Mon, 02 Feb 2015 17:38:10 +
> victor.stinner  wrote:
>
>> https://hg.python.org/cpython/rev/42b376c8cf60
>> changeset:   94465:42b376c8cf60
>> parent:  94463:0b3bc51341aa
>> parent:  94464:2cd6621a9fbc
>> user:Victor Stinner 
>> date:Mon Feb 02 18:36:59 2015 +0100
>> summary:
>>   Merge 3.4 (asyncio)
>
> IMO it would be nice to keep the original code in the default branch,
> since it helps exercise generators.
>
> 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/victor.stinner%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] Workflow PEP proposals are now closed

[Brett Cannon]

On Mon Feb 02 2015 at 2:40:21 PM Antoine Pitrou  wrote:

>
> Hi,
>
> What does "closed" mean in this context?
>

No new PEPs on this topic will be taken under consideration, so submissions
are now "closed" to new participants.

-Brett


>
> Regards
>
> Antoine.
>
>
>
> On Mon, 02 Feb 2015 14:35:47 +
> Brett Cannon  wrote:
> > The PEPs under consideration are PEPs 474
> >  and 462
> >  from Nick Coghlan to use
> > Kallithea and do self-hosting, and PEP 481
> >  from Donald Stufft that
> > proposes using GitHub.
> >
> > At this point I expect final PEPs by PyCon US so I can try and make a
> > decision by May 1. Longer still is to hopefully have whatever solution we
> > choose in place right after Python 3.5 is released.
> >
> > And just a reminder to people, the lofty goal is to improve the overall
> > workflow for CPython itself such that our patch submission queue can
> > actually be cleared regularly. This not only benefits core devs by
> letting
> > us be more effective, but also contributors by making sure their hard
> work
> > gets addressed quickly and thus doesn't languish on the issue tracker for
> > very long.
> >
> > If we can't find a solution for fixing our CPython workflow I will then
> be
> > willing to entertain these PEPs narrowing their scopes and only focus on
> > ancillary repos like the devguide, etc. where the workflows are simple.
> >
> > I know the absolute worst case is nothing changes, but honestly I think
> the
> > worst case is Nick's work gets us off of Rietveld, the ancillary repos
> move
> > to GitHub, and we make the GitHub and Bitbucket mirrors of CPython
> official
> > ones for people to work from (bonus points if we get the issue tracker to
> > have push button patch pulling from GitHub; Bitbucket is already covered
> > thanks to our remote hg repo support). IOW I see nothing but a win for
> > contributors and core devs as well as everyone proposing solutions which
> is
> > a nice place to start from. =)
> >
>
>
> ___
> 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/
> brett%40python.org
>
___
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 475 accepted

[Antoine Pitrou]

Hello,

I'm now accepting PEP 475 - "Retry system calls failing with EINTR".
You can read it at https://www.python.org/dev/peps/pep-0475/

The implementation is more or less ready at
http://bugs.python.org/issue23285, so you can expect it to land in the
main repo relatively soon.

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] PEP 475 accepted

[Guido van Rossum]

W00t! Congratulations les Français!

On Mon, Feb 2, 2015 at 12:45 PM, Antoine Pitrou  wrote:

>
> Hello,
>
> I'm now accepting PEP 475 - "Retry system calls failing with EINTR".
> You can read it at https://www.python.org/dev/peps/pep-0475/
>
> The implementation is more or less ready at
> http://bugs.python.org/issue23285, so you can expect it to land in the
> main repo relatively soon.
>
> 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/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] Import Fails in setup.py On Android

[Cyd Haselton]

Update: While waiting for replies I made the change referenced here: 
https://bugs.python.org/review/5309/diff2/12811:12826/setup.py?context=3&column_width=80

specifically changing 
   importlib. _bootstrap._SpecMethods(spec).load()
to
   importlib._bootstrap.load(spec)

I no longer get a terminating 'undefined reference to dlopen' error, but I do 
get 'importing extensions failed' errors for each extension...like this:

*** WARNING: importing extension "_pickle" failed with : 'module' object has no attribute 'load'

On February 2, 2015 1:36:29 PM CST, Cyd Haselton  wrote:
>After fixing a segfault issue (many thanks Ryan) I'm back to the same
>issue I was having with Python 2.7.8; the newly built python throws an
>undefined reference to dlopen when running setup.py...specifically when
>importing just-built extensions
>
>I've managed to narrow the problem down to the following line:
>
>importlib._bootstrap._SpecMethods(spec).load()
>
>Googling this brings up a few hits from bugs.python.org and not much
>else.  I'm new to Python; any ideas what this does...or where I can
>read up on it for troubleshooting purposes?
>-- 
>Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
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] Import Fails in setup.py On Android

[Cyd Haselton]

After fixing a segfault issue (many thanks Ryan) I'm back to the same issue I 
was having with Python 2.7.8; the newly built python throws an undefined 
reference to dlopen when running setup.py...specifically when importing 
just-built extensions

I've managed to narrow the problem down to the following line:

importlib._bootstrap._SpecMethods(spec).load()

Googling this brings up a few hits from bugs.python.org and not much else.  I'm 
new to Python; any ideas what this does...or where I can read up on it for 
troubleshooting purposes?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
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] PEP 475 accepted

[Victor Stinner]

2015-02-02 21:49 GMT+01:00 Guido van Rossum :
> W00t! Congratulations les Français!

We will celebrate this acceptance with a glass of red wine and cheese.

Thanks Antoine! I hate EINTR. It's a pain to handle them for each
syscall in subprocess and asyncio (where signals are likely). It's
good to not have to handle them explicitly anymore!

FYI in Python 3.5 it's now also possible to use signal.set_wakeup_fd()
with a socket on Windows.

Victor
___
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] PEP 475 accepted

[Antoine Pitrou]

On Mon, 2 Feb 2015 12:49:32 -0800
Guido van Rossum  wrote:
> W00t! Congratulations les Français!

I hoped nobody would notice :-)

Regards

Antoine.


> 
> On Mon, Feb 2, 2015 at 12:45 PM, Antoine Pitrou  wrote:
> 
> >
> > Hello,
> >
> > I'm now accepting PEP 475 - "Retry system calls failing with EINTR".
> > You can read it at https://www.python.org/dev/peps/pep-0475/
> >
> > The implementation is more or less ready at
> > http://bugs.python.org/issue23285, so you can expect it to land in the
> > main repo relatively soon.
> >
> > 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/guido%40python.org
> >
> 
> 
> 

___
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] PEP 475 accepted

[Giampaolo Rodola']

On Mon, Feb 2, 2015 at 9:45 PM, Antoine Pitrou  wrote:

>
> Hello,
>
> I'm now accepting PEP 475 - "Retry system calls failing with EINTR".
> You can read it at https://www.python.org/dev/peps/pep-0475/
>
> The implementation is more or less ready at
> http://bugs.python.org/issue23285, so you can expect it to land in the
> main repo relatively soon.
>
> Regards
>
> Antoine.
>

I may be chiming in a little late, however, I'd have a question: does this
affect non-blocking applications somehow?
How often should we expect to receive EINTR? Is it correct to state that in
case many EINTR signals are sent repeatedly a non-blocking framework such
as asyncio may hang for "too long"?

-- 
Giampaolo - http://grodola.blogspot.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] Import Fails in setup.py On Android

[Ryan Gonzalez]

In reality, things just got broken even more. I don't know when that patch
was created, but it's now very out of date: importlib._bootstrap has no
load function. That's what the error you're getting is telling you. Since
it isn't getting to load anything, the issue seems "solved". Not really.

What's the full traceback for the undefined reference exception?

On Mon, Feb 2, 2015 at 2:04 PM, Cyd Haselton  wrote:

> Update: While waiting for replies I made the change referenced here:
> https://bugs.python.org/review/5309/diff2/12811:12826/setup.py?context=3&column_width=80
>
> specifically changing
> importlib. _bootstrap._SpecMethods(spec).load()
> to
> importlib._bootstrap.load(spec)
>
> I no longer get a terminating 'undefined reference to dlopen' error, but I
> do get 'importing extensions failed' errors for each extension...like this:
>
> *** WARNING: importing extension "_pickle" failed with  'AttributeError'>: 'module' object has no attribute 'load'
>
>
> On February 2, 2015 1:36:29 PM CST, Cyd Haselton 
> wrote:
>>
>> After fixing a segfault issue (many thanks Ryan) I'm back to the same
>> issue I was having with Python 2.7.8; the newly built python throws an
>> undefined reference to dlopen when running setup.py...specifically when
>> importing just-built extensions
>>
>> I've managed to narrow the problem down to the following line:
>>
>> importlib._bootstrap._SpecMethods(spec).load()
>>
>> Googling this brings up a few hits from bugs.python.org and not much
>> else. I'm new to Python; any ideas what this does...or where I can read up
>> on it for troubleshooting purposes?
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> ___
> 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/rymg19%40gmail.com
>
>


-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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] Import Fails in setup.py On Android

[Cyd Haselton]

No traceback unfortunately...the fakechroot in the environment throws the error 
and setup.py fails.

I'll roll back that change...any idea where I could find info about the 
original method?

On February 2, 2015 3:17:54 PM CST, Ryan Gonzalez  wrote:
>In reality, things just got broken even more. I don't know when that
>patch
>was created, but it's now very out of date: importlib._bootstrap has no
>load function. That's what the error you're getting is telling you.
>Since
>it isn't getting to load anything, the issue seems "solved". Not
>really.
>
>What's the full traceback for the undefined reference exception?
>
>On Mon, Feb 2, 2015 at 2:04 PM, Cyd Haselton 
>wrote:
>
>> Update: While waiting for replies I made the change referenced here:
>>
>https://bugs.python.org/review/5309/diff2/12811:12826/setup.py?context=3&column_width=80
>>
>> specifically changing
>> importlib. _bootstrap._SpecMethods(spec).load()
>> to
>> importlib._bootstrap.load(spec)
>>
>> I no longer get a terminating 'undefined reference to dlopen' error,
>but I
>> do get 'importing extensions failed' errors for each extension...like
>this:
>>
>> *** WARNING: importing extension "_pickle" failed with > 'AttributeError'>: 'module' object has no attribute 'load'
>>
>>
>> On February 2, 2015 1:36:29 PM CST, Cyd Haselton
>
>> wrote:
>>>
>>> After fixing a segfault issue (many thanks Ryan) I'm back to the
>same
>>> issue I was having with Python 2.7.8; the newly built python throws
>an
>>> undefined reference to dlopen when running setup.py...specifically
>when
>>> importing just-built extensions
>>>
>>> I've managed to narrow the problem down to the following line:
>>>
>>> importlib._bootstrap._SpecMethods(spec).load()
>>>
>>> Googling this brings up a few hits from bugs.python.org and not much
>>> else. I'm new to Python; any ideas what this does...or where I can
>read up
>>> on it for troubleshooting purposes?
>>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>> ___
>> 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/rymg19%40gmail.com
>>
>>
>
>
>-- 
>Ryan
>If anybody ever asks me why I prefer C++ to C, my answer will be
>simple:
>"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that
>was
>nul-terminated."
>Personal reality distortion fields are immune to contradictory
>evidence. -
>srean
>Check out my website: http://kirbyfan64.github.io/

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
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] Import Fails in setup.py On Android

[Ryan Gonzalez]

Unfortunately, I have no idea. You might want to ask someone who's more
familiar with the Python source than I am.

What exactly appears? Does it say anything about the source of the error?

On Mon, Feb 2, 2015 at 3:24 PM, Cyd Haselton  wrote:

> No traceback unfortunately...the fakechroot in the environment throws the
> error and setup.py fails.
>
> I'll roll back that change...any idea where I could find info about the
> original method?
>
>
> On February 2, 2015 3:17:54 PM CST, Ryan Gonzalez 
> wrote:
>>
>> In reality, things just got broken even more. I don't know when that
>> patch was created, but it's now very out of date: importlib._bootstrap has
>> no load function. That's what the error you're getting is telling you.
>> Since it isn't getting to load anything, the issue seems "solved". Not
>> really.
>>
>> What's the full traceback for the undefined reference exception?
>>
>> On Mon, Feb 2, 2015 at 2:04 PM, Cyd Haselton  wrote:
>>
>>> Update: While waiting for replies I made the change referenced here:
>>> https://bugs.python.org/review/5309/diff2/12811:12826/setup.py?context=3&column_width=80
>>>
>>> specifically changing
>>> importlib. _bootstrap._SpecMethods(spec).load()
>>> to
>>> importlib._bootstrap.load(spec)
>>>
>>> I no longer get a terminating 'undefined reference to dlopen' error, but
>>> I do get 'importing extensions failed' errors for each extension...like
>>> this:
>>>
>>> *** WARNING: importing extension "_pickle" failed with >> 'AttributeError'>: 'module' object has no attribute 'load'
>>>
>>>
>>> On February 2, 2015 1:36:29 PM CST, Cyd Haselton 
>>> wrote:

 After fixing a segfault issue (many thanks Ryan) I'm back to the same
 issue I was having with Python 2.7.8; the newly built python throws an
 undefined reference to dlopen when running setup.py...specifically
 when importing just-built extensions

 I've managed to narrow the problem down to the following line:

 importlib._bootstrap._SpecMethods(spec).load()

 Googling this brings up a few hits from bugs.python.org and not much
 else. I'm new to Python; any ideas what this does...or where I can read up
 on it for troubleshooting purposes?

>>>
>>> --
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>
>>> ___
>>> 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/rymg19%40gmail.com
>>>
>>>
>>
>>
>> --
>> Ryan
>> If anybody ever asks me why I prefer C++ to C, my answer will be simple:
>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
>> nul-terminated."
>> Personal reality distortion fields are immune to contradictory evidence.
>> - srean
>> Check out my website: http://kirbyfan64.github.io/
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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] PEP 475 accepted

[Victor Stinner]

2015-02-02 22:11 GMT+01:00 Giampaolo Rodola' :
> I may be chiming in a little late, however, I'd have a question: does this
> affect non-blocking applications somehow?
> How often should we expect to receive EINTR?

Each time a program is interrupted by a signal while it was waiting
for a sycall. Most syscalls are fast, especially in an application
written with non blocking operations.

For example, timeit says that os.getuid() takes 370 nanoseconds (on
Linux). getpid() only takes 285 nanoseconds, but it looks to be cached
in the libc: strace doesn't show me syscalls.

Network syscalls are probably slower.

haypo@selma$ ./python -Wignore -m timeit -s 'import socket;
s,c=socket.socketpair()' 's.send(b"a"); c.recv(1)'
10 loops, best of 3: 2.26 usec per loop

> Is it correct to state that in case many EINTR signals are sent
> repeatedly a non-blocking framework such as asyncio may hang for "too long"?

A syscall fails with EINTR each time it gets a signal. You are
unlikely if the same syscall requires to be retried twice (executed 3
times) because it got EINTR twice.

I don't see why the kernel would make a syscall fails EINTR multiple times.

asyncio doesn't process the signal immediatly. asyncio uses
signal.set_wakeup_fd(). At the C level, the C signal handler writes
the signal number into a pipe. At the Python level, the selector is
awaken by the write. Later, asyncio executes the Python handler of the
signal (if a Python signal handler was registered).

A nice side effect of the PEP is to avoid to awake the application if
it's not necessary. If no Python signal handler is registered, no byte
is written into the pipe, the selector continues to wait for events.

Victor
___
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] Import Fails in setup.py On Android

[Frank, Matthew I]

There’s now (as of a couple days ago) a python mobile-sig 
(https://mail.python.org/mailman/listinfo/mobile-sig).  While that group is 
much smaller than python-dev and probably not as knowledgeable about the 
Cpython source base, that’s where you’re going to find folks who have a vested 
interest in getting Python working on mobile platforms like Android.  (And who 
would be interested in hearing about your experiences, no matter whether they 
can help you or not.)

What you are doing (trying to run the entire C compiler toolchain on an Android 
machine, instead of using the cross-compilers that come in Google’s Android NDK 
(native development kit)) is way outside the mainstream.  (I.e., you’re not 
going to find very many people trying to do this here or anywhere.)

Since you compiled all the libraries that you are linking against, there is 
some possibility (likelihood) that the problem is in one of those libraries, 
not anywhere in the CPython source.  (Some other library was compiled without 
the necessary –dl flag.)  The right way to track down this problem (no matter 
where it is) is to run under gdb and type “where” when the program crashes.

The reason I suspect that the problem is in one of the libraries you compiled 
before building Python, rather than a problem in the CPython sources or build 
scripts, is that I don’t have this problem when I cross-compile Python 3.4.2 on 
a Linux machine, then take the result and copy it over to the Android machine.  
I’ve posted instructions and patches for successfully performing this cross 
compilation (for Android KitKat running on an x86) here: 
https://github.com/wandering-logic/android_x86_python-3.4.

Best,
-Matt

From: Cyd Haselton [mailto:chasel...@gmail.com]
Sent: Monday, February 02, 2015 3:25 PM
To: Ryan Gonzalez
Cc: Python-Dev
Subject: Re: [Python-Dev] Import Fails in setup.py On Android

No traceback unfortunately...the fakechroot in the environment throws the error 
and setup.py fails.

I'll roll back that change...any idea where I could find info about the 
original method?
On February 2, 2015 3:17:54 PM CST, Ryan Gonzalez 
mailto:rym...@gmail.com>> wrote:
In reality, things just got broken even more. I don't know when that patch was 
created, but it's now very out of date: importlib._bootstrap has no load 
function. That's what the error you're getting is telling you. Since it isn't 
getting to load anything, the issue seems "solved". Not really.

What's the full traceback for the undefined reference exception?

On Mon, Feb 2, 2015 at 2:04 PM, Cyd Haselton 
mailto:chasel...@gmail.com>> wrote:
Update: While waiting for replies I made the change referenced here: 
https://bugs.python.org/review/5309/diff2/12811:12826/setup.py?context=3&column_width=80

specifically changing
importlib. _bootstrap._SpecMethods(spec).load()
to
importlib._bootstrap.load(spec)

I no longer get a terminating 'undefined reference to dlopen' error, but I do 
get 'importing extensions failed' errors for each extension...like this:

*** WARNING: importing extension "_pickle" failed with : 'module' object has no attribute 'load'

On February 2, 2015 1:36:29 PM CST, Cyd Haselton 
mailto:chasel...@gmail.com>> wrote:
After fixing a segfault issue (many thanks Ryan) I'm back to the same issue I 
was having with Python 2.7.8; the newly built python throws an undefined 
reference to dlopen when running setup.py...specifically when 
importing just-built extensions

I've managed to narrow the problem down to the following line:

importlib._bootstrap._SpecMethods(spec).load()

Googling this brings up a few hits from bugs.python.org 
and not much else. I'm new to Python; any ideas what this does...or where I can 
read up on it for troubleshooting purposes?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
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/rymg19%40gmail.com



--
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's 
becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was 
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. - srean
Check out my website: http://kirbyfan64.github.io/

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
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] Import Fails in setup.py On Android

[Eric Snow]

On Mon, Feb 2, 2015 at 12:36 PM, Cyd Haselton  wrote:
> After fixing a segfault issue (many thanks Ryan) I'm back to the same issue
> I was having with Python 2.7.8; the newly built python throws an undefined
> reference to dlopen when running setup.py...specifically when importing
> just-built extensions
>
> I've managed to narrow the problem down to the following line:
>
> importlib._bootstrap._SpecMethods(spec).load()

That call is where modules are created (and executed) via the loader
designated for the module by the import machinery.  So a problem here
may simply reflect a problem with the loader.  Which module is being
imported when you run into trouble?  Is it a C-extension module?

Also keep in mind that basically everything in importlib._bootstrap is
frozen into your Python binary when you build Python (or should be).
So if you are seeing any errors related to something missing or broken
in importlib._bootstrap, it could be related to the build step where
importlib gets frozen.

Either way, more info (e.g. a traceback) would be great if you need more help.

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