I have a module that has a tests/ directory which contains a C
extension that's only used by test cases. I don't want to install it.
I'm building it as a setuptools.Extension() added to setup() using the
ext_modules argument. The test directory is not added to setup's
pac
email is long enough.
The full set of features and tutorials are in https://byexamples.github.io
(by the way, the examples in that web page are the tests of byexample!)
Repo: https://github.com/byexamples/byexample (feel free to submit any
issue or question)
You can install it with pip:
pi
directories. But when he ran the test
suite, 4 tests failed with a numpy import error that Jeremy Kloth says
is due to a mix.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
On 2020-09-14 02:18, Terry Reedy wrote:
User Tushar Sadhwani and I both have Win 10 with 3.8.5 installed. When
he runs
...> py -3.8 -m turtledemo.colormixer
and moves the sliders a reasonable amount, he repeatably gets
Fatal Python error: Cannot recover from stack overflow.
...
https://bugs.pyth
On 2020-09-14 7:07 AM, Frank Millman wrote:
On 2020-09-14 3:18 AM, Terry Reedy wrote:
User Tushar Sadhwani and I both have Win 10 with 3.8.5 installed.
When he runs
...> py -3.8 -m turtledemo.colormixer
and moves the sliders a reasonable amount, he repeatably gets
Fatal Python error: Cannot re
On 2020-09-14 3:18 AM, Terry Reedy wrote:
User Tushar Sadhwani and I both have Win 10 with 3.8.5 installed. When
he runs
...> py -3.8 -m turtledemo.colormixer
and moves the sliders a reasonable amount, he repeatably gets
Fatal Python error: Cannot recover from stack overflow.
...
https://bugs.p
User Tushar Sadhwani and I both have Win 10 with 3.8.5 installed. When
he runs
...> py -3.8 -m turtledemo.colormixer
and moves the sliders a reasonable amount, he repeatably gets
Fatal Python error: Cannot recover from stack overflow.
...
https://bugs.python.org/issue41758
I have no problem, re
On 2/18/2019 3:35 PM, Marcin G wrote:
Hmm. From looking at your full log (THANK YOU for posting that, btw -
so many people don't), it looks like an issue with certificate
checking. Might be a bug in the test itself. Does the same thing
happen with a more recent Python build? It could be a weirdne
On Tue, Feb 19, 2019 at 7:55 AM Grant Edwards wrote:
>
> On 2019-02-18, Chris Angelico wrote:
>
> > Hmm. From looking at your full log (THANK YOU for posting that, btw -
> > so many people don't), it looks like an issue with certificate
> > checking. Might be a bug in the test itself. Does the sa
On 2019-02-18, Chris Angelico wrote:
> Hmm. From looking at your full log (THANK YOU for posting that, btw -
> so many people don't), it looks like an issue with certificate
> checking. Might be a bug in the test itself. Does the same thing
> happen with a more recent Python build? It could be a
On Tue, Feb 19, 2019 at 7:36 AM Marcin G wrote:
>
> Hmm. From looking at your full log (THANK YOU for posting that, btw -
> so many people don't), it looks like an issue with certificate
> checking. Might be a bug in the test itself. Does the same thing
> happen with a more recent Python build? It
Hmm. From looking at your full log (THANK YOU for posting that, btw -
so many people don't), it looks like an issue with certificate
checking. Might be a bug in the test itself. Does the same thing
happen with a more recent Python build? It could be a weirdness with
specific versions of OpenSSL.
H
failure in a
narrow part of SSL handling, one that most code won't hit.
> All I want is to have an installation that is not broken. If the above
> failures are false positives, I can gladly ignore them; however, since
> (unsupressed) warnings and failing tests are usually a sign o
en. If the above failures
are false positives, I can gladly ignore them; however, since (unsupressed)
warnings and failing tests are usually a sign of serious problems, I wonder
what should I do get a functional installation?
I do believe I should have all dependencies installed. First, I
On Wed, Jul 18, 2018 at 7:59 PM, MRAB wrote:
> On 2018-07-18 22:40, Larry Martell wrote:
>>
>> On Tue, Jul 17, 2018 at 11:43 AM, Neil Cerutti wrote:
>>>
>>> On 2018-07-16, Larry Martell wrote:
I had some code that did this:
meas_regex = '_M\d+_'
meas_re = re.compile(meas
On 2018-07-18 22:40, Larry Martell wrote:
On Tue, Jul 17, 2018 at 11:43 AM, Neil Cerutti wrote:
On 2018-07-16, Larry Martell wrote:
I had some code that did this:
meas_regex = '_M\d+_'
meas_re = re.compile(meas_regex)
if meas_re.search(filename):
stuff1()
else:
stuff2()
I then had
On 18Jul2018 17:40, Larry Martell wrote:
On Tue, Jul 17, 2018 at 11:43 AM, Neil Cerutti wrote:
On 2018-07-16, Larry Martell wrote:
I had some code that did this:
meas_regex = '_M\d+_'
meas_re = re.compile(meas_regex)
if meas_re.search(filename):
stuff1()
else:
stuff2()
I then had
On Tue, Jul 17, 2018 at 11:43 AM, Neil Cerutti wrote:
> On 2018-07-16, Larry Martell wrote:
>> I had some code that did this:
>>
>> meas_regex = '_M\d+_'
>> meas_re = re.compile(meas_regex)
>>
>> if meas_re.search(filename):
>> stuff1()
>> else:
>> stuff2()
>>
>> I then had to change it t
On 2018-07-16, Larry Martell wrote:
> I had some code that did this:
>
> meas_regex = '_M\d+_'
> meas_re = re.compile(meas_regex)
>
> if meas_re.search(filename):
> stuff1()
> else:
> stuff2()
>
> I then had to change it to this:
>
> if meas_re.search(filename):
> if 'MeasDisplay' in f
x27;s of files, and it runs
> often, so it needs to run very fast. Needless to say, my change has
> made it take 2x as long.
That is *not* self-evident. Usually stuffX() would take much longer than the
initial tests.
So the first step would be to verify that
if meas_re.search(filen
On Mon, Jul 16, 2018 at 6:01 PM, Gilmeh Serda
wrote:
> On Mon, 16 Jul 2018 14:17:57 -0400, Larry Martell wrote:
>
>> This code needs to process many tens of 1000's of files, and it runs
>> often, so it needs to run very fast. Needless to say, my change has made
>> it take 2x as long. Can anyone se
Op 2018-07-16, Larry Martell schreef :
> I had some code that did this:
>
> meas_regex = '_M\d+_'
> meas_re = re.compile(meas_regex)
>
> if meas_re.search(filename):
> stuff1()
> else:
> stuff2()
>
> I then had to change it to this:
>
> if meas_re.search(filename):
> if 'MeasDisplay' in
I had some code that did this:
meas_regex = '_M\d+_'
meas_re = re.compile(meas_regex)
if meas_re.search(filename):
stuff1()
else:
stuff2()
I then had to change it to this:
if meas_re.search(filename):
if 'MeasDisplay' in filename:
stuff1a()
else:
stuff1()
else:
On Thu, 5 Oct 2017 02:23 am, Skip Montanaro wrote:
[...]
>> Ew. Sounds like a badly designed package.
>
> I will refer interested readers to the nose documentation:
>
>
https://nose.readthedocs.io/en/latest/doc_tests/test_init_plugin/init_plugin.html
>
> where the author writes, "Many applicati
that we're discussing Python, in a Python
> group, what are senses are relevant?
I have to test an entire application, which involves at least one
package, unit tests and doctests. I suppose I should have used the
word "application." My apology.
>
>> You probably have sp
> You probably have specific unit
> tests, maybe some doctests scattered around in doc strings. Further,
> suppose that package requires you call an initialize function of some
> sort. Where does that go?
Ew. Sounds like a badly designed package. Importing the package should
initialise
On Oct 4, 2017, at 6:07 AM, Skip Montanaro wrote:
>
> Suppose you want to test a package (in the general sense of the word,
> not necessarily a Python package). You probably have specific unit
> tests, maybe some doctests scattered around in doc strings. Further,
> suppose that p
> I've not had this problem myself, but py.test has the idea of "autouse
> fixtures" which would work for this situation. Define your setup call
> in a function, declare it with the pytest.fixture decorator with
> autouse=True, and it'll be run before every test. The declaration goes
> in a conftes
ourself (although I believe it
does discover unittest and doctest tests, so you don't need to change
all your tests over).
There's an example of an autouse fixture in pip's test suite, although
it's massively more complex than what you're describing, so don't be
put
Suppose you want to test a package (in the general sense of the word,
not necessarily a Python package). You probably have specific unit
tests, maybe some doctests scattered around in doc strings. Further,
suppose that package requires you call an initialize function of some
sort. Where does that
;s failing to find the lib package. Since you removed
>> the "lib" directory from sys.path, does its parent directory exist in
>> sys.path?
>
>
> The path is not in the modules path or in sys.path. Hence the append. I
> thought I could add the local "lib"
sys.path, does its parent directory exist in
sys.path?
The path is not in the modules path or in sys.path. Hence the append. I
thought I could add the local "lib" path via "." or "lib.", but it seems
not.
import lib.character fails in the tests/ directory.
Relative
est session starts
> =
> platform linux2 -- Python 2.6.6 -- pytest-2.3.5
> collected 0 items / 3 errors
>
> === ERRORS
> ====
> __
= test session starts
=
platform linux2 -- Python 2.6.6 -- pytest-2.3.5
collected 0 items / 3 errors
=== ERRORS
_______
issue I have created for the bug :-
>
> https://github.com/gdabah/distorm/issues/118
...though this time it does:
diff --git a/examples/tests/test_distorm3.py
b/examples/tests/test_distorm3.py
index aec1d63..babaacc 100644
--- a/examples/tests/test_distorm3.py
+++ b/examples/tests/test_distorm3.p
I am trying to get distorm3's unittests working but to no avail.
I am not really a Python programmer so was hoping someone in the know maybe
able to fix this for me.
Here's a GitHub issue I have created for the bug :-
https://github.com/gdabah/distorm/issues/118
--
Aaron Gray
Independent
Howdy all,
I am pleased to announce the first release of the testing library I've
named Gajja https://pypi.python.org/pypi/gajja/>.
Its purpose is to allow fine-grained control of not only file content,
but metadata and system access behaviour, for in-memory test doubles.
Currently it provides c
hers!) to detect whether
> > or not both code paths are covered in the test suite.
>
> Coverage.py has, for many releases now, had good measurement of branch
> coverage by your tests. Enable it with the ‘--branch’ option to ‘run’
>
Oh, cool. I'm actually using coverage indi
ion here is that this construct is useful to use when the
> two code paths are very different operationally from each other, one is an
> unusual path that you are not >100% sure is well-covered in your test
> suite, but that your first instinct should be to avoid such code.
>
&
e test suite.
Coverage.py has, for many releases now, had good measurement of branch
coverage by your tests. Enable it with the ‘--branch’ option to ‘run’
https://coverage.readthedocs.org/en/latest/branch.html>.
--
\ “They who can give up essential liberty to obtain a little |
`\t
On Thu, Oct 15, 2015 at 12:49 PM, Jason Swails wrote:
> My question is, what do you think of the "else: pass" statement? It is a
> complete no-op and is syntactically equivalent to the same code with those
> lines removed. Up until earlier today, I would look at that and cringe (I
> still do, a
Hi everyone,
I'd like to get some opinions about some coding constructs that may seem at
first glance to serve no purpose, but does have *some* non-negligible
purpose, and I think I've come to the right place :).
The construct is this:
def my_function(arg1, arg2, filename=None):
""" Some fun
On Friday, August 28, 2015 at 11:56:53 AM UTC+5:30, Steven D'Aprano wrote:
> Completely off-topic. Stop reading now if you only want to read things about
> Python.
>
>
> On Fri, 28 Aug 2015 09:46 am, Ben Finney wrote:
>
> > \ “Of course, everybody says they're for peace. Hitler was for |
People are naturally competitive. People naturally don't like to hear the
word know. People love to get what they want. Combine all of these things
together and you have all of the elements necessary to eventually create
another conflict. Just because it doesn't happen immediately doesn't mean
it's
On 8/28/2015 4:52 AM, Christian Gollwitzer wrote:
Here is a small patch which improves the error message a lot:
diff -ru Python-3.4.3/Modules/_tkinter.c
Python-3.4.3-patched/Modules/_tkinter.c
--- Python-3.4.3/Modules/_tkinter.c2015-02-25 12:27:45.0 +0100
+++ Python-3.4.3-patched/Mod
On 08/28/2015 01:27 AM, Ben Finney wrote:
> --
> \ “Capitalism is the astounding belief that the most wickedest of |
> `\men will do the most wickedest of things for the greatest good |
> _o__) of everyone.” —John Maynard Keynes |
Now that is an interestin
On Sat, Aug 29, 2015 at 12:02 AM, Steven D'Aprano wrote:
> On Fri, 28 Aug 2015 04:35 pm, Nick Sarbicki wrote:
>
>> Well who would we fight if we were all friends with each other?
>
> According to the Nac Mac Feegle, there's always *someone* to fight. If not
> an enemy, there's always your friends,
On Fri, 28 Aug 2015 04:35 pm, Nick Sarbicki wrote:
> Well who would we fight if we were all friends with each other?
According to the Nac Mac Feegle, there's always *someone* to fight. If not
an enemy, there's always your friends, family, inanimate objects, and if
all else fails, yourself.
"Criv
On 08/28/2015 11:24 AM, Marko Rauhamaa wrote:
Would you rather be an powerful, armed war hero admired and feared by
your nation or a foresaken unemployed drunkard who rots in jail?
Marko
Time to quote the most famous general in the galaxy:
“Ohhh. Great warrior.Wars not make one great.” ;)
J
Ben Finney :
> Steven D'Aprano writes:
>> Many people over the ages have thought that if only war was more
>> terrible, we would stop making it. Alas, that appears to be false: no
>> matter how terrible war is, there is always someone who thinks that
>> it is better than peace.
>
> Those who bene
Am 28.08.15 um 08:46 schrieb Terry Reedy:
On 8/28/2015 1:56 AM, Christian Gollwitzer wrote:
Am 27.08.15 um 20:32 schrieb Terry Reedy:
On 8/27/2015 4:56 AM, Petr Viktorin wrote:
1321, in _configure
self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
_tkinter.TclError: expected inte
Steven D'Aprano writes:
> With the greatest of respect to Chomsky, I think he is simply wrong
> about Hitler. Hitler actually believed that war was good for the
> national character, and indeed good for the soul, and that long
> periods of peace would enfeeble a nation and make it decadent and
>
On Fri, 2015-08-28 at 06:35 +, Nick Sarbicki wrote:
> Well who would we fight if we were all friends with each other?
That's what Paintball is for.
/Martin S
--
This address is for technical mail lists only.For all other matters, please use
my main addressat the .org domain.
--
https://mai
Well who would we fight if we were all friends with each other?
On Fri, 28 Aug 2015 07:31 Steven D'Aprano wrote:
> Completely off-topic. Stop reading now if you only want to read things
> about
> Python.
>
>
> On Fri, 28 Aug 2015 09:46 am, Ben Finney wrote:
>
> > \“Of course, everybody s
On 8/28/2015 1:56 AM, Christian Gollwitzer wrote:
Am 27.08.15 um 20:32 schrieb Terry Reedy:
On 8/27/2015 4:56 AM, Petr Viktorin wrote:
1321, in _configure
self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
_tkinter.TclError: expected integer but got ""
Very puzzling. The only o
Completely off-topic. Stop reading now if you only want to read things about
Python.
On Fri, 28 Aug 2015 09:46 am, Ben Finney wrote:
> \ “Of course, everybody says they're for peace. Hitler was for |
> `\ peace. Everybody is for peace. The question is: what kind of |
> _o__)
Am 27.08.15 um 20:32 schrieb Terry Reedy:
On 8/27/2015 4:56 AM, Petr Viktorin wrote:
1321, in _configure
self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
_tkinter.TclError: expected integer but got ""
Very puzzling. The only obviously even possibly relevant change from 3.4
to
rambius writes:
> Hello,
>
> петък, 21 август 2015 г., 21:43:19 UTC-4, Ben Finney написа:
> > The ‘testscenarios’ library is one way to have a set of scenarios
> > applied at run-time to produce tests across all combinations
> > https://pypi.python.org/pypi/testsce
is 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.
On Fedora 21, the tests pass (Python 3.4.1 and latest dev version).
On Fedora 23, I see:
$ python3 -V
Python 3.4.3
$ python3 -m test
pplied at run-time to produce tests across all combinations
> https://pypi.python.org/pypi/testscenarios/>.
testscenarios worked for me. Thank you for your recommendation.
Regards
Ivan
--
https://mail.python.org/mailman/listinfo/python-list
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.
On Fedora 21, the tests pass (Python 3.4.1 and latest dev version).
On Fedora 23, I
rambius writes:
> I am running one and the same unit tests that test some web
> application. I would like to execute them against different servers
> that may host different instances of the application.
Those aren't unit tests, then. A unit test, by definition, tests a smal
In a message of Fri, 21 Aug 2015 08:17:32 -0700, rambius writes:
>Although I developed these tests as unit tests they are more of integration
>tests. Is there an integration testing framework that supports a more
>convenient passing of test parameters / data?
>
>Thank you in a
Hello,
I am running one and the same unit tests that test some web application. I
would like to execute them against different servers that may host different
instances of the application.
So far I have something like
#!/usr/bin/env python
import unittest
server = ""
user = &
On 8/13/2015 1:11 AM, Laura Creighton wrote:
In a message of Wed, 12 Aug 2015 21:49:24 -0400, Terry Reedy writes:
https://bugs.python.org/issue15601
Could you add a note to the issue then?
Done, though I wonder if it isn't a separate issue.
I was not sure. The people currently nosy will
In a message of Wed, 12 Aug 2015 21:49:24 -0400, Terry Reedy writes:
>On 8/8/2015 2:40 AM, Laura Creighton wrote:
>> In a message of Fri, 07 Aug 2015 21:25:21 -0400, Terry Reedy writes:
>
> >> https://bugs.python.org/issue15601
>>> was about this very test failure. The failure only occurred with t
On 8/8/2015 2:40 AM, Laura Creighton wrote:
In a message of Fri, 07 Aug 2015 21:25:21 -0400, Terry Reedy writes:
>> 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
-
y test_idle
[1/3] test_tk
[2/3] test_ttk_guionly
[3/3] test_idle
All 3 tests OK.
--
https://mail.python.org/mailman/listinfo/python-list
Tried this on a different debian unstable system.
lac@fido:~$ lsb_release -a
No LSB modules are available.
Distributor ID:Debian
Description: Debian GNU/Linux unstable (sid)
Release: unstable
Codename: sid
lac@fido:~$
Same 3 errors. (So it is not just me.)
Laura
-
Ok, I moved to debian unstable (stretch/sid)
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-amd
Laura Creighton wrote:
>>This leads me to believe that your tests and the tkinter shared library
>>may not match. Does
>>
>>$ python3 -c 'import _tkinter; print(_tkinter)'
>>>dynload/_tkinter.cpython-34m-x86_64-linux-gnu.so'>
>>
>&g
In a message of Fri, 07 Aug 2015 21:25:21 -0400, Terry Reedy writes:
>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 Re
I forgot to mention that I am running OpenBox as a window manager, so
if this is a problem with ubuntu Unity, then so far we don't seem to
have any Unity users running these tests.
Laura
--
https://mail.python.org/mailman/listinfo/python-list
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):
tk test failed once but passed on retry. Three obscure tk tests failed
on another system. On the same system, though, the ttk and (incomplete)
idle tests passed. Conclusion: I should not worry about ttk on Linux.
Thank you all for helping.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
er/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
On 8/6/2015 10:18 PM, Ben Finney wrote:
Terry Reedy writes:
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.
Could you verify exactly what is the command to
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
--
https://mail.
x86_64 x86_64 GNU/Linux
NOTE: This is a 32-bit userspace system, just with a 64-bit kernel
Python 3.6.0a0 (default:e56893df8e76, Aug 7 2015, 16:36:30)
[GCC 4.8.4] on linux
[1/3] test_tk
[2/3] test_ttk_guionly
[3/3] test_idle
All 3 tests OK.
Python 3.5.0b4+ (3.5:b9a0165a3de8, Aug 7 2015, 16:21:51)
>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 _tkint
===
> 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
y", 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
--
https://mail.python.org/mailman/listinfo/python-list
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 -
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; 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'
gt;> 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
h
>>
>> $ 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
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]
On Fri, Aug 7, 2015 at 7:15 PM, Peter Otten <__pete...@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
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
tk_guionly
test test_ttk_guionly failed -- Traceback (most recent call last):
File "/usr/local/lib/python3.5/tkinter/test/test_ttk/test_widgets.py",
line 947, in test_tab_identifiers
self.fail("Tab with text 'a' not found")
AssertionError: Tab with text '
nvironment 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.
>
>
st_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
On 07/08/2015 04:46, Grant Edwards wrote:
On 2015-08-07, Grant Edwards wrote:
On 2015-08-07, 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
On Fri, Aug 7, 2015 at 12:20 PM, Chris Angelico wrote:
> rosuav@sikorsky:~$ uname -a
> Linux sikorsky 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1
> (2015-04-24) x86_64 GNU/Linux
>
> The 3.4 is my system Python (Debian Wheezy)
Oh, and for what it's worth, I'm running Xfce here.
ChrisA
--
h
only 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'
On 2015-08-07, 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
re a couple of beeps.
rosuav@sikorsky:~$ python3 -V
Python 3.6.0a0
rosuav@sikorsky:~$ 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.
rosuav@sikorsky:~$ python3.5 -V
Python 3.5.0b1+
rosuav@sikorsky:~$ python3.5 -m test -ugui t
Terry Reedy writes:
> 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.
Could you verify exactly what is the command to run? I'd hate for a
bunch of commands
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 w
1 - 100 of 538 matches
Mail list logo
