Programmer/Analyst (Python/JPython) - Dallas, TX
Job Description:
- Translate Business Specifications into Python/JPython scripts.
- Interact with Business Analysts, Systems Analysts, and Quality Assurance
to understand business/functional requirements.
- Interact with Java Developers to implement and test scripts.
- Create and design test cases and plans.
Minimum Required Skills:
- 1+ year Python and/or JPython
- Basic data modeling knowledge/experience
- Good design skills
- Ability to manage time and meet schedule commitments
- Initiative
- High attention to detail with documentation, design, coding, and
maintaining standards
- Excellent written and verbal communications skills for interaction with
other groups
- Desire to learn
- Great attitude and personality
Desired Skills:
- Documenting Business Process Flows
- Creating Functional Specifications
- Developing Test Cases
ExoLink Corporation is an e-business broker / transaction clearinghouse. We
are located at I-35 and Corporate Drive in Lewisville, TX. We provide
e-commerce services for companies engaged in the de-regulated retail energy
industry. This is accomplished through the creation of a virtual marketplace
via our ExoTran application. This cutting edge Java based system allows for
the fast and most efficient flow of all forms of data across all platforms.
We utilize technologies such as Java, CORBA, Oracle v8i RDBMS, Windows NT
v4.0, UNIX (Sun Solaris) and more.
ExoLink Corporation is a small, rapidly growing company. We currently have
70+ employees and have open positions for an additional 20-30 employees. Our
rapid growth rate is due to new clients and projects resulting from both
direct and strategic marketing partners. The company has an objective to go
public by 2002. ExoLink has a fun and fast paced environment. Our dress is
business casual. We have great benefits and offer PRE-IPO STOCK OPTIONS.
- 3 Positions Available
- Start Date: ASAP
- SALARY: Open (dependent upon skill set, skill level, and experience) +
Pre-IPO Stock Options + Benefits
- Benefits: Health Insurance (Company pays employee's: monthly medical
premiums, monthly dental premiums, long term disability, life insurance), 18
Paid Time Off (PTO) days/year (covers vacation, illness, personal time,
etc.) + 10 holidays, 401(k), Pre-IPO Stock Options
- Travel: NO TRAVEL
- Location: Dallas, TX (Lewisville)
For more information about ExoLink, please visit us at www.exolink.com
Paul Cain
ExoLink Corporation
(972) 538-6977
(972) 538-6850 fax
paul.cain(a)exolink.com
www.exolink.com
Hello,
I am just dropping a note to announce the alpha release of the first
implementation of a full-fledged Java-Python integration: JPE.
In contrast to JPython, this implementation relies on "C" Python and
Java 2.0 SDK 1.2's JNI C API.
In other terms, JPE maintains a Java and a Python virtual machines
running in the same process space (while JPython entirely runs within
the Java virtual machine).
Java and Python threads are associated together at the OS thread level.
For many other question: http://www/arakne.com/jpe.
The source (Mozilla open source license) is available on sourceforge at
http://sourceforge.net/projects/jpe.
Ciao,
Frederic Giacometti
frederic.giacometti(a)arakne.com
A WikiWikiWeb is a collaborative hypertext environment, with an emphasis on
easy access to and modification of information. MoinMoin is a Python
WikiClone that allows you to easily set up your own wiki, only requiring a
Web server and a Python installation.
This release features graphical smileys, processing instructions (page
redirection, multiple input formats, comments), a RandomPage macro,
configurable HTML page footers, and the usual set of bugfixes.
The code is now refactored to modules, and as expected a lot easier to
extend and maintain. While some of the new features are not fully
finished, some quite useful ones are (see the list below), and the active
code base has reached some maturity.
As a consequence of the multi-module implementation, starting with this
release you need to have the "MoinMoin" directory in your python path,
since "moin.cgi" is now only a small driver to a package named
"MoinMoin" (said directory). See "INSTALL" for more information.
As a compensation for the slightly more complex setup, there is now a
"test.cgi" script to check your installation. For multi-wiki setups, the
new scheme is actually easier (only one directory you need to update).
Homepage:
http://moin.sourceforge.net/
Download:
http://download.sourceforge.net/moin/
Mailing lists:
http://lists.dragon-ware.com/mailman/listinfo/moin-usershttp://lists.dragon-ware.com/mailman/listinfo/moin-dev
New features:
* Major refactoring: code is now broken up into modules within the
"MoinMoin" package
* Diagnosis of installation via a "test.cgi" script
* Smileys
* "#format" processing instruction
* "##comment"
* [[RandomPage]] and [[RandomPage(number)]] macro
* configurable footer ("page_footer1" and "page_footer2")
* "#redirect" processing instruction
Bugfixes:
* Bugfix for broken CGI environment of IIS/4.0
* URLs and InterWiki links are now less greedy (punctuation at the end
is excluded, and "<" ends them, too)
DOOP is a distributed, object-oriented MOO server written in Python.
It began with the POO source of last year, but has diverged greatly
from it. This version is GPL, with the kind permission of the
original POO author, Joseph Strout.
The server is in pre-alpha stage at the moment, though most of the
functionality is working just fine. I still have to hammer out some
of the scripts, and test the remoting/multi-threaded code under heavy
load.
You can try out a one-user version of the server at:
http://doop.sourceforge.net
Just run the script "bootstrap", followed by "run". Note that you
will need Pyro 1.4 to use DOOP, with the modifications below.
Suggestions are welcome!
John Wiegley <johnw(a)gnu.org>
----------------------------------------------------------------------
--- Pyro-1_4/Pyro/__init__.py Mon Aug 7 14:07:51 2000
+++ pyro/Pyro/__init__.py Thu Nov 16 10:19:52 2000
@@ -27,13 +27,15 @@
PYRO_VERSION = '1.4'
-import configuration, os
+import configuration, os, os.path
config = configuration.Config()
try:
confFile = os.environ['PYRO_CONFIG_FILE']
except KeyError:
confFile = ''
+if not confFile and os.path.isfile("Pyro.conf"):
+ confFile = "Pyro.conf"
config.setup(confFile)
--- Pyro-1_4/Pyro/core.py Sun Oct 15 06:01:36 2000
+++ pyro/Pyro/core.py Thu Nov 16 10:21:23 2000
@@ -60,7 +60,7 @@
if flags & RIF_Varargs:
# reconstruct the varargs from a tuple like (a,b,(va1,va2,va3...))
args=args[:-1]+args[-1]
- if method in ('remote_hasattr', 'remote_getattr', 'remote_setattr'):
+ if method in dir(ObjBase):
return apply(getattr(self,method),args,keywords)
else:
return apply(getattr(self.delegate,method),args,keywords)
@@ -187,11 +187,6 @@
def __str__(self):
return repr(self)
- # Note that a slightly faster way of calling is this:
- # instead of proxy.method(args...) use proxy('method',args...)
- def __call__(self, method, *vargs, **kargs):
- self._name.append(method)
- return self.__invokePYRO__
def __invokePYRO__(self, *vargs, **kargs):
if self.adapter is None:
# delayed adapter binding.
.
[I'm resending this, because the note I sent yesterday didn't
seem to have made it to the newsgroups.]
Hi everybody,
due to the frequent downtimes of Starship.python.net I am moving
all my Python Pages including the mx Extensions to a new site which
will hopefully provide a more stable platform.
Python Pages URL
----------------
You can find everything at this new URL:
http://www.lemburg.com/python/
Please update your links to this new URL. Once I get my login
for starship to work again, I'll also post an announcement
there.
mx Extensions URL
------------------
The mx Extensions (e.g. mxDateTime, mxODBC, mxTextTools, etc.) can
be downloaded in versions for Python 1.5.2 and Python 2.0 from:
http://www.lemburg.com/python/mxExtensions.html
Sorry for the delays and mixups during the last few days,
--
Marc-Andre Lemburg
______________________________________________________________________
Company: http://www.egenix.com/
Consulting: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/
Python-dev summary, November 1-15, 2000
=======================================
To comment on material in this python-dev summary, you can simply post
to comp.lang.python / <python-list(a)python.org>. These summaries are
archived at <URL:http://www.amk.ca/python/dev/>.
The move to Digital Creations has broken the dam, burying python-dev
in a flood of new ideas. This two week period was very busy,
beginning with a call for feature proposals for Python 2.1.
This summary will therefore be more telegraphic than usual; it would
be too time-consuming to summarize the major threads, which were all
quite lengthy, and the final result would still distort the arguments.
So, if one of the topics is of interest to you, please refer to the
python-dev archives for all the details.
Python 2.1 tasks
================
GvR listed the PEPs he wants to consider for Python 2.1, and requested
more input: "If you have an idea for a PEP that you think should be
implemented in Python 2.1, or if you want to revive a PEP that's
currently listed in one of the "unattainable" categories, now's the
time to make a plea!"
http://www.python.org/pipermail/python-dev/2000-November/017072.html
Various people followed up stating what they'd like to work on: Moshe
Zadka wants to tackle the question of integer division (see below),
AMK wants to use the Distutils to build Python itself, and so forth.
Discussion of most of the topics covered in this summary was triggered
by this call for suggestions. After being closely focused on the release of
Python 2.0 for so long, python-dev is beginning to direct its gaze
toward the distant horizon of the future.
Integer division
================
Moshe drafted PEP 228, "Reworking Python's Numeric Model". This PEP
proposes a numeric model for Python that isn't based on C's model,
which ultimately derives from machine representations of integers and
floats. "While coercion rules will remain for add-on types and classes, the
built in type system will have exactly one Python type -- a
number."
http://python.sourceforge.net/peps/pep-0228.html
The ensuing discussion was scattered, mostly revolving around whether
and when to use rational numbers, and whether floating point literals
should be considered exact or inexact numbers. It's not obvious that
this PEP can be solidified in time for its results to be incorporated
in Python 2.1.
Stackless Python, and microthreads
==================================
Some sort of resolution to Stackless Python seems likely for 2.1.
Guido is inclined to take a solution for 90% of the problems: "I still
think that the current Stackless implementation is too complex, and
that continuations aren't worth the insanity they seem to require (or
cause :-), but that microthreads and coroutines *are* worth having and
that something not completely unlike Stackless will be one day the way
to get there..." He then went on to post a strawman API for
microthreads:
http://www.python.org/pipermail/python-dev/2000-November/017216.html
Christian Tismer agreed with him that continuations aren't really
necessary. "I'm happy to toss continuations for core Python, if we can
find the right building blocks for coro/gen/uthreads. I think Guido
comes quite near this, already."
http://www.python.org/pipermail/python-dev/2000-November/017252.html
And so did Tim: "I don't know of any comprehensible application of
continuations that can't be done without them."
http://www.python.org/pipermail/python-dev/2000-November/017258.html
Christian Tismer enumerated the changes to ceval.c made by Stackless:
http://www.python.org/pipermail/python-dev/2000-November/017238.html
Finally, Gordon McMillan put up a Stackless intro and tutorial:
http://www.mcmillan-inc.com/stackless.html
Class/type dichotomy
====================
The seam that runs between classes, defined in Python code, and types,
defined in C code, has been in Python from the beginning. Various
schemes for bridging the gap were suggested.
M.A. Lemburg suggested adding an extra indirection, letting C types
identify themselves as subclasses of another C type:
http://www.python.org/pipermail/python-dev/2000-November/017152.html
Greg Ewing, inspired by Ruby's implementation, suggested adding a
global dictionary to add extra attributes to type instances:
http://www.python.org/pipermail/python-dev/2000-November/017196.html
Scoping changes
===============
Python's two-level scoping rules have been the subject of debate for a
while. Many new users expect Python to have Pascal-like static
scoping and are surprised when variable references in lambdas or other
nested functions behave unexpectedly. Previously this would have
presented technical problems, since nesting scopes would create
cyclical references, which couldn't be handled by Python's reference
counting.
Jeremy wrote PEP 227, "Statically Nested Scopes", to make a concrete
proposal: "The current language definition defines exactly three
namespaces that are used to resolve names -- the local, global, and
built-in namespaces. The addition of nested scopes would allow
resolution of unbound local names in enclosing functions' namespaces."
http://python.sourceforge.net/peps/pep-0227.html
Some discussion ensued, mostly about whether it's worth changing this
just to fix nested functions. A side thread on dynamic scoping, as
opposed to static, spun off at one point, but since practically
everyone thought it was a bad idea, nothing emerged from it worth
summarizing.
Other matters
=============
Another item on GvR's list for 2.1 was a framework for printing
optional warnings:
http://www.python.org/pipermail/python-dev/2000-November/017134.html
Coincidentally, Paul Prescod was also working on a warning framework,
and had a draft PEP:
http://www.python.org/pipermail/python-dev/2000-November/017144.html
AMK tried to raise some interest in PEP 222, which lists some
improvements to make Web programming in Python easier, but there seems
to be little interest. If no further interest is shown by the
community, the PEP will simply be abandoned.
http://python.sourceforge.net/peps/pep-0222.html
A Web page listing critical patches for 2.0 was created:
http://www.python.org/cgi-bin/moinmoin
Related Links
=============
Python-dev archives:
http://www.python.org/pipermail/python-dev/
Python project page on SourceForge:
http://sourceforge.net/projects/python
Python Enhancement Proposals (PEPs):
http://python.sourceforge.net/peps/
ANN: 4Suite 0.9.2
Fourthought, Inc. (http://Fourthought.com) announces the release of
4Suite 0.9.2
---------------------------
Open source tools for standards-based XML, DOM, XPath, XSLT, RDF
XPointer, XLink and object-database development in Python
4Suite is a collection of Python tools for XML processing and object
database management. An integrated packaging of several formerly
separately-distributed components: 4DOM, 4XPath and 4XSLT, 4RDF, 4ODS
4XPointer and featuring the new 4XLink and DbDOM.
News
----
- The 4Suite home page has been moved to
http://4Suite.org
- 4Suite has moved to a derivative of the Apache license.
- 4Suite now workd with Python 2.0 as well as Python 1.5.2. Python
1.6 is not supported, although it might work. Python 1.5.2 support
is expected to be dropped in the next release of 4Suite.
- PyXML 0.6.2 is still required even if you are using Python 2.0
http://sourceforge.net/projects/pyxml
- Changes to the software:
* Introduced 4XLink: A processor to expand XLink attributes
* Introduced DbDom: An alpha Dom implmentaiton on top of 4ODS
* ODS: Improved the test suites to handle more cases and conform to protocol
* cDomlette: added support for methods
* 4RDF: Fixes and improvements to serialization, the back end and the API
* All: Many improvements to the docs
* All: Standardized reader interfaces across DOM implementations
* All: Test with python 2.0
* All: PyXML not needed with Python 2.0
* Many misc optimizations
* Many misc bug-fixes
- We have set up a contest for stories of 4Suite usage. See
http://www.4suite.org/contest.epy
More info and Obtaining 4Suite
------------------------------
Please see
http://4Suite.org
>From where you can download source, Windows and Linux binaries.
4Suite is distributed under a license similar to that of the
Apache Web Server.
--
Uche Ogbuji Principal Consultant
uche.ogbuji(a)fourthought.com +01 303 583 9900 x 101
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python
What is it:
The Sybase module provides a Python interface to the Sybase relational
database system. The Sybase package supports almost all of the Python
Database API, version 2.0 with extensions.
The module works with Python versions 1.5.2 and later and Sybase
versions 11.0.3 and later. It is based on the Sybase Client Library
(ct_* API), and the Bulk-Library Client (blk_* API) interfaces.
Changes:
- A Numeric object exposes the Sybase numeric / decimal data type to
Python. Columns of type numeric / decimal will be returned as
Numeric objects.
Numeric objects can be used in almost all places as other Python
number objects. The following operations have been implemented; +,
-, *, /, int(), float(), long(), str(), cmp(), repr(), hash(),
abs().
A Numeric object has two readonly attributes; precision, and scale.
You can create a new Numeric object by using the
Sybase.numeric(value) function. This will convert the int / long /
float / string object passed as value to Numeric.
At the moment, money and money4 types are still transformed into
float objects because I have not worked out how to tell the Sybase
library to generate the right number of decimal places in arithmetic
results. For example:
You can pickle the new numeric data type.
>>> import Sybase
>>> n = Sybase.numeric(100200300400500L)
>>> n.precision, n.scale
(77, 0)
>>> m = Sybase.numeric(n, 30, 2)
>>> m
100200300400500.00
>>> m.precision, m.scale
(30, 2)
If you want to increase the scale without modifying the precision,
pass -1 as the precision.
>>> m = Sybase.numeric(n, -1, 4)
>>> m
100200300400500.0000
>>> m.precision, m.scale
(77, 4)
Where can you get it:
http://www.object-craft.com.au/projects/sybase/
- Dave
--
http://www.object-craft.com.au
This release contains:
* Many bug-fixes
* Updated documentation
* Updated demos that reflect new Snack features
* Expanded test suite
* Improved Windows installers
The Snack Sound Toolkit is designed to be used with a scripting
language.
Snack adds commands to play, record, and process sound and supports
in-memory sound objects, file based audio, and streaming audio.
It handles fileformats such as WAV, MP3, AU, AIFF, and NIST/Sphere.
Snack is extensible, new commands, filters, and sound file formats can
be added using the Snack C-library. An easy to build example extension
is contained in the source distribution.
Snack also does sound visualization, e.g. waveforms and spectrograms.
The visualization objects update in real-time and can output postscript.
Snack works with Tcl8.0 - Tcl8.4 and Python 1.5.2-2.0
Platforms: Linux, Solaris, HP-UX, IRIX, NetBSD, Macintosh, and
Windows95/98/NT/2K.
Source and binaries can be downloaded from
http://www.speech.kth.se/snack/
Regards,
Kare Sjolander
kare(a)speech.kth.se