Re: Are the critiques in "All the things I hate about Python" valid?
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: Which one is the best XML-parser?
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: Getting back into PyQt and not loving it.
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: Type hinting of Python is just a toy ?
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: New user's initial thoughts / criticisms of Python
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: anomaly
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: Beginner's assignment question
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
Re: type-checking support in Python?
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: Thoughts on language-level configuration support?
On 31 Mar, 09:19, jfager wrote: > On Mar 31, 2:54 am, David Stanek wrote: > > > On Mon, Mar 30, 2009 at 9:40 AM, jfager 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: 2d graphics - what module to use?
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
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: XML-schema 'best practice' question
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: XML-schema 'best practice' question
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
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: Pyfora, a place for python
On Nov 1, 8:06 am, Saketh 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: Pyfora, a place for python
On Nov 3, 11:37 am, Steven D'Aprano 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: Choosing GUI Module for Python
On Nov 9, 9:01 pm, Simon Hibbs 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: Choosing GUI Module for Python
On Nov 10, 11:08 pm, Simon Hibbs 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
On Nov 11, 9:48 am, Lorenzo Gatti 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: random number including 1 - i.e. [0,1]
On 10 Giu, 06:23, Esmail 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
