[Python-Dev] A Testing language Construct that could also be a Distributed programming construct - How can this be done in Python
I am using Python as a test language and wondering how best to represent
what is shown below in TTCN-3
TTCN-3, a testing domain specific language has a construct that looks
like below Its trying to send a request and define 3 alternative
outcomes/events.
web_port.send("http://www.googe.com/";)
resonseTimer.start(300)
alt {
[] web_port.receive("something") {
responseTimer.stop;
setverdict(pass);
}
[] web_port.receive("somethingelse") {
responseTimer.stop;
setverdict(fail);
}
[] responseTimer.timeout {
setverdict(fail);
}
}
I am trying to do something similar with python and find myself in a fix
as to how to code it clean.
I can't do it with
if ...elseif ... elseif else
unless I wrap it in an event loop.
Since otherwise it means that each condition function will be executed
once. While what we are looking for is way to define potential events
that can happen and a particular segment of code to executed for a
specific event match
The closest thing that I can do is something like this, assuming I
implement the doalternatives method to take a list of function, code
pairs. It would take the list of function-name, parameters list and run
it in an event loop or in separate threads as the need may be to match
one of them.
When one of them matches it would be expected to run the code block
associated with it. Which would get me the same behaviour.
doalternatives(
[web_port.receive,"something"],
"responseTimer.stop;
setverdict(pass);"
[web_port.receive,"somethingelse"],
"responseTimer.stop;
setverdict(fail);"
[responseTimer.timeout],
"responseTimer.stop;
setverdict(pass);"
}
The above looks pretty ok. Except that I have to define the python code
block as a string.
It would be nice if there was a python language construct that would
allow me to define a block of python code that can be passed as a code
object into a function.
That would serve the above purpose as well as cases for distributed or
parallel programming as well.
A construct like
invoke doalternatives with:
param [web_port.receive,"something"]
param:
responseTimer.stop()
setverdict(pass)
param [web_port.receive,"something else"]
param:
responseTimer.stop()
setverdict(fail)
param [responseTimer.timeout]
param:
responseTimer.stop()
setverdict(pass)
I am sure we can do better than what I have proposed above. But the
general idea is to be able to define and pass code segments as code
objects around a function invocation and and pass the code objects as
parameters into the invoked function.
What do people think? Is there any existing construct that I might be
missing to achieve the above?
Sarvi
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A Testing language Construct that could also be a Distributed programming construct - How can this be done in Python
This is the wrong mailing list to ask this question; python-dev is for
discussing the design of the language. General help questions should
go to comp.lang.python.
On Sun, Aug 17, 2008 at 3:52 AM, Saravanan Shanmugham (sarvi)
<[EMAIL PROTECTED]> wrote:
> I am using Python as a test language and wondering how best to represent
> what is shown below in TTCN-3
> TTCN-3, a testing domain specific language has a construct that looks like
> below Its trying to send a request and define 3 alternative
> outcomes/events.
>
> web_port.send("http://www.googe.com/";)
> resonseTimer.start(300)
> alt {
> [] web_port.receive("something") {
> responseTimer.stop;
> setverdict(pass);
> }
> [] web_port.receive("somethingelse") {
> responseTimer.stop;
> setverdict(fail);
> }
> [] responseTimer.timeout {
> setverdict(fail);
> }
> }
>
> I am trying to do something similar with python and find myself in a fix as
> to how to code it clean.
>
> I can't do it with
> if ...elseif ... elseif else
> unless I wrap it in an event loop.
> Since otherwise it means that each condition function will be executed
> once. While what we are looking for is way to define potential events that
> can happen and a particular segment of code to executed for a specific event
> match
>
> The closest thing that I can do is something like this, assuming I implement
> the doalternatives method to take a list of function, code pairs. It would
> take the list of function-name, parameters list and run it in an event loop
> or in separate threads as the need may be to match one of them.
> When one of them matches it would be expected to run the code block
> associated with it. Which would get me the same behaviour.
>
> doalternatives(
> [web_port.receive,"something"],
> "responseTimer.stop;
> setverdict(pass);"
> [web_port.receive,"somethingelse"],
> "responseTimer.stop;
> setverdict(fail);"
> [responseTimer.timeout],
> "responseTimer.stop;
> setverdict(pass);"
> }
>
> The above looks pretty ok. Except that I have to define the python code
> block as a string.
> It would be nice if there was a python language construct that would allow
> me to define a block of python code that can be passed as a code object into
> a function.
>
> That would serve the above purpose as well as cases for distributed or
> parallel programming as well.
>
> A construct like
> invoke doalternatives with:
> param [web_port.receive,"something"]
> param:
> responseTimer.stop()
> setverdict(pass)
> param [web_port.receive,"something else"]
> param:
> responseTimer.stop()
> setverdict(fail)
> param [responseTimer.timeout]
> param:
> responseTimer.stop()
> setverdict(pass)
>
> I am sure we can do better than what I have proposed above. But the general
> idea is to be able to define and pass code segments as code objects around a
> function invocation and and pass the code objects as parameters into the
> invoked function.
>
> What do people think? Is there any existing construct that I might be
> missing to achieve the above?
>
> Sarvi
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Think a dead import finding script would be handy?
After Christian mentioned how we could speed up interpreter start-up by removing some dead imports he found, I decided to write up a quick script that generates the AST for a source file and (very roughly) tries to find imports that are never used. People think it's worth tossing into Tools, even if it is kind of rough? Otherwise I might toss it into the sandbox or make a quick Google code project out of it. Regardless, one interesting side-effect of the script is that beyond finding some extraneous imports in various places, it also found some holes in __all__. I have the script look for the definition of __all__ and consider an import used if it is listed there. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Think a dead import finding script would be handy?
Brett Cannon schrieb: > After Christian mentioned how we could speed up interpreter start-up > by removing some dead imports he found, I decided to write up a quick > script that generates the AST for a source file and (very roughly) > tries to find imports that are never used. People think it's worth > tossing into Tools, even if it is kind of rough? Otherwise I might > toss it into the sandbox or make a quick Google code project out of > it. > > Regardless, one interesting side-effect of the script is that beyond > finding some extraneous imports in various places, it also found some > holes in __all__. I have the script look for the definition of __all__ > and consider an import used if it is listed there. pylint already finds unused imports. It finds tons of other, relatively useless, stuff in the default configuration, but I'm sure it can be coaxed into only showing unused imports too. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] no-op symtable methods
I've been working on getting the symtable module back in working order. However, there are some methods that aren't functioning as they advertise because of changes in the compiler internally. I doubt that any cares or has noticed because I think it's been broken for several releases now. :) These methods are: Symbol.is_in_tuple() Symbol.is_vararg() Symbol.is_keyword() Anyway, if there are no objects, I will deprecate the functions in 2.6 and kill them off for good in 3.0. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP-3121 and PyType_Copy
Hi, In the mailing list archive I see a message that this PEP was implemented, dated June 10. However, while everything else PEP describes does seem to be in SVN, I cannot find PyType_Copy(). Is this function still planned for Python 3000, or are there any simple alternatives? Or are modules just supposed to share types across interpreters? Thanks, Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Think a dead import finding script would be handy?
Brett Cannon wrote: After Christian mentioned how we could speed up interpreter start-up by removing some dead imports he found, I decided to write up a quick script that generates the AST for a source file and (very roughly) tries to find imports that are never used. People think it's worth tossing into Tools, even if it is kind of rough? Otherwise I might toss it into the sandbox or make a quick Google code project out of it. Regardless, one interesting side-effect of the script is that beyond finding some extraneous imports in various places, it also found some holes in __all__. I have the script look for the definition of __all__ and consider an import used if it is listed there. Zope 3 has various tools for sorting imports or checking for unused imports. See http://svn.zope.org/Zope3/trunk/utilities/ Python 3.0 currently imports 25 modules on startup, Python 2.6 just 14: ./python -S -c "import sys; print(list(sorted(sys.modules)), len(sys.modules))" ['__main__', '_abcoll', '_codecs', '_fileio', '_thread', '_weakref', '_weakrefset', 'abc', 'builtins', 'codecs', 'copyreg', 'encodings', 'encodings.aliases', 'encodings.latin_1', 'encodings.utf_8', 'errno', 'genericpath', 'io', 'os', 'os.path', 'posix', 'posixpath', 'signal', 'stat', 'sys', 'zipimport'] 26 _abcoll os.envirion uses _abcoll.MutableMapping _weakref + _weakrefset imported for abc abc imported for io.IOBase copyreg imported by os to register some pickle handlers. Could be removed by placing the code into copyreg instead. encodings.* imported early to avoid various bootstrapping issues (IIRC) encodings.aliases: Could be removing by delaying the import until search_function() is called the first time errno, genericpath, posix, posixpath, stat: import by os and os.path stat: Could probably be replaced by a simple and faster C implementation in posixmodule.c to spare the import signal: I'm not sure why the module is loaded at all. I think we can get rid of copyreg and encodings.aliases easily. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Think a dead import finding script would be handy?
On Sun, Aug 17, 2008 at 1:40 PM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Brett Cannon schrieb: >> After Christian mentioned how we could speed up interpreter start-up >> by removing some dead imports he found, I decided to write up a quick >> script that generates the AST for a source file and (very roughly) >> tries to find imports that are never used. People think it's worth >> tossing into Tools, even if it is kind of rough? Otherwise I might >> toss it into the sandbox or make a quick Google code project out of >> it. >> >> Regardless, one interesting side-effect of the script is that beyond >> finding some extraneous imports in various places, it also found some >> holes in __all__. I have the script look for the definition of __all__ >> and consider an import used if it is listed there. > > pylint already finds unused imports. It finds tons of other, relatively > useless, stuff in the default configuration, but I'm sure it can be > coaxed into only showing unused imports too. > Does anyone ever run pylint over the stdlib on occasion? -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Think a dead import finding script would be handy?
On Sun, 17 Aug 2008 15:04:58 -0700, Brett Cannon <[EMAIL PROTECTED]> wrote: On Sun, Aug 17, 2008 at 1:40 PM, Georg Brandl <[EMAIL PROTECTED]> wrote: Brett Cannon schrieb: After Christian mentioned how we could speed up interpreter start-up by removing some dead imports he found, I decided to write up a quick script that generates the AST for a source file and (very roughly) tries to find imports that are never used. People think it's worth tossing into Tools, even if it is kind of rough? Otherwise I might toss it into the sandbox or make a quick Google code project out of it. Regardless, one interesting side-effect of the script is that beyond finding some extraneous imports in various places, it also found some holes in __all__. I have the script look for the definition of __all__ and consider an import used if it is listed there. pylint already finds unused imports. It finds tons of other, relatively useless, stuff in the default configuration, but I'm sure it can be coaxed into only showing unused imports too. Does anyone ever run pylint over the stdlib on occasion? Buildbot includes a pyflakes step. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Think a dead import finding script would be handy?
On Sun, Aug 17, 2008 at 3:04 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > On Sun, Aug 17, 2008 at 1:40 PM, Georg Brandl <[EMAIL PROTECTED]> wrote: >> Brett Cannon schrieb: >>> After Christian mentioned how we could speed up interpreter start-up >>> by removing some dead imports he found, I decided to write up a quick >>> script that generates the AST for a source file and (very roughly) >>> tries to find imports that are never used. People think it's worth >>> tossing into Tools, even if it is kind of rough? Otherwise I might >>> toss it into the sandbox or make a quick Google code project out of >>> it. >>> >>> Regardless, one interesting side-effect of the script is that beyond >>> finding some extraneous imports in various places, it also found some >>> holes in __all__. I have the script look for the definition of __all__ >>> and consider an import used if it is listed there. >> >> pylint already finds unused imports. It finds tons of other, relatively >> useless, stuff in the default configuration, but I'm sure it can be >> coaxed into only showing unused imports too. >> > > Does anyone ever run pylint over the stdlib on occasion? I usually run pychecker (which also finds unused imports and a whole lot more) before releases. I typically wait for things to settle down (ie, well into beta). n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
