Jeremy Hylton wrote:
Make sure App.Product is imported first, so that test.py can work.
This change does not affect the old utilities/testrunner.py.
This checkin message caused me to notice 'test.py' for the first time. Can you point me to any discussion/docs on it? When did/will it replace testrunner? Shouldn't the python2.2 in the "#!" line be python2.3? Sorry for the flood of questions, but this and the recent doctest-style tests being checked in have made me wonder if I've been missing a significant shift in testing tech. Cheers, Evan @ 4-am
On Wed, 2004-03-10 at 13:39, Evan Simpson wrote:
Jeremy Hylton wrote:
Make sure App.Product is imported first, so that test.py can work.
This change does not affect the old utilities/testrunner.py.
This checkin message caused me to notice 'test.py' for the first time. Can you point me to any discussion/docs on it? When did/will it replace testrunner? Shouldn't the python2.2 in the "#!" line be python2.3?
There is minimal documentation in the test.py docstring. All the command line arguments are described. It's basic strategy for finding tests isn't documented, but I don't think it's too different from testrunner.py. test.py obsoleted testrunner.py as of Zope 2.7. test.py was being used by ZODB3 and Zope3 for a while before it was added to Zope 2.7. I'm not sure which #! line you mean, but I think you're right to say it should be python 2.3. All the software on the head requires python 2.3.
Sorry for the flood of questions, but this and the recent doctest-style tests being checked in have made me wonder if I've been missing a significant shift in testing tech.
test.py has all sorts of bells and whistle for running tests. It's a lot more flexible than testrunner.py. Jeremy
Hi! Jeremy Hylton wrote:
test.py obsoleted testrunner.py as of Zope 2.7. test.py was being used by ZODB3 and Zope3 for a while before it was added to Zope 2.7.
Why does setup.py still install testrunner.py, not test.py? And BTW: Could *all* files necessary to run tests be installed?
I'm not sure which #! line you mean, but I think you're right to say it should be python 2.3. All the software on the head requires python 2.3.
Some grep results from Zope HEAD: setup.py: #! /usr/bin/env python test.py: #! /usr/bin/env python2.2 utilities\check_catalog.py: #!/usr/bin/env python2.1 utilities\requestprofiler.py: #!/usr/bin/env python utilities\compilezpy.py: #!/usr/bin/env python utilities\zpasswd.py: #!/usr/bin/env python utilities\testrunner.py: #! /usr/bin/env python2.2 utilities\ZODBTools\space.py: #! /usr/bin/env python And many tests, some of them still with python1.5, e.g. lib\python\TAL\tests\run.py: #! /usr/bin/env python1.5 Could we have a policy for this? I guess '#! /usr/bin/env python' is easier to keep up to date ... Cheers, Yuppie
yuppie wrote:
Jeremy Hylton wrote:
test.py obsoleted testrunner.py as of Zope 2.7. test.py was being used by ZODB3 and Zope3 for a while before it was added to Zope 2.7.
Why does setup.py still install testrunner.py, not test.py?
And BTW: Could *all* files necessary to run tests be installed?
I'm not sure which #! line you mean, but I think you're right to say it should be python 2.3. All the software on the head requires python 2.3.
Some grep results from Zope HEAD:
setup.py: #! /usr/bin/env python test.py: #! /usr/bin/env python2.2 utilities\check_catalog.py: #!/usr/bin/env python2.1 utilities\requestprofiler.py: #!/usr/bin/env python utilities\compilezpy.py: #!/usr/bin/env python utilities\zpasswd.py: #!/usr/bin/env python utilities\testrunner.py: #! /usr/bin/env python2.2 utilities\ZODBTools\space.py: #! /usr/bin/env python
And many tests, some of them still with python1.5, e.g.
lib\python\TAL\tests\run.py: #! /usr/bin/env python1.5
Could we have a policy for this? I guess '#! /usr/bin/env python' is easier to keep up to date ...
-1. We should specify the required minimum version everywhere. The 'env' hack is evil because it pretends to be flexible, while still leaving you vulnerable to strangeness. BTW, the space after the '!' should go, too; it is not guaranteed to be honored by all shells. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Hi! Tres Seaver wrote:
yuppie wrote:
Some grep results from Zope HEAD:
setup.py: #! /usr/bin/env python test.py: #! /usr/bin/env python2.2 utilities\check_catalog.py: #!/usr/bin/env python2.1 utilities\requestprofiler.py: #!/usr/bin/env python utilities\compilezpy.py: #!/usr/bin/env python utilities\zpasswd.py: #!/usr/bin/env python utilities\testrunner.py: #! /usr/bin/env python2.2 utilities\ZODBTools\space.py: #! /usr/bin/env python
And many tests, some of them still with python1.5, e.g.
lib\python\TAL\tests\run.py: #! /usr/bin/env python1.5
Could we have a policy for this? I guess '#! /usr/bin/env python' is easier to keep up to date ...
-1. We should specify the required minimum version everywhere.
I'm fine with that.
The 'env' hack is evil because it pretends to be flexible, while still leaving you vulnerable to strangeness.
Is there a better alternative than the 'env hack'? (I had to google to find out what you mean by 'env hack' and found <http://www.faqts.com/knowledge_base/view.phtml/aid/1406>, but nothing about better solutions.)
BTW, the space after the '!' should go, too; it is not guaranteed to be honored by all shells.
Good to know. So you propose to replace *all* the #! lines by #!/usr/bin/env python2.3 Right? Cheers, Yuppie
yuppie wrote:
So you propose to replace *all* the #! lines by
#!/usr/bin/env python2.3
#!/usr/bin/python2.3 distutils will munge it anyway, if it installs the scripts. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
On Thursday 11 March 2004 10:40 am, Tres Seaver wrote:
#!/usr/bin/python2.3
distutils will munge it anyway, if it installs the scripts.
That won't work for a lot of developers, I'll bet, who have python2.3 installed in /usr/local/bin. The "env hack" is more reasonable for developers; since distutils is going to munge the sh-bang line anyway, it's not an issue for real installations. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
Hi! Fred Drake wrote:
On Thursday 11 March 2004 10:40 am, Tres Seaver wrote:
#!/usr/bin/python2.3
distutils will munge it anyway, if it installs the scripts.
That won't work for a lot of developers, I'll bet, who have python2.3 installed in /usr/local/bin. The "env hack" is more reasonable for developers; since distutils is going to munge the sh-bang line anyway, it's not an issue for real installations.
I don't care much *how* this is resolved, but I'd like to have this consistent and up to date. If I always have to check if the python version is set correctly that line isn't helpful at all. If we can get any consensus on this question I'll volunteer to check in the changes. Cheers, Yuppie
On Friday 12 March 2004 05:40 am, yuppie wrote:
I don't care much *how* this is resolved, but I'd like to have this consistent and up to date. If I always have to check if the python version is set correctly that line isn't helpful at all.
Well, Tres appearantly hasn't had time to respond. I think the line should become: #!/usr/bin/env python2.3 This will then be modified on installation by distutils to point to the Python interpreter which was involved in the installation. I think this is the right thing for both developers working from CVS and site developers and administrators working with installed versions. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
This is a Zope Newbie here When I am trying to pick up files from a Windows directory structure (C:\tmp), the code seems to always return me the error BadRequest! This is saved as a code in the Extensions folder as getDirectoryFiles.py file = 'C:\tmp' def readFile(file=file): fd = open(file, 'r') lines=fd.readlines() fd.close() return lines Is there some problem with the first line : file = 'C:\tmp"?? I have tried all kinds of permutations! Also when iterating over the file objects using DTML <dtml-in expr="objectValues(['File','Folder'])"> <li><a href = "&dtml-absolute_url;"> <dtml-var title_or_id></a></li> </dtml-in> I get a listing of all the folders + files which have been created using the ZMI. Now I want Zope to pick up files and folders from C:\tmp and display all the contents as direct URL's!. Problem is the above code picks up only those files which are created explicitly by the ZMI (which are a part of Zopes' custom database and are not directly accessible!) thx Darshan
Darshan Preet Singh Manku wrote:
This is a Zope Newbie here
Then you should be using the zope@zope.org list, zope-dev@zope.org is for the development OF zope, not the development of applications WITH it.
When I am trying to pick up files from a Windows directory structure (C:\tmp), the code seems to always return me the error BadRequest!
Look at LocalFS or ExtFile... Exception type, value and traceback from the error_log object would be handy in any case...
This is saved as a code in the Extensions folder as getDirectoryFiles.py
file = 'C:\tmp' def readFile(file=file): fd = open(file, 'r') lines=fd.readlines() fd.close() return lines
Is there some problem with the first line : file = 'C:\tmp"?? I have tried all kinds of permutations!
well, does C:\tmp exists? Sounds like it might be a folder, which wouldn't work.
Also when iterating over the file objects using DTML
Might be best to stick to one problem per email...
<dtml-in expr="objectValues(['File','Folder'])"> <li><a href = "&dtml-absolute_url;"> <dtml-var title_or_id></a></li> </dtml-in>
I get a listing of all the folders + files which have been created using the ZMI.
Yes, what else would you expect?
Now I want Zope to pick up files and folders from C:\tmp and display all the contents as direct URL's!. Problem is the above code picks up only those files which are created explicitly by the ZMI (which are a part of Zopes' custom database and are not directly accessible!)
The LocalFS product is what you're after... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (8)
-
Chris Withers -
Darshan Preet Singh Manku -
Evan Simpson -
Fred Drake -
Jeremy Hylton -
Toby Dickenson -
Tres Seaver -
yuppie