Dear,
I have faced a problem as below when I startup the python IDLE
[cid:image001.png@01D0E0CE.454096D0]
Then I try to run a simple program like this:
[cid:image002.png@01D0E0CE.454096D0]
Other issue is pop out
[cid:image003.png@01D0E0CE.454096D0]
May I know how to fix the issue? My laptop
On 8/27/2015 12:35 AM, Chris Angelico wrote:
On Thu, Aug 27, 2015 at 2:20 PM, Terry Reedy tjre...@udel.edu 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
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
https://mail.python.org/mailman/listinfo/python-list mailing list or
Stack Overflow
*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
https://mail.python.org/mailman/listinfo/python-list mailing list or Stack
Overflow http://stackoverflow.com/.
On Thu, Aug 27,
On Thu, 27 Aug 2015 14:24:36 -0400, Terry Reedy tjre...@udel.edu wrote:
On 8/27/2015 12:35 AM, Chris Angelico wrote:
On Thu, Aug 27, 2015 at 2:20 PM, Terry Reedy tjre...@udel.edu wrote:
None of the linux buildbots run with X enabled. Consequently none of the
tkinter (or tkinter user) gui
* R. David Murray rdmur...@bitdance.com [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
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
On Fri, Aug 28, 2015 at 5:00 AM, R. David Murray rdmur...@bitdance.com 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
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
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 yselivanov...@gmail.com
wrote:
On 2015-08-27
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
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
On Thu, 27 Aug 2015 at 14:39 Yury Selivanov yselivanov...@gmail.com 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
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
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.
On 28 August 2015 at 09:00, Yury Selivanov yselivanov...@gmail.com 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
On Thu, 27 Aug 2015 at 14:16 Yury Selivanov yselivanov...@gmail.com 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
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 yselivanov...@gmail.com
wrote:
On 2015-08-27 5:53 PM, Brett Cannon wrote:
Considering that Python versioning is defined as
On Thu, 27 Aug 2015 at 15:24 Yury Selivanov yselivanov...@gmail.com 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
On Thu, 27 Aug 2015 at 15:44 Guido van Rossum gu...@python.org 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
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
21 matches
Mail list logo
