[Python-Dev] Python Issue-subprocess problem

2015-08-27 Thread Low, Wai HoeX 
Dear,

I have faced a problem as below when I startup the python IDLE

[cid:[email protected]]

Then I try to run a simple program like this:
[cid:[email protected]]

Other issue is pop out

[cid:[email protected]]

May I know how to fix the issue? My laptop is window 7 64bits.



Thanks and having a  nice day !

Regards,
Arthur Low Wai Hoe

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Issue-subprocess problem

2015-08-27 Thread Ryan Gonzalez 
*before anyone else says it*

This list is for development *of* Python, not *in* Python. If you need help
with things like this, I'd advise you to use the python-list
 mailing list or Stack
Overflow .

On Thu, Aug 27, 2015 at 3:57 AM, Low, Wai HoeX 
wrote:

> Dear,
>
>
>
> I have faced a problem as below when I startup the python IDLE
>
>
>
> [image: cid:[email protected]]
>
>
>
> Then I try to run a simple program like this:
>
> [image: cid:[email protected]]
>
>
>
> Other issue is pop out
>
>
>
> [image: cid:[email protected]]
>
>
>
> May I know how to fix the issue? My laptop is window 7 64bits.
>
>
>
>
>
>
>
> Thanks and having a  nice day !
>
>
>
> Regards,
>
> Arthur Low Wai Hoe
>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Issue-subprocess problem

2015-08-27 Thread Terry Reedy 

On 8/27/2015 11:05 AM, Ryan Gonzalez wrote:

*before anyone else says it*

This list is for development /of/ Python, not /in/ Python. If you need
help with things like this, I'd advise you to use the python-list
 mailing list or
Stack Overflow .


+ sent private message

--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Testing tkinter on Linux

2015-08-27 Thread Terry Reedy 

On 8/27/2015 12:35 AM, Chris Angelico wrote:

On Thu, Aug 27, 2015 at 2:20 PM, Terry Reedy  wrote:

None of the linux buildbots run with X enabled.  Consequently none of the
tkinter (or tkinter user) gui tests are run on Linux.  It was thus pointed
out to me, during discussion of using ttk widgets in Idle, that we do not
really know if ttk works on the variety of Linux systems (beyond the one
Serhiy uses) and that I should look into this.


If it helps, my buildbot has full GUI services, so if there's a simple
way to tell it to run the GUI tests every time, they should pass.


Somewhere your buildbot has a shell script to run that ends with a 
command to start the tests. The commands are echoed to the buildbot 
output.  Here are two that I found.


./python  ./Tools/scripts/run_tests.py -j 1 -u all -W --timeout=3600
... PCbuild\..\lib\test\regrtest.py" -uall -rwW -n --timeout 3600
(and python -m test ... should work)

If the command has -ugui (included in -uall) *and* a graphics system can 
be initiated (X on Linux), then the gui resource is marked present and 
gui tests will run.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Testing tkinter on Linux

2015-08-27 Thread R. David Murray 
On Thu, 27 Aug 2015 14:24:36 -0400, Terry Reedy  wrote:
> On 8/27/2015 12:35 AM, Chris Angelico wrote:
> > On Thu, Aug 27, 2015 at 2:20 PM, Terry Reedy  wrote:
> >> None of the linux buildbots run with X enabled.  Consequently none of the
> >> tkinter (or tkinter user) gui tests are run on Linux.  It was thus pointed
> >> out to me, during discussion of using ttk widgets in Idle, that we do not
> >> really know if ttk works on the variety of Linux systems (beyond the one
> >> Serhiy uses) and that I should look into this.
> >
> > If it helps, my buildbot has full GUI services, so if there's a simple
> > way to tell it to run the GUI tests every time, they should pass.
> 
> Somewhere your buildbot has a shell script to run that ends with a 
> command to start the tests. The commands are echoed to the buildbot 
> output.  Here are two that I found.

No, the master controls this.

> ./python  ./Tools/scripts/run_tests.py -j 1 -u all -W --timeout=3600
> ... PCbuild\..\lib\test\regrtest.py" -uall -rwW -n --timeout 3600
> (and python -m test ... should work)
> 
> If the command has -ugui (included in -uall) *and* a graphics system can 
> be initiated (X on Linux), then the gui resource is marked present and 
> gui tests will run.

I believe gui depends on the existence of the DISPLAY environment
variable on unix/linux (that is, TK will fail to start if DISPLAY is not
set, so _is_gui_available will return False).  You should be able to
confirm this by looking at the text of the skip message in the buildbot
output.

It is possible to create a "virtual" X on an otherwise headless linux
system, but I've never tried to do it myself.  If someone comes up
with a recipe we could add it to the devguide chapter on running
a buildbot.

--David
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Testing tkinter on Linux

2015-08-27 Thread Florian Bruhin 
* R. David Murray  [2015-08-27 15:00:40 -0400]:
> It is possible to create a "virtual" X on an otherwise headless linux
> system, but I've never tried to do it myself.  If someone comes up
> with a recipe we could add it to the devguide chapter on running
> a buildbot.

It's usually as easy as installing Xvfb and prepending "xvfb-run" to
the command:

$ export DISPLAY=

$ python3 -m test -ugui test_tk test_ttk_guionly test_idle
[1/3] test_tk
test_tk skipped -- Tk unavailable due to TclError: couldn't connect to display 
""
[2/3] test_ttk_guionly
test_ttk_guionly skipped -- Tk unavailable due to TclError: couldn't connect to 
display ""
[3/3] test_idle
1 test OK.
2 tests skipped:
test_tk test_ttk_guionly

$ xvfb-run python3 -m test -ugui test_tk test_ttk_guionly test_idle
[1/3] test_tk
[2/3] test_ttk_guionly
[3/3] test_idle
All 3 tests OK.

Florian

-- 
http://www.the-compiler.org | [email protected] (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
 I love long mails! | http://email.is-not-s.ms/


pgpr5QOltyNhr.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] How To Forward-Merge Your Change After Your Pull Request Is Accepted Into Python 3.5.0rcX

2015-08-27 Thread Larry Hastings 



Now that we're in the "release candidate" phase of Python 3.5.0, the 
workflow

has changed a little.  We're trying an experiment using Bitbucket and pull
requests.  You can read about that workflow, here:

https://mail.python.org/pipermail/python-dev/2015-August/141167.html

But the instructions for that workflow are pretty hazy on what you do after
your pull request is accepted.  This message is an addendum to those
instructions, describing exactly what you should do after your pull
request is accepted.

To save wear and tear on my hands (and your eyes), for the rest of these
instructions, I'm going to refer to each place-you-can-check-things-in-to
by version number as follows:

3.4   : hg.python.org/cpython (branch "3.4")
3.5.0 : https://bitbucket.org/larry/cpython350 (branch "3.5")
3.5.1 : hg.python.org/cpython (branch "3.5")
3.6   : hg.python.org/cpython (branch "default")

With that nomenclature established I can now precisely say: when your pull
request is accepted into 3.5.0, you need to merge from 3.5.0 into 3.5.1,
and then from 3.5.1 into 3.6.

Doing this is much like the existing workflow.   You use "hg merge" to merge
your changes from previous versions into subsequent versions (what I call
"forward merging").

What complicates matters is the fact that the 3.5.0 release candidates don't
live in the normal repo--they lives in a repo on Bitbucket which is only
writeable by me.  In order to keep a tight lid on the changes checked in to
the 3.5.0 release candidates, I won't pull revisions from the normal CPython
repo.  (If I did, I'd also pull in changes intended for 3.5.1, and...
it'd be a mess.)

So here come the instructions.  They look long, but that's just because I go
into a lot of detail to try and make them as foolproof as possible. They
aren't really much longer or more complicated than the steps you already
follow to perform forward-merges.

Note that these are easy, guaranteed-clean instructions on how to 
perform the

merge.  Are there shortcuts you could take that might speed things up?  Yes.
But I encourage you to skip those shortcuts and stick to my instructions.
Working with multiple branches is complicated enough, and this external repo
makes things even more complicated.  It's all too easy to make a mistake.


HOW TO FORWARD-MERGE FROM 3.5.0 TO 3.5.1



 1: Wait until your pull request has been accepted.


 2: Make a *clean* local clone of the CPython tree, updated to the "3.5"
branch.  In my instructions I'll call the clone "cpython351-merge":

% hg clone ssh://[email protected]/cpython -u 3.5 cpython351-merge

% cd cpython351-merge


 3: Confirm that you're in the correct branch.  You should be in the
"3.5" branch.  Run this command:

% hg id

Let's assume that the current head in the "3.5" branch has changeset
ID "7890abcdef".  If that were true, the output of "hg id" would look
like this:

7890abcdef (3.5)

It might also say "tip" on the end, like this:

7890abcdef (3.5) tip

If it doesn't say "3.5", switch to the 3.5 branch:

% hg up -r 3.5

and repeat this step.


 4: Pull from the 3.5.0 repo into your "cpython351-merge" directory.

% hg pull ssh://[email protected]/larry/cpython350

You should now have two "heads" in the 3.5 branch; the existing head
you saw in the previous step, and the new head you just pulled in,
which should be the changeset from your pull request.


 5: As an optional step: confirm you have the correct two heads.
This command will print a list of all the heads in the current repo:

% hg heads

Again, you should have exactly two identified as being on the "3.5"
branch; one should have the changeset ID shown by "hg id" in step 3,
the other should be your change from the pull request.


 6: Merge the two heads together:

% hg merge

If there are merge conflicts, Mercurial will guide you through the
conflict resolution process as normal.


 7: Make sure that all your changes merged properly and you didn't
merge anything else by accident.  I run these two commands:

% hg stat

% hg diff

and read all the output.


 8: Make sure Misc/NEWS has your update in the right spot.  (See below.)


 9: Check in.  The checkin comment should be something like

Merge from 3.5.0 to 3.5.1.


10: Push your changes back into the main CPython repo.

% hg push


11: Now forward-merge your change to 3.6 as normal, following the
CPython Dev Guide instructions:

https://docs.python.org/devguide/committing.html#merging-between-different-branches-within-the-same-major-version


FREQUENTLY ASKED QUESTIONS
--


Q: I screwed something up!  What do I do now?

If you haven't pushed your changes out, it's no problem.  Just delete your
repo and start over.

If you *have* pushed your changes out, obviously we'

Re: [Python-Dev] Testing tkinter on Linux

2015-08-27 Thread Chris Angelico 
On Fri, Aug 28, 2015 at 5:00 AM, R. David Murray  wrote:
> I believe gui depends on the existence of the DISPLAY environment
> variable on unix/linux (that is, TK will fail to start if DISPLAY is not
> set, so _is_gui_available will return False).  You should be able to
> confirm this by looking at the text of the skip message in the buildbot
> output.

A recent buildbot log [1] shows that the GUI tests are being skipped,
although I'm not seeing the message. Where do I go to set DISPLAY for
the bot (which runs mostly in the background)?

Note that it's all running as root, which may make a difference to the
defaults, so this might have to be done more explicitly than it
otherwise would. (But root is quite happy to use X; running xclock
brings up a clock just fine.)

[1] 
http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.5/builds/210/steps/test/logs/stdio

ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] provisional status for asyncio

2015-08-27 Thread Yury Selivanov 

Recently, in an asyncio related issue [1], Guido said that new features
for asyncio have to wait till 3.6, since asyncio is no longer a provisional
package.  Later, in an off-list conversation, he suggested that this topic
should be discussed on python-dev, and that it might indeed make sense to
either write a new PEP for cases like this or to augment PEP 411.

My opinion on this topic is that we must maintain full backwards
compatibility for asyncio from 3.5.0, as it is now widely used, and there
is quite a big ecosystem around it.  However, asyncio is simply not mature
enough to be completely feature frozen for about 2 years.

For example, there is an issue [2] to add starttls support to asyncio.  It
is an essential feature, because some protocols start as clear text and
upgrade to TLS later, for example PostgreSQL PQ3 protocol.  It's very hard
to implement starttls on top of asyncio, lots of code will have to be
duplicated -- it's a feature that has to implemented in the asyncio core.

Aside from adding new APIs, we also have to improve debugging
capabilities.  One example is using os.fork() from within a running event
loop -- it must be avoided by all means.  There are safe ways to fork in
asyncio applications (and I plan to document them soon), but asyncio
should raise an exception in debug mode if this happens (see issue [3]).

These are just two immediate issues that I have in mind.  In reality,
asyncio is quite young compared to frameworks like Twisted, which had
years to mature, and accumulate essential features.

My proposal is to amend PEP 411 with two levels of provisional packages:

Level 1: Backwards incompatible changes might be introduced in point
releases.

Level 2: Only backwards compatible changes can be introduced in new point
releases.

With the above amendments, asyncio status should be restated as a
level-2 provisional package.

I'm CC-ing authors of PEP 411 Nick and Eli.

Thank you,
Yury

[1] http://bugs.python.org/issue23630
[2] http://bugs.python.org/issue23749
[3] http://bugs.python.org/issue21998
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] provisional status for asyncio

2015-08-27 Thread Yury Selivanov 

On 2015-08-27 5:24 PM, Brett Cannon wrote:


My proposal is to amend PEP 411 with two levels of provisional
packages:

Level 1: Backwards incompatible changes might be introduced in point
releases.

Level 2: Only backwards compatible changes can be introduced in
new point
releases.


How is this any different from the normal compatibility promise we 
have for any non-provisional code in the stdlib?


And by point release I assume you mean a new minor release, e.g. 3.5 
-> 3.6.


Right, my mistake, I indeed meant minor releases.

The difference is that right now we don't introduce new features 
(regardless of backwards compatibility promises) for any non-provisional 
code in minor releases, we can only do bug fixes.


My proposal is to enable asyncio receiving new strictly backwards 
compatible APIs/features (and bug fixes too, of course) in minor 
releases (3.5.x).


Yury
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] provisional status for asyncio

2015-08-27 Thread Yury Selivanov 


On 2015-08-27 5:31 PM, Yury Selivanov wrote:

On 2015-08-27 5:24 PM, Brett Cannon wrote:


My proposal is to amend PEP 411 with two levels of provisional
packages:

Level 1: Backwards incompatible changes might be introduced in point
releases.

Level 2: Only backwards compatible changes can be introduced in
new point
releases.


How is this any different from the normal compatibility promise we 
have for any non-provisional code in the stdlib?


And by point release I assume you mean a new minor release, e.g. 3.5 
-> 3.6.


Right, my mistake, I indeed meant minor releases.

The difference is that right now we don't introduce new features 
(regardless of backwards compatibility promises) for any 
non-provisional code in minor releases, we can only do bug fixes.


My proposal is to enable asyncio receiving new strictly backwards 
compatible APIs/features (and bug fixes too, of course) in minor 
releases (3.5.x).




Turns out I was lost in terminology :)

Considering that Python versioning is defined as major.minor.micro, I'll 
rephrase the proposal:


Level 1: Backwards incompatible changes might be introduced in new 
Python releases (including micro releases)


Level 2: Only backwards compatible changes (new APIs including) can be 
introduced in micro releases.


Sorry for the confusion.

Yury
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] provisional status for asyncio

2015-08-27 Thread Guido van Rossum 
Please use "feature release" (e.g. 3.5 -> 3.6) and "bugfix release" (e.g.
3.5.0 -> 3.5.1). The major/minor terminology is confusing, since something
like 2 -> 3 isn't just "major", it is "earthshattering". :-)

On Thu, Aug 27, 2015 at 2:39 PM, Yury Selivanov 
wrote:

>
> On 2015-08-27 5:31 PM, Yury Selivanov wrote:
>
>> On 2015-08-27 5:24 PM, Brett Cannon wrote:
>>
>>>
>>> My proposal is to amend PEP 411 with two levels of provisional
>>> packages:
>>>
>>> Level 1: Backwards incompatible changes might be introduced in point
>>> releases.
>>>
>>> Level 2: Only backwards compatible changes can be introduced in
>>> new point
>>> releases.
>>>
>>>
>>> How is this any different from the normal compatibility promise we have
>>> for any non-provisional code in the stdlib?
>>>
>>> And by point release I assume you mean a new minor release, e.g. 3.5 ->
>>> 3.6.
>>>
>>
>> Right, my mistake, I indeed meant minor releases.
>>
>> The difference is that right now we don't introduce new features
>> (regardless of backwards compatibility promises) for any non-provisional
>> code in minor releases, we can only do bug fixes.
>>
>> My proposal is to enable asyncio receiving new strictly backwards
>> compatible APIs/features (and bug fixes too, of course) in minor releases
>> (3.5.x).
>>
>>
> Turns out I was lost in terminology :)
>
> Considering that Python versioning is defined as major.minor.micro, I'll
> rephrase the proposal:
>
> Level 1: Backwards incompatible changes might be introduced in new Python
> releases (including micro releases)
>
> Level 2: Only backwards compatible changes (new APIs including) can be
> introduced in micro releases.
>
> Sorry for the confusion.
>
>
> Yury
> ___
> Python-Dev mailing list
> [email protected]
> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] provisional status for asyncio

2015-08-27 Thread Brett Cannon 
On Thu, 27 Aug 2015 at 14:39 Yury Selivanov  wrote:

>
> On 2015-08-27 5:31 PM, Yury Selivanov wrote:
> > On 2015-08-27 5:24 PM, Brett Cannon wrote:
> >>
> >> My proposal is to amend PEP 411 with two levels of provisional
> >> packages:
> >>
> >> Level 1: Backwards incompatible changes might be introduced in point
> >> releases.
> >>
> >> Level 2: Only backwards compatible changes can be introduced in
> >> new point
> >> releases.
> >>
> >>
> >> How is this any different from the normal compatibility promise we
> >> have for any non-provisional code in the stdlib?
> >>
> >> And by point release I assume you mean a new minor release, e.g. 3.5
> >> -> 3.6.
> >
> > Right, my mistake, I indeed meant minor releases.
> >
> > The difference is that right now we don't introduce new features
> > (regardless of backwards compatibility promises) for any
> > non-provisional code in minor releases, we can only do bug fixes.
> >
> > My proposal is to enable asyncio receiving new strictly backwards
> > compatible APIs/features (and bug fixes too, of course) in minor
> > releases (3.5.x).
> >
>
> Turns out I was lost in terminology :)
>
> Considering that Python versioning is defined as major.minor.micro, I'll
> rephrase the proposal:
>
> Level 1: Backwards incompatible changes might be introduced in new
> Python releases (including micro releases)
>
> Level 2: Only backwards compatible changes (new APIs including) can be
> introduced in micro releases.
>

In that case I don't think it's a good idea for something that has
widespread use to get new APIs in a micro release; I lived the
2.2.1/boolean event and I don't want to go through that again. If a module
is used enough to warrant not breaking backwards-compatibility then it
warrants not being provisional and being like any other module.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] provisional status for asyncio

2015-08-27 Thread Brett Cannon 
On Thu, 27 Aug 2015 at 14:16 Yury Selivanov  wrote:

> Recently, in an asyncio related issue [1], Guido said that new features
> for asyncio have to wait till 3.6, since asyncio is no longer a provisional
> package.  Later, in an off-list conversation, he suggested that this topic
> should be discussed on python-dev, and that it might indeed make sense to
> either write a new PEP for cases like this or to augment PEP 411.
>
> My opinion on this topic is that we must maintain full backwards
> compatibility for asyncio from 3.5.0, as it is now widely used, and there
> is quite a big ecosystem around it.  However, asyncio is simply not mature
> enough to be completely feature frozen for about 2 years.
>
> For example, there is an issue [2] to add starttls support to asyncio.  It
> is an essential feature, because some protocols start as clear text and
> upgrade to TLS later, for example PostgreSQL PQ3 protocol.  It's very hard
> to implement starttls on top of asyncio, lots of code will have to be
> duplicated -- it's a feature that has to implemented in the asyncio core.
>
> Aside from adding new APIs, we also have to improve debugging
> capabilities.  One example is using os.fork() from within a running event
> loop -- it must be avoided by all means.  There are safe ways to fork in
> asyncio applications (and I plan to document them soon), but asyncio
> should raise an exception in debug mode if this happens (see issue [3]).
>
> These are just two immediate issues that I have in mind.  In reality,
> asyncio is quite young compared to frameworks like Twisted, which had
> years to mature, and accumulate essential features.
>
> My proposal is to amend PEP 411 with two levels of provisional packages:
>
> Level 1: Backwards incompatible changes might be introduced in point
> releases.
>
> Level 2: Only backwards compatible changes can be introduced in new point
> releases.
>

How is this any different from the normal compatibility promise we have for
any non-provisional code in the stdlib?

And by point release I assume you mean a new minor release, e.g. 3.5 -> 3.6.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] provisional status for asyncio

2015-08-27 Thread Yury Selivanov 

On 2015-08-27 5:53 PM, Brett Cannon wrote:



Considering that Python versioning is defined as
major.minor.micro, I'll
rephrase the proposal:

Level 1: Backwards incompatible changes might be introduced in new
Python releases (including micro releases)

Level 2: Only backwards compatible changes (new APIs including) can be
introduced in micro releases.


In that case I don't think it's a good idea for something that has 
widespread use to get new APIs in a micro release; I lived the 
2.2.1/boolean event and I don't want to go through that again. If a 
module is used enough to warrant not breaking backwards-compatibility 
then it warrants not being provisional and being like any other module.


I wasn't using Python 2.2/2.3, but from what I could google the 
"2.2.1/boolean event" you mention was introducing True/False/bool 
built-ins.  This sounds like a language-level change, as opposed to new 
API in a stdlib module, which is a different scale.


My understanding about adding new features in bugfix releases (3.5.x) is 
that you might end up in a situation where your 3.5 code developed on 
3.5.x suddenly stops working on 3.5.y.  Yes, you have to be careful 
about how you deploy and test your code when using a provisional package.


But the thing about asyncio is that it *is* still provisional in 3.4.  
During 3.4 release cycle we introduced many new features to asyncio, and 
to be honest, I haven't heard anybody complaining.  I believe that main 
motivation for making asyncio non-provisional was to guarantee that we 
won't introduce backwards-incompatible changes to it.


Given the fact that asyncio sees some adoption, I support that from now 
on we will guarantee that backwards compatibility is preserved. But 
withholding new useful (and sometimes essential) features till 3.6.0 is 
out (March 2017?) sounds wrong to me.


I should also mention that asyncio is different from other packages in 
the stdlib:


1. It's new, it virtually didn't exist before 3.4.0.

2. It's not a module, it's a framework.  If it lacks a core feature 
(like starttls) that is hard to implement as an add-on, you're basically 
forced either copy/paste a lot of code or to fork asyncio.  And if you 
fork it, how will your dependencies can be upgraded to use that fork?


I want to continue (as we did in 3.4.x releases) evolving asyncio on a 
faster scale than CPython currently evolves, *and* to guarantee that we 
won't break existing code.  That's why I propose to tweak our definition 
of provisional packages.


Yury
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] provisional status for asyncio

2015-08-27 Thread Guido van Rossum 
Maybe asyncio should just be kept provisional during 3.5, with a separate
promise to remain backward compatible?

On Thu, Aug 27, 2015 at 3:24 PM, Yury Selivanov 
wrote:

> On 2015-08-27 5:53 PM, Brett Cannon wrote:
>
>>
>>
>> Considering that Python versioning is defined as
>> major.minor.micro, I'll
>> rephrase the proposal:
>>
>> Level 1: Backwards incompatible changes might be introduced in new
>> Python releases (including micro releases)
>>
>> Level 2: Only backwards compatible changes (new APIs including) can be
>> introduced in micro releases.
>>
>>
>> In that case I don't think it's a good idea for something that has
>> widespread use to get new APIs in a micro release; I lived the
>> 2.2.1/boolean event and I don't want to go through that again. If a module
>> is used enough to warrant not breaking backwards-compatibility then it
>> warrants not being provisional and being like any other module.
>>
>
> I wasn't using Python 2.2/2.3, but from what I could google the
> "2.2.1/boolean event" you mention was introducing True/False/bool
> built-ins.  This sounds like a language-level change, as opposed to new API
> in a stdlib module, which is a different scale.
>
> My understanding about adding new features in bugfix releases (3.5.x) is
> that you might end up in a situation where your 3.5 code developed on 3.5.x
> suddenly stops working on 3.5.y.  Yes, you have to be careful about how you
> deploy and test your code when using a provisional package.
>
> But the thing about asyncio is that it *is* still provisional in 3.4.
> During 3.4 release cycle we introduced many new features to asyncio, and to
> be honest, I haven't heard anybody complaining.  I believe that main
> motivation for making asyncio non-provisional was to guarantee that we
> won't introduce backwards-incompatible changes to it.
>
> Given the fact that asyncio sees some adoption, I support that from now on
> we will guarantee that backwards compatibility is preserved. But
> withholding new useful (and sometimes essential) features till 3.6.0 is out
> (March 2017?) sounds wrong to me.
>
> I should also mention that asyncio is different from other packages in the
> stdlib:
>
> 1. It's new, it virtually didn't exist before 3.4.0.
>
> 2. It's not a module, it's a framework.  If it lacks a core feature (like
> starttls) that is hard to implement as an add-on, you're basically forced
> either copy/paste a lot of code or to fork asyncio.  And if you fork it,
> how will your dependencies can be upgraded to use that fork?
>
> I want to continue (as we did in 3.4.x releases) evolving asyncio on a
> faster scale than CPython currently evolves, *and* to guarantee that we
> won't break existing code.  That's why I propose to tweak our definition of
> provisional packages.
>
>
> Yury
> ___
> Python-Dev mailing list
> [email protected]
> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] provisional status for asyncio

2015-08-27 Thread Brett Cannon 
On Thu, 27 Aug 2015 at 15:24 Yury Selivanov  wrote:

> On 2015-08-27 5:53 PM, Brett Cannon wrote:
> >
> >
> > Considering that Python versioning is defined as
> > major.minor.micro, I'll
> > rephrase the proposal:
> >
> > Level 1: Backwards incompatible changes might be introduced in new
> > Python releases (including micro releases)
> >
> > Level 2: Only backwards compatible changes (new APIs including) can
> be
> > introduced in micro releases.
> >
> >
> > In that case I don't think it's a good idea for something that has
> > widespread use to get new APIs in a micro release; I lived the
> > 2.2.1/boolean event and I don't want to go through that again. If a
> > module is used enough to warrant not breaking backwards-compatibility
> > then it warrants not being provisional and being like any other module.
>
> I wasn't using Python 2.2/2.3, but from what I could google the
> "2.2.1/boolean event" you mention was introducing True/False/bool
> built-ins.  This sounds like a language-level change, as opposed to new
> API in a stdlib module, which is a different scale.
>

True, but that doesn't mean that 3.5.1 will be able to run code that 3.5.0
has no chance of running because you introduced a new feature in asyncio.


>
> My understanding about adding new features in bugfix releases (3.5.x) is
> that you might end up in a situation where your 3.5 code developed on
> 3.5.x suddenly stops working on 3.5.y.  Yes, you have to be careful
> about how you deploy and test your code when using a provisional package.
>
> But the thing about asyncio is that it *is* still provisional in 3.4.
>

Right, but we're talking about 3.5 here, right?


> During 3.4 release cycle we introduced many new features to asyncio, and
> to be honest, I haven't heard anybody complaining.  I believe that main
> motivation for making asyncio non-provisional was to guarantee that we
> won't introduce backwards-incompatible changes to it.
>
> Given the fact that asyncio sees some adoption, I support that from now
> on we will guarantee that backwards compatibility is preserved. But
> withholding new useful (and sometimes essential) features till 3.6.0 is
> out (March 2017?) sounds wrong to me.
>
> I should also mention that asyncio is different from other packages in
> the stdlib:
>
> 1. It's new, it virtually didn't exist before 3.4.0.
>

Sure, but now it does. You said yourself that asyncio is seeing adoption,
so exists now for at least some people.


>
> 2. It's not a module, it's a framework.


But it's still in the stdlib and has already gone through one release as
provisional.


>   If it lacks a core feature
> (like starttls) that is hard to implement as an add-on, you're basically
> forced either copy/paste a lot of code or to fork asyncio.  And if you
> fork it, how will your dependencies can be upgraded to use that fork?
>

I'm not forking so that's not my problem. =)


>
> I want to continue (as we did in 3.4.x releases) evolving asyncio on a
> faster scale than CPython currently evolves, *and* to guarantee that we
> won't break existing code.  That's why I propose to tweak our definition
> of provisional packages.
>

I still don't like it. I say it's either fully provisional or it's not. I'm
fine with extending its provisional status another feature release as long
as it clearly states that in What's New for 3.5, but I don't think this
granularity guarantee of not breaking APIs while adding new features is
worth it. What if you want to add a new feature that is really hard to do
right without breaking compatibility? We all know how trying that is. If
you truly want to keep an accelerated development cycle, then short of
releasing new stdlib versions every 6 months separate from the language
then I say keep it provisional for 3.5.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] provisional status for asyncio

2015-08-27 Thread Yury Selivanov 



On 2015-08-27 6:44 PM, Guido van Rossum wrote:
Maybe asyncio should just be kept provisional during 3.5, with a 
separate promise to remain backward compatible?


I'm +1.

I'm also certain that by 3.6.0 we will stabilize asyncio to the point we 
can freeze it like any other stdlib module.


Yury

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] provisional status for asyncio

2015-08-27 Thread Brett Cannon 
On Thu, 27 Aug 2015 at 15:44 Guido van Rossum  wrote:

> Maybe asyncio should just be kept provisional during 3.5, with a separate
> promise to remain backward compatible?
>

My worry is that promising backwards-compatibility while still trying to
change things is going to lead to needlessly hampering the evolution of the
framework. If you want to say you will try hard to not break code and stay
provisional I'm all for that (although I assume we already do that anyway),
but making our standard backwards-compatibility promise on top of new
features just seems too messy to me without knowing where the new features
will take you. Past that it seems like asyncio is cheating on our bugfix
release compatibility promises because it was lucky enough to be added as
provisional.

I realize asyncio went in like it did partially to motivate `yield from`
and now async/await, and that's fine. But I say go all-in and just stay
provisional another release and then lock it down in 3.6.

-Brett


>
> On Thu, Aug 27, 2015 at 3:24 PM, Yury Selivanov 
> wrote:
>
>> On 2015-08-27 5:53 PM, Brett Cannon wrote:
>>
>>>
>>>
>>> Considering that Python versioning is defined as
>>> major.minor.micro, I'll
>>> rephrase the proposal:
>>>
>>> Level 1: Backwards incompatible changes might be introduced in new
>>> Python releases (including micro releases)
>>>
>>> Level 2: Only backwards compatible changes (new APIs including) can
>>> be
>>> introduced in micro releases.
>>>
>>>
>>> In that case I don't think it's a good idea for something that has
>>> widespread use to get new APIs in a micro release; I lived the
>>> 2.2.1/boolean event and I don't want to go through that again. If a module
>>> is used enough to warrant not breaking backwards-compatibility then it
>>> warrants not being provisional and being like any other module.
>>>
>>
>> I wasn't using Python 2.2/2.3, but from what I could google the
>> "2.2.1/boolean event" you mention was introducing True/False/bool
>> built-ins.  This sounds like a language-level change, as opposed to new API
>> in a stdlib module, which is a different scale.
>>
>> My understanding about adding new features in bugfix releases (3.5.x) is
>> that you might end up in a situation where your 3.5 code developed on 3.5.x
>> suddenly stops working on 3.5.y.  Yes, you have to be careful about how you
>> deploy and test your code when using a provisional package.
>>
>> But the thing about asyncio is that it *is* still provisional in 3.4.
>> During 3.4 release cycle we introduced many new features to asyncio, and to
>> be honest, I haven't heard anybody complaining.  I believe that main
>> motivation for making asyncio non-provisional was to guarantee that we
>> won't introduce backwards-incompatible changes to it.
>>
>> Given the fact that asyncio sees some adoption, I support that from now
>> on we will guarantee that backwards compatibility is preserved. But
>> withholding new useful (and sometimes essential) features till 3.6.0 is out
>> (March 2017?) sounds wrong to me.
>>
>> I should also mention that asyncio is different from other packages in
>> the stdlib:
>>
>> 1. It's new, it virtually didn't exist before 3.4.0.
>>
>> 2. It's not a module, it's a framework.  If it lacks a core feature (like
>> starttls) that is hard to implement as an add-on, you're basically forced
>> either copy/paste a lot of code or to fork asyncio.  And if you fork it,
>> how will your dependencies can be upgraded to use that fork?
>>
>> I want to continue (as we did in 3.4.x releases) evolving asyncio on a
>> faster scale than CPython currently evolves, *and* to guarantee that we
>> won't break existing code.  That's why I propose to tweak our definition of
>> provisional packages.
>
>
>>
>> Yury
>>
>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] provisional status for asyncio

2015-08-27 Thread Yury Selivanov 

Brett,

On 2015-08-27 6:46 PM, Brett Cannon wrote:
[...]
I say it's either fully provisional or it's not. I'm fine with 
extending its provisional status another feature release as long as it 
clearly states that in What's New for 3.5, but I don't think this 
granularity guarantee of not breaking APIs while adding new features 
is worth it. What if you want to add a new feature that is really hard 
to do right without breaking compatibility? We all know how trying 
that is. If you truly want to keep an accelerated development cycle, 
then short of releasing new stdlib versions every 6 months separate 
from the language then I say keep it provisional for 3.5. 


I'm fine with keeping it provisional in 3.5 (and Guido suggests this 
idea too in this thread).


A lot of companies (including big ones) are using asyncio already, 
despite the fact that it's provisional in 3.4.  I seriously doubt that 
keeping it provisional in 3.5 will do any harm.


asyncio documentation in 3.4.x has the following notes section:

Note: The asyncio package has been included in the
standard library on a provisional basis. Backwards
incompatible changes (up to and including removal
of the module) may occur if deemed necessary by the
core developers.

I suggest to add a slightly less strong-worded note to 3.5 documentation:

Note: The asyncio package has been included in the
standard library on a provisional basis. Backwards
incompatible changes may occur if deemed absolutely
necessary by the core developers.


Yury


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] provisional status for asyncio

2015-08-27 Thread Nick Coghlan 
On 28 August 2015 at 09:00, Yury Selivanov  wrote:
> Brett,
>
> On 2015-08-27 6:46 PM, Brett Cannon wrote:
> [...]
>>
>> I say it's either fully provisional or it's not. I'm fine with extending
>> its provisional status another feature release as long as it clearly states
>> that in What's New for 3.5, but I don't think this granularity guarantee of
>> not breaking APIs while adding new features is worth it. What if you want to
>> add a new feature that is really hard to do right without breaking
>> compatibility? We all know how trying that is. If you truly want to keep an
>> accelerated development cycle, then short of releasing new stdlib versions
>> every 6 months separate from the language then I say keep it provisional for
>> 3.5.
>
>
> I'm fine with keeping it provisional in 3.5 (and Guido suggests this idea
> too in this thread).
>
> A lot of companies (including big ones) are using asyncio already, despite
> the fact that it's provisional in 3.4.  I seriously doubt that keeping it
> provisional in 3.5 will do any harm.
>
> asyncio documentation in 3.4.x has the following notes section:
>
> Note: The asyncio package has been included in the
> standard library on a provisional basis. Backwards
> incompatible changes (up to and including removal
> of the module) may occur if deemed necessary by the
> core developers.
>
> I suggest to add a slightly less strong-worded note to 3.5 documentation:
>
> Note: The asyncio package has been included in the
> standard library on a provisional basis. Backwards
> incompatible changes may occur if deemed absolutely
> necessary by the core developers.

I'd suggest including a clearer motivation there:

Note: The asyncio package has been included in the standard
library on a provisional basis, and thus may gain new APIs and
capabilities in maintenance releases as it matures. Backwards
incompatible changes may occur if deemed absolutely necessary by the
core developers.

It's a gentler phrasing that still serves to warn away folks that are
particularly change averse, while also assuring folks on faster
iteration cycles that the update cadence is still 6 months rather than
18-24 months. New standard library APIs could thus evolve through "not
stable yet" -> "mostly stable" -> "stable".

This is essentially Yury's original "two levels of provisional" idea -
if a package survives an entire release cycle, it's pretty clear we're
not going to be taking it out, but it's also the case that a
comparatively broad API like asyncio may take a couple of feature
release cycles to settle down to a point where we can declare it
sufficiently complete that we're only going to add new interfaces in
future feature releases.

asyncio's just the first addition we've made under the PEP 411
guidelines that's big enough to benefit from the extra release cycle
of stabilisation.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Testing tkinter on Linux

2015-08-27 Thread Zachary Ware 
On Thu, Aug 27, 2015 at 4:13 PM, Chris Angelico  wrote:
> On Fri, Aug 28, 2015 at 5:00 AM, R. David Murray  
> wrote:
>> I believe gui depends on the existence of the DISPLAY environment
>> variable on unix/linux (that is, TK will fail to start if DISPLAY is not
>> set, so _is_gui_available will return False).  You should be able to
>> confirm this by looking at the text of the skip message in the buildbot
>> output.
>
> A recent buildbot log [1] shows that the GUI tests are being skipped,
> although I'm not seeing the message. Where do I go to set DISPLAY for
> the bot (which runs mostly in the background)?
>
> Note that it's all running as root, which may make a difference to the
> defaults, so this might have to be done more explicitly than it
> otherwise would. (But root is quite happy to use X; running xclock
> brings up a clock just fine.)

I just set up a buildslave building with X available [1].  I don't
know if the way I did it is strictly correct, but my slave is set up
with Xvfb set to start at boot, and I hacked the buildbot.tac file to
add 'os.environ["DISPLAY"] = ":100"' (which is what Xvfb starts on) as
that was the simplest way I could figure out to do it.  It seems to
work; an initial test build of 2.7 passed all the Tcl/Tk tests [2].

For those interested, the slave has Tcl/Tk 8.5.17 installed (which is
the latest "stable" release in portage).

[1] http://buildbot.python.org/all/buildslaves/ware-gentoo-x86
[2] 
http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%20with%20X%202.7/builds/0/steps/test/logs/stdio

-- 
Zach
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com