File format for automatic and manual tests
This is an idea of a new PEP. I propose to create a portable file format which will list command line options to run Python scripts with dual purpose: 1. for automatic tests executing scripts from this file (and optionally checking their stdout against specified values). 2. for running the scripts in a Python debugger. The scripts may be either real command line applications written in Python or scripts created specifically for testing. Currently I use PyCharm to debug my command line application. PyCharm allows to define and store different command line options for Python scripts. This has two drawbacks: 1. It is not portable and this makes me not to submit the PyCharm configuration into my GitHub repo. 2. I can't (at least easily) use these command line profiles for automated testing. I propose to create the file format listing such test/debug cases based on options available in PyCharm, that is: - Python script path - command line parameters - environment variables - Python interpreter and interpreter options - working directory - tweaks of PYTHONPATH to include our source directory as necessary - redirect input from It would be nice to add "variables" (substituted with strings) to our file format. Automated tests should support iterations of command lines with different vars substituted. I hope a future version of PyCharm will support our file format.
On Wed, Aug 08, 2018 at 12:57:51AM +0300, Victor Porton wrote:
Feel free to create whatever file format you like. There are tens of thousands of them, one more won't hurt, and you certainly don't need to write a PEP first. But I see no reason why this has anything to do with the Python standard library. Can you explain why you want to distribute an experimental file format in the Python std lib? That means that the file format must be stable (you cannot make any future changes, due to backwards compatibility), and only available for Python 3.8 or higher. [...]
You can put anything you like in your GitHub repo, GitHub won't care whether it is portable or not. -- Steve
On 08/08/18 02:18, Steven D'Aprano wrote:
As I pointed out, I want this format to become common (standardized!) for different IDEs and other development environment.
The issue is in the file format itself, not in the libraries it may be processed by. I propose to make the PEP containing a description of the file format (to be developed). It is important for integration among different development environments. The PEP should be marked as "stable" when the format becomes stable.
On Wed, 8 Aug 2018 at 00:35, Victor Porton <porton@narod.ru> wrote:
This strikes me as *absolutely* something that should be promoted outside of the stdlib, as a 3rd party project, and once it's established as a commonly used and accepted standard, only then propose that the stdlib offer support for it (if that's even needed at that point). Trying to promote a standard by making it "official" and then encouraging tools to accept it "because it's the official standard" seems like it's doing things backwards, to me at least. Paul
a suggest : don't make it obligatory i think it might come as suggested settings as settings on different environments different. or we can specify only in modules like in setup.py the name of the file, then each user configures it's own (considering pip we can make use it false by default) in the case of using it in a script, we can add a special comment # -*- file settings : True -*- Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ Mauritius
On Tuesday, 7 August 2018 22:57:51 BST Victor Porton wrote:
At the moment I solve this problem with various solutions, depending on requirements. * use python unittest * add a test target to a makefile. * write a bash script to run the tests and diff output if required * on windows do the same with CMD scripts * use python to run python in a subprocess that run the tests. Given all these ways to solve the problem what extra are you looking for? Barry
Hi Victor Thank you for your contribution, regarding standards for Python tools. Here is my two cents worth. You wrote:
We need a standard to make PyCharm and others to conform to it.
Things don't quite work that way, in the Python community. True, we have a Benevolent Dictator For Life (BDFL), but that's more an expression of respect for Guido, than a position of power. And anyway, he's on well-deserved vacation. For what you're suggesting, it's more that standards emerge through community use, and then are adopted as a PEP Python standard. Wherever possible, start first with an 'ad hoc' standard. You say your proposal enhances PyCharm. So ask PyCharm and its users set something up. As a first step, solve your own personal problem, and put it up somewhere where others can pick it up. Prove that the idea is good by establishing a group of users, starting perhaps with yourself. -- Jonathan
On 07/08/18 22:57, Victor Porton wrote:
You are going about this the wrong way. If you want IDE-makers to use your putative file format, you are going to have to persuade them that it is useful. Demanding that they do something because you like it is not persuasive. (Personally I don't use IDEs, so you proposal is exactly no use to me. I don't think it's a suitable subject for a PEP.) -- Rhodri James *-* Kynesim Ltd
On Wed, Aug 08, 2018 at 12:57:51AM +0300, Victor Porton wrote:
Feel free to create whatever file format you like. There are tens of thousands of them, one more won't hurt, and you certainly don't need to write a PEP first. But I see no reason why this has anything to do with the Python standard library. Can you explain why you want to distribute an experimental file format in the Python std lib? That means that the file format must be stable (you cannot make any future changes, due to backwards compatibility), and only available for Python 3.8 or higher. [...]
You can put anything you like in your GitHub repo, GitHub won't care whether it is portable or not. -- Steve
On 08/08/18 02:18, Steven D'Aprano wrote:
As I pointed out, I want this format to become common (standardized!) for different IDEs and other development environment.
The issue is in the file format itself, not in the libraries it may be processed by. I propose to make the PEP containing a description of the file format (to be developed). It is important for integration among different development environments. The PEP should be marked as "stable" when the format becomes stable.
On Wed, 8 Aug 2018 at 00:35, Victor Porton <porton@narod.ru> wrote:
This strikes me as *absolutely* something that should be promoted outside of the stdlib, as a 3rd party project, and once it's established as a commonly used and accepted standard, only then propose that the stdlib offer support for it (if that's even needed at that point). Trying to promote a standard by making it "official" and then encouraging tools to accept it "because it's the official standard" seems like it's doing things backwards, to me at least. Paul
a suggest : don't make it obligatory i think it might come as suggested settings as settings on different environments different. or we can specify only in modules like in setup.py the name of the file, then each user configures it's own (considering pip we can make use it false by default) in the case of using it in a script, we can add a special comment # -*- file settings : True -*- Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ Mauritius
On Tuesday, 7 August 2018 22:57:51 BST Victor Porton wrote:
At the moment I solve this problem with various solutions, depending on requirements. * use python unittest * add a test target to a makefile. * write a bash script to run the tests and diff output if required * on windows do the same with CMD scripts * use python to run python in a subprocess that run the tests. Given all these ways to solve the problem what extra are you looking for? Barry
Hi Victor Thank you for your contribution, regarding standards for Python tools. Here is my two cents worth. You wrote:
We need a standard to make PyCharm and others to conform to it.
Things don't quite work that way, in the Python community. True, we have a Benevolent Dictator For Life (BDFL), but that's more an expression of respect for Guido, than a position of power. And anyway, he's on well-deserved vacation. For what you're suggesting, it's more that standards emerge through community use, and then are adopted as a PEP Python standard. Wherever possible, start first with an 'ad hoc' standard. You say your proposal enhances PyCharm. So ask PyCharm and its users set something up. As a first step, solve your own personal problem, and put it up somewhere where others can pick it up. Prove that the idea is good by establishing a group of users, starting perhaps with yourself. -- Jonathan
On 07/08/18 22:57, Victor Porton wrote:
You are going about this the wrong way. If you want IDE-makers to use your putative file format, you are going to have to persuade them that it is useful. Demanding that they do something because you like it is not persuasive. (Personally I don't use IDEs, so you proposal is exactly no use to me. I don't think it's a suitable subject for a PEP.) -- Rhodri James *-* Kynesim Ltd
participants (9)
-
Abdur-Rahmaan Janhangeer -
Barry -
Barry Scott
-
Jonathan Fine -
Nicholas Chammas -
Paul Moore -
Rhodri James -
Steven D'Aprano -
Victor Porton