Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #95099 > unrolled thread

Linux users: please run gui tests

Back to article view | Back to comp.lang.python

Contents

  Linux users: please run gui tests Terry Reedy <tjreedy@udel.edu> - 2015-08-06 22:07 -0400
    Re: Linux users: please run gui tests Grant Edwards <invalid@invalid.invalid> - 2015-08-07 03:43 +0000
      Re: Linux users: please run gui tests Grant Edwards <invalid@invalid.invalid> - 2015-08-07 03:46 +0000
        Re: Linux users: please run gui tests Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-08-07 08:08 +0100
        Re: Linux users: please run gui tests Terry Reedy <tjreedy@udel.edu> - 2015-08-07 20:40 -0400
    Re: Linux users: please run gui tests Cecil Westerhof <Cecil@decebal.nl> - 2015-08-07 09:53 +0200
      Re: Linux users: please run gui tests Cecil Westerhof <Cecil@decebal.nl> - 2015-08-07 10:23 +0200
        Re: Linux users: please run gui tests Peter Otten <__peter__@web.de> - 2015-08-07 11:15 +0200
          Re: Linux users: please run gui tests Cecil Westerhof <Cecil@decebal.nl> - 2015-08-07 12:59 +0200
            Re: Linux users: please run gui tests Cecil Westerhof <Cecil@decebal.nl> - 2015-08-07 14:36 +0200
        Re: Linux users: please run gui tests Chris Angelico <rosuav@gmail.com> - 2015-08-07 19:51 +1000
        Re: Linux users: please run gui tests Laura Creighton <lac@openend.se> - 2015-08-07 14:38 +0200
        Re: Linux users: please run gui tests Peter Otten <__peter__@web.de> - 2015-08-07 15:06 +0200
        Re: Linux users: please run gui tests Laura Creighton <lac@openend.se> - 2015-08-07 15:46 +0200
        Re: Linux users: please run gui tests Peter Otten <__peter__@web.de> - 2015-08-07 17:34 +0200
        Re: Linux users: please run gui tests Laura Creighton <lac@openend.se> - 2015-08-07 19:01 +0200
        Re: Linux users: please run gui tests Peter Otten <__peter__@web.de> - 2015-08-07 21:13 +0200
        Re: Linux users: please run gui tests Laura Creighton <lac@openend.se> - 2015-08-07 22:35 +0200
        Re: Linux users: please run gui tests Terry Reedy <tjreedy@udel.edu> - 2015-08-07 21:04 -0400
        Re: Linux users: please run gui tests Terry Reedy <tjreedy@udel.edu> - 2015-08-07 21:25 -0400
        Re: Linux users: please run gui tests Laura Creighton <lac@openend.se> - 2015-08-08 08:35 +0200
        Re: Linux users: please run gui tests Laura Creighton <lac@openend.se> - 2015-08-08 08:40 +0200
        Re: Linux users: please run gui tests Peter Otten <__peter__@web.de> - 2015-08-08 09:53 +0200
        Re: Linux users: please run gui tests Laura Creighton <lac@openend.se> - 2015-08-08 17:41 +0200
        Re: Linux users: please run gui tests Laura Creighton <lac@openend.se> - 2015-08-08 19:20 +0200
        Re: Linux users: please run gui tests Terry Reedy <tjreedy@udel.edu> - 2015-08-12 21:49 -0400
        Re: Linux users: please run gui tests Laura Creighton <lac@openend.se> - 2015-08-13 07:11 +0200
        Re: Linux users: please run gui tests Terry Reedy <tjreedy@udel.edu> - 2015-08-13 07:55 -0400
    Re: Linux users: please run gui tests David Bolen <db3l.net@gmail.com> - 2015-08-07 16:53 -0400

Page 1 of 2  [1] 2  Next page →

#95099 — Linux users: please run gui tests

Python has an extensive test suite run after each 'batch' of commits on 
a variety of buildbots.  However, the Linux buildbots all (AFAIK) run 
'headless', with gui's disabled.  Hence the following
test_tk test_ttk_guionly test_idle
(and on 3.5, test_tix, but not important)
are skipped either in whole or in part.

We are planning on adding the use of tkinter.ttk to Idle after the 3.5.0 
release, but a couple of other core developers have expressed concern 
about the reliability of tkinter.ttk on Linux.

There is also an unresolved issue where test_ttk hung on Ubuntu Unity 3 
years ago. https://bugs.python.org/issue14799

I would appreciate it if some people could run the linux version of
py -3.4 -m test -ugui test_tk test_ttk_guionly test_idle
(or 3.5).  I guess this means 'python3 for the executable.

and report here python version, linux system, and result.
Alteration of environment and locale is a known issue, skip that.

-- 
Terry Jan Reedy

[toc] | [next] | [standalone]

#95102

On 2015-08-07, Terry Reedy <tjreedy@udel.edu> wrote:
> Python has an extensive test suite run after each 'batch' of commits on 
> a variety of buildbots.  However, the Linux buildbots all (AFAIK) run 
> 'headless', with gui's disabled.  Hence the following
> test_tk test_ttk_guionly test_idle
> (and on 3.5, test_tix, but not important)
> are skipped either in whole or in part.
>
> We are planning on adding the use of tkinter.ttk to Idle after the 3.5.0 
> release, but a couple of other core developers have expressed concern 
> about the reliability of tkinter.ttk on Linux.
>
> There is also an unresolved issue where test_ttk hung on Ubuntu Unity 3 
> years ago. https://bugs.python.org/issue14799
>
> I would appreciate it if some people could run the linux version of
> py -3.4 -m test -ugui test_tk test_ttk_guionly test_idle
> (or 3.5).  I guess this means 'python3 for the executable.
>
> and report here python version, linux system, and result.
> Alteration of environment and locale is a known issue, skip that.

$ uname -a
Linux aleph 3.12.21-gentoo-r1 #1 SMP PREEMPT Wed Jul 2 22:46:08 CDT 2014 i686 Intel(R) Core(TM) i3-3220T CPU @ 2.80GHz GenuineIntel GNU/Linux

$ python3 --version
Python 3.3.5

$ py -3.4 -m test -ugui test_tk test_ttk_guionly test_idle
bash: py: command not found

$ python3 -3.4 -m test -ugui test_tk test_ttk_guionly test_idle
Unknown option: -3
usage: python3 [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try `python -h' for more information.

--
Grant

[toc] | [prev] | [next] | [standalone]

#95103

On 2015-08-07, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2015-08-07, Terry Reedy <tjreedy@udel.edu> wrote:
>> Python has an extensive test suite run after each 'batch' of commits on 
>> a variety of buildbots.  However, the Linux buildbots all (AFAIK) run 
>> 'headless', with gui's disabled.  Hence the following
>> test_tk test_ttk_guionly test_idle
>> (and on 3.5, test_tix, but not important)
>> are skipped either in whole or in part.
>>
>> We are planning on adding the use of tkinter.ttk to Idle after the 3.5.0 
>> release, but a couple of other core developers have expressed concern 
>> about the reliability of tkinter.ttk on Linux.
>>
>> There is also an unresolved issue where test_ttk hung on Ubuntu Unity 3 
>> years ago. https://bugs.python.org/issue14799
>>
>> I would appreciate it if some people could run the linux version of
>> py -3.4 -m test -ugui test_tk test_ttk_guionly test_idle
>> (or 3.5).  I guess this means 'python3 for the executable.
>>
>> and report here python version, linux system, and result.
>> Alteration of environment and locale is a known issue, skip that.
>
> $ uname -a
> Linux aleph 3.12.21-gentoo-r1 #1 SMP PREEMPT Wed Jul 2 22:46:08 CDT 2014 i686 Intel(R) Core(TM) i3-3220T CPU @ 2.80GHz GenuineIntel GNU/Linux
>
> $ python3 --version
> Python 3.3.5
>
> $ py -3.4 -m test -ugui test_tk test_ttk_guionly test_idle
> bash: py: command not found
>
> $ python3 -3.4 -m test -ugui test_tk test_ttk_guionly test_idle
> Unknown option: -3
> usage: python3 [option] ... [-c cmd | -m mod | file | -] [arg] ...
> Try `python -h' for more information.

Ah, I guess the -3.4 isn't valid.

$ python3 --version
Python 3.3.5

$ 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.


$ python3.4 --version
Python 3.4.1

$ python3.4 -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.

In both cases, some small, yellow windows flash briefly on the screen.

[toc] | [prev] | [next] | [standalone]

#95105

On 07/08/2015 04:46, Grant Edwards wrote:
> On 2015-08-07, Grant Edwards <invalid@invalid.invalid> wrote:
>> On 2015-08-07, Terry Reedy <tjreedy@udel.edu> wrote:
>>> Python has an extensive test suite run after each 'batch' of commits on
>>> a variety of buildbots.  However, the Linux buildbots all (AFAIK) run
>>> 'headless', with gui's disabled.  Hence the following
>>> test_tk test_ttk_guionly test_idle
>>> (and on 3.5, test_tix, but not important)
>>> are skipped either in whole or in part.
>>>
>>> We are planning on adding the use of tkinter.ttk to Idle after the 3.5.0
>>> release, but a couple of other core developers have expressed concern
>>> about the reliability of tkinter.ttk on Linux.
>>>
>>> There is also an unresolved issue where test_ttk hung on Ubuntu Unity 3
>>> years ago. https://bugs.python.org/issue14799
>>>
>>> I would appreciate it if some people could run the linux version of
>>> py -3.4 -m test -ugui test_tk test_ttk_guionly test_idle
>>> (or 3.5).  I guess this means 'python3 for the executable.
>>>
>>> and report here python version, linux system, and result.
>>> Alteration of environment and locale is a known issue, skip that.
>>
>> $ uname -a
>> Linux aleph 3.12.21-gentoo-r1 #1 SMP PREEMPT Wed Jul 2 22:46:08 CDT 2014 i686 Intel(R) Core(TM) i3-3220T CPU @ 2.80GHz GenuineIntel GNU/Linux
>>
>> $ python3 --version
>> Python 3.3.5
>>
>> $ py -3.4 -m test -ugui test_tk test_ttk_guionly test_idle
>> bash: py: command not found
>>
>> $ python3 -3.4 -m test -ugui test_tk test_ttk_guionly test_idle
>> Unknown option: -3
>> usage: python3 [option] ... [-c cmd | -m mod | file | -] [arg] ...
>> Try `python -h' for more information.
>
> Ah, I guess the -3.4 isn't valid.
>

Correct.  The "py -3.4" is the Python Launcher for Windows, hence the 
"run the linux version of".

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#95146

On 8/6/2015 11:46 PM, Grant Edwards wrote:

> In both cases, some small, yellow windows flash briefly on the screen.

I should have warned about this ;-).  Gui tests mean 'actually flash 
stuff on screen', which is why they do not get run.



-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#95109

On Friday  7 Aug 2015 04:07 CEST, Terry Reedy wrote:

> Python has an extensive test suite run after each 'batch' of commits
> on a variety of buildbots. However, the Linux buildbots all (AFAIK)
> run headless', with gui's disabled. Hence the following test_tk
> test_ttk_guionly test_idle (and on 3.5, test_tix, but not important)
> are skipped either in whole or in part.
>
> We are planning on adding the use of tkinter.ttk to Idle after the
> 3.5.0 release, but a couple of other core developers have expressed
> concern about the reliability of tkinter.ttk on Linux.
>
> There is also an unresolved issue where test_ttk hung on Ubuntu
> Unity 3 years ago. https://bugs.python.org/issue14799
>
> I would appreciate it if some people could run the linux version of
> py -3.4 -m test -ugui test_tk test_ttk_guionly test_idle
> (or 3.5).  I guess this means 'python3 for the executable.
>
> and report here python version, linux system, and result.
> Alteration of environment and locale is a known issue, skip that.

I made a Bash script:
    python3 --version
    python3 -m test -ugui test_tk test_ttk_guionly test_idle

This gives:
    Python 3.4.1
    [1/3] test_tk
    [2/3] test_ttk_guionly
    [3/3] test_idle
    All 3 tests OK.

This was on openSUSE 13.2.

I also tried to run it on Debian, but there I get:
    No moduke named test.__main__; 'test' is a package and cannot be
    directly executed

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#95110

On Friday  7 Aug 2015 09:53 CEST, Cecil Westerhof wrote:

> On Friday  7 Aug 2015 04:07 CEST, Terry Reedy wrote:
>
>> Python has an extensive test suite run after each 'batch' of
>> commits on a variety of buildbots. However, the Linux buildbots all
>> (AFAIK) run headless', with gui's disabled. Hence the following
>> test_tk test_ttk_guionly test_idle (and on 3.5, test_tix, but not
>> important) are skipped either in whole or in part.
>>
>> We are planning on adding the use of tkinter.ttk to Idle after the
>> 3.5.0 release, but a couple of other core developers have expressed
>> concern about the reliability of tkinter.ttk on Linux.
>>
>> There is also an unresolved issue where test_ttk hung on Ubuntu
>> Unity 3 years ago. https://bugs.python.org/issue14799
>>
>> I would appreciate it if some people could run the linux version of
>> py -3.4 -m test -ugui test_tk test_ttk_guionly test_idle
>> (or 3.5).  I guess this means 'python3 for the executable.
>>
>> and report here python version, linux system, and result.
>> Alteration of environment and locale is a known issue, skip that.
>
> I made a Bash script:
> python3 --version
> python3 -m test -ugui test_tk test_ttk_guionly test_idle
>
> This gives:
> Python 3.4.1
> [1/3] test_tk
> [2/3] test_ttk_guionly
> [3/3] test_idle
> All 3 tests OK.
>
> This was on openSUSE 13.2.
>
> I also tried to run it on Debian, but there I get:
> No moduke named test.__main__; 'test' is a package and cannot be
> directly executed

I also tried it on an Ubuntu system: there I got the same error. (Not
very strange because it is a Debian derivative.)

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#95114

Cecil Westerhof wrote:

>> python3 --version
>> python3 -m test -ugui test_tk test_ttk_guionly test_idle
>>
>> This gives:
>> Python 3.4.1
>> [1/3] test_tk
>> [2/3] test_ttk_guionly
>> [3/3] test_idle
>> All 3 tests OK.
>>
>> This was on openSUSE 13.2.
>>
>> I also tried to run it on Debian, but there I get:
>> No moduke named test.__main__; 'test' is a package and cannot be
>> directly executed
> 
> I also tried it on an Ubuntu system: there I got the same error. (Not
> very strange because it is a Debian derivative.)

By default Debian doesn't install the test suite -- that's why you cannot 
run it ;)

Install it with

$ sudo apt-get install libpython3.4-testsuite

and then try again.

[toc] | [prev] | [next] | [standalone]

#95117

On Friday  7 Aug 2015 11:15 CEST, Peter Otten wrote:

> Cecil Westerhof wrote:
>
>>> python3 --version
>>> python3 -m test -ugui test_tk test_ttk_guionly test_idle
>>>
>>> This gives:
>>> Python 3.4.1
>>> [1/3] test_tk
>>> [2/3] test_ttk_guionly
>>> [3/3] test_idle
>>> All 3 tests OK.
>>>
>>> This was on openSUSE 13.2.
>>>
>>> I also tried to run it on Debian, but there I get:
>>> No moduke named test.__main__; 'test' is a package and cannot be
>>> directly executed
>>
>> I also tried it on an Ubuntu system: there I got the same error.
>> (Not very strange because it is a Debian derivative.)
>
> By default Debian doesn't install the test suite -- that's why you
> cannot run it ;)
>
> Install it with
>
> $ sudo apt-get install libpython3.4-testsuite
>
> and then try again.

python3-tk needs also to be installed.

I changed the script to:
    uname -mrs
    python3 --version
    start=$(date +%s)
    python3 -m test -ugui test_tk test_ttk_guionly test_idle
    end=$(date +%s)
    printf "Running the tests took %d seconds\n" $((end - start))

On my openSUSE system this gives:
    Linux 3.16.7-21-desktop x86_64
    Python 3.4.1
    [1/3] test_tk
    [2/3] test_ttk_guionly
    [3/3] test_idle
    All 3 tests OK.
    Running the tests took 20 seconds

On the Debian system this gives:
    Linux 3.16.0-4-586 i686
    Python 3.4.2
    [1/3] test_tk
    [2/3] test_ttk_guionly
    [3/3] test_idle
    All 3 tests OK.
    Running the tests took 16 seconds


-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#95120

On Friday  7 Aug 2015 12:59 CEST, Cecil Westerhof wrote:

> On Friday  7 Aug 2015 11:15 CEST, Peter Otten wrote:
>
>> Cecil Westerhof wrote:
>>
>>>> python3 --version
>>>> python3 -m test -ugui test_tk test_ttk_guionly test_idle
>>>>
>>>> This gives:
>>>> Python 3.4.1
>>>> [1/3] test_tk
>>>> [2/3] test_ttk_guionly
>>>> [3/3] test_idle
>>>> All 3 tests OK.
>>>>
>>>> This was on openSUSE 13.2.
>>>>
>>>> I also tried to run it on Debian, but there I get:
>>>> No moduke named test.__main__; 'test' is a package and cannot be
>>>> directly executed
>>>
>>> I also tried it on an Ubuntu system: there I got the same error.
>>> (Not very strange because it is a Debian derivative.)
>>
>> By default Debian doesn't install the test suite -- that's why you
>> cannot run it ;)
>>
>> Install it with
>>
>> $ sudo apt-get install libpython3.4-testsuite
>>
>> and then try again.
>
> python3-tk needs also to be installed.
>
> I changed the script to:
> uname -mrs
> python3 --version
> start=$(date +%s)
> python3 -m test -ugui test_tk test_ttk_guionly test_idle
> end=$(date +%s)
> printf "Running the tests took %d seconds\n" $((end - start))
>
> On my openSUSE system this gives:
> Linux 3.16.7-21-desktop x86_64
> Python 3.4.1
> [1/3] test_tk
> [2/3] test_ttk_guionly
> [3/3] test_idle
> All 3 tests OK.
> Running the tests took 20 seconds
>
> On the Debian system this gives:
> Linux 3.16.0-4-586 i686
> Python 3.4.2
> [1/3] test_tk
> [2/3] test_ttk_guionly
> [3/3] test_idle
> All 3 tests OK.
> Running the tests took 16 seconds

On another Debian system I get:
    Linux 3.16.0-4-amd64 x86_64
    Python 3.4.2
    [1/3] test_tk
    [2/3] test_ttk_guionly
    [3/3] test_idle
    All 3 tests OK.
    Running the tests took 28 seconds

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#95115

On Fri, Aug 7, 2015 at 7:15 PM, Peter Otten <__peter__@web.de> wrote:
> By default Debian doesn't install the test suite -- that's why you cannot
> run it ;)
>
> Install it with
>
> $ sudo apt-get install libpython3.4-testsuite
>
> and then try again.

Which makes it work fine on my system.

ChrisA

[toc] | [prev] | [next] | [standalone]

#95119

In a message of Fri, 07 Aug 2015 19:51:51 +1000, Chris Angelico writes:
>On Fri, Aug 7, 2015 at 7:15 PM, Peter Otten <__peter__@web.de> wrote:
>> By default Debian doesn't install the test suite -- that's why you cannot
>> run it ;)
>>
>> Install it with
>>
>> $ sudo apt-get install libpython3.4-testsuite
>>
>> and then try again.
>
>Which makes it work fine on my system.
>
>ChrisA

Not here.  

I'm running debian unstable (jessie)
I've already got libpython3.4-testsuite installed, and I cannot run
the tests.

lac@smartwheels:~$ lsb_release -a
LSB Version:	   core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID:	   Debian
Description:	   Debian GNU/Linux 8.0 (jessie)
Release:	   8.0
Codename:	   jessie

lac@smartwheels:~$ cat /proc/version
Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org)
(gcc version 4.8.4  (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt9-2 (2015-04-13)

lac@smartwheels:~$ python3 --version
Python 3.4.3+

I have the lastest version of libpython3.4-testsuite installed.
lac@smartwheels:~$ apt-cache policy libpython3.4-testsuite
libpython3.4-testsuite:
  Installed: 3.4.3-8
  Candidate: 3.4.3-8
  Version table:
 *** 3.4.3-8 0
       500 http://ftp.se.debian.org/debian/ unstable/main amd64 Packages
       500 http://ftp.debian.org/debian/ unstable/main amd64 Packages
       100 /var/lib/dpkg/status
							      
This is a brand new terminal window, i.e. I am not sitting in a virtualenv
that I have completely forgotten about.

But I still get:
lac@smartwheels:~$ python3 -m test -ugui test_tk test_ttk_guionly test_idle
/usr/bin/python3: Error while finding spec for 'test.__main__' (<class 'ImportError'>: bad magic number in 'test': b'\x03\xf3\r\n'); 'test' is a package and cannot be directly executed

Now I am very puzzled.  What else could I be missing to cause this?

Laura

[toc] | [prev] | [next] | [standalone]

#95121

Laura Creighton wrote:

> In a message of Fri, 07 Aug 2015 19:51:51 +1000, Chris Angelico writes:
>>On Fri, Aug 7, 2015 at 7:15 PM, Peter Otten <__peter__@web.de> wrote:
>>> By default Debian doesn't install the test suite -- that's why you
>>> cannot run it ;)
>>>
>>> Install it with
>>>
>>> $ sudo apt-get install libpython3.4-testsuite
>>>
>>> and then try again.
>>
>>Which makes it work fine on my system.
>>
>>ChrisA
> 
> Not here.
> 
> I'm running debian unstable (jessie)
> I've already got libpython3.4-testsuite installed, and I cannot run
> the tests.
> 
> lac@smartwheels:~$ lsb_release -a
> LSB Version:	  
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-
amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-
amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-
amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID:	   Debian
> Description:	   Debian GNU/Linux 8.0 (jessie)
> Release:	   8.0
> Codename:	   jessie
> 
> lac@smartwheels:~$ cat /proc/version
> Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org)
> (gcc version 4.8.4  (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt9-2
> (2015-04-13)
> 
> lac@smartwheels:~$ python3 --version
> Python 3.4.3+
> 
> I have the lastest version of libpython3.4-testsuite installed.
> lac@smartwheels:~$ apt-cache policy libpython3.4-testsuite
> libpython3.4-testsuite:
>   Installed: 3.4.3-8
>   Candidate: 3.4.3-8
>   Version table:
>  *** 3.4.3-8 0
>        500 http://ftp.se.debian.org/debian/ unstable/main amd64 Packages
>        500 http://ftp.debian.org/debian/ unstable/main amd64 Packages
>        100 /var/lib/dpkg/status
> 
> This is a brand new terminal window, i.e. I am not sitting in a virtualenv
> that I have completely forgotten about.
> 
> But I still get:
> lac@smartwheels:~$ python3 -m test -ugui test_tk test_ttk_guionly
> test_idle /usr/bin/python3: Error while finding spec for 'test.__main__'
> (<class 'ImportError'>: bad magic number in 'test': b'\x03\xf3\r\n');
> 'test' is a package and cannot be directly executed
> 
> Now I am very puzzled.  What else could I be missing to cause this?

I can provoke something similar with

$ touch test.py
$ python -c import\ test
$ rm test.py
$ python3 -m test -ugui test_tk
/usr/bin/python3: bad magic number in 'test': b'\x03\xf3\r\n'

>From that I'd conclude that your python3 sees a leftover python2 pyc instead 
of the actual test package. Have a look at your working directory or 
PYTHONPATH.

[toc] | [prev] | [next] | [standalone]

#95123

In a message of Fri, 07 Aug 2015 15:06:41 +0200, Peter Otten writes:
>$ touch test.py
>$ python -c import\ test
>$ rm test.py
>$ python3 -m test -ugui test_tk
>/usr/bin/python3: bad magic number in 'test': b'\x03\xf3\r\n'
>
>>From that I'd conclude that your python3 sees a leftover python2 pyc instead 
>of the actual test package. Have a look at your working directory or 
>PYTHONPATH.

Right you are.  Thank you.

lac@smartwheels:~$ python3 -m test -ugui test_tk test_ttk_guionly test_idle
[1/3] test_tk
test test_tk failed -- multiple errors occurred; run in verbose mode for details
[2/3/1] test_ttk_guionly
[3/3/1] test_idle
2 tests OK.
1 test failed:
    test_tk

running python3 -v -m test -ugui test_tk 2>test_tk.out produces a whole lot
of output.

I put the file up here.
http://www2.openend.se/~lac/test_tk.out

But I don't think there is anything useful in it.  grepping the file
for 'failed' only gives you the same old
est test_tk failed -- multiple errors occurred; run in verbose mode for details

What would you (Terry)  like me to do now?

Laura

[toc] | [prev] | [next] | [standalone]

#95127

Laura Creighton wrote:

> In a message of Fri, 07 Aug 2015 15:06:41 +0200, Peter Otten writes:
>>$ touch test.py
>>$ python -c import\ test
>>$ rm test.py
>>$ python3 -m test -ugui test_tk
>>/usr/bin/python3: bad magic number in 'test': b'\x03\xf3\r\n'
>>
>>>From that I'd conclude that your python3 sees a leftover python2 pyc
>>>instead
>>of the actual test package. Have a look at your working directory or
>>PYTHONPATH.
> 
> Right you are.  Thank you.
> 
> lac@smartwheels:~$ python3 -m test -ugui test_tk test_ttk_guionly
> test_idle
> [1/3] test_tk
> test test_tk failed -- multiple errors occurred; run in verbose mode for
> details
> [2/3/1] test_ttk_guionly
> [3/3/1] test_idle
> 2 tests OK.
> 1 test failed:
>     test_tk
> 
> running python3 -v -m test -ugui test_tk 2>test_tk.out produces a whole
> lot of output.
> 
> I put the file up here.
> http://www2.openend.se/~lac/test_tk.out
> 
> But I don't think there is anything useful in it.  grepping the file
> for 'failed' only gives you the same old
> est test_tk failed -- multiple errors occurred; run in verbose mode for
> details
> 
> What would you (Terry)  like me to do now?

Run

$ python3 -m test -ugui -v test_tk

(That way the unittest framework will see the -v option)

Note that there are lines like

# possible namespace for /home/lac/src/accounting/test

in your python3 -v output that indicate that there may still be too much in 
your PYTHONPATH.

[toc] | [prev] | [next] | [standalone]

#95132

In a message of Fri, 07 Aug 2015 17:34:54 +0200, Peter Otten writes:
>Run
>
>$ python3 -m test -ugui -v test_tk
>
>(That way the unittest framework will see the -v option)

Aha, I didn't understand that.  Thank you.

>Note that there are lines like
>
># possible namespace for /home/lac/src/accounting/test
>
>in your python3 -v output that indicate that there may still be too much in 
>your PYTHONPATH.

It's now "" for this test.

I get 3 failures, as follows (I trimmed the rest of the ok ones).

= CPython 3.4.3+ (default, Jul 28 2015, 13:17:50) [GCC 4.9.3]
==   Linux-3.16.0-4-amd64-x86_64-with-debian-stretch-sid little-endian
==   hash algorithm: siphash24 64bit
==   /tmp/test_python_7974
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)

test_default (tkinter.test.test_tkinter.test_variables.TestBooleanVar) ... FAIL
test_get (tkinter.test.test_tkinter.test_variables.TestBooleanVar) ... FAIL
test_set (tkinter.test.test_tkinter.test_variables.TestBooleanVar) ... FAIL

======================================================================
FAIL: test_default (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_variables.py", line 163, in test_default
      self.assertIs(v.get(), False)
      AssertionError: 0 is not False

======================================================================
FAIL: test_get (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_variables.py", line 167, in test_get
      self.assertIs(v.get(), True)
      AssertionError: 1 is not True

======================================================================
FAIL: test_set (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_variables.py", line 186, in test_set
      self.assertEqual(self.root.globalgetvar("name"), true)
      AssertionError: 42 != 1

----------------------------------------------------------------------
Ran 660 tests in 3.901s

FAILED (failures=3)
1 test failed:
    test_tk
    

[toc] | [prev] | [next] | [standalone]

#95138

Laura Creighton wrote:

> In a message of Fri, 07 Aug 2015 17:34:54 +0200, Peter Otten writes:
>>Run
>>
>>$ python3 -m test -ugui -v test_tk
>>
>>(That way the unittest framework will see the -v option)
> 
> Aha, I didn't understand that.  Thank you.
> 
>>Note that there are lines like
>>
>># possible namespace for /home/lac/src/accounting/test
>>
>>in your python3 -v output that indicate that there may still be too much
>>in your PYTHONPATH.
> 
> It's now "" for this test.
> 
> I get 3 failures, as follows (I trimmed the rest of the ok ones).
> 
> = CPython 3.4.3+ (default, Jul 28 2015, 13:17:50) [GCC 4.9.3]
> ==   Linux-3.16.0-4-amd64-x86_64-with-debian-stretch-sid little-endian
> ==   hash algorithm: siphash24 64bit
> ==   /tmp/test_python_7974
> Testing with flags: sys.flags(debug=0, inspect=0, interactive=0,
> optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0,
> ignore_environment=0, verbose=0, bytes_warning=0, quiet=0,
> hash_randomization=1, isolated=0)
> 
> test_default (tkinter.test.test_tkinter.test_variables.TestBooleanVar) ...
> FAIL test_get (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
> ... FAIL test_set
> (tkinter.test.test_tkinter.test_variables.TestBooleanVar) ... FAIL
> 
> ======================================================================
> FAIL: test_default
> (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_variables.py",
>   line 163, in test_default
>       self.assertIs(v.get(), False)
>       AssertionError: 0 is not False
> 
> ======================================================================
> FAIL: test_get (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_variables.py",
>   line 167, in test_get
>       self.assertIs(v.get(), True)
>       AssertionError: 1 is not True
> 
> ======================================================================
> FAIL: test_set (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_variables.py",
>   line 186, in test_set
>       self.assertEqual(self.root.globalgetvar("name"), true)
>       AssertionError: 42 != 1
> 
> ----------------------------------------------------------------------
> Ran 660 tests in 3.901s
> 
> FAILED (failures=3)
> 1 test failed:
>     test_tk

test_set() was introduced in a bugfix

http://bugs.python.org/issue15133
https://hg.python.org/cpython/rev/117f45749359/

that I don't have on my machine (up-to-date Linux Mint 17).  When I download

https://hg.python.org/cpython/file/117f45749359/Lib/tkinter/test/test_tkinter/test_variables.py

and manually run that file I get errors similar to those you are reporting:

$ python3 test_variables.py | grep -v ok$
test_default (__main__.TestBooleanVar) ... FAIL
test_get (__main__.TestBooleanVar) ... FAIL
test_invalid_value_domain (__main__.TestBooleanVar) ... FAIL
test_set (__main__.TestBooleanVar) ... FAIL

======================================================================
FAIL: test_default (__main__.TestBooleanVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_variables.py", line 163, in test_default
    self.assertIs(v.get(), False)
AssertionError: 0 is not False

======================================================================
FAIL: test_get (__main__.TestBooleanVar)
Traceback (most recent call last):
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_variables.py", line 167, in test_get
    self.assertIs(v.get(), True)
AssertionError: 1 is not True

======================================================================
  File "test_variables.py", line 212, in <module>
FAIL: test_invalid_value_domain (__main__.TestBooleanVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_variables.py", line 196, in test_invalid_value_domain
    v.set("value")
AssertionError: TclError not raised

======================================================================
FAIL: test_set (__main__.TestBooleanVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_variables.py", line 184, in test_set
    self.assertEqual(self.root.globalgetvar("name"), false)
AssertionError: '0' != 0

----------------------------------------------------------------------
Ran 22 tests in 0.098s

FAILED (failures=4)
    run_unittest(*tests_gui)
  File "/usr/lib/python3.4/test/support/__init__.py", line 1719, in 
run_unittest
    _run_suite(suite)
  File "/usr/lib/python3.4/test/support/__init__.py", line 1694, in 
_run_suite
    raise TestFailed(err)
test.support.TestFailed: multiple errors occurred
$ 

This leads me to believe that your tests and the tkinter shared library may 
not match. Does

$ python3 -c 'import _tkinter; print(_tkinter)'
<module '_tkinter' from '/usr/lib/python3.4/lib-
dynload/_tkinter.cpython-34m-x86_64-linux-gnu.so'>

show something suspicious?

[toc] | [prev] | [next] | [standalone]

#95140

In a message of Fri, 07 Aug 2015 21:13:02 +0200, Peter Otten writes:
>test_set() was introduced in a bugfix
>
>http://bugs.python.org/issue15133
>https://hg.python.org/cpython/rev/117f45749359/
>
>that I don't have on my machine (up-to-date Linux Mint 17).  When I download
>
>https://hg.python.org/cpython/file/117f45749359/Lib/tkinter/test/test_tkinter/test_variables.py
>
>and manually run that file I get errors similar to those you are reporting:
>
>$ python3 test_variables.py | grep -v ok$
>test_default (__main__.TestBooleanVar) ... FAIL
>test_get (__main__.TestBooleanVar) ... FAIL
>test_invalid_value_domain (__main__.TestBooleanVar) ... FAIL
>test_set (__main__.TestBooleanVar) ... FAIL

>This leads me to believe that your tests and the tkinter shared library may 
>not match. Does
>
>$ python3 -c 'import _tkinter; print(_tkinter)'
><module '_tkinter' from '/usr/lib/python3.4/lib-
>dynload/_tkinter.cpython-34m-x86_64-linux-gnu.so'>
>
>show something suspicious?

lac@smartwheels:~$ python3 -c 'import _tkinter; print(_tkinter)'
<module '_tkinter' from '/usr/lib/python3.4/lib-dynload/_tkinter.cpython-34m-x86_64-linux-gnu.so'>

Laura

[toc] | [prev] | [next] | [standalone]

#95148

On 8/7/2015 1:01 PM, Laura Creighton wrote:
> In a message of Fri, 07 Aug 2015 17:34:54 +0200, Peter Otten writes:
>> Run
>>
>> $ python3 -m test -ugui -v test_tk
>>
>> (That way the unittest framework will see the -v option)
>
> Aha, I didn't understand that.  Thank you.
>
>> Note that there are lines like
>>
>> # possible namespace for /home/lac/src/accounting/test
>>
>> in your python3 -v output that indicate that there may still be too much in
>> your PYTHONPATH.
>
> It's now "" for this test.
>
> I get 3 failures, as follows (I trimmed the rest of the ok ones).
>
> = CPython 3.4.3+ (default, Jul 28 2015, 13:17:50) [GCC 4.9.3]
> ==   Linux-3.16.0-4-amd64-x86_64-with-debian-stretch-sid little-endian
> ==   hash algorithm: siphash24 64bit
> ==   /tmp/test_python_7974
> Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
>
> test_default (tkinter.test.test_tkinter.test_variables.TestBooleanVar) ... FAIL
> test_get (tkinter.test.test_tkinter.test_variables.TestBooleanVar) ... FAIL
> test_set (tkinter.test.test_tkinter.test_variables.TestBooleanVar) ... FAIL
>
> ======================================================================
> FAIL: test_default (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_variables.py", line 163, in test_default
>        self.assertIs(v.get(), False)
>        AssertionError: 0 is not False
>
> ======================================================================
> FAIL: test_get (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_variables.py", line 167, in test_get
>        self.assertIs(v.get(), True)
>        AssertionError: 1 is not True
>
> ======================================================================
> FAIL: test_set (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_variables.py", line 186, in test_set
>        self.assertEqual(self.root.globalgetvar("name"), true)
>        AssertionError: 42 != 1
>
> ----------------------------------------------------------------------
> Ran 660 tests in 3.901s
>
> FAILED (failures=3)
> 1 test failed:
>      test_tk

The only thing I found on the tracker is
https://bugs.python.org/issue20067
I suspect that this is more an issue with the tests, which are somewhat 
new, than tkinter itself.  In any case, my personal concern is whether 
adding ttk to Idle creates a problem, and those two tests passes.  Thank 
you for trying.



-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#95151

On 8/7/2015 1:01 PM, Laura Creighton wrote:

> ======================================================================
> FAIL: test_get (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_variables.py", line 167, in test_get
>        self.assertIs(v.get(), True)
>        AssertionError: 1 is not True

https://bugs.python.org/issue15601
was about this very test failure.  The failure only occurred with tk 
8.4.  What tk version do you have?  (Easily found, for instance, in Idle 
-> Help -> About Idle. (python3 -m idlelib should start idle).

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web