Re: Type hinting of Python is just a toy ?

[lorenzo . gatti]

On Friday, January 4, 2019 at 9:05:11 AM UTC+1, iam...@icloud.com wrote:
> I read that pep 484 type hinting of python has no effect of performance, then 
> what’s the purpose of it? Just a toy ?
Having no effect on performance is a good thing; Python is already slowish, 
additional runtime type checking would be a problem. 
The purpose of type hinting is helping tools, for example ones that look for 
type errors in source code (e.g. a function parameter is supposed to be a 
string, but an integer is being passed).
> 
> Python is an old programming language, but not better than other programming 
> languages, then what are you all dong for so many times ? 
Being nice in general, and not too aggressive with trolls in particular, is 
also a good thing.
> 
> Pep484 is too complex. Typle should not a seperate type, in fact it should be 
> just a class. Like this in other programming language
> Python: Tuple(id: int, name: string, age: int)
> Other: class someClass {
>   public int id;
>   public string name;
>   public int age;
> }
But tuple (not Tuple) is already is a class. Are you missing the difference 
between declaring a type and invoking a constructor? Try to work out complete 
examples.
> Design of OOP of python is too bad, so it treat Tuple as a seperate type.
If you mean that defining classes could be replaced by uniformly using tuples, 
it is not the case because classes can have a lot of significant behaviour, 
including encapsulation.
If you mean that the specific tuple class shouldn't exist and all classes 
should be in some way like tuple, it is not the case because many classes have 
to behave differently and above that tuple has special syntax support. It's 
about as special as the dict class and the list class, and clearly different.
> Why looks different than others? afraid of cannot been watched by others?
Like most programming languages, Python was deliberately designed to be 
different from existing programming languages in order to make an experiment 
(which could be summarized as interpreted, with a lot of convenient syntax in 
order to be brief and readable, strictly object oriented, strongly but 
dynamically typed) and to gain adoption (by offering an advantage to users who 
wouldn't bother trying a language that is only marginally different from 
existing ones). 
By all means, use other programming languages if you think they are better, but 
don't expect Python to change in radical ways.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[lorenzo . gatti]

On Saturday, February 17, 2018 at 12:28:29 PM UTC+1, Ben Bacarisse wrote:
> Marko Rauhamaa  writes:
> 
> > Many people think static typing is key to high quality. I tend to think
> > the reverse is true: the boilerplate of static typing hampers
> > expressivity so much that, on the net, quality suffers.
> 
> I don't find that with Haskell.  It's statically typed but the types are
> almost always inferred.  If you see an explicit type, it's usually
> because the author thinks it helps explain something.
> 
> (I don't want to start a Haskell/Python thread -- the only point is that
> static typing does not inevitably imply lots of 'boilerplate'.)
> 
> -- 
> Ben.
There are two sides to not declaring types: having readers spend a fraction of 
a second to figure out what types are being used and having tools apply type 
inference for useful purposes. 
Python is bad at type inference (but only because deliberate loopholes like 
eval() are preserved) but good at making programmers trust code, while Haskell 
is bad at encouraging straightforward and understandable types but good at 
extracting maximum value from type inference.  
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Getting back into PyQt and not loving it.

[lorenzo . gatti]

PyGTK is obsolete and stopped at Python 2.7, while PyGObject for Windows is 
several versions behind (currently 3.18 vs 3.21) and it doesn't support Python 
3.5. Game over for GTK+.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Which one is the best XML-parser?

[lorenzo . gatti]

On Thursday, June 23, 2016 at 11:03:18 PM UTC+2, David Shi wrote:
> Which one is the best XML-parser?
> Can any one tell me?
> Regards.
> David

Lxml offers lxml.etree.iterparse 
(http://lxml.de/tutorial.html#event-driven-parsing), an important combination 
of the memory savings of incremental parsing and the convenience of visiting a 
DOM tree without dealing with irrelevant details. 
An iterable incrementally produces DOM element objects, which can be deleted 
after processing them and before proceeding to parse the rest of the document. 
This technique allows easy processing of huge documents containing many 
medium-size units of work whose DOM trees fit into memory easily. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: anomaly

[lorenzo . gatti]

On Monday, May 11, 2015 at 2:58:09 AM UTC+2, zipher wrote:
 I guess everyone expects this behavior since Python implemented this idea of 
 everything is an object, but I think this branch of OOP (on the branch of 
 the Tree of Programming Languages) has to be chopped off.  The idea of 
 everything is an object is backwards (unless your in a LISP machine).  Like I 
 say, it's trying to be too pure and not practical.

Expressing this sort of emphatic, insulting and superficial opinions, to the 
people who would be most irritated by them (the Python mailing list) and 
without the slightest interest for contrary viewpoints and constructive 
discussion, is a very unpleasant form of trolling. 

If you don't like Python, you are welcome to prefer other programming 
languages. If you want to use Python with C-like primitive types, you can use 
arrays. Both choices are perfectly good, and routinely made without bothering 
other people with inane conversations.

Lorenzo Gatti
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New user's initial thoughts / criticisms of Python

[lorenzo . gatti]

Regarding the select statement, I think the most Pythonic approach is using 
dictionaries rather than nested ifs. 
Supposing we want to decode abbreviated day names (mon) to full names 
(Monday):
day_abbr='mon'

day_names_mapping={
'mon':'Monday',
'tue':'Tuesday',
'wed':'Wednesday',
'thu':'Thursday',
'fri':'Friday',
'sat':'Saturday',
'sun':'Sunday'
}
try:
full_day_name=day_names_mapping[day_abbr.casefold()]
except KeyError:
raise GoodLuckFixingItException('We don't have '+day_abbr+' in our week')

This style is more compact (usually one line per case) and more meaningful 
(generic processing driven by separate data) than a pile of if statement, and 
more flexible: 

full_day_names=('Monday','Tuesday','Wednesday','Thursday','Friday','Saturday','Sunday')
day_names={x.casefold()[0:3] : x for x in full_day_names}
#

A dict can also contain tuples, lists, and nested dicts, consolidating multiple 
switches over the same keys and organizing nested switches and other more 
complex control structures.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Choosing GUI Module for Python

[Lorenzo Gatti]

On Nov 11, 9:48 am, Lorenzo Gatti ga...@dsdata.it wrote:

 On a more constructive note, I started to follow the instructions 
 athttp://www.pyside.org/docs/pyside/howto-build/index.html(which are
 vague and terse enough to be cross-platform) with Microsoft VC9
 Express.
 Hurdle 0: recompile Qt because the provided DLLs have hardcoded wrong
 paths that confuse CMake.
 How should Qt be configured? My first compilation attempt had to be
 aborted (and couldn't be resumed) after about 2 hours: trial and error
 at 1-2 builds per day could take weeks.

Update: I successfully compiled Qt (with WebKit disabled since it
gives link errors), as far as I can tell, and I'm now facing
apiextractor.

Hurdle 1a: convince CMake that I actually have Boost headers and
compiled libraries.
The Boost directory structure is confusing (compiled libraries in two
places), and CMake's script (FindBoost.cmake) is inconsistent (should
I set BOOST_INCLUDEDIR or BOOST_INCLUDE_DIR?), obsolete (last known
version is 1.38 rather than the requisite 1.40) and rather fishy (e.g.
hardcoded c:\boost paths).
Would the Cmake-based branch of Boost work better? Any trick or recipe
to try?
Hurdle 1b: the instructions don't mention a dependency from libxml2.

Lorenzo Gatti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Choosing GUI Module for Python

[Lorenzo Gatti]

On Nov 10, 11:08 pm, Simon Hibbs simon.hi...@gmail.com wrote:

 Since QT runs on Windows,
 porting to the Windows version of QT shouldn't be hard.

The PySide developers, who are better judges of their own project than
you and me, consider a Windows port so hard (and time consuming) that
they didn't even try; a second iteration of the already working
binding generator has a higher priority than supporting a large
portion of the potential user base with a Windows port, so don't hold
your breath.

On a more constructive note, I started to follow the instructions at
http://www.pyside.org/docs/pyside/howto-build/index.html (which are
vague and terse enough to be cross-platform) with Microsoft VC9
Express.
Hurdle 0: recompile Qt because the provided DLLs have hardcoded wrong
paths that confuse CMake.
How should Qt be configured? My first compilation attempt had to be
aborted (and couldn't be resumed) after about 2 hours: trial and error
at 1-2 builds per day could take weeks.

Regards,
Lorenzo Gatti

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Choosing GUI Module for Python

[Lorenzo Gatti]

On Nov 9, 9:01 pm, Simon Hibbs simon.hi...@gmail.com wrote:

 The main objection to using PyQT untill now was that for commercial
 development you needed to buy a license (it was free for GPL
 projects). That's rapidly becoming a non-issue as the core QT
 framework is now LGPL and Nokia have a project underway to produce
 PyQT compatible LGPL python bindings under the PySide project.

I also would like to use PySide, but unlike PyQt and Qt itself it
doesn't seem likely to support Windows in the foreseeable future. A
pity, to put it mildly.

Regards,
Lorenzo Gatti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pyfora, a place for python

[Lorenzo Gatti]

On Nov 3, 11:37 am, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
 On Tue, 03 Nov 2009 02:11:59 -0800, Lorenzo Gatti wrote:
[...]
 Are you saying that now that comp.lang.python and stackoverflow exists,
 there no more room in the world for any more Python forums?

 I think that's terrible.

Although there is a high barrier to entry for general Python forums,
it is not a problem because the door is always open for specialized
forums that become the natural home of some group or thought leader
or of some special interest, for example the forum of a new software
product or of the fans of an important blog.

Unfortunately, pyfora.org has neither a distinct crowd behind it nor
an unique topic, and thus no niche to fill; it can only contribute
fragmentation, which is unfortunate because Saketh seems enthusiastic.

What in some fields (e.g. warez forums or art boards) would be healthy
redundancy and competition between sites and forums becomes pure
fragmentation if the only effect of multiple forums is to separate the
same questions and opinions that would be posted elsewhere from
potential readers and answerers.
Reasonable people know this and post their requests for help and
discussions either in the same appropriate places as everyone else or
in random places they know and like; one needs serious personal issues
to abandon popular forums for obscure ones.

 Saketh, would you care to give a brief explanation for sets your forum
 apart from the existing Python forums, and why people should choose to
 spend time there instead of (or as well as) the existing forums? What
 advantages does it have?

That's the point, I couldn't put it better.

  It would be the Internet equivalent of looking for a poker tournament in
  a desert valley instead of driving half an hour less and going to Las
  Vegas:
  [...]
 How about avoiding the noise and obtrusive advertising and bright lights
 of Las Vegas, the fakery, the showmanship,
 [...]
 if you're interested in poker without all the mayonnaise, maybe
 that poker tournament away from the tourists is exactly what you need.

I didn't explain my similitude clearly: I was comparing the fitness
for purpose of going to Las Vegas with a plan to gamble with the
absurdity of stopping, say, at an isolated gas station in the hope of
finding a poker tournament there.
If you are hinting that popular newsgroups and forums might be so full
of fakery, showmanship, mayonnaise, etc. to deserve secession, it's
another topic.

Regards,
Lorenzo Gatti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pyfora, a place for python

[Lorenzo Gatti]

On Nov 1, 8:06 am, Saketh saketh.bhamidip...@gmail.com wrote:
 Hi everyone,

 I am proud to announce the release of Pyfora (http://pyfora.org), an
 online community of Python enthusiasts to supplement comp.lang.python
 and #python. While the site is small right now, please feel free to
 register and post any questions or tips you may have.

I'll feel free to not even bookmark it. I'm sorry, but it is just a
bad idea.

Your forum cannot (and should not) compete either with Python's
official newsgroup, IRC channel and mailing list or with popular, well-
made and well-frequented general programming sites like
stackoverflow.com.

It would be the Internet equivalent of looking for a poker tournament
in a desert valley instead of driving half an hour less and going to
Las Vegas: there are no incentives to choose your forum, except
perhaps for isolationists who value being a big fish in a small pond
over being part of a community.

If you want to claim a small Python-related corner of the web, you
should write a blog: if it is any good, and probably even if it isn't,
it would be linked and read by someone and it would add to collective
knowledge instead of fragmenting it.

Regards,
Lorenzo Gatti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: random number including 1 - i.e. [0,1]

[Lorenzo Gatti]

On 10 Giu, 06:23, Esmail ebo...@hotmail.com wrote:
 Here is part of the specification of an algorithm I'm implementing that
 shows the reason for my original query:

 vid = w * vid + c1 * rand( ) * ( pid – xid ) + c2 * Rand( ) * (pgd –xid ) (1a)

 xid = xid + vid (1b)

 where c1 and c2 are two positive constants,
 rand() and Rand() are two random functions in the range [0,1],
 ^
 and w is the inertia weight.

1) I second John Yeung's suggestion: use random integers between 0 and
N-1 or N inclusive and divide by N to obtain a maximum value of (N-1)/
N or 1 as you prefer. Note that N doesn't need to be very large.

2) I'm not sure a pseudo-closed range is different from a pseudo-open
one. You are perturbing vid and xid by random amounts, scaled by
arbitrary coefficients c1 and c2: if you multiply or divide these
coefficients by (N-1)/N the minimum and maximum results for the two
choices can be made identical up to floating point mangling.

Regards,
Lorenzo Gatti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Thoughts on language-level configuration support?

[Lorenzo Gatti]

On 31 Mar, 09:19, jfager jfa...@gmail.com wrote:
 On Mar 31, 2:54 am, David Stanek dsta...@dstanek.com wrote:

  On Mon, Mar 30, 2009 at 9:40 AM, jfager jfa...@gmail.com wrote:
  http://jasonfager.com/?p=440.

   The basic idea is that a language could offer syntactic support for
   declaring configurable points in the program.  The language system
   would then offer an api to allow the end user to discover a programs
   configuration service, as well as a general api for providing
   configuration values.

A configuration service? An end user that bothers to discover it?
API for providing configuration values? This suggestion, and the
companion blog post, seem very distant from the real world for a
number of reasons.

1) Users want to supply applications with the least amount of useful
configuration information as rarely and easily as possible, not to use
advanced tools to satisfy an application's crudely expressed
configuration demands.

Reducing inconvenience for the user entails sophisticated and mostly
ad hoc techniques: deciding without asking (e.g. autoconf looking into
C compiler headers and trying shell commands or countless applications
with user profiles querying the OS for the current user's home
directory), asking when the software is installed (e.g. what 8 bit
character encoding should be used in a new database), designing
sensible and safe defaults.

2) Practical complex configuration files (or their equivalent in a DB,
a LDAP directory, etc.) are more important and more permanent than the
applications that use them; their syntax and semantics should be
defined by external specifications (such as manuals and examples), not
in the code of a particular implementation.

User documentation is necessary, and having a configuration mechanism
that isn't subject to accidents when the application is modified is
equally important.

3) Configuration consisting of values associated with individual
variables is an unusually simple case. The normal case is translating
between nontrivial sequential, hierarchical or reticular data
structures in the configuration input and quite different ones in the
implementation.

4) Your actual use case seems to be providing a lot of tests with a
replacement for the real configuration of the actual application.
Branding variables as configuration all over the program isn't an
useful way to help the tests and the actual application build the same
data structures in different ways.

  What value does this have over simply having a configuration file.

 Simply having a configuration file - okay.  What format?  What if
 the end user wants to keep their configuration info in LDAP?

Wait a minute. Reading the configuration from a live LDAP directory
is a major feature, with involved application specific aspects (e.g.
error handling) and a solid justification in the application's
requirements (e.g. ensuring up to date authentication and
authorization data), not an interchangeable configuration provider and
certainly not something that the user can replace.

Deciding where the configuration comes from is an integral part of the
design, not something that can or should be left to the user: there
can be value in defining common object models for various sources of
configuration data and rules to combine them, like e.g. in the Spring
framework for Java, but it's only a starting point for the actual
design of the application's configuration.

  In your load testing application you could have easily checked for the
  settings in a config object.

 Not really easily, no.  It would have been repeated boilerplate across
 many different test cases (actually, that's what we started with and
 refactored away), instead of a simple declaration that delegated the
 checking to the test runner.

A test runner has no business configuring tests beyond calling generic
setup and teardown methods; tests can be designed smartly and factored
properly to take care of their own configuration without repeating
boilerplate.

  I think that the discover-ability of
  configuration can be handled with example configs and documentation.

 Who's keeping that up to date?  Who's making sure it stays in sync
 with the code?  Why even bother, if you could get it automatically
 from the code?

It's the code that must remain in sync with the documentation, the
tests, and the actual usage of the application. For example, when did
you last see incompatible changes in Apache's httpd.conf?

You seem to think code is central and actual use and design is a
second class citizen. You say in your blog post: Users shouldn’t have
to pore through the code to find all the little bits they can tweak.
They shouldn't because a well designed application has adequate
documentation of what should be configured in the form of manuals,
wizards, etc. and they shouldn't because they don't want to tweak
little bits, not even if they have to.

Regards,

Lorenzo Gatti
--
http://mail.python.org/mailman/listinfo/python-list

Re: type-checking support in Python?

[Lorenzo Gatti]

On 7 Ott, 08:36, Lawrence D'Oliveiro [EMAIL PROTECTED]
central.gen.new_zealand wrote:
 In message [EMAIL PROTECTED], Gabriel

 Genellina wrote:
  As an example, in the oil industry here in my country there is a mix of
  measurement units in common usage. Depth is measured in meters, but pump
  stroke in inches; loads in lbs but pressures in kg/cm².

 Isn't the right way to handle that to attach dimensions to each number?

Can you afford to avoid floats and ints? Attaching suffixes is the
best one can do with the builtin types.
In C++ one can check dimensions at compile time (http://www.boost.org/
doc/libs/1_36_0/doc/html/boost_units.html) with a modest increase of
cumbersomeness, but Python would need very heavyweight classes
containing a value and its dimension and a replacement of all needed
functions and operations.

Regards,
Lorenzo Gatti
--
http://mail.python.org/mailman/listinfo/python-list

Re: XML-schema 'best practice' question

[Lorenzo Gatti]

On 20 Set, 07:59, Frank Millman [EMAIL PROTECTED] wrote:

 I want to introduce an element of workflow management (aka Business
 Process Management) into the business/accounting system I am
 developing. I used google to try to find out what the current state of
 the art is. After several months of very confusing research, this is
 the present situation, as best as I can figure it out.

What is the state of the art of existing, working software? Can you
leverage it instead of starting from scratch? For example, the
existing functionality of your accounting software can be reorganized
as a suite of components, web services etc. that can be embedded in
workflow definitions, and/or executing a workflow engine can become a
command in your application.

 There is an OMG spec called BPMN, for Business Process Modeling
 Notation. It provides a graphical notation
[snip]
 there is no standard way
 of exchanging a diagram between different vendors, or of using it as
 input to a workflow engine.

So BPMN is mere theory. This spec might be a reference for
evaluating actual systems, but not a standard itself.

 There is an OASIS spec called WS-BPEL, for Web Services Business
 Process Execution Language. It defines a language for specifying
 business process behavior based on Web Services. This does have a
 formal xml-based specification. However, it only covers processes
 invoked via web services - it does not cover workflow-type processes
 within an organisation. To try to fill this gap, a few vendors got
 together and submitted a draft specification called BPEL4People. This
 proposes a series of extensions to the WS-BPEL spec. It is still at
 the evaluation stage.

Some customers pay good money for buzzword compliance, but are you
sure you want to be so bleeding edge that you care not only for WS-
something specifications, but for evaluation stage ones?

There is no need to wait for BPEL4People before designing workflow
systems with human editing, approval, etc.
Try looking into case studies of how BPEL is actually used in
practice.

 The BPMN spec includes a section which attempts to provide a mapping
 between BPMN and BPEL, but the authors state that there are areas of
 incompatibility, so it is not a perfect mapping.

Don't worry, BPMN does not exist: there is no incompatibility.
On the other hand, comparing and understanding BPMN and BPEL might
reveal different purposes and weaknesses between the two systems and
help you distinguish what you need, what would be cool and what is
only a bad idea or a speculation.

 Eventually I would like to make sense of all this, but for now I want
 to focus on BPMN, and ignore BPEL. I can use wxPython to design a BPMN
 diagram, but I have to invent my own method of serialising it so that
 I can use it to drive the business process. For good or ill, I decided
 to use xml, as it seems to offer the best chance of keeping up with
 the various specifications as they evolve.

If you mean to use workflow architectures to add value to your
business and accounting software, your priority should be executing
workflows, not editing workflow diagrams (which are a useful but
unnecessary user interface layer over the actual workflow engine);
making your diagrams and definitions compliant with volatile and
unproven specifications should come a distant last.

 I don't know if this is of any interest to anyone, but it was
 therapeutic for me to try to organise my thoughts and get them down on
 paper. I am not expecting any comments, but if anyone has any thoughts
 to toss in, I will read them with interest.


1) There are a number of open-source or affordable workflow engines,
mostly BPEL-compliant and written in Java; they should be more useful
than reinventing the wheel.

2) With a good XML editor you can produce the workflow definitions,
BPEL or otherwise, that your workflow engine needs, and leave the
interactive diagram editor for a phase 2 that might not necessarily
come; text editing might be convenient enough for your users, and for
graphical output something simpler than an editor (e.g a Graphviz
exporter) might be enough.

3) Maybe workflow processing can grow inside your existing accounting
application without the sort of big bang redesign you seem to be
planning; chances are that the needed objects are already in place and
you only need to make workflow more explicit and add appropriate new
features.

Regards,
Lorenzo Gatti
--
http://mail.python.org/mailman/listinfo/python-list

Re: XML-schema 'best practice' question

[Lorenzo Gatti]

Sorry for pressing the send button too fast.

On 20 Set, 07:59, Frank Millman [EMAIL PROTECTED] wrote:

 I want to introduce an element of workflow management (aka Business
 Process Management) into the business/accounting system I am
 developing. I used google to try to find out what the current state of
 the art is. After several months of very confusing research, this is
 the present situation, as best as I can figure it out.

What is the state of the art of existing, working software? Can you
leverage it instead of starting from scratch? For example, the
existing functionality of your accounting software can be reorganized
as a suite of components, web services etc. that can be embedded in
workflow definitions, and/or executing a workflow engine can become a
command in your application.

 There is an OMG spec called BPMN, for Business Process Modeling
 Notation. It provides a graphical notation
[snip]
 there is no standard way
 of exchanging a diagram between different vendors, or of using it as
 input to a workflow engine.

So BPMN is mere theory. This spec might be a reference for
evaluating actual systems, but not a standard itself.

 There is an OASIS spec called WS-BPEL, for Web Services Business
 Process Execution Language. It defines a language for specifying
 business process behavior based on Web Services. This does have a
 formal xml-based specification. However, it only covers processes
 invoked via web services - it does not cover workflow-type processes
 within an organisation. To try to fill this gap, a few vendors got
 together and submitted a draft specification called BPEL4People. This
 proposes a series of extensions to the WS-BPEL spec. It is still at
 the evaluation stage.

Some customers pay good money for buzzword compliance, but are you
sure you want to be so bleeding edge that you care not only for WS-
something specifications, but for evaluation stage ones?

There is no need to wait for BPEL4People before designing workflow
systems with human editing, approval, etc.
Try looking into case studies of how BPEL is actually used in
practice.

 The BPMN spec includes a section which attempts to provide a mapping
 between BPMN and BPEL, but the authors state that there are areas of
 incompatibility, so it is not a perfect mapping.

Don't worry, BPMN does not exist: there is no incompatibility.
On the other hand, comparing and understanding BPMN and BPEL might
reveal different purposes and weaknesses between the two systems and
help you distinguish what you need, what would be cool and what is
only a bad idea or a speculation.

 Eventually I would like to make sense of all this, but for now I want
 to focus on BPMN, and ignore BPEL. I can use wxPython to design a BPMN
 diagram, but I have to invent my own method of serialising it so that
 I can use it to drive the business process. For good or ill, I decided
 to use xml, as it seems to offer the best chance of keeping up with
 the various specifications as they evolve.

If you mean to use workflow architectures to add value to your
business and accounting software, your priority should be executing
workflows, not editing workflow diagrams (which are a useful but
unnecessary user interface layer over the actual workflow engine);
making your diagrams and definitions compliant with volatile and
unproven specifications should come a distant last.

 I don't know if this is of any interest to anyone, but it was
 therapeutic for me to try to organise my thoughts and get them down on
 paper. I am not expecting any comments, but if anyone has any thoughts
 to toss in, I will read them with interest.


1) There are a number of open-source or affordable workflow engines,
mostly BPEL-compliant and written in Java; they should be more useful
than reinventing the wheel.

2) With a good XML editor you can produce the workflow definitions,
BPEL or otherwise, that your workflow engine needs, and leave the
interactive diagram editor for a phase 2 that might not necessarily
come; text editing might be convenient enough for your users, and for
graphical output something simpler than an editor (e.g a Graphviz
exporter) might be enough.

3) Maybe workflow processing can grow inside your existing accounting
application without the sort of big bang redesign you seem to be
planning; chances are that the needed objects are already in place and
you only need to make workflow more explicit and add appropriate new
features.

Regards,
Lorenzo Gatti
--
http://mail.python.org/mailman/listinfo/python-list

Re: XML-schema 'best practice' question

[Lorenzo Gatti]

On 18 Set, 08:28, Frank Millman [EMAIL PROTECTED] wrote:

 I am thinking of adding a check to see if a document has changed since
 it was last validated, and if not, skip the validation step. However,
 I then do not get the default values filled in.

 I can think of two possible solutions. I just wondered if this is a
 common design issue when it comes to xml and schemas, and if there is
 a 'best practice' to handle it.

 1. Don't use default values - create the document with all values
 filled in.

 2. Use python to check for missing values and fill in the defaults
 when processing the document.

 Or maybe the best practice is to *always* validate a document before
 processing it.

The stated problem rings a lot of premature optimization bells;
performing the validation and default-filling step every time,
unconditionally, is certainly the least crooked approach.

In case you really want to avoid unnecessary schema processing, if you
are willing to use persistent data to check for changes (for example,
by comparing a hash or the full text of the current document with the
one from the last time you performed validation) you can also store
the filled-in document that you computed, either as XML or as
serialized Python data structures.

Regards,
Lorenzo Gatti
--
http://mail.python.org/mailman/listinfo/python-list

Re: 2d graphics - what module to use?

[Lorenzo Gatti]

On 25 Lug, 08:13, Pierre Dagenais [EMAIL PROTECTED] wrote:
 What is the easiest way to draw to a window? I'd like to draw something
   like sine waves from a mathematical equation.
 Newbie to python.

What you are really asking for is what GUI library you should use;
every one allows you to draw freely. What do you need to do besides
drawing sine waves? You should look at your full range of options;
http://wiki.python.org/moin/GuiProgramming is a good starting point.

The easiest way to draw might be with those toolkits that offer
primarily a canvas to draw on rather than composable widgets. For
example, Pyglet (http://pyglet.org/) offers OpenGL contexts with
sensible defaults and unobtrusive automation:

from pyglet import *
from pyglet.gl import *
import math
win = window.Window(width=700, height=700, caption=sine wave demo,
resizable=True)
frequency,phase,amplitude=0.1,0.0,0.9
@win.event
def on_draw():
half_height=win.height*0.5
glClear(GL_COLOR_BUFFER_BIT)
glColor3f(0.9, 1.0, 0.8)
glBegin(GL_LINE_STRIP)
for x in xrange(0,win.width):
y=half_height*(1.0+amplitude*math.sin(x*frequency+phase))
glVertex2f(x,y)
glEnd()
app.run()



Regards,

Lorenzo Gatti
--
http://mail.python.org/mailman/listinfo/python-list

Re: str(bytes) in Python 3.0

[Lorenzo Gatti]

On Apr 12, 5:51 pm, Kay Schluehr [EMAIL PROTECTED] wrote:
 On 12 Apr., 16:29, Carl Banks [EMAIL PROTECTED] wrote:

   And making an utf-8 encoding default is not possible without writing a
   new function?

  I believe the Zen in effect here is, In the face of ambiguity, refuse
  the temptation to guess.  How do you know if the bytes are utf-8
  encoded?

 How many encodings would you define for a Rectangle constructor?

 Making things infinitely configurable is very nice and shows that the
 programmer has worked hard. Sometimes however it suffices to provide a
 mandatory default and some supplementary conversion methods. This
 still won't exhaust all possible cases but provides a reasonable
 coverage.

There is no sensible default because many incompatible encodings are
in common use; programmers need to take responsibility for tracking ot
guessing string encodings according to their needs, in ways that
depend on application architecture, characteristics of users and data,
and various risk and quality trade-offs.

In languages that, like Java, have a default encoding for convenience,
documents are routinely mangled by sloppy programmers who think that
they live in an ASCII or UTF-8 fairy land and that they don't need
tight control of the encoding of all text that enters and leaves the
system.
Ceasing to support this obsolete attitude with lenient APIs is the
only way forward; being forced to learn that encodings are important
is better than, say, discovering unrecoverable data corruption in a
working system.

Regards,
Lorenzo Gatti


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Beginner's assignment question

[Lorenzo Gatti]

On Mar 1, 3:39 pm, Schizoid Man [EMAIL PROTECTED] wrote:
 As in variable assignment, not homework assignment! :)

 I understand the first line but not the second of the following code:

 a, b = 0, 1
 a, b = b, a + b

 In the first line a is assigned 0 and b is assigned 1 simultaneously.

 However what is the sequence of operation in the second statement? I;m
 confused due to the inter-dependence of the variables.

The expressions of the right of the assignment operator are evaluated
before assigning any new values, to the destinations on the left side
of the assignment operator.
So substitutig the old values of a and b the second assignment means

a, b = 0, 0 + 1

Simplifying the Python Reference Manual (6.3 Assignment Statements)
a little :

assignment_stmt ::= target_list =+ expression_list

An assignment statement evaluates the expression list (remember that
this can be a single expression or a comma-separated list, the latter
yielding a tuple) and assigns the single resulting object to each of
the target lists, from left to right.

[...]

WARNING: Although the definition of assignment implies that overlaps
between the left-hand side and the right-hand side are `safe' (for
example a, b = b, a swaps two variables), overlaps within the
collection of assigned-to variables are not safe! For instance, the
following program prints [0, 2]:

x = [0, 1]
i = 0
i, x[i] = 1, 2
print x

Lorenzo Gatti




-- 
http://mail.python.org/mailman/listinfo/python-list