Re: Python and Db
[EMAIL PROTECTED] escribió: I would like to use sqlite, But I also wanted a tutorial with the basis of the sql and etc, I never dealed with dbs before For practicing SQL on-line, I'd suggest sqlzoo.net. -- http://mail.python.org/mailman/listinfo/python-list
Re: unit testing
[EMAIL PROTECTED] wrote: I maintain old code... code written a long time ago, before unittest was popular. Getting unittest to work on that is difficult at best. Writing unit tests for lots of old code is not the most funny thing you can imagine... For situations like that, it might be much better to use a tool like TextTest http://texttest.carmen.se/ . -- http://mail.python.org/mailman/listinfo/python-list
Re: python 2.5 and 3gb switch
neil wrote: I see python is not really there for 64 bit yet but most of the people I think you mean Windows is not really there for 64 bit yet. Python works well on real 64 bit operating system. Blender does too I presume. -- http://mail.python.org/mailman/listinfo/python-list
Re: A question on python performance.
Joe Goldthwaite wrote: I didn't know about the getattr function. I tried to search for that type of function but not knowing how to word the search request, I couldn't find it. You should really read through chapter 2 (Built-in Objects) of the library reference. All that stuff is core Python functionality that you should be aware of. Reading chapter 3 (Built-in Types) is also a really good idea. A lot of the rest is good too, but there is really no excuse for not knowing the contents of those chapters. ;) It's just a few pages, and very useful to know. Read them now! -- http://mail.python.org/mailman/listinfo/python-list
Re: Something in the function tutorial confused me.
Lee Fleming wrote:
Hello,
I have a simple question. Say you have the following function:
def f(x, y = []):
...
But this, the code that fixes the list accumulation confounds me:
def f(x, y=None):
if y is None: y = []
...
In other words, what's going on here? How is it that y accumulates
argument values between function calls in the first function, but
doesn't in the second one?
I think the important thing to understand here is the
distinction between names/variables and objects/values
in Python.
While you could interpret C code like this...
void f() {
...
int i = 5;
...
int j = i;
...
}
... as create a place in the namespace of the f function
where you can fit an integer value, and put the value 5
there. Later, create another place in the namespace of f
which is also big enough for an integer. Copy the contents
of the location named 'i', to the location named 'j'.
You would instead interpret this similar Python code...
def f():
...
i = 5
...
j = i
...
... as create an integer object with the value 5. Then
define a name/tag/variable in the namespace of function
f which refers to the integer object with the value 5.
Later, make a new name/tag/variable in the namespace of
f which refers to the same object (happens to be an
integer with the value 5) as i refers to.
The semantics is very different.
If you understand this, Python will seem much less magical,
and you will never ask meaningless questions as whether
Python uses call by reference or call by value.
It's all a matter of understanding that all the juicy bits
in the Python data model is in the actual values or objects.
That's the stuff with type safety, a location in memory,
qualities such as mutability etc. A variable is basically
just a reference to an arbitrary object in a particular
namespace. Assignments semantics is not about copying
data as in C, and it's nothing arbitrarily defined in
classes as in C++. It's all about deciding which object
a name refers to.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python end of file marker similar to perl's __END__
Neil Cerutti wrote: On 2007-08-01, Cameron Laird [EMAIL PROTECTED] wrote: . I want to re-emphasize the triple-quote it tip mentioned earlier in this thread. I think the original questioner will find this quite satisfying, if I understand his situ- ation at all. *I* certainly have source code with embedded junk commented out as multi-line strings. I used to do that, but now that I use doctests so much it's infeasible to comment out arbitrary code that way, since they can't necessarily nest. If you consistently use e.g. ''' for doc strings, you can use to comment out code blocks. I still think it's better to do test-driven programming though. Then you will very rarely have large blocks on non-working code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Where do they tech Python officialy ?
On July 23, NicolasG wrote: I want to be a professional python programmer... unfortunately sometimes to work as a programmer is really hard in this world, every employee requires professional experience and you can't really start as a beginner.. On July 24, NicolasG wrote: Python is what I like, I would love to be more creative with this language and be able to produce things that I can't right now.. Why not try to find a work that you would like ? I don't want to work as a programmer to became one because I'm already a programmer, I just want to work as a programmer .. I'm not sure I understand what you mean by I'm already a programmer if you can't get jobs because you're a beginner. That sounds a bit like I'm a surgeon, except that I haven't done any surgery just yet. I also don't understand the concept on choosing a university depending on whether they use a particular language in their courses. I think it's a good idea with a good academic education, but whether Python is part of that is really a minor issue. The most important part of education for people who are going to work as programmers is advanced mathematics! That's what will teach you logic and systematic problem solving. Learning Python is a very small and easy part in learning to develop software in a professional way. There are no silver bullets. You won't find a language or a university course that will fix things for you. The world (and your job) is full of problems waiting to be solved. Solve them with Python, use your spare time if you're ambitious and don't get the opportunity to use working hours. Use the internet to find ideas and libraries etc. Doing this will make work more fun, if you are talented enough it will make you much more productive, you should be appreciated for the improvements you achieve, and you will build up a portfolio of software and solutions that you can show a prospective employer. If I'm hiring a consultant for a few weeks, prior Python experience might be an issue, but if I employ someone, I don't care whether they already know Python. I expect them to know a few languages well. I assert that they are capable of applying a programming language to solve problems swiftly and intelligently, and I'm pretty sure they pick up Python quickly. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python end of file marker similar to perl's __END__
beginner wrote: Hi All, This is just a very simple question about a python trick. In perl, I can write __END__ in a file and the perl interpreter will ignore everything below that line. This is very handy when testing my program. Does python have something similar? raise SystemExit() exits the program at that point (unless you catch the exception...) import sys;sys.exit(0) is basically another spelling of the same thing. It doesn't mean that the interpreter ignores the rest of the file though, so it will complain about syntax in the whole file. Since I don't usually write linear top-to-bottom scripts in Python, I don't really see the use of splitting a file in an interpreted top and an ignored bottom though. I'd suggest employing a test driven approach to development. Then you don't usually have big chunks of code that you don't want to run. All that's there works (almost)... See e.g. http://powertwenty.com/kpd/downloads/TestDrivenDevelopmentInPython.pdf -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's only one way to do it philosophy isn't good?
Alex Martelli wrote: PL/1 is basically gone, but its legacy of take what you need and leave the rest is unfortunately alive in other languages that are blind to the enormous advantages of simplicity and uniformity. Reminds me of RUP... No wonder Ivar Jacobson gave up and started all over. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python not giving free memory back to the os get's me in real problems ...
[EMAIL PROTECTED] wrote:
Our (python-)macro uses massively nested loops which are unfortunately
necessary. These loops perform complex calculations in this commercial
tool. To give you a quick overview how long this macros runs:
The outer loop takes 5-7 hours for one cycle. Each cycle creates one
outputfile. So we would like to perform 3-5 outer cycles en bloc.
Unfortunately one of our computers (768MB RAM) crashes after just ~10%
of the first cycle with the following error message:
http://img2.freeimagehosting.net/uploads/7157b1dd7e.jpg
while another computer (1GB RAM) crashes after ~10% of the fourth
loop. While the virtual memory on the 1gb machine was full to the
limit when it crashed the memory usage of the 768mb machine looked
this this:
While Python won't return memory to the OS, this is not
the same as a memory leak. When your Python program is
done using some objects, the memory they needed can be
used by other Python objects in the same process. The
process size should never grow bigger than the actually
needed memory at a point in time.
The (not only) Python problem is that the virtual memory
of your process will never shrink, once it has attained
its maximum size. Since the unused parts of its virtual
memory will be paged out to disk, this is probably not
big a problem anyway.
If you have a long running process that you want to
keep slim, it might be worth factoring out the memory
intensive parts to separate processes like this in your
macros:
for x,y,z in outer_loop_sequence:
os.system('python the_real_worker.py %s %s %s' % (x,y,z))
This should contain the big memory usage to short-running
processes. It should not solve your crash problem though.
If your crashes go away if you rig it like this, something
was broken, either in your macro, or in the way the
application uses Python for macros. You won't spend less
memory because you divide the problem to two processes.
To actually solve the problem, you need to look closer at
your algorithms and data structures. Are you using effective
ways of storing data? For instance, I imagine that numarray
or whatever those things are called these days are much,
much more effective at handling a vector of numerical values
than a Python list of e.g. ints. Lists are pretty expensive.
Lists of ints are at least twice as big as efficient integer
arrays. Are you copying data when you should just share
references? Are you hanging on to data longer than you
actually need it?
I don't see why there would be a big difference if you
use Python or e.g. C or C++ to solve this kind of problem.
If you use lots of data, you need to understand the data
structures and use them effectively. With Python you are
get shorter development time and less code to maintain to
solve a certain problem. The price for that is typically
longer execution time, but disregarding small systems that
can't bear the size of the Python runtime, memory should
not be a big problem. Python isn't Java.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
Jarek Zgoda wrote: I am not a hacker, just a software developer, but I'd have no problems in either installing PyGTK on Ubuntu box (sudo apt-get install python-gtk2, but it's installed by default anyway) or on Windows XP machine (double click on installer icon). Simple user is not an idiot either and if she can read English, she wouldn't have hard time too. The rumours on problems installing GUI toolkits are greatly exagerated IMO. It might not be a big deal for your own computer, but if you are distributing software professionally to a bunch of customers, things get more complex. Let's say your customers use RHEL4 for instance. If you would like to use a recent PyGTK, this means that the GTK libs in RHEL4 aren't new enough. Upgrading GTK will force you to upgrade a bunch of other libraries as well. That means that the system will no longer be the vanilla RHEL4 with your additions. Bugs might pop up in other applications on the system than yours, because they assumed other versions of shared objects. You can (perhaps) install the newer versions of the libs in non-standard locations and set LD_LIBRARY_PATH to that location for your program, but that means that things brake fairly easy, and if you for instance have a larger system, where Python scripts relying on this new PyGTK are started from a Python interpreter embedded in some big application, this big application will also see the newer versions of all those shared objects that PyGKT pulled in. Unless you are very careful, other programs that you start up from within your application (maybe it's possible to spawn a new shell from your app with the embedded Python interpreter and start arbitrary applications from there) will also get the non-standard shared objects. If you just install the shared objects the new PyGTK rely on in the standard locations, you have probably removed security patches and bug fixes added to the software by Red Hat from the system. Any application might cease to work, and the customer might have problem getting support from Red Hat on the system. You might end up with a lot more support and maintenance work than intended, or get very unhappy customers. Now imagine that you have half a dozen other platforms besides RHEL4 on x86_64 that you need to support... This is a problem you need to deal with if you develop software for Unix. It's not impossible to solve all these problems, but there is certainly a cost in this. If you handle it well, there is a cost in testing and adapting the systems. If you don't handle it well, there might be a big cost in handling emergencies and dealing with unhappy customers or users. -- http://mail.python.org/mailman/listinfo/python-list
Fast and capable XML parser?
I'm looking for some library to parse XML code much faster than the libs built into Python 2.4 (I'm stuck with 2.4 for quite a while) and I also need XML Schema validation, and would appreciate support for e.g. XPath and XInclude. I also want an API which is more Pythonic than e.g. a thin wrapper over a C or C++ API. It should be available on at least Linux, Solaris and AIX. Some uses involve parsing lots of (often small) XML files at reasonable speed, i.e. several hundred files per second. That means that we can't use anything like an os.system call to xmllint for XML Schema validation--it gets too slow. I also suspect that the standard Python libs (in Python 2.4 at least) are slower than we'd like them to be. (Not that it matters if they don't support XML Schema validation.) Any suggestions? -- http://mail.python.org/mailman/listinfo/python-list
Re: Fast and capable XML parser?
Larry Bates wrote: I don't know if it meets ALL of your requirements but this might help: http://www.reportlab.org/pyrxp.html AFAIK, there is no XML Schema support in PyRXP. This is really bad enough. GPL is not an option for us, and a commercial licence is less good than e.g. MIT or LGPL. (Partly due to the cost, but also because it causes much more work for me.) Besides, I'm a bit suspicious concerning the lack of benchmarks for the Unicode version... It seems to me that lxml is better in all aspects. -- http://mail.python.org/mailman/listinfo/python-list
Re: Random passwords generation (Python vs Perl) =)
NoName wrote:
Perl:
@char=(A..Z,a..z,0..9);
do{print join(,@char[map{rand @char}(1..8)])}while();
If you generate passwords like that to normal computer
users, you'll end up with a lot of my password doesn't
work tickets. You should skip the symbols that are
easy to mistake for each other.
Skip at least Il1 and 0O. On the other hand, you could
probably use other characters besides letters and digits
to make the passwords stronger. Which ones to use is
unfortunately platform dependent.
--
http://mail.python.org/mailman/listinfo/python-list
Re: OODB vs RDBMS
Thomas Guettler wrote: Hi, most of the time I use ZODB/Durus to store my data. I like it, but I know that it has some weaknesses: - only accesible from python - I need to code your indexes for fast searching yourself. There are other features of relational database systems that I find much more relevant than those, but then I don't know what your use case is. For high performance, mission critical, multi-user database systems, where many simultaneous users actually do fine grained data manipulation, I don't think there is any competition. Also, I don't know any other solution that lets you do serious tuning without code changes. Even if the application is the same, data size and usage patterns might lead to vastly different performance. Being able to speed up some operation on the expense of some other operations might be just the right thing for a certain installation at a certain time. This can be more or less automatic, depending on your brand and version of RDBMS. For a non-critical, single-user system without huge amounts of data in a structure that fits the relational model, it might not be worth the effort. I think about using a RDBMS for the next project. What I don't like about RDBMS: If you need a list of values you need to create a new table. Example: If you want to store several email addresses of one customer, you need to create a new table. I think this is a tiny thing when you look at the big picture. I don't know a lot about the PostgreSQL extensions, but the way things work in relational database has proven to work very well for quite some time. Obviously, OODBMS's haven't made any huge impact, despite two decades of efforts. The impedance mismatch between OO programming and relational databases is annoying, but it's something we have to (and can) deal with. Since the namespace if tablenames is flat, you soon have so many tables, that it is hard to browse them. The tablename namespace is not flat in SQL. Where did you get this from? Although not implemented in every RDBMS, the SQL standard has the concept of a schema, and every table should belong to a schema. For instance Oracle lacks schemata, but more or less makes up for it by through the way it implements users. (Tables are owned by users.) There's just this two level structure though, no abitrary hierarchy. Postgres has extensions which allows you to store arrays in a column. Is this supported by the python binding? Are there other databases which support this? I don't know about the first question, but regarding the second, none of the popular ones do as far as I know. PostrgeSQL is a fine RDBMS though. By the way, a database is a collection of data, not some software. Are there OR-mappers (object relational mappers) which support lists in a column? I think they do, but having a separate class for the email addresses (if we continue with your example above) has its advantages too. If the customer has several email addresses (and you feel a desire to keep track of that) they are probably different in some ways. It's e.g. likely that you should use one particular address as recipient when you send mail, not just one at random, or all of them. You might also realize than not only customers, but also other entities, such as employees, sub-contractors and authorities have email addresses. Actually, while you might get more tables due to the first normal form, your tables might well get leaner, the total amount of columns smaller, and your over-all datamodel more coherent. How is the unicode support of the python bindings to RDBMSs? I don't want to convert the results of a query to unicode myself. Can you insert unicode strings into a SELECT statement? As far as I remember, all the bindings I tried returned unicode objects from varchar and char fields, and always accepted them as parameters for CHAR/VARCHAR fields. Remember to always pass parameters properly. I.e. use e.g. cur.execute(SELECT * FROM T WHERE C=?, col_value) rather than something like cur.execute(SELECT * FROM T WHERE C=+col_value). The former will prevent SQL injection attacks, remove the need to worry about quoting and escaping, and also make performance better in the major systems. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is python for me?
I think Python is for you. lennart wrote: Can you define 'large'? Is that large in code, or large in database? I don't know which database is supported. If its a external db, like MySql, the query is performed through the software of MySql, am I right? If I'm correct, the 'slowness' comes from the amount of code in python itself, not from the database. I'm afraid dakman's comment wasn't really very helpful. Size is not a problem in itself. Ok, if the code modules are very large, you will have a larger startup time, but this is probably even worse in lower level languages such as C/C++. The python byte code works at a higher level of abstraction than machine code, so the byte code files are much more compact than corresponding executable binaries from e.g. C/C++/Delphi. The Python programming language, with its classes, modules, packages etc is in my experience much better for writing large applications without causing a mess than e.g. C++. It's much easier to make a mess with C/C++'s #include than with Python's import. The lack of static typing means that some problems that the compiler/linker would find in e.g. C++ development won't turn up until you test your code in Python, but you'll get to testing much faster with Python, and if you don't test well, you'll fail with any larger development project however clever your compiler and linker is. Due to Python's very dynamic nature, there are a lot of operations that will be much slower than in e.g. C or C++. For instance, if you write a = b + c in C, the compiler knows at compile time what types a, b and c are, and if they for example are ints, the addition will be translated into a few very simple and quick machine code instructions. In Python, the types typically won't be know until runtime. This means that the objects need to be inspected during execution to figure out what + means for these kinds of objects. Python also handles memory allocation etc. The consequence of this is that some kinds of programs that do millions of trivial things, such as cryptography applications where there are a lot of repeated multiplications and additions, would be much, much slower in pure Python than in pure C. This doesn't mean that Python is bad for a large group of applications. It means that for a large group of applications, there are some parts (for instance computationally intensive or e.g. interfacing with some kind of devices or third party products) that should be handled by extensions written in e.g. C. Whatever you plan to do, it's likely that the extensions you need already exists. There are such extensions for databases, networking, maths, cryptography, XML parsing, etc etc. I'm a programmer working with C, C++, Python, SQL etc, and despite 10 years of Python coding I never actually needed to code any C extension myself yet. It's very likely that you'll get away using 100% pure Python too. Note that large parts of your programs will be C code, but C code you didn't have to write yourself, and as far as your programming is concerned it could as well have been Python, it's just that things will run faster than if it had been pure Python... Have fun! -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
John Salerno wrote:
personally, i don't mind the colon and see no need to lose it, but if we
are talking in the realm of aesthetics, it actually seems like it would
be cleaner if it weren't there...sure, at first everyone who is used to
it might feel like something is missing, or the line is hanging open,
but overall the less characters, the better, right? isn't that why the
braces are gone?
Which is the better writing style for text intended for human readers?
I have some things to say:
Seagulls belong in the sky.
Colon fits in the text.
I have some things to say
{
Seagulls belong in the text.
Colon fits in the belly.
}
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
sturlamolden wrote: There is a whole generation of computer users out there scared stiff of using the keyboard. Soon, computers will not have a keyboard at all. The trend is perhaps more pronounced among managers not writing code themselves, but taking decisions about which tools to use. Is it just me, or does someone else feel that this is like using magnetic letters on a refrigerator door instead of a pen and paper. My two year old son thinks those magnetic letters are fun, but then he can't write at all. My seven year old has certainly switched to pen and paper (or computer) for 99% of his writing. Sure, they have their use--it might be more effective to write TENNIS with colorful letters across the fridge door in some situation, but most of the time, pen and paper is much more useful. You never run out of letters, and it's easy to draw lines or arrows, complement the text with a little picture etc. The cost for learning the skill to write readable letters is well compensated for... We recently released a toolkit for interfacing our systems with legacy systems, and very soon, people started using it in way we had never expected. I suppose that could be possible with a visual tool too, but it seems to me that those tools are typically fairly limited, just as computer based role-playing games are much more limited than the ones played around a table with a good flesh-and-blood game master who can respond to any idea you come up with at the spur of the moment. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there a commas-in-between idiom?
Ernesto García García wrote: list = [1,2,3,4,5,6] Just a nit-pick: It's considered an anti-idiom to hide builtins just as list by using it as a name for a variable. list=[1,2,3,4,5] tuple = (1,2,3,4,5) if list == list(tuple): print equal ... Traceback (most recent call last): File stdin, line 1, in ? TypeError: 'list' object is not callable #ouch! ... l=list del list if l == list(tuple): print equal ... equal if tuple(l)==tuple: print equal ... Traceback (most recent call last): File stdin, line 1, in ? TypeError: 'tuple' object is not callable t=tuple del tuple if tuple(l)==t: print equal ... equal -- http://mail.python.org/mailman/listinfo/python-list
Re: Python in sci/tech applications
robert wrote: When one follows .. http://docs.python.org/inst/tweak-flags.html#SECTION000622000 http://www.zope.org/Members/als/tips/win32_mingw_modules ..this seems only to cover the immediate python dll issues. What happens with the C runtime libraries? You'll bind 2 different C-RTLs (DLLs) etc.? And what happens for example with heap objects created with one C-RTL and deleted/free'd with the other? As far as I understand, there should be only one runtime library involved. MinGW relies on the Microsoft runtime. It seems some people have had problems using MSVCRT71 with MinGW, but I'm sure that e.g. the Enthought people can explain those issues, since they bundle MinGW in their Python 2.4 distribution. -- http://mail.python.org/mailman/listinfo/python-list
Re: is mod_python borked?
walterbyrd wrote: *sigh* maybe I'll just use php until the web-hosters catch up, if they ever do. The first general availability release of Apache 2.0 (2.0.35) appeared in April 2002. There are many ISPs. Perhaps you should limit yourself to those who lag behind less than four years? I can understand that it isn't always so easy. If you're approached by a client who has a web site up and running on some backwards ISP, it might not be so easy to get them to move their site or place parts of it on a separate server. Hopefully, virtual server prices will continue to drop and become more of a normal choice fairly soon. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: wxPython 2.7.1.3
robert wrote: John Salerno wrote: You want Python 2.3 for Windows? yes. (I know no other big libs which already stops support of py2.3-win) The general policy for Python is to support version 2.n-1 when 2.n is the current version, but not older versions than that. There was recently a 2.3.6 release with a security fix, but this is really an exception. Since Python 2.5 was released, Python 2.4 is the oldest supported Python version. I was about to give a reference to the appropriate PEP, but right now I can't for my life figure out where I read this... I'm just a bit more brain dead than usual today, due to some virus. -- http://mail.python.org/mailman/listinfo/python-list
Re: Event driven server that wastes CPU when threaded doesn't
Snor wrote: I'm attempting to create a lobby game server for a multiplayer game, and have hit a problem early on with the server design. I am stuck between using a threaded server, and using an event driven server. I've been told time and time again that I should use an event driven server design (that is, use twisted). [snip] Is the only solution to use a threaded server to let my clients make their requests and receive a response in the fastest possible time? You got a lot of long-winded replies, but the short reply is that Twisted has packaged solutions for this. See http://twistedmatrix.com/projects/core/enterprise Twisted provides an interface to any Python DB-API 2.0 compliant database through an asynchronous interface which allows database connections to be used, and multiplexed by multiple threads, while still remaining thread-safe for use with Twisted's event-based main loop. Twisted Enterprise provides these services by leveraging Twisted Internet's utilities for managing thread pools and asynchronous programming. -- http://mail.python.org/mailman/listinfo/python-list
Re: print dos format file into unix format
Tim Roberts wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Suppose I have a dos format text file. The following python code will
print ^M at the end. I'm wondering how to print it in unix format.
fh = open(options.filename)
for line in fh.readlines()
print line,
Are you running this on Unix or on DOS?
On Unix, you can do:
for line in open(options.filename).readlines():
print line.rstrip()
Perhaps quicker is:
sys.stdout.write( open(options.filename).read().replace('\r\n','\n') )
There are more differences between text files than that.
I don't know any unix systems that uses CP 437 etc. I'd
convert the text to unicode through .decode('cp437') etc,
and then print that. If things aren't set up so than
unicode object print correctly, use
.decode('cp437').encode('utf8') etc to get it to an
appropriate encoding.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Restricting import file lookup for pyd, dll, ...
Bernard Lebel wrote: Hi, That's because I'm using Python through another application, via the pywin32 extensions. When that other application starts, it performs several thousands of file requests (we're talking 4,500, roughly) in the Python installation, locations where there are Python files, and in some other locations that don't make sense. This adds considerable time to the startup time of the application, we're talking between 2 and 9 seconds. Sounds like a broken (networked?) file system. The only time I've had that kind of problems with python startup is when I've had really slow anti-virus programs that scanned all the files I opened. But then it wasn't file requests that mattered, but actually opening them... It still wasn't anywhere near 9 seconds though... -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.5 ; Effbot console ; thank ; pb release.
Méta-MCI wrote: Hi! (***sorry for my approximative english***) That's ok. Quite amusing to read that you were repaired. A few months ago, I needed a console, under Windows. After several research, I selected the console of EffBot. Thank you very much, Fredrik Lundh, for this small tool, quite practical and which repaired me well. Then, Python 2.5 arrived. That doesn't mean it's clever to use 2.5 right now... There's plenty of code which isn't adapted to 2.5 yet. Personally, I use 2.4 at work (although sometimes I still need to be 2.2 compatible) and at home I have both 2.4 and 2.5 installed. Most of the time I work with 2.4 since I use packages which don't support 2.5 yet (or at least the last time I checked). -- http://mail.python.org/mailman/listinfo/python-list
Re: python GUIs comparison (want)
David Boddie wrote: You're forgetting that Qt isn't just a widget toolkit. I suspect that the non-GUI parts are (just like in Wx) C++ stuff which is more or less equivalent with things that are either Python builtins or parts of Python's standard library. Besides, getting those proprietary dependencies even further down into the code than the GUI is not a plus in my book. Last time I looked, Qt code wasn't even pure C++ but needed some preprocessing like embedded SQL. Yet another programming language in other words. I suppose I can ignore that from Python, but it still smells... -- http://mail.python.org/mailman/listinfo/python-list
Re: Ok. This IS homework ...
Frederic Rentsch wrote: Once upon a time programmers did things like this: BEGIN | --|- | | | | catch input| | | | | input type valid? - prompt for correct input --| | + | |input too large? + --- prompt for new input -- | - | add to running total | | | status report | | -- - running total = max? + report done | END It was called a flow chart. Flow charts could be translated directly into machine code written in assembly languages which had labels, tests and jumps as the only flow-control constructs. When structured programming introduced for and while loops they internalized labeling and jumping. That was a great convenience. Flow-charting became rather obsolete because the one-to-one correspondence between flow chart and code was largely lost. As long as you only draw your loops to the right (or left, just be consistent) and make sure you don't cross any lines, you're doing structured programming. (I think...) E.g. | v blah1+ | ^ v | if xx--foo | ||| vv| bar baz | ||| +---+| | | v | maybe+ | v -- http://mail.python.org/mailman/listinfo/python-list
Re: Book about database application development?
Wolfgang Keller wrote: does anyone know of a good book that about development of database applications? Scott Ambler's Agile Database Techniques Regardless of whether you'll actually use a full MVC framework or not, I suggest that you write model classes that are fully decoupled from the UI. Work in a test-driven fashion, writing tests first and just coding until the test goes through, and then write the next test. See e.g. Kent Beck's Test-Driven Development. If you use an SQL database below some ORM, you can use SQLite with an in-memory database :memory: for your functional test. Fast and simple. I'd make the GUI as thin as possible, since GUI code it typically more complicated to test automatically. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to write Smart Python programs?
Raj wrote: Hi, We just executed a project with Python using TG. The feedback was to use more python like programming rather than C style code executed in Python. The feedback is from a Python purist and for some reasons we cannot solicity his help. So we'd like to do is to scrub through the codebase and identify places where the codebase needs improvement, both from styling as well as design. Is there any website that can provide me with advanced tips rather than just tutorials coz thats not of much help. Python Cookbook. There's both a web site and a book version. -- http://mail.python.org/mailman/listinfo/python-list
Re: What value should be passed to make a function use the default argument value?
Antoon Pardon wrote: Well maybe he didn't intend that, but how is the reader of the documentation to know that? The reader can only go by how things are documented. If those are not entirely consistent with the intend of the programmer, that is not the readers fault. I don't think I ever assumed that it was right to call functions with keyword arguments if they weren't defined with keyword parameters, but when I read 4.7.2 of the tutorial, I can see that it's stated through an example that this is a correct thing to do. I suppose the tutorial (and maybe the language reference) should be corrected if this isn't supposed to be guaranteed behavior. It seems like a bad idea to have different calling semantics depending on whether a callable is implemented in C or Python. Even if non-keyword parameters in Python implemented callables, *can* be called with keyword arguments, it seems like a bad idea to encourage that use. Perhaps it would be a good idea to deprecate that possibility and remove it in Python 3.0? I think it's better to force some calls into using f(*a, **kw) instead of f(**kw) if it decreases the risk that reimplementing functions in C in an API will break client code. Sure, it's simple to make a Python wrapper, but if you're after raw speed, you might not want to do that. The main downside to removing the possibility of calling non keyword parameters with keyword arguments might be that using keyword arguments could fill a documentation purpose in the code, e.g. x=get(host=arg[0], port=arg[1], path=arg[2]) would be clearer than x=get(arg[0], arg[1], arg[2]). Of course, host, port, path = arg; x=get(host, port, path) is even better (if s/;/\n) but in some cases, it's better to be able to inline things. -- http://mail.python.org/mailman/listinfo/python-list
Re: Where is Python in the scheme of things?
Bruno Desthuilliers wrote: gord wrote: As a complete novice in the study of Python, I am asking myself where this language is superior or better suited than others. For example, all I see in the tutorials are lots of examples of list processing, arithmetic calculations - all in a DOS-like environment. s/DOS-like/command line/ The command line interface is widely used on unix-like systems, and is very handy for a lot of things. In general, I think using the keyboard more and the mouse less is typically a win, both in power of expression and in speed. I don't think it's a coincidence that most of us use the keyboard and plain text to communicate in this forum. Writing text by pointing, dragging and clicking instead of by typing, would probably slow us down quite a bit. I feel much more productive in bash than in most Windows apps. (I still like to have several terminal windows though.) My seven year old son did play a bit with magnetic letters we have on the fridge door in the kitchen (when he was small, he'd say now) but he's dropped that entirely in favor of pencil and paper. His two year old brother can play with that fridge-based GUI... When we reach a certain level of expertize, we often find it easier to pick the things we put together from our memory and imagination, rather than from some kind of menu in our field of vision. Ok, the keyboard is a kind of menu too, but that's not the point. The important thing is that text is an extremely powerful way of conveying information that we've used for thousands of years. It's far more sophisticated than pointing at visible objects. Also, a tool like Python isn't bound to keyboards, like VB is bound to the Windows GUI. Almost everything, from network traffic, to GUI interaction, to hardware manipulations can be effectively translated to and from text formats. Not that Python can't handle binary data, but going via textual representations usually makes testing, debugging and understanding much easier. I'd suggest that the OP look at the Wikipedia page in Unix Philosophy. Read about Gancarz tenets, and replace shell scripts with Python. (Of course, Python offers more elaborate communication than pipes.) I'd also the link to Joel Spolsky's Biculturalism article, and read that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Where is Python in the scheme of things?
gord wrote: As a complete novice in the study of Python, I am asking myself where this language is superior or better suited than others. For example, all I see in the tutorials are lots of examples of list processing, arithmetic calculations - all in a DOS-like environment. Python runs on almost everything from mobile phones to mainframes, so it can't really provide one particular GUI or one particular development environment. There are a number of free and commercial IDEs and GUI tool kits, but I don't know if there is anything that gives you such a low entry threshold for GUI development as VB or Delphi. I never painted GUIs in Python, I coded them in a plain editor, but you get used to that pretty soon, and you'll feel more in control, and the more complex your GUIs get, the more you can gain from having that control. In my experience it's much easier to reuse GUI code in Python than in VB etc. If you have made a few windows, and written your code in an intelligent way, making additional and similar windows can be very quick, and maintaining their uniform look, feel and behavior can be easier. Anyway, if GUI development is what you want, you need to look at a particular GUI toolkit. Depending on what you are after, you might want to use Dabo, WxPython, PyGame or some other toolkit. I know, it's much easier to choose if you only have one choice, but this is the way things work in free software: no one tries to lock you in, so there is a flora of different tools suited for different needs. This makes it a bit harder to get started: You need to take more decisions--but you'll hopefully end up with something which is a better fit, where you don't need to work around the limits of the tool, or limit your world view to idioms supported a one-size-fits-all tool. What is particularly disappointing is the absence of a Windows IDE, components and an event driven paradigm. How does Python stand relative to the big 3, namely Visual C++, Visual Basic and Delphi? I realize that these programming packages are quite expensive now while Python is free (at least for the package I am using - ActivePython). It's more like Java than like any of these three really. It's not specifically geared towards building GUI apps (like two of the above) and it It's a more modern language than the above. It started from scratch around 1990, as opposed to BASIC, C++ and Pascal. Both C and Pascal popped up around 1970, and BASIC is older than that. While they have developed a lot, the modern incarnations still carry a historical baggage. Python's syntax has been based on research and 20 more years of experiences in the problems that your other languages are stuck with. Python's major inspiration was ABC, a programming language developed as a research project with the aim of being easy and pedagogical to use. On the other hand it's more like C++ than like Java in the sense that it supports object-oriented programming, but it doesn't enforce it. C++ and Python (as well as Delphi's Object Pascal I guess) can be described as multi-paradigm languages. Please discuss where Python shines. Until 1996, it was my firm belief that there were only two kind of tools in the software development world. - Some tools (e.g. VB and Access) makes it easy to get started and make small thing, but when the systems grow and the requirements get tougher, your problems start to grow exponentially. You hit a wall it seems. At least it starts to feel like a tough uphill battle. - Other tools are more difficult to learn (e.g. Unix), but once you master them, they grow on you, and you feel that you can take on harder problems without hitting that wall. It was a revelation to bump into Python in 1996. Suddenly, there was something which was easy to get started with, but still just felt better and better the longer I used it. That's the killer feature in my mind. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python to use a non open source bug tracker?
Fredrik Lundh wrote: you're not on the infrastructure list, I hear. I tried to figure out where that list is, so I could have a look at the archives, but I didn't find it in the (for me) obvious places. Could someone please provide a link to the archives for this mailing list, or aren't there any public archives of them? Only for PSF members? python.org could still need a few more roundup volunteers, but it's not like nobody's prepared to contribute manhours. don't underestimate the community. So, how many have offered to help? Is this information available in some public repository? I don't know how much work it actually takes to maintain a roundup installation for the Python project, but I know that in general, not all people manage to follow through on everything they commit to do, even if they have good intentions, so I'd be a bit worried to move to roundup if only two or three people had offered to run it, even if that might nominally be enough. Of course, this depends on who those people would be... Ten seems like a bit too many though. I somehow suspect that less work would get done in a group of ten than in a group of six people... It seems to me that an obvious advantage with either Roundup or Trac, is that if the Python project used it, the Python project would have a significant impact on how this product developed. Even if the Jira people seem eager to please us, I'm pretty convinced that it will be easier to get Roundup or Trac improved to fit our particular needs. That's valuable in two ways: 1) The Python project would get a bug tracker which is developed with the needs of the Python project as a prime concern. (Being the major customer of a product has benefits. Jira on the other hand, might get more and more integrated with other Java stuff that we don't really care about. 2) We'd help making a good Python product even better, and probably more widely used, thus spreading the use of Python even further. -- http://mail.python.org/mailman/listinfo/python-list
Re: a different question: can you earn a living with *just* python?
John Salerno wrote: It's a nice thought that a person can earn a living programming with Python, which is fun enough to use just for its own sake. But for someone like me (i.e. no programming experience) it's always a little disheartening to see that most (if not all) job descriptions that ask for Python still require some C/C++ or other language knowledge. I suppose this isn't an issue if you studied CS in college, because you would have been exposed to many languages. But what if you are an expert Python program and have zero clue about other languages? Can you still earn a living that way, or do most/all companies require multiple language proficiency? Being a programmer isn't just a matter of knowing one or several programming languages, just as being an author isn't merely a matter of knowing writing and a language. I've been involved in one development project where COBOL programmers were handed detailed design descriptions written in pseudo code. The SQL code used to access the database was complete in the spec. These programmer just needed to know how to translate pseudo code to COBOL one module at a time, and of course, they needed to know how to operate the IDE and run tests etc. In all other projects I've worked in, programmers were also involved in design etc, often in the whole loop from requirements gathering to deployment and maintenance of the product. Knowing a programming language is a tiny part of that. Knowing two or three languages is still a tiny part of the set of skill and abilities required. I'm talking about communication skills, ability to extract relevant information from people who know a problem domain, but lack system design skills etc, strong analytical abilities, design skills, problem solving skills, the general ability to get things done in a reliable and timely manner etc etc. I'd be reluctant to employ someone without at least a B.Sc. in some relevant subject unless they had a proven track record. -- http://mail.python.org/mailman/listinfo/python-list
Re: A critique of cgi.escape
Jon Ribbens wrote: In article [EMAIL PROTECTED], Fredrik Lundh wrote: maybe you haven't done software long enough to understand that software works better if you use it the way it was intended to be used, but that's no excuse for being stupid. So what's your excuse? If you don't like Fredrik's manner I suggest that you simply don't use any code he's written. Good luck using Python! :^) Don't bite the hand that feeds you... -- http://mail.python.org/mailman/listinfo/python-list
Re: Talking to marketing people about Python
Roy Smith wrote: I'm working on a product which for a long time has had a Perl binding for our remote access API. A while ago, I wrote a Python binding on my own, chatted it up a bit internally, and recently had a (large) customer enquire about getting access to it. I asked for permission to distribute the Python binding, and after a few weeks of winding its way through the corporate bureaucracy I got an email from a product manager who wants to meet with me to understand the market demand for Python API before we commercialize it. Can anybody suggest some good material I can give to him which will help explain what Python is and why it's a good thing, in a way that a marketing/product management person will understand? (I don't expect you to answer the questions below to us, they might well be business secrets, it's just things you might want to think about.) It's certainly reasonable to ask those questions. Every item on your product list has a cost (even if the development is done already), in terms of maintenance, administration, making the product portfolio less easy to digest etc. Also, if you've read Brook's Mythical Man Month, you know that it's a big difference between fully working code and shippable product. Documentation, packaging etc costs plenty. You need a reasonable demand to pay for these costs. Whether the bindings have their own price in your price list, or are bundled and seem to increase the overall value and lead to more sales of the big product is a different matter. I guess it might be good if you can figure out what he's really after... Is this just business are usual, or have they been burnt by something else? Is the Perl binding seen as a profit maker, or is it just a cost? If there is a customer who wants it, that's certainly a relevant start, particularly if they are willing to pay for it... It's difficult to say so much without knowing more about your market. If you plan to sell your system to Google, it might well be a big plus! I'm not involved in the Perl community, so maybe I'm misinformed, but it seems to me that Perl is a language in decline. I quote the perl6 web site: The community brainstorming process finished August 1, 2000, resulting in 361 RFCs. There is no release date set yet, more than six years later. I suspect that most of those who want a better Perl than Perl 5, have changed to Ruby already, even if the Perl 5 development has continued from 5.6.0 to 5.8.8. After all, there are reasons why the Perl community wanted to change Perl so drastically, and there are also reasons why it wasn't deemed reasonable to change the language more gradually. Compare this with Python, where we progressively get new features in each version, and the purpose of the next major rewrite is more about trimming off annoying warts in a controlled way. Many of the Perl 6 features the Perl community are still waiting for have been in Python for a long, long time. Others have been smoothly incorporated into the last years minor revisions of Python while Perl is standing still. I suspect that most of those with a lot of Perl code, will continue to use it, but for new development, Perl might not be a preferred solution. Providing a Python option gives you another strength here. Python can do what Perl does, but it scales better, it's easier to maintain, and while it's mature and widely spread, it's very actively developed, backed by giants such as Google, and still growing in popularity. Just look at Python and Perl books at Amazon.com. For Perl, 4 of the 12 books in the first page (listing by relevance) are written in 2005-2006. For Python, it's 8 of 12. Guess where the action is! In other words, Python has to a significant taken over the role Perl had. Perl once succeeded because it was in the right place at the right time, but it's failed in the long ruin because it can't handle the complexity of real world applications when they scale. It gets too messy. Python can. I'm certainly not the only old Perl programmer who jumped ship as soon as I met Python and never looked back. The only competitor to Python that I see today when it comes to delivering functionality for general application development at a very high productivity, is Ruby. Python is much more mature and widely used than Ruby. As I see it, Python's multi-paradigm approach is also more useful than Ruby's pure OO mindset. Google is using Python a lot, and investing money in the development of the language and main implementation. Microsoft is investing in its .NET port IronPython, which was just released inversion 1.0. There are other interesting projects, such as the E.U. funded PyPy project, which might open up new doors. -- http://mail.python.org/mailman/listinfo/python-list
Re: Leave the putdowns in the Perl community, the Python world does not need them
[EMAIL PROTECTED] wrote: Steve makes a good point. Fredrik is one of the most important contributors of Python code, tools, etc and as far as I am concerned, that is so important that it gives him the right to be cranky from tiem to time. Since February last year I've had the opportunity to write most of my code in Python, in a very cool company with lots of bright people. When I asked why they started to use Python here, it turned out that a course held by a certain Fredrik Lundh was something of a turning point... It seems that made them see the light. I'm very thankful for that! (As I understood it, the reason for the Python course, was actually that some third party product used Python. I'm pretty sure we don't use that product any longer, but we certainly kept Python.) Today, we actually hold Python courses ourselves, for customers from all over the globe (mainly big airlines). In my opinion, the most important aspect of contributors to a forum like c.l.py is signal/noise ratio. I much prefer competent but rude remarks to friendly ignorance which just wastes my time. Calling someone stupid might not be the most pedagogic or diplomatic approach when an ignorant person fails to realize his limitations, but it's understandable. Being so stupid is also understandable. It's easy for reasonably smart people to find (perceived) flaws in the reasonings of others, but with age I've learned that I can usually learn a lot from others even if I feel that I can crush their arguments. There is usually something more behind their resistance to my ideas, and if I manage to figure out what the real problem is, I can often avoid getting into trouble... The best discussions are the ones that make me change my mind about something. Then I've grown. That's difficult if I let my ego be in charge. I guess you either need to be involved some fairly big, real world development project where APIs are used by many people outside the project, or alternatively read (and understand) any serious book on software engineering, to really realize that changing public APIs *is* a major issue. If you use Python more as a toy, and just write snippets, it's difficult to imagine the cost of small API changes for the big organizations who use the same APIs. -- http://mail.python.org/mailman/listinfo/python-list
Re: does anybody earn a living programming in python?
Stuart Bishop wrote: My personal experience is that there is a shortage of good Python programmers. In Melbourne, Australia for example there is a continual need for about 2 more - one Python shop there just hires clueful developers and makes their first task 'learn Python'. We generally have a few positions open at any particular moment too - http://www.ubuntu.com/employment (but we are picky - it is hard to hand hold when the hand is several time zones away). It's much easier to learn Python than it is to learn good general software development skills, so I think that's a good approach. My room mate here at work didn't know any Python programming before he came, but he was fluent pretty soon. Like me, he's starting to make stupid mistakes in C++, such as forgetting trailing ; after each line. :) We are fairly picky here when we employ people, but while we appreciate that they already know Python, we don't see it as a major issue. It's quick and easy to learn. Mentioning Python in job ads is maybe more a way to attract people who take clever initiatives. On a slight tangent, one of the appealing things about Python (and other 'non-mainstream' languages) in the past has been that the people who knew Python also tended to be the people you wanted to employ - they generally had experience in other languages but moved onto something they perceived as 'better' either at work or home. It indicated a level of care and pride about their profession rather than someone who just treated cutting code as a day job. That depends if you are an employer who wants to lead a team of skilled professionals or if you prefer a herd of sheep that you lead around with a stick. So, as someone who want to be employed, you influence what kinds of job you tend to get with what you learn. Do you prefer a job where you are just expected to do exactly what you are told, or are you eager to take initiatives and change your work place to something better? -- http://mail.python.org/mailman/listinfo/python-list
Re: does anybody earn a living programming in python?
walterbyrd wrote: If so, I doubt there are many. Depends on what you compare with. I'm pretty sure there are thousands of people working as Python programmers, and many more using it as a smaller tool in their work. Of course this is small compared to Java or C++. In the US, it seems a lot of companies in the animation industry, such as Dreamworks and Industrial Light Magic regularly look for Python skilled people. In my vicinity, Göteborg with surroundings in Sweden, I know of several places where people work with Python. I'm sure the amount of C++, Java or VB programmers are magnitudes bigger, but there are also a lot more people eager to fill those positions. My employer, Jeppesen Systems AB, has dozens of Python programmers, and we train our customers to use Python for customization and integration etc. So, we know that a significant number of the world's largest air lines and some significant railroad companies have trained Python developers (we trained them) and use Python for customizing our products, and for e.g. integration with legacy systems. Just a few hundred meters from us, there is AB Strakt, which was more or less a pure Python company last time I looked. The pharmaceuticals company Astra Zeneca uses Python in some of their research, and I've seen people from other companies in the vicinity asking Python questions on various mailing lists etc. Python is certainly used in Chalmers, the technical University here. This is in a region with way less than one million inhabitants. I'm pretty sure we have 1 Python programmer per 10 000 inhabitants. Let's say that's above Swedish average. I still think there is at least 300 Python programmers among the 9 million people here. Although we're just 0.15% of the worlds populations, my experience is that we make and use something like 1% of the high tech stuff in the world, so my standard extrapolation technique would yield 3 python programmers globally. I wonder why that is? Well, it takes time to change things, and many decision makers aren't very well informed. Maybe they are more likely to choose something which is marketed and supported by some large commercial entity. The rise of Linux and open source is changing that, but it takes time. If you look at languages introduced the last 15 years or so, I think Python is one of the more popular. The languages I can think of right now, that have appeared since 1990 or so, and received a significant mindshare are C#, Java, JavaScript, Perl, PHP, Python, Ruby and Visual Basic. Of these, C#, Java and Visual Basic have serious commercial backing which promoted them heavily for certain applications, and provided a lot of convenient tools. Those languages are also closely modeled syntactically on a predecessor, C++ for Java, Java for C#, and VB is just a new BASIC dialect, which makes the transition to start using them easier, at the expense of retaining stupid aspect of old languages that we'd rather get rid of. I.e. getting started seems more important than getting it right. That should help in the short run, but be less good in the long run. Perl and CGI was the best available tool when the big web boost happened, and PHP has taken over that role. They are very popular in a particular niche (but Perl seems to be in decline) but like JavaScript, they are niche tools. Ruby is the language most like Python I guess, and it's nowhere near Python in popularity, even if RoR has given it a boost. As people have noticed, Python is often used together with C or C++, and it seems to me that Java programmer might prefer Ruby to Python. This might be because Java and Ruby are both purely OO, and might fit people who think OO is everything, while Python and C++ are multi paradigm programmers that share a different mindset. So, to summarize, Python is probably the most popular general purpose programming language invented since 1990 which didn't have multi billion dollar backing. Now, it has more backing, with Google investing in it, for instance by hiring the creator and other important Python developers. Python 2.5 has advanced it even further, and it seems to me that Python 3.0 will be a much smoother ride than Perl 6 turned out to be for the Perl community. IronPython and PyPy are also very interesting projects. Python is a generic programming language, so I don't think we need some kind of killer application like RoR. On the other hand, I think a really smooth IDE with a convenient GUI builder could help making it more widely spread among the masses. -- http://mail.python.org/mailman/listinfo/python-list
Re: I need some tips to begin a simple project
dutche wrote: Hi, I'm new in Python and I'm learning with Learning Python oreilly's book which is very good written and explanatory. You're not saying how new you are to programming (particularly GUI programming) in general. Python itself is probably not the tricky part here. And I can use some other graphical interface, like OpenGL? Or with PyGame I can do an animattion like zooming the icon image when hover? It seems to me that PyGame might be a candidate for the kind of stuff you want to do, although I'm no expert in that. I'd download it and play with it. There are some PyGame tutorials and example code to get you started. Good Luck! -- http://mail.python.org/mailman/listinfo/python-list
Re: Replace single character at given position
Larry Bates wrote:
How do I replace a single character in a string at a given position?
You can't. Strings can't be mutated in Python how ever hard you try.
The string type is immutable. (Of course, I suspect you can write a
horrible C extension that would help you cheat. Yuk!)
You need to create a *new* string object with the properties you like.
This is what you do below. As soon as you use s1=..., you are
rebinding s1 to a (typically) different string object than it was
bound to before.
If you think about this, it will probably also answer the does Python
use call by reference or call by value questions that will eventually
pop up in your head if you come from C.
From programming languages like C I expect something like that:
What you need to realize is that objects and assignments are
different in Python and in C. In C, a=x basically means put
the value identified by x in the location defined by a. In
Python, a=x basically means bind the name a to the object
identified by x. See http://pyref.infogami.com/naming-and-binding
You can do this:
s1=s1.replace('x','y', 1) # Only replace the first x with y
or
s1l=list(s1)
s1l[1]='y'
s1=''.join(s1l)
Both these examples creates new string objects and rebind the
name s1 to these new objects. In other words, if you had s2=s1
on a previous line, the expression s1==s2 will be false after
the code above has been executed.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python programs always open source?
Ben Finney wrote: Leif K-Brooks [EMAIL PROTECTED] writes: Ben Finney wrote: So long as you're not distributing some or all of Python itself, or a derivative work, the license for Python has no legal effect on what license you choose for your own work. I was replying to Ben Finney's claim that in a hypothetical world where Python was licensed under the GPL, there would still be no restriction on distributing Python programs under a closed-source license. My claim (and IANAL) is that it doesn't matter *what* license Python is distributed under; unless you do something with Python that is a right of the copyright holder, such as distributing part or all of Python, the copyright license terms of Python have no legal effect on what license you choose for your own work. As I read the GPL, you should be ok if you don't copy, distribute or modify Python (if Python was GPL). Those are the activities covered by the GPL license. Using py2exe to make a binary with both Python and your own code would be a different matter. Even distributing a CD with a GPL Python and your python modules would be a problem, since you would be distributing GPL software with non-GPL software which will be combined into a program as you run it. If you just distribute your .py files, it probably doesn't matter if someone else will run the unholy combination of GPL Python and nongpl.py. I don't think a judge would consider executing gplpython nonglp.py being copying, distribution or modification. On the other hand, I think your doesn't matter *what* license Python is distributed under-claim holds. If we are allowed to think up other evil licenses, they could make claims on all files ever used with their evil software, and I doubt that you could develop non- trivial software without ever invoking it. Still, the important thing is that Python uses a license which is convenient for both proprietary software development and open source. -- http://mail.python.org/mailman/listinfo/python-list
Re: When is it a pointer (aka reference) - when is it a copy?
Fredrik Lundh wrote: this article http://effbot.org/zone/python-objects.htm may be useful for those who haven't already seen it. I don't know how many times I've referred to, or paraphrased, that article. Shouldn't it be incorporated into the standard tutorial? I think it's very helpful for people who are used to the way C etc handles variables. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it just me, or is Sqlite3 goofy?
Paul Boddie wrote: Well, if the client is free not to bother signalling anything about erroneous value types, one has to wonder why there's so much of a specification. If you read it, I think you'll notice that the committee has managed to produce a lot of text without spending too much ink on error handling. I'm not completely up to date with the latest standards, but last time I looked, a lot of things that are essential parts of all serious implementations were missing from the standards. I'm pretty certain it would overwhelm the SQL standards committee if they had to specify how error conditions are handled. It would certainly be useful though. E.g. is PostgreSQL SQL compliant in forcing a rollback as soon as an operation fails. E.g. in Oracle, you can have a transaction with a loop where you try to insert values, and fall back to updating instead if you get a duplicate key on insert error. In PostgreSQL you need to set a savepoint before the the insert and rollback to that. Does the standard say whether this is kosher? I think not. -- http://mail.python.org/mailman/listinfo/python-list
Re: best small database?
David Isaac wrote: I have no experience with database applications. This database will likely hold only a few hundred items, including both textfiles and binary files. I would like a pure Python solution to the extent reasonable. Suggestions? You haven't provided enough requirements for us to make any intelligent suggestions. Perhaps you might learn something from reading through my old EuroPython presentation. http://www.thinkware.se/cgi-bin/thinki.cgi/DatabaseProgrammingWithPython Relational databases with SQL syntax provides a convenient way to store data with an appropriate structure. You can always force a tool into handling things it wasn't designed for, but SQL database work best when you have strict, well defined structures, such as in accounting systems, booking systems etc. It gives you a declarative query language, transaction handling, typically multi user support and varying degrees of scalability and high availability features. For you, it's probably overkill, and if you have files to start with, keeping them in the file system is the natural thing to do. That means that you can use a lot of standard tools to access, manipulate, backup and search through them. Perhaps you rather need a search engine for the file system? Do you intend to store information concerning how these files relate to each other? Perhaps it's better in that case to just keep that relationship information in some small database system, and to keep the actual files in the file system. Perhaps it's enough to keep an XML file with the structure, and to use something like ElementTree to manipulate that XML structure. You gain a lot of power, robustness and flexibility by using some kind of plain text format. Simple files play well with configuration management systems, backup systems, editors, standard search tools, etc. If you use XML, it's also easier to transform your structural information to some presentable layout through standard techniques such as XSL. -- http://mail.python.org/mailman/listinfo/python-list
Re: question about including something like sqlite in python
John Salerno wrote: I was just thinking, since Python 3.0 is supposed to clean up a lot of the unnecessary or redundant features of Python and make other things more streamlined, does it seem to anyone that including SQLite goes against this goal? Not to me. I don't see the redundancy. The DB-API spec has been around for years. I think it's great that one implementation comes with Python. This is just me thinking out loud, mind you, but it seems like including a database module (especially one that many people won't use in favor of MySQL or PostgreSQL, etc.) is weighing down the standard library. I suppose the sqlite module might still be removed in 3.0, but the inclusion of it at all seems a little strange (and also sort of like an endorsement for using it). Sure, but primarily it's endorsement for using the the DB-API. Including SQLite lowers the barrier for getting started in writing applications in a domain where Python fits well. A domain where Visual Basic and tools like FoxPro have dominated. Libraries such as datetime and decimal also goes in the same direction. One could argue that a simple to use GUI building tool is another requisite in this domain, but maybe a web tool kit is more appropriaet these days... In short I think it helps making Python into a VB-killer, or if you prefer (yuk!) the new COBOL! ;^) -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it just me, or is Sqlite3 goofy?
First of all, anyone with extensive experience in database systems understand that validating and cleaning input is an unavoidable task. Static typing can help identify some of the problems, but far from all, and there is often data processing done before the data enters the database, so it's often too late to do the cleaning at that time anyway. Once you are dealing with data within your system, it's a bug in the software if data doesn't fulfill the intended constraints. Such problems should be identified by unit tests. Mike Owens wrote: Next, as far as transferring you data, you most likely have to resort to some delimited format, or INSERT statements, which is no different than any other database. You can always write a Python script which reads from one database, cleans up the data and inserts into another, one row at a time. This isn't just a porting activity. I've written a Python app that moved data from a DB2 mainframe production database to DB2 testing database on Windows. It moved data from a hierarchy of tables, starting in a given table, and reading foreign keys from system tables (very slow in mainframe DB2!) to figure out what data to bring from which tables. Since the system used abstract keys and moved data to a populated database, it had to generate new keys and adjust the foreign keys in the dependent tables. It also had to work around bugs and quirks in Windows NT, DB2 and ADODBAPI etc. These things are relatively easy, but it's never trivial. There are always a lot of details to deal with. For big volumes, you typically need to use some kind of bulk loading facility. Inserts are generally much too slow. (I'm talking about general data porting woes here--in the case of SQLite it's not likely that you have many million rows of data.) Efficient bulk loading means that you have different data format for different database systems, and also that you need to validate your data before insertion, so the problems directly related to SQLite doesn't seem very odd. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it just me, or is Sqlite3 goofy?
[EMAIL PROTECTED] wrote: What was Richard Hipp's justification for slandering the writers of the SQL Language Specification? First of all, if you read the text you quoted and understand English, you should be able to see that the author of the text is clearly expressing an opinion, not stating a fact. Calling this lies or slander is just absurd. the authors of SQLite feel very strongly that this is a feature The authors argue that static typing is a bug in the SQL specification If you think that these sentences imply some kind objective truth that could be claimed to be a lie, then you are confused about English or logic or both. Is there anything more rude than describling the SQL Language Specification as a bug that needs to be fixed? Using waterheadretard in a posting subject perhaps? Seriously, this is the first time I ever heard anyone being religious about the SQL standard in that way. Also, while I actually find your statement about SQL being a bug rather funny and fitting, it's not what Hipp is saying. He's talking about static typing, which is really only a detail in SQL and has no bearing on the relational theories. Equality and inequality can certainly be defined in a strict way regardless on whether it is columns or values that have a distinct type. The use of NULL as a permitted value for all types mean that SQL has already relaxed the traditional type mechanism a bit. Python, Tcl, SQLite etc goes one step further. To cleanse you from this affliction, I suggest that you read Date and Darwen's A Guide to the SQL Standard. After all, these guys are seriously involved in the SQL standard development, and they are certainly not very religious about it. Among their claims you can find these pearls: SQL in particular is very far from ideal as a relational language, although there are well-established principles for the design of formal languages, there is little evidence that SQL was ever designed in accordance with any such principles, Standard SQL especially is additionally deficient in a number of respects. Many people have claimed through the years that SQL is broken, and that Quel was a much better language, and the only reason that SQL killed Quel and not vice versa was the IBM backing. Richard Hipp is hardly being controversial in this respect... -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it just me, or is Sqlite3 goofy?
Paul Boddie wrote: To be fair, that text originates in section 12.3, referring to input parameters to procedures. Meanwhile, the following text (subclause 13.8, insert statement) appears to be more pertinent: If the data type of the target identified by the i-th column name is an exact numeric type, then the data type of the i-th item of the insert statement shall be an exact numeric type. And SQLite behaves as expected if you provide a numeric value to a numeric column, right? In other words, it complies to that clause. Does the spec state how the database engine should behave if the client breaks the requirements for insert? I guess that this is implementation dependent. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it just me, or is Sqlite3 goofy?
[EMAIL PROTECTED] wrote: I think an explanation of how Sqlite3 differs from SQL and a better set of examples is still warranted. In general, Python standard library modules that are wrappers for third party libraries are very thinly documented, and they should probably remain that way, because it's really too much of a burden on the Python developers to develop this documentation and keep it up to date. The idea is to document the wrapper, not the wrapped library. If I had a choice concerning these wrapper libraries, I'd much rather see more docs on the tkinter and xml libraries. There you need to guess a lot. There is no shortage of Tcl/Tk docs, but it doesn't look the same within Python. For the Python xml libraries, I've had to experiment a lot, and I have this nagging feeling that I don't do things the way I should. (From Python 2.5, we have ElementTree, which is much better from this perspective, but we've just started using 2.4 at work, and we try to keep the amount of third party libraries to a minimum here.) It seems to me that the sqlite3 module is fairly decent in this regard, particularly since it's not even included in a completed Python release yet. Concerning the API, I'm surprised to see magic method naming such as __conform__ introduced in a library like that. It seems to me that this is a violation of PEP 8. I'm sure there are further details that could be worth mentioning in the docs, but I think it's important that we don't try to duplicate the SQLite docs in the Python docs. -- http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] RuPy 2007 - Python Ruby Conference
Jakub Piotr Nowak wrote: RuPy 2007 Python Ruby Conference Poznan, Poland April 7-8, 2007 Are you aware of the EuroPython Conference which will take place in Vilnius three months later? -- http://mail.python.org/mailman/listinfo/python-list
Is it just me, or is Sqlite3 goofy?
While I can understand your frustration, I think it is important to think about the tone in our postings here. Hydrocephalus is one of the most common birth defects, and it's not terribly unlikely that someone who reads this has a family member or someone else in his proximity who suffers from this condition. [EMAIL PROTECTED] wrote: Fixed? Up until now, I didn't think it was possible for crackpot theories to be implemented in computer science. This is absolutely the craziest thing I've ever heard. Still, many people with lots of experience in databases use it, and prefer it for certain kinds of applications. All systems have limitations and deviations, and those limitations and deviations are stated more clearly for SQLite than for most commercial products at least. The market leader Oracle still can't store empty strings in VARCHAR fields for instance. They are silently converted to NULL. I'm pretty sure that has been in clear violation to the official spec since 1986 at least. As far as I understand, noone here is forcing you to use SQLite, and with your long experience of MS Access I'd expect you to be fairly used to almost SQL... It's some time since I used Jet/Access now, but I had much more problems with that than I've had with SQLite. SQLite is built in Tcl, by someone who appreciates the way Tcl works, with its weak typing. I don't think Tcl's type handling is nearly as clever as Python's, but I think it's a good thing that Python's standard lib finally has a DB-API compliant module, and while I would have preferred something that was closer to standard SQL, I don't know of a better candidate than SQLite. It's good that it's usable without a server setup, and that it's very light weight. A Jet engine is obviously not an option, and I would have preferred SQLite even if Jet was open source and worked on all platforms. (Well, if JET *was* open source, I suspect it would have been fixed by now.) It's possible that one could have used the embedded version of Firebird instead, but in my experience that's not nearly as lean or easy to deploy. With your long experience of Access and SQL Server I'm sure you know well that any attempt to build a working database application requires extensive knowledge of the backend to understand its peculiarities and limitations. The list of software projects where not quite competent developers built Access applications that worked ok in small scale tests and failed catastrophically in real life is looong... Of course, if you've stayed with one vendor for 15 years, I can imagine that you've forgotten how long it took you Having worked with half a dozen backends or so, I'm no longer surprised that SQL can be interpreted in so many ways... I agree that SQLite is unique in it's approach to typing, but if you are aware of this, it's really not a big problem. -- http://mail.python.org/mailman/listinfo/python-list
Re: Permission Denied
Jorge Godoy wrote: ;-) And think about security as well. I.e. put '.' in the end of your PATH, never in the beginning! -- http://mail.python.org/mailman/listinfo/python-list
Re: Project organisation
rony steelandt wrote: Imagine I have x projects and they all use util.py What would be the best way to organise this 1. c --\project1\*.py | |-\project2\*.py | --\globals\util.py This organisation has the problem that if I have to modify something to util.py that I need in project2, I'll have to retest project1 to make sure it still works (that could be project 1..n). 2. A copy of util.py in each project directory ? The advantage is that I can modify each util.py in function of the need of the project but it looks clutered, having n versions of util.py. What is the best solution ? or is there another even better solution ? Extensive automated regression tests certainly helps! Take a look at e.g. http://www.texttest.org/ This is really not a Python issue at all, it would be the same thing with a util.dll written in C++... -- http://mail.python.org/mailman/listinfo/python-list
Re: running python from a memory stick?
John Salerno wrote: Is there a way to 'install' and use Python on a memory stick, just as you would on any computer? I use Windows, and I know the installation does things with the registry, so probably I couldn't use the executable file to install it. But is it possible to do it some other way, such as how you might build it yourself on Linux (although I don't know how to do that yet) and then just write and run scripts normally straight from your memory stick? Google for 'python on a memory stick and follow the first link? -- http://mail.python.org/mailman/listinfo/python-list
Re: How to display name of elements in list?
My list called elten looks like that: [Tensor: id = 1, intensity = 2976.52 xx = -1447.32, xy = 52.458, xz = -594.186 yy = -1090.54, yz = -0.0158068, zz = -4043. , Tensor: id = 26, intensity = 2896.9 ... , Tensor: id = 5, intensity = 2920.5 xx = -1534.53, xy = 23.4858, xz = -623.967 yy = -1070.47, yz = 99.6301, zz = -3979.87 ] The list above is not a valid Python list. What is it that you store in that list? It might well be a normal Python list. The question is what type the items in the list are... The result of printing a list L is basically a string you could make like this: '[' + ','.join(map(repr,L)) + ']' It seems the elements in this list appear as something like this when you apply the repr() function on them: Tensor: id = 1, intensity = 2976.52 xx = -1447.32, xy = 52.458, xz = -594.186 yy = -1090.54, yz = -0.0158068, zz = -4043. So, the issue is not how you work with a list, but how you work with the elements of this type. To reduce the problem to that, you can assign the first element in the list to a variable. elem0 = elten[0] Then you can inspect that in isolation, without the confusion of the list. type(elem0) dir(elem0) etc... -- http://mail.python.org/mailman/listinfo/python-list
Re: Specifing arguments type for a function
Paolo Pantaleo wrote: I have a function def f(the_arg): ... and I want to state that the_arg must be only of a certain type (actually a list). Is there a way to do that? You can state that in your documentation. You're very likely to get a reasonable runtime error from this when you start using the_arg in your code. The pythonic way of programming is not with overly strict assumptions about typing, but rather by: a) Assuming as little as possible about the data you get from a caller or from a called function. b) Use a comprehensive suite of automated tests to make sure that you find programming errors. From a hypothetical point of view, tests can only find bugs, and never prove that programs are correct, but in practice, automated tests is one of the best ways to keep bugs out of your code. Compile time type checks can only find a small fraction of the bugs programmers make, and the tests that find the harder bugs will also find all the type mismatches that are problematic in any way. There are those who speculate that we will eventually have methods to formally prove correctness of programs through some kind of analysis, but static type checks and other compile time tests are very far from doing that. I think you will find that this approach of assuming as little as possible about parameters and return values will make your code both more robust and more flexible than a traditional approach with static typing as in C++, Java or ADA etc. -- http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
Michele Simionato wrote: Roy Smith wrote: snip That being said, you can indeed have private data in Python. Just prefix your variable names with two underscores (i.e. __foo), and they effectively become private. Yes, you can bypass this if you really want to, but then again, you can bypass private in C++ too. Wrong, _foo is a *private* name (in the sense don't touch me!), __foo on the contrary is a *protected* name (touch me, touch me, don't worry I am protected against inheritance!). This is a common misconception, I made the error myself in the past. While your wording makes sense, it's probably confusing for anyone with a C++ background, where private roughly means only accessible within the actual class and protected roughly means only accessible within the class and other classes derived from it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
Gregor Horvath wrote: Scott David Daniels schrieb: Using a relational DBMS is most definitely _not_ premature optimization. A relational system provides a way to store data so that it is later I did not mean that using a relational DBMS is premature optimization but not using a ORM because of performance considerations is one . Whether or not to use an ORM might be a fairly big design decision, and a part of the entire approach to your data handling. For some kinds of data and some kinds of applications, it will drastically reduce your flexibility in how you can conveniently deal with the data. Object oriented design and programming, is often very helpful, but it's not the only approach you can take to solving a problem in software, and I'm not sure it's always the best approach... Using an ORM means that you are making it much more difficult to use the full expressiveness of SQL. On the other hand, using the full expressiveness of SQL might make it much more difficult to use your data in an object oriented way... You have to weigh the pros and cons depending on the situation. I'm sure different ORMs might be more or less limiting on SQL. I suspect that this depends on how well the designer of the ORM knows SQL. I guess the problem is that those who are best at SQL and most capable of writing a non-limiting ORB are fairly good at working without an ORM, so it's the guys who don't really understand and appreciate the strengths of SQL that designs the ORMs... :) If it turns out that the ORM is a performance problem you can always tune it afterwards. (probably by the DBMS setup, indexes etc.) To a large extent, use of ORMs and a proper OO design, means that you move a lot of logic from the the DB and the SQL layer up to the Python (or whatever language you use) layer, and there are efficient SQL solutions you simply can't reach in that way. As a simple example, the natural way to calculate the averages of an attribute in a set of object in an OO system is to iterate over the objects, get the value, add up a sum, count the objects as you iterate and divide the sum with the count once you were done iterating. It's very simple and straight forward, and often magnitudes slower than the corresponding obvious SQL solution. Its just a layer and therefore the endresult is SQL much the same as the one you would hand code. (and you still can use direct SQL if you like with most of them) That's a joke, right? It might be much the same as *you* would have hand coded, but perhaps very different from what *I* (and I suspect Scott) would have coded. With different approaches to your design, you solve problems in completely different ways. Different languages lend themselves to very different design approaches. The distinction between declarative and imperative languages is pretty big, as is the more concrete ways to actually work with data in Python and SQL. SQL is a really stupid language in many ways. It's pretty useless without a good partner, such as Python, and even considering its limited perspective as a language for querying and manipulating relational databases, I think it could have been designed so much better. I can't see any intelligent reason not to provide the kind of abstractions that function calls provide for instance. The amount of repetition in SQL code in large database applications is appalling. Still, there are applications where it's widely superior to any really existing alternatives, and it goes far beyond manipulating or fetching individual records in tables. In any way you have to bridge the logical gap between the relational and the object data model in your programm. Certainly. So you will end up in building a layer between your persistence code and your problem and domain specific application code, so what you are actually doing is writing an ORM. Well, I wouldn't say it's an ORM unless it tries to be generic in some way. In many cases, this mapping is fairly trivial. I once used SQLObject for a whisky tasting database web app, and I think it made life easier for me than raw SQL would have been, but that was a small system where it was more important to make development fast than to make the end product fast and robust. Not reinventing the wheel every time and using a existing one is IMHO a better approach. Well, as usual... That depends... For each project you have to decide how well different available alternatives fit your actual requirements. If there's an ORM that fit yours, fine. No such external product would be able to handle the applications I work with right now. The kind of conventional use of SQL in ORMs simply won't work for our needs for several reasons. For us, and ORM simply can't solve the problem. For others, it's overkill. As I said, ORMs have their uses, but it seems to me that a reason for many people to use ORMs is to avoid having to properly understand the way relational databases work, and that means they will never use the
Re: Py+SQLite or other (big output) ?
DurumDara wrote: I want to process many data with python, and want to store in database. ... So I want to use one database file - but I want to protect it. How to do it with SQLite ? I see that solutions: - 1. I use transactions. - 2. I create full copy of database after every bigger transation. - 3. Shadow file ??? - 4. Mirror database (this is problematic to synch.). The transactions are very good things, but does not protect the database from injuring. The copy operation is better, but very decrease the processing speed, because the result db grow fast, and copy of 1/2,2/3 GBs is slow, and not too good. With these requirements (data recovery, sizes of several gigabytes, transaction safety etc) you might consider something heavier than SQLite. Of course, there is more work to administer something like DB2, Oracle or PostgreSQL than SQLite, but at least the code is as easy as for SQLite, and they are built to provide very robust storage of large amounts of data in a transaction safe way, with ample possibilities to spread out data across disks etc. Also, with e.g. Oracle, you can define the max sizes of the database files so that disks never get full. If the allotted files are all full, there won't be any crash. You will just get a error from the last INSERT, and stay in your transaction. If you catch this error and alert the user, more disk space could be made available for the database, the erring INSERT repeated and then you just go on with the rest. I think you could do the same in recent PostgreSQL versions by using savepoints. (PostrgeSQL requires a rollback after an SQL error--savepoints enables you to rollback less than a full transacion.) -- http://mail.python.org/mailman/listinfo/python-list
Re: How to search HUGE XML with DOM?
Ivan Vinogradov wrote: I have not much clue about databases, except that they exist, somewhat complex, and often use proprietary formats for efficiency. Prorietary storage format, but a standardized API... So any points on whether RDBM-based setup would be better would be greatly appreciated. The typical use case for RDBMS is that you have a number of record types (classes/relations/tables) with a regular structure, and all data fits into these structures. When you want to search for something, you know exactly in what field of what table to look (but not which item of course). You also typically have multiple users who need to be able to update the same database simultaneously without getting in each others way. Even trivial aspects, such as whether to produce RDBM during the simulation, or convert the complete XML log file into one, are not entirely clear to me. Most databases as suited at writing data in fairly small chunks, although it's typically much faster to write 100 items in a transaction, than to write 100 transactions with one item each. I gather that RDBM would be much better suited for analysis, but what about portability ? Is database file a separate entity that may be passed around? Who says that a database needs to reside in a file? Most databases reside on disk, but it might well be in raw partitions. In general, you should see the database as a persistent representation of data in a system. It's not a transport mechanism. -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a language/framework
Steve Juranich wrote: [EMAIL PROTECTED] wrote: As far as hosting, I also know where Zope/Plone hosting from 7.95 a month - although the host doesn't list it on their ads, they do use and host it. Which host would this be? I'm currently exploring some options for getting a Zope site hosted. Virtual servers is getting cheaper and cheaper. That's obviously a viable way to host Zope, if you don't mind being your own sysop. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Debugger / IDE ??
Don Taylor wrote: Is there a free or low-cost version of Delphi for Windows available anywhere? Sure. If my memory serves me correctly, I have several CDs from various computer magazines with previous versions of Delphi at home. I don't know if such offers have been around recently, but you could check some computer magazines with included CDs or DVDs. Borlands web site currently says: Please note that Delphi 2005 Personal is only distributed through select publications, and is not available for download. Google for more info... See e.g. http://www.delphigamedev.com/2005_04_01_archive.htm#111429746345094436 http://blogs.slcdug.org/rhordijk/archive/2005/02/12/1114.aspx See also: http://groups.google.se/group/borland.public.delphi.non-technical -- http://mail.python.org/mailman/listinfo/python-list
Re: does python could support sequence of short or int?
momobear wrote: hi, is there a way to let python operate on sequence of int or short? If you want to work with arrays of numbers, you might want to look at NumArray etc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Set Windows Environment Variable
Duncan Booth wrote: Fuzzyman wrote: In the ``win32api`` package there is a ``GetEnvironmentVariable`` function, but no ``SetEnvironmentVariable``. Any options ? No, your only option is to find a solution which doesn't involve changing another process's environment. Surely there must be a way to programatically set up the environment variables for not yet started processes? I.e. doing the same as when you manually change things in the control panel. I'm pretty sure many Windows installers do that, and while I suppose this is technically a registry manipulation, I suspect there is a more direct API somewhere. -- http://mail.python.org/mailman/listinfo/python-list
Re: does python could support sequence of short or int?
momobear wrote:
but what about buffer is not be declared in python program, it comes
from a C function. and what about I want to treat a string as a short
list?
Python is a high level language with much stronger typing than C.
If you want a list of integers, use a list of integers. Strings
are for text. You might well extract numeric values from a string that
you get from another source, and you can use array or struct for that,
but don't use that while processing numeric values in Python.
Sorry, but when I hear you, I see the image of someone who shoves dirt
into the trunk of a car, goes over to the front, tries to lift it with
his bare hands, and complains that this is a really clunky wheel-barrow.
;^)
Don't try to make Python into some kind of crippled C. It's much more
powerful than C if you use it as intended. Used backward, it will only
irritate you. I can well understand that you try to use C idioms if that
is what you know, but you should understand that this will often lead
you to bad Python solutions.
I don't quite understand how you intend that the interface between C
and Python would look. You can't just pass a raw C pointer to Python.
If you want that data to be managed by your C code, you need to provide
an API that you can access from Python that will make sense for Python.
If you e.g. pass a string as a return value from a wrapped C function,
you can e.g. use array or struct in Python to access it in a way that
makes sense in Python.
Assuming that your C function returns a string with 2 byte integers like
this:
s
'\x01\x00\x02\x00\x03\x00\x04\x00\x05\x00\x06\x00\x07\x00\x08\x00\t\x00'
You can easily make a list like this:
import struct
l = list(struct.unpack('h'*(len(s)/2), s))
l
[1, 2, 3, 4, 5, 6, 7, 8, 9]
If you don't need to manipulate it, you can skip the 'list()'
part and get an immutable tuple instead.
The advantage with struct over array in s case like this (as far as I
understand) is that you have control over endianness.
--
http://mail.python.org/mailman/listinfo/python-list
Re: New development windows, IronPython or PythonWin
Dan wrote: Just starting to do some windows Client / Server programming. Which would you recommend? I need to create a server to fire events and communicate with clients over a lan. Thanks There are plenty of Python solutions for this, most of them work with Windows, but aren't locked to it. You might want to look at one of these: http://pyro.sourceforge.net/ http://dabodev.com/ See also http://wiki.python.org/moin/DistributedProgramming and http://www.thinkware.se/cgi-bin/thinki.cgi/UsingPythonWithOtherLanguages -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for Web App
Harlin Seritt wrote: I want to make a recommendation to a group of internal customers where I work concerning a Python web framework. They are seeking to build a portal that can handle around 5000 total users but probably no more than 100-200 simultaneous users. This is supposed to serve mainly static content - the content will hold references, tutorials and examples for different technologies, a forum (similar probably to phpbb) and podcasts (rss and mp3 files). Also I believe it will definitely need a decent DB server for this. They have some other suggestions ranging from Websphere/JSP's to PHP. I personally don't think the PHP will scale well for growth and I also think that using Java/JSPs will be too slow for this sort of thing. There are certainly big PHP sites (Wikipedia?) and I'm not sure Python is faster than Java/JSP (given enough memory on the server). I'd use Python too, but that's more due to maintainablility and rapid development than performance. I normally work as system and application admin and use Python in a number of ways to get the job done. Naturally, I am naturally inclined to suggest something that uses Python or something Pythonic. I wanted to suggest Zope but there are also other ones I'm thinking of as well like CherryPy and Karrigell. Which one of these (or other ones you guys know of) would do the best job in this situation? I never felt Zope was very pythonic... You certainly get a lot out of the box with Zope, but there seems to be a big learning curve as soon as you go beyond the most obvious things. Knowing Python won't mean that you feel at home in Zope. Zope 3 seems to improve things, but almost all existing Zope products today are Zope 2 thingies, so it seems a year early or so to jump onto the Zope 3 train if you don't want a lot of work. It seems the popular tool kits these days are Django and Turbo Gears. I have heard a lot of good things about both. I think both have video tutorials and other introduction docs that are easy to digest. Also do you guys know if MySQL would work with this or should they use something more robust like DB2 (IBM shop)? Typically, I warn people about MySQL, since it's not very mature in the role as a full RDBMS, but it's been very successful for use as container for web site content. This role, with lots of simple reads, no complex transactions and relatively few updates is just where MySQL shines. Don't use it for mission critical OLTP applications such as booking or accounting systems though. I think MySQL is robust. -- http://mail.python.org/mailman/listinfo/python-list
Re: What's the best way to learn perl for a python programmer?
vj wrote: I've been given a project which requires writing scripts that need to be run on over 3000 servers. Only about 15% of them have python installed on them. While all/most of them will have perl. I'll try and do as much as possible in pexpect but am sure I'll have do some significant perl. Any suggestions on what is the best way to get upto speed on perl? The thing that really bit me when I tried to go back to Perl after years with Python was dereferencing. Completely obvious things in Python, such as extracting an element from a list inside a dict in another list felt like black magic. I actually gave up, but later I realized that there is an entire chapter in Programming Perl about the stumbling blocks with dereferencing in Perl. I don't think people in this group :) will disagree if I claim that Python software is much more maintainable and easier to develop and debug than Perl scripts. That's probably relevant if they are to run on thousands of servers. I'd make a real effort to investigate if it's possible to either install Python on all boxes or use something like cx_Freeze to make executables out of the scripts. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiple assignment
Anand wrote: Suppose i have a big list and i want to take tke the first one and rest of the list like car/cdr in lisp. is there any easy way to do this in python? It seems like overkill to me to make the syntax more complex just to avoid writing a one-line function. def first_rest(seq): return seq[0], seq[1:] -- http://mail.python.org/mailman/listinfo/python-list
Re: datetime iso8601 string input
[EMAIL PROTECTED] wrote: Why not dt = datetime.datetime(*time.strptime(s, %Y-%m-%dT%H:%M:%S)[0:6]) ? Maybe due to neglection of the 7th commandment? Most of the other commandments can be ignored while coding Python, but the 7th certainly applies here. http://www.lysator.liu.se/c/ten-commandments.html As I've written before, the ISO 8601 spec contains many variations in date formats. Making a full ISO 8601 parser is probably possible if we ignore time deltas, but it's hardly worth the effort. Writing something that parses a few percent of the possible ISO 8601 messages and calling that an ISO 8601 parser seems silly to me. With code like Skip's above it's obvious what kind of strings are handled. In typical applications, one such format is enough, and this needs to be properly specified. In a recent case I wrote the spec like this: The timestamp shall be an ISO 8601 combination of UTC date and time with complete representation in extended format, with representation of fractions of seconds with up to six decimals preceeded by a full stop as decimal sign. E.g. 2005-06-20T13:42:55.2425Z Despite my verbosity here, someone who didn't follow the example, would still be able to write ISO 8601 strings following the requirements above that we won't parse, since I didn't actually write that dates should be written as year-month-day. For a brief summary of some of the allowed variation see http://hydracen.com/dx/iso8601.htm -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compiler
Rc wrote: But ,my question is when I start Python it is a Dos Window that opened.I think it is not possible on a XP computer? The Windows NT family, including XP, is not based on MS DOS. It still has a text more interface, and it is much better than DOS ever was. You can start that by clicking on the Start button, selecting 'run' and typing cmd.exe and pressing ENTER. You don't need that--but as you gain experience, you might start to prefer it... The keyboard is much faster than the mouse... The standard Python installer contains a graphical development environment called IDLE. Have a look at Danny Yoo's tutorial http://hkn.eecs.berkeley.edu/~dyoo/python/idle_intro/ Good Luck! -- http://mail.python.org/mailman/listinfo/python-list
Re: Need design advice. What's my best approach for storing this data?
Mudcat wrote: I am trying to build a tool that analyzes stock data. Therefore I am going to download and store quite a vast amount of it. Just for a general number - assuming there are about 7000 listed stocks on the two major markets plus some extras, 255 tradying days a year for 20 years, that is about 36 million entries. Obviously a database is a logical choice for that. However I've never used one, nor do I know what benefits I would get from using one. I am worried about speed, memory usage, and disk space. This is a typical use case for relational database systems. With something like DB2 or Oracle here, you can take advantage of more than 20 years of work by lots of developers trying to solve the kind of problems you will run into. You haven't really stated all the facts to decide what product to choose though. Will this be a multi-user applications? Do you forsee a client/server application? What operating system(s) do you need to support? With relational databases, it's plausible to move some of the hard work in the data analysis into the server. Using this well means that you need to learn a bit about how relational databases work, but I think it's with the trouble. It could mean that much less data ever needs to reach your Python program for processing, and that will mean a lot for your performance. Relational databases are very good at searching, sorting and simple aggregations of data. SQL is a declarative language, and in principle, your SQL code will just declare the correct queries and manipulations that you want to achieve, and tuning will be a separate activity, which doesn't need to involve program changes. In reality, there are certainly cases where changes in SQL code will influence performance, but to a very large extent, you can achieve good performance through building indices and by letting the database gather statistics and analyze the queries your programs contain. As a bonus, you also have advanced systems for security, transactional safety, on- line backup, replication etc. You don't get these advantages with any other data storage systems. I'd get Chris Fehily's SQL Visual Quickstart Guide, which is as good as his Python book. As database, it depends a bit on your platform you work with. I'd avoid MySQL. Some friends of mine have used it for needs similar to yours, and they are now running into its severe shortcomings. (I did warn them.) For Windows, I think the single user version of SQL Server (MSDE?) is gratis. For both Windows and Linux/Unix, there are (I think) gratis versions of both Oracle 10g, IBM DB2 UDB and Mimer SQL. Mimer SQL is easy to install, Oracle is a pain, and I think DB2 is somewhere in between. PostgreSQL is also a good option. Either way, it certainly seems natural to learn relational databases and SQL if you want to work with financial software. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there no end to Python?
John Salerno wrote: But isn't Python sort of known for the opposite, i.e. 'one simple way', or something to that effect? If we compare it with the opposite language--Perl, and think of these languages as natural languages, rather than programming languages, Perl's inventor Larry Wall, felt that having a lot of synonymns and allowing a lot of flexibility in word order etc, would make it easier to express one's ideas well. Python's inventor Guido van Rossum took a different approach. With fewer synonyms and a less redundant grammer, it will be easier to master the language, and certainly easier to read texts written by others. I don't know, but I suspect that the difference in approach is rooted in Guido's understanding that we typically spend much more time reading source code than we spend writing source code. As it turns out, having fewer synonyms and grammatic variants, does not make it harder to come up with different solutions to problems. It rather seems that the lack of complexity that a simpler grammer leads to makes it much easier to try out different solutions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing an output from another function
Byte wrote:
Now what do I do if Func1() has multiple outputs and Func2() requires
them all to give its own output, as follows:
import random
def Func1():
choice = ('A', 'B', 'C')
output = random.choice(choice)
output2 = random.choice(choice)
return output
return output2
def Func2(item1, item2):
print item1, item2
output1 = Func1()
Func2(output1)
Some more options (untested):
def func1(n, choice=('A', 'B', 'C')):
# n=number of choices
# choice can now be overridden with
# other values
choices = []
for i in range(n):
choices.append(random.choice(choice))
return choices
def func2(choices):
for choice in choices:
print choice,
print
func2(func1(2))
#
class ChoosePrinter(object):
def __init__(self, to_choose_from=('A', 'B', 'C')):
self.to_choose_from=to_choose_from
self.choosen = []
def get_choices(self, n=2):
for i in range(n):
self.choosen.append(random.choice(choice))
def dump_choosen(self):
print .join(self.choosen)
self.choosen = []
cp = ChoosePrinter()
cp.get_choices(2)
cp.dump_choosen()
--
http://mail.python.org/mailman/listinfo/python-list
Re: python debugging question
[EMAIL PROTECTED] wrote: I am a python newbie. I have writen some 500 lines of code. There are 4 classes and in all 5 files. Now, I am trying to run the program. I am getting wrong values for the simulation results. If you first write 500 lines of code, and *then* try to run it, it seems you are using a development approach suitable in the 1960's when running a program meant handing a stack of punch cards to a computer operator in a white coat, and then getting the result of the run the next day (if you're lucky). I was taught to write like this as recently as in the late 80's when I was in universtity, but today I typically run my code every ten minutes or so. It's rare that I run the code I work on less frequently than every thirty minutes. In my experience, my current way of developing software leads to higher productivity, better quality and much better predictability in regards to both development time and software performance and features. The way to achieve this is to use lots of automated tests and a development time where you learn to work in small increments. Martin Fowler's book Refactoring is a good guide for this, and Python is a very good language to use for this kind of development. Perhaps this might be useful? http://www.thinkware.se/cgi-bin/thinki.cgi/SoftwareTestingWithPython http://thinkware.se/epc2004test/log.html -- http://mail.python.org/mailman/listinfo/python-list
Re: list/classmethod problems
ahart wrote: I thank you all for your help and suggestions. I wasn't aware that default values were considered class (static) values. That seems a little odd to me, but as long as I know that's the case, I'll be fine. It's all very simple and regular: Things in the class scope is shared between all instances of the class. This applies to both __text, __get_text, __set_text, text and __init__ in the Item class. All these things are shared, since they are defined in the scope of the class. That's the namespace where they exists, not the instance. The typical thing to put in the class scope is obviously methods, although some plain data can belong there too. When you access something in the instance, e.g. self.__text, where self is an Item instance, it will follow a certain lookup procedure. If it finds __text in the instance, it will use that object. If not, it will look in the scope of the class, and if it's not found there, it will look in base classes of Item and so on. This means that __get_text will find Item.__text if __text does not exist in the instance object. On the other hand, when you assign to self.__text in __set_text, you will get a new name __text in the instance, and the next __get_item call will find a __text in the instance, not the shared in the class scope. Assignments in Python means make this name refer to that object. As far as I understand, that's like Java if you don't use those half-life types like int that aren't proper objects. So, it does never mean copy a value to this location in memory as it does in C / C++. With the list in Parent, you never make any assignment, so there will never be any __item in the instance namespace. All self.__items lookups will end up in the class namespace. Since lists are mutable, you can change this list object, and the changes will be visible to all instance. With the __text attribute in Item, which is a string (immutable) there is no way to change the value. To get a new __text value in the class scope, you'd have to do self.__class__.__text = ... or Item.__text = ..., and I doubt that you would do that by accident! ;^) What made you try to put your private attributes in the class scope instead of putting them in __init__? Perhaps it's hard to entirely give up the idea of somehow declaring your class attributes even if there is no such things as variable declarations in Python. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any overheard with try/except statements?
John Salerno wrote: Thanks guys! I had a feeling exceptions were nothing like in C languages (i.e. a pain to deal with). :) Since when does C have exceptions? (You're not confusing C with C++ or C#?) -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any overheard with try/except statements?
John Salerno wrote: One of the things I learned with C# is that it's always better to handle any errors that might occur within the codes itself (i.e. using if statements, etc. to catch potential out of range indexing) rather than use too many try/catch statements, because there is some overhead every time the program encounters the try. Premature optimization is the root of all evil (or at least most of it) in programming. -- http://mail.python.org/mailman/listinfo/python-list
Re: A better RE?
Schüle Daniel wrote: txt = 21MAR06 31APR06 1236 m = '(?:JAN|FEB|MAR|APR|MAI|JUN|JUL|AUG|SEP|OCT|NOV|DEZ)' # non capturing group (:?) p = re.compile(r(\d\d%s\d\d) (\d\d%s\d\d) (?=[1234567])(1?2?3?4?5?6?7?) % (m,m)) p.match(txt).group(1) '21MAR06' p.match(txt).group(2) '31APR06' p.match(txt).group(3) 1236 Excellent. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: A better RE?
Fredrik Lundh wrote:
Magnus Lycka wrote:
r(\d\d[A-Z]{3}\d\d) (\d\d[A-Z]{3}\d\d) (?=[1234567])(1?2?3?4?5?6?7?)
Thanks a lot. (I knew about {3} of course, I was in a hurry
when I posted since I was close to missing my train...)
--
http://mail.python.org/mailman/listinfo/python-list
Alternative style sheets - Re: New python.org website
Phoe6 wrote: beta.python.org evolved very nice and noticed today the new python.org website going live. There is a change in the look n feel, wherein it looks more official and maximum possible information about python is now directly accessible from the home page itself. Kudoes to the design team. I also feel this is a big improvement. I know that a web site like this needs constant nurturing, so I hope that it's been developed in such as way that it will be easier to maintain it and to involve more contributors. Concerning style sheets, it's pretty trivial to make several style sheets and let people use the one they like best. If we enable that, it should also be simple to see from the web site statistics which style sheet people prefer. Then we can use the most popular style sheet as the default! Since people have different tastes, different screens with various resolutions and colors etc, darker or lighter rooms, might want different styles for on-screen viewing and on paper etc, I think it would be a good idea to have several styes even if there is no ambivalence concerning what look we want. -- http://mail.python.org/mailman/listinfo/python-list
Re: New python.org website
Nicola Musatti wrote: The obviously perfect logo would be Kaa's face: http://disney.go.com/vault/archives/villains/kaa/kaa.html The Soviet version is better, and I think most of the Maugli movies are made before 1973, which means that they aren't copyrighted outside the former Soviet Union. (Disclaimer: IANAL) I'm not sure either version really works as a logo though. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Evangelism
rtilley wrote: Steve Holden wrote: Doug Bromley wrote: I can see Ruby overtaking Python if we don't ALL do something about it. I think it's the name. Python. Let's change it to something nicer. Think about it... if you found a Ruby, you'd pick it up and put it in your pocket. If you ran across a Python, you'd run away. I think you have a point, but I also think it's a bit late to change it after 15 years or so, considering all books, web sites etc. We're stuck with Python, and can only do the best of that. Actually, in Swedish, Jag mår pyton i.e. I feel like python means I feel sick, and det luktar pyton i.e. it smells python, means it stinks. That doesn't make Python easier to sell here... Still to late to change... It's not too late to rename the cheese shop though. (We don't need even more stink...) I think a good example on the problem with letting techies like us do naming is that grand successor of Unix developed by the great minds at Bell Labs. First, they name it after a movie which is famous for being exceptionally bad--Plan 9 (from outer space). Really grand company there! Then, when they make a real product of it, they call it Inferno, and some part of it gets called Limbo. They do this on purpose in the U.S. A country full of religious fanatics, where it's impossible to be elected president unless you claim that you are a devoted Christian and say God bless America every time you open your mouth. No wonder the preferred operating systems (except a boring proprietary one) are still purely old fashion Unix based ones. Most of those smart improvements never quite made it... -- http://mail.python.org/mailman/listinfo/python-list
A better RE?
I want an re that matches strings like 21MAR06 31APR06 1236, where the last part is day numbers (1-7), i.e it can contain the numbers 1-7, in order, only one of each, and at least one digit. I want it as three groups. I was thinking of r(\d\d[A-Z]\d\d) (\d\d[A-Z]\d\d) (1?2?3?4?5?6?7?) but that will match even if the third group is empty, right? Does anyone have good and not overly complex RE for this? P.S. I know the now you have two problems reply... -- http://mail.python.org/mailman/listinfo/python-list
Re: String functions: what's the difference?
Harro de Jong wrote: Thanks for the pointer. I was using time.time(), which I now see isn't very accurate on Windows. time.clock() is more accurate on Windows (and much less so on Linux, where it also measures something completely different.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Learning different languages
Rich wrote: Anyway, my question is: what experience you people have with working with different languages at the same time? I typically use Python, C++ and SQL. When there's been lots of Python and little C++, I tend to forget to terminate C++ statements with semicolon... Otherwise I seem to keep them apart. In general, I think Python made me a better C++ programmer. You certainly can't apply all Python ideas in C++ or vice versa. The languages have different strengths and weaknesses, and an idiom which is good in one language might be bad in the other. Still, it was with Python I learned OOP properly, and since Python doesn't get in the way as much, using Python has made it easier to develop as a systems designer and architect. SQL is certainly different enough from the other to prevent any confusion. Concerning more similar languages, such as Python, PHP and Perl, I don't really see the point of mastering several languages that are so similar. To be honest, learning Python made me never want to touch Perl again, and learning PHP felt very much like going backwards, so I didn't get beyond a very superficial understanding. I feel so much more productive with Python, and it can handle all the things PHP or Perl handles well enough. There are certainly cases were PHP would be more convenient, and a big existing base of Perl code, but I've managed to get by well with Python anyway. -- http://mail.python.org/mailman/listinfo/python-list
Re: ODBC module and strange date reference ...
[EMAIL PROTECTED] wrote: I'm all for using for the latest version of Python. I'm just now learning about Python classes, and it seems like there were some significant changes at 2.2. I don't remember exactly what appeared when, but nothing you learn with 2.1 will stop working in 2.2 (I think--at least nothing broke for me, and I haven't heard of any problems in this regard). On Windows, you might have problems crossing the 2.2 - 2.3 gap if you use non-ASCII characters in the source code. That's the only upgrade problem I ever had from 1.4.2 to 2.4.2... -- http://mail.python.org/mailman/listinfo/python-list
Re: Python advocacy in scientific computation
Terry Reedy wrote: I believe it is Guido's current view, perhaps Google's collective view, and a general *nix view that such increases can just as well come thru parallel processes. I believe one can run separate Python processes on separate cores just as well as one can run separate processes on separate chips or separate machines. Your view has also been presented and discussed on the pydev list. (But I am not one for thread versus process debate.) That's ok for me. I usually have lots of different things happening on the same computer, but for someone who writes an application and want to make his particular program faster, there is not a lot of support for building simple multi-process systems in Python. While multi-threading is nasty, it makes it possible to perform tasks in the same program in parallel. I could well imagine something similar to Twisted, where the different tasks handled by the event loop were dispatched to parallel execution on different cores/CPUs by some clever mechanism under the hood. If the typical CPU in X years from now is a 5GHz processor with 16 cores, we probably want a single Python program to be able to use more than one core for CPU intensive tasks. At least if writing threaded applications becomes less error prone in competing languages, this might well be the weak point of Python in the future. Queue.Queue was added to help people write correct threaded programs. What I'm trying to say is that multi-threaded programming (in all languages) is difficult. If *other* languages manage to make it less difficult than today, they will achieve a convenient performance boost that Python can't compete with when the GIL prevents parallel execution of Python code. - For many years, CPU performance has increased year after year through higher and higher processor clock speeds. The number of instructions through a single processing pipeline per second has increased. This simple kind of speed increase is flattening out. The first 1GHz CPUs from Intel appeared about five years ago. At that time, CPU speed still doubled every 2 years. With that pace, we would have had 6GHz CPUs now. We don't! Perhaps someone will make some new invention and the race will be on again...but it's not the case right now. - The hardware trend right now, is to make CPUs allow more parallel execution. Today, double core CPU's are becoming common, and in a few years there will be many more cores on each CPU. - While most computers have a number of processes running in parallel, there is often one process / application that is performance critical on typical computers. - To utilize the performance in these multi-core processors, we need to use multi-threading, multiple processes or some other technology that executes code in parallel. - I think languages and application design patterns will evolve to better support this parallel execution. I guess it's only a few languages such as Erlang that support it well today. - If Python isn't to get far behind the competition, it has to manage this shift in how to utilize processor power. I don't know if this will happen through core language changes, or via some conveninent modules that makes fork/spawn/whatever and IPC much more convenient, or if there is something entirely different waiting around the corner. Something is needed I think. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python advocacy in scientific computation
Dennis Lee Bieber wrote: I did look at Ruby once... It looked to me like the worst aspects of PERL grafted onto the worst parts of old Python. Don't forget that there are portions of Smalltalk syntax (blocks) added in as well. I guess it could be seen as Perl-NG. Both the name 'Ruby' and the Ruby syntax seems to suggest that Matz had the idea to flirt a bit with the Perl programmers, and considering how Perl seems to be in decline today, that might have been clever from a user-base point of view. Whether it was really good for the language is another issue. I still think it's a bit prettier than Perl though. For CPU-bound number-crunching, perhaps... For I/O-bound jobs, the GIL is(should be) released when ever a thread is blocked waiting for I/O to complete. I think CPU-bound number-crunching was the big deal in this case. Somehow, I doubt that the OP uses Matlab for I/O-bound jobs. At least if writing threaded applications becomes less error prone in competing languages, this might well be the weak point of Python in the future. I hope to see some clever solution to this from the Python developers. It seems the Python attitude to performance has largely been: Let Python take care of development speed, and let Moore's law and the hardware manufacturers take care of execution speed. As it seems now, increases in processing speed the coming years will largely be through parallell thread. If Python can't utilize that well, we have a real problem. 5. I don't like numpy's array slicing. Array operations should be a part of the language, as in Matlab, Fortran 90, Ada 95, D, Octave. Python is not primarily a mathematics language. It's not a text processing language either, so no regexp support directly in the syntax. That might make it less ideal as a Matlab substitute, or as a sed or awk substitute, but on the other hand, it's useful for so many other things... Everything in Python is a reference to an object. I think the question you want is more on the lines of: Can I change an object that has been passed? The key lies in understanding that a=b means bind the local name (unless declared global) a to the object the name b refers to. It never means copy the content of b into the location of a. -- http://mail.python.org/mailman/listinfo/python-list
Re: Incorrect Decimal-Float behaviour in comparison tests
Sergei Organov wrote: Well, without reading the manuals I'd expect this to raise an exception instead of yielding of meaningless and confusing result, consider: Without reading the manuals, you can only expect that Python will be compatible with the ideas you have of things based on previous experience and your own ideas, and since the set of previous experiences and ideas among N people is probably bigger than N, it's really tough to make Python fulfil that! -- http://mail.python.org/mailman/listinfo/python-list
Re: re-posting: web.py, incomplete
_wolf wrote: then the output is :: Hello, oops! Hello, oops! 20 lines omitted/ Hello, oops! Hel Are you running Python unbuffered? I.e. python -u -- http://mail.python.org/mailman/listinfo/python-list
Re: Best python module for Oracle, but portable to other RDBMSes
[EMAIL PROTECTED] wrote: # Print new list print recordList [872L, 'ACTIVE', DbiDate object at 011F6000, DbiDate object at 00EA1428, None, '1.0.0.0', None, None, None] Read the Python library manual chapter 2. Read all of it, it's all very useful information, but take a particular look at str() and repr(). All Python object can be viewed in two standard ways, via the str() or repr() functions. In short, the str() stringification is typically to be more end-user friendly, while the repr() stringi- fication is more intended to properly identify exactly what kind of an object we see: what type it is, and often the value too. (Above, you don't see any reasonable value at all in the DbiDate objects, but for some reason that didn't seem to bother you as much as the suffixed L on the long ints.) When you just print a Python object x of some kind, i.e. print x it will be equivalent of print str(x) To see the other representation, use print repr(x) Python collections, such as lists, tuples and dicts, aren't really intended to be printed as is to end users. If recordList is a list, and there is a statement print recordList, it's probable that it is intended as a diagnostic help to a programmer during development, rather than to an end user. So, it's rather clever to use the repr() stringification, so that it's clear exactly what we see, e.g. all strings are quoted, so you clearly see things as trailing spaces, can differentiate between tabs and sequences of spaces, and aren't confused by commas inside the strings. Also, for longs, you get a trailing L to indicate that this isn't simply a normal integer, but an arbitrarily long one. -- http://mail.python.org/mailman/listinfo/python-list
Re: ODBC module and strange date reference ...
[EMAIL PROTECTED] wrote: Incidentally, I have just ordered: * Learning Python * Python Cookbook * Python Pocket Reference Are there any other books y'all would recommend as essential Python references and/or books for becoming fluent in Python? Both Beazley's Python Essential Reference and Martelli's Python in a Nutshell are good reference books. I think Beazley's book has just been released in its 3rd edition, and I understand that Alex is working on the 2nd edition of the Nutshell book. They are both good, so if you don't want to wait, I think you should get Beazley's book, which should be more up to date than the 1st ed of the Nutshell book. I think Chris Fehily's Python: Visual Quickstart Quide was good too. The 2nd ed is due in April. It might be a bit redundant if you have Learning Python though. I guess the same goes for Magnus Lie Hetlands new book. If you are working with Python on Windows and want to use COM or other Windows features, you might want to get Python Programming on Win32 by Hammond and Robinson. It's six years old, so it's not 100% up to date, but I think it's the only book that covers Windows programming with Python in detail. There are also good books concerning other spcific topics such as text processing, networking, GUI development etc, but don't get all the books at once. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: ODBC module and strange date reference ...
[EMAIL PROTECTED] wrote: Been using the ODBC module for Python 2.1 It might well become a problem that you are stuck with a five year old Python version. Python 2.1 is no longer a supported Python version. Support for 2.2 will probably end soon. Are you using an old version of ESRI software, or are they shipping a product with an ancient version of Python? You can't really expect that third party product will support Python 2.1 any longer. A lot of new software take advantage of the new features in Python that came in later versions. Current Python versions are also a bit faster. If I were you, I'd check with ESRI support if you can't use a newer version of Python. I think it's possible. Concerning mxODBC, you might want to have a second look at it. I don't know your business context of course, but if I understand correctly, it can be used for free for inhouse use, and if that doesn't apply to your situation, a licence might well be worth its price. If this is something you will distribute to customers, I suspect you can make a deal with eGenix and get a better price than the normal site license. (It's a while since I looked at their pricing, so I don't know if I'm making sense...) Anyway, I think the best option would be to get a newer Python installed if that's reasonable, but I realize that might cause some extra work if your code is to run on a lot of machines... -- http://mail.python.org/mailman/listinfo/python-list
Re: white space in expressions and argument lists
Sybren Stuvel wrote: Scott David Daniels enlightened us with: One reason is such code changes too much on code edits, which makes code differences hard to read. Good point. I'll keep it in mind :) Think particularly about using version management systems and applying patches coming from different sources etc. Touching more lines of code than you actually need will both make it difficult for a reviewer to understand what has changed (although good diff tools can be told to ignore pure whitespace changes) and it will also increase the risk of conflicts in the version management system if several people are editing the same code. Finally, if you end up with something like... a= 1 b= 5 df = 7 ew = 5 qw = 7 a2 = 5 a4 = 7 d3 = 5 df = 7 this_is_a_very_long_variable_name_indeed = 42 ...it's *not* easier to see what the value of e.g. a4 is than if you had just used one space between the variable name and the =. As usual, Guido is right, even if it isn't obvious at first unless you are Dutch. ;^) -- http://mail.python.org/mailman/listinfo/python-list
Re: re-posting: web.py, incomplete
Dennis Lee Bieber wrote: On 3 Mar 2006 04:01:44 -0800, _wolf [EMAIL PROTECTED] declaimed the following in comp.lang.python: it does look like it, no? No, it looks the other way around: You have buffered output, and parts of your stdout never gets flushed. -u is not a problem, it's the normal fix for this. but i don't---at least i think i don't. in my httpd conf it says ``AddHandler cgi-script .py``, and at the top of my script, ``#!/usr/local/bin/python``. standard, no ``-u`` here. That may be part of the problem -- partial buffer not being written... Have you tried a flush operation on stdout? Just change the first line to ``#!/usr/local/bin/python -u``. You don't want buffered output in CGI apps. -- http://mail.python.org/mailman/listinfo/python-list
Re: Best python module for Oracle, but portable to other RDBMSes
[EMAIL PROTECTED] wrote: This is from a database I didn't design and can't change. The problem is that the ODBC module suffixes an L to any integer returned that was defined as data type number(p). For example, an integer stored as: 56 will be returned as 56L. Numbers that were specified as number(p,s), the module has no problem with. Anyone know why this would happen? I'm sure the Python tutorial explains the difference between integer and long types. Fields of type NUMBER or DECIMAL might well be larger than sys.maxint, so you always get longs back when you fetch data from such a column. This is as it should be. What seems to be the problem? If you actually get a suffixed L in the resulting text file, you are using a strange way to convert your data to text. You aren't simply printing lists or tuples are you? Then other types, such as datetime objects will also look bizarre. (Not that the ancient odbc would support that...) You might want to look at the csv module for text export. -- http://mail.python.org/mailman/listinfo/python-list
Re: Best python module for Oracle, but portable to other RDBMSes
[EMAIL PROTECTED] wrote: The other thing I didn't do a good job of explaining is that I want to have a layer of abstraction between the underlying RDBMS and the business logic. It's the business logic I want to use Python for, so that would stay roughly the same between RDBMS changes, if we ever have an RDBMS change. I agree that I probably have more things to worry if I was to change RDBMS vendors than what I'm describing here. Have a look at SQLAlchemy. -- http://mail.python.org/mailman/listinfo/python-list
