How to get a network resource on a windows server

2005-11-30 Thread Frank.Lin
I am new to learn program. please do me a favor. 

I am working in windows environment and I want copy some files from a
remote share folder.

I formerly mapped these share folers to a local device, then run my
python script to copy files matching the given pattern to destination
folder and deal with them

Now I want to let my script establish a connection between NULL device
name and a shared resource
then return a list of files matching the given pattern and copy them
to local host

I have installed Window Extensions but I do not know how to operate
this romote resource. 

who can give some instruction or a sample about it.  thanks!


best  reagards
Frank Lin
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: General question about Python design goals

2005-11-30 Thread Mike Meyer
"Donn Cave" <[EMAIL PROTECTED]> writes:
> Tuples and lists really are intended to serve two fundamentally different
> purposes.  We might guess that just from the fact that both are included
> in Python, in fact we hear it from Guido van Rossum, and one might add
> that other languages also make this distinction (more clearly than Python.)
>
> As I'm sure everyone still reading has already heard, the natural usage
> of a tuple is as a heterogenous sequence.  I would like to explain this
> using the concept of an "application type", by which I mean the set of
> values that would be valid when applied to a particular context.  For
> example, os.spawnv() takes as one of its arguments a list of command
> arguments, time.mktime() takes a tuple of time values.  A homogeneous
> sequence is one where  a  and  a[x:y]  (where x:y is not 0:-1)  have
> the same application type.  A list of command arguments is clearly
> homogeneous in this sense - any sequence of strings is a valid input,
> so any slice of this sequence must also be valid.  (Valid in the type
> sense, obviously the value and thus the result must change.)  A tuple
> of time values, though, must have exactly 9 elements, so it's heterogeneous
> in this sense, even though all the values are integer.
>
> One doesn't count elements in this kind of a tuple, because it's presumed
> to have a natural predefined number of elements.  One doesn't search for
> values in this kind of a tuple, because the occurrence of a value has
> meaning only in conjunction with its location, e.g., t[4] is how many
> minutes past the hour, but t[5] is how many seconds, etc.

I get all that, I really do. I would phrase it as "a tuple is a set of
attributes that happen to be named by integers." count doesn't make
sense on the attributes of an object - so it doesn't make sense on a
tuple. index doesn't make sense on the attributes of an object - so it
doesn't make sense on a tuple. A loop over the attributes of an object
doesn't make sense - so it doesn't make sense on a tuple.

So why the $*@& (please excuse my Perl) does "for x in 1, 2, 3" work?

Seriously. Why doesn't this have to be phrased as "for x in list((1,
2, 3))", just like you have to write list((1, 2, 3)).count(1), etc.?

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Making immutable instances

2005-11-30 Thread bonono

Mike Meyer wrote:
> [EMAIL PROTECTED] writes:
> > Quoting the frequently used term "Practicality beats purity". If I have
> > a practical problem/needs now and it solves it, why not use it ?
>
> In other words, you have a use case. Cool. Please tell us what it is -
> at least if it's better than "I think that's bad style."
>
Huh ? I said that if I need "immutable instance", I won't hestiate to
use __slot__, I didn't say I have a need.

In other words, I see __slot__ as a solution to the problem, I am not
saying I have the problem in the first place. The "practicabilty beats
purity" is used to support this using __slot__ situation, not about the
need of immutable instance.

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


Re: General question about Python design goals

2005-11-30 Thread Ben Finney
Donn Cave <[EMAIL PROTECTED]> wrote:
> Tuples and lists really are intended to serve two fundamentally
> different purposes.
> [...]
> As I'm sure everyone still reading has already heard, the natural
> usage of a tuple is as a heterogenous sequence. [...] A list of
> command arguments is clearly homogeneous in this sense - any
> sequence of strings is a valid input, so any slice of this sequence
> must also be valid.  (Valid in the type sense, obviously the value
> and thus the result must change.)  A tuple of time values, though,
> must have exactly 9 elements, so it's heterogeneous in this sense,
> even though all the values are integer.
> 
> I have to confess that this wasn't obvious to me, either, at first,
> and in fact probably about half of my extant code is burdened with
> the idea that a tuple is a smart way to economize on the overhead of
> a list. Somewhere along the line, I guess about 5 years ago? maybe
> from reading about it here, I saw the light on this, and since then
> my code has gotten easier to read and more robust.

Strangely, I learned this as I was learning the language, and
understood it after reading the explanation a couple of times (I can't
remember where I was reading it, but it must have been a decent
guide).

However, in the intervening time I'd forgotten this fundamental
difference between the *purpose* of list and tuple.

Thanks very much for this reminder. You've probably stopped me from
writing a bunch of misguided code and realising 5 years too late :-)

-- 
 \   "Timid men prefer the calm of despotism to the boisterous sea |
  `\ of liberty."  -- Thomas Jefferson |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list


Database Module in a Web Application

2005-11-30 Thread mohammad babaei
Hi,
I'm going to write my first web application in Python,
is it an good idea to write a database module that handles the connection to database & executing queries ?
 
 
Regards
M.B
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Making immutable instances

2005-11-30 Thread Mike Meyer
[EMAIL PROTECTED] writes:
> Quoting the frequently used term "Practicality beats purity". If I have
> a practical problem/needs now and it solves it, why not use it ?

In other words, you have a use case. Cool. Please tell us what it is -
at least if it's better than "I think that's bad style."

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: python speed

2005-11-30 Thread elbertlev
Isaac Gouy wrote:

> Which stated "Python is doing the heavy lifting with GMPY which is a
> compiled C program with a Python wrapper" - but didn't seem to compare
> that to GMPY with a Java wrapper?

You are missing the main idea: Java is by design a general purpose
programming language. That's why all "GMPYs" and alike are written in
Java - now wrappers to C-libraries. Python, by design, is glue
language. Python program is assembly of  C extensions and buildins
wrapped in Python sintax.

IHMO "real life" benchmark yuo are critisizing represents real life
situation.

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


Re: General question about Python design goals

2005-11-30 Thread Donn Cave
Quoth [EMAIL PROTECTED]:
| Christoph Zwerschke wrote:
...
|> Sorry, but I still do not get it. Why is it a feature if I cannot count
|> or find items in tuples? Why is it bad program style if I do this? So
|> far I haven't got any reasonable explanation and I think there is no.
|
| I have no idea, I can understand their view, not necessarily agree. And
| reasonable explanation is not something I usually find on this group,
| for issues like this.

It's hard to tell from this how well you do understand it, and of
course it's hard to believe another explanation is going to make
any difference to those who are basically committed to the opposing
point of view.  But what the hell.

Tuples and lists really are intended to serve two fundamentally different
purposes.  We might guess that just from the fact that both are included
in Python, in fact we hear it from Guido van Rossum, and one might add
that other languages also make this distinction (more clearly than Python.)

As I'm sure everyone still reading has already heard, the natural usage
of a tuple is as a heterogenous sequence.  I would like to explain this
using the concept of an "application type", by which I mean the set of
values that would be valid when applied to a particular context.  For
example, os.spawnv() takes as one of its arguments a list of command
arguments, time.mktime() takes a tuple of time values.  A homogeneous
sequence is one where  a  and  a[x:y]  (where x:y is not 0:-1)  have
the same application type.  A list of command arguments is clearly
homogeneous in this sense - any sequence of strings is a valid input,
so any slice of this sequence must also be valid.  (Valid in the type
sense, obviously the value and thus the result must change.)  A tuple
of time values, though, must have exactly 9 elements, so it's heterogeneous
in this sense, even though all the values are integer.

One doesn't count elements in this kind of a tuple, because it's presumed
to have a natural predefined number of elements.  One doesn't search for
values in this kind of a tuple, because the occurrence of a value has
meaning only in conjunction with its location, e.g., t[4] is how many
minutes past the hour, but t[5] is how many seconds, etc.

I have to confess that this wasn't obvious to me, either, at first, and
in fact probably about half of my extant code is burdened with the idea
that a tuple is a smart way to economize on the overhead of a list.
Somewhere along the line, I guess about 5 years ago? maybe from reading
about it here, I saw the light on this, and since then my code has gotten
easier to read and more robust.  Lists really are better for all the
kinds of things that lists are for -- just for example, [1] reads a lot
better than (1,) -- and the savings on overhead is not worth the cost to
exploit it.  My tendency to seize on this foolish optimization is however
pretty natural, as is the human tendency to try to make two similar things
interchangeable.  So we're happy to see that tuple does not have the
features it doesn't need, because it helps in a small way to make Python
code better.  If only by giving us a chance to have this little chat once
in a while.

Donn Cave, [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Making immutable instances

2005-11-30 Thread bonono

Mike Meyer wrote:
> [EMAIL PROTECTED] writes:
> > Mike Meyer wrote:
> >> [EMAIL PROTECTED] writes:
> >> > Well, in this case, would it be simple for the OP that if he wants to
> >> > disallow this attaching additional things, just use __slot__.
> >> That's *documented* as an implementation-dependent behavior. Using it
> >> to get that effect is abuse of the feature, and may well quit working
> >> in the future.
> > It still won't affect what is working, so it is harmless side effect,
> > if it ever changes in the future.
>
> If not allowing is required, then allowing is "not working", pretty
> much by definition.
>
> > Abuse or not doesn't matter so long it fits the needs, IMO.
>
> I guess it doesn't matter to you whether or not your code works in the
> future. It does to me.
>
For this particular case, I don't see it as a problem.

First it meets the need, works on 2.2, 2.3, 2.4. No one knows what
would change in the future, beside the fact that I don't see it as
implementation-dependent in the doc.

Adding to the fact that things can/may be removed even it is fully
documented, without this caveat emptor(like the famous reduce/map
etc.). That is if I read the document when I was writing python codes
in the early days and used reduce/map/filter/lambda, my code still
breaks if in one day those are removed and I can't forsee that either.

So why bother, unless it has some definitive schedule(like saying in
2.5, reduce won't be there or __slot__ behaviour will definitely
change), then I would consider if the code I write now should avoid
using it.

And back to this case, I regard it as a no harm side effect, yes, it
doesn't perform as expected(assume it really is changed in some unknown
version in the future) that someone does hang something there, it
doesn't hurt my expected usage of the class, as this is used to prevent
unexpected usage.

Quoting the frequently used term "Practicality beats purity". If I have
a practical problem/needs now and it solves it, why not use it ?

The zip(it,it) case is even worse than this __slot__ situation and I
don't have much problem in using that either. It is not unusual in this
industry that certain software only expects to be working with some
combination of OS/Compiler version.

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


Re: python speed

2005-11-30 Thread Mohammad Jeffry
I did a small test some time ago and I think python is faster then java:
http://linuxlah.blogspot.com/2005/11/swap-speed-for-python-c-c-and-java.html


On 11/30/05, Krystian <[EMAIL PROTECTED]> wrote:
Hiare there any future perspectives for Python to be as fast as java? iwould like to use Python as a language for writing games.best regardskrystian--
http://mail.python.org/mailman/listinfo/python-list-- And whoever does an atom's weight of evil will see it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Newbie: Python & Serial Port question

2005-11-30 Thread Peter Hansen
Sanjay Arora wrote:
> Am a python newbie. Does python have a native way to communicate with a
> PC serial port? I found that pyserial needs java.

This is not true unless you are using Jython.  The code in 
serial/__init__.py does this:

if os.name == 'nt': #sys.platform == 'win32':
 from serialwin32 import *
elif os.name == 'posix':
 from serialposix import *
elif os.name == 'java':
 from serialjava import *

so the java stuff will not be used on regular Python under "nt" 
(Windows) or Linux.


-Peter

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


Re: A bug in struct module on the 64-bit platform?

2005-11-30 Thread Neal Norwitz
[EMAIL PROTECTED] wrote:
> Hi,
>
> I have a user who complained about how "struct" module computes C
> struct data size on Itanium2 based 64-bit machine.

I wouldn't be surprised, but I don't understand the problem.

>>>struct.calcsize('idi')
>16
>>>struct.calcsize('idid')
>24
>>>struct.calcsize('did')
>20

These are what I would expect on a 32 or 64 bit platform.  i == int, d
== float.  ints are typically 4 bytes on 64 bit platforms.  If you want
8 byte integers, you typically need to use longs (format letter is ell,
l).

You didn't say which version of python, so it's possible this was a bug
that was fixed too.

On my system:

python: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
GNU/Linux 2.4.1, dynamically linked (uses shared libs), not stripped

>>> struct.calcsize('l') #that's a lowercase ell
8

If you think it's a bug, you should file a bug report on source forge.

n

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


Re: an intriguing wifi http server mystery...please help

2005-11-30 Thread jojoba
Hi again Istvan,

Good suggestion.
I have tried another server and it works flawlessly, regardless of the
computers being wireless or wired. Excellent.
However, i am still intrigued as to why the server is fast when both
computers are wireless and the desktop is the server (while the laptop
is the client), but slow when both computers are wireless and the
desktop is the client (while the laptop is the server).
I guess i am just curious as to what possible thing (most likely in
software, as we have discovered) could cause this assymetry.

Thanks for any ideas,
jojoba

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


Re: sax.make_parser() segfaults

2005-11-30 Thread Frank Millman

Frank Millman wrote:
> > Hi all
> >
> > I am using Python 2.4.1. I have machines running FC4, RH9, and MSW
> > Server 2003 for testing.
> >
> > If I call sax.make_parser() from the interpreter or from a stand-alone
> > program, it works fine on all machines, but in the following setup it
> > works correctly on MSW, but segfaults on both FC4 and RH9.
> >
> > The setup is a client program running wxPython as a gui, and Twisted as
> > a means of connecting to a server.
>
> Progress report - I have narrowed it down to wxPython. I wrote small
> stand-alone programs, one using Twisted, one using wxPython. Twisted
> works fine, wxPython segfaults.
>

No-one? I thought that a error like this in a standard module would be
of some concern, even if it turns out that the fault is with wxPython.

Anyway, I have found a workaround.

I call sax.make_parser() from the main line of the program, before
starting the wxPython main loop. The reference it returns is global,
and can be used anywhere within the program. This seems to work ok.

Frank

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


Re: Making immutable instances

2005-11-30 Thread Mike Meyer
[EMAIL PROTECTED] writes:
> Mike Meyer wrote:
>> [EMAIL PROTECTED] writes:
>> > Well, in this case, would it be simple for the OP that if he wants to
>> > disallow this attaching additional things, just use __slot__.
>> That's *documented* as an implementation-dependent behavior. Using it
>> to get that effect is abuse of the feature, and may well quit working
>> in the future.
> It still won't affect what is working, so it is harmless side effect,
> if it ever changes in the future.

If not allowing is required, then allowing is "not working", pretty
much by definition.

> Abuse or not doesn't matter so long it fits the needs, IMO.

I guess it doesn't matter to you whether or not your code works in the
future. It does to me.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: General question about Python design goals

2005-11-30 Thread Chris Mellon
On 11/30/05, Christoph Zwerschke <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> Paul Rubin wrote:
> Look at the list.count() example at the start of this thread.
> Diagnosing it isn't hard.  Curing it isn't hard.  It doesn't bloat
> Python by an order of magnitude.  A suitably factored implementation
> might handle lists and strings with the exact same code and not
incur
> any extra cost at all.  That type of thing happens all the time
here.
> 
> I believe the language creator use the "lack of" as a way to
> prevent/discourage that kind of usage. Just like the ternary
> operator(still don't know why it is finally accepted). It is not a
> problem(not having), it is a feature(to teach you program better),
so
> what cure are we talking about ?
> 
> Sorry, but I still do not get it. Why is it a feature if I cannot
count
> or find items in tuples? Why is it bad program style if I do this?
So
> far I haven't got any reasonable explanation and I think there is
no.
> 
> -- Christoph
> 

I'd have to say this:

First, remember that while your idea is obvious and practical and
straightforward to you, everybodys crummy idea is like that to them.
And while I'm not saying your idea is crummy, bear in mind that not
everyone is sharing your viewpoint.

If you want to make changes to the language, you need to be prepared
to convince other people that your idea really is a good one.
Therefore:

Be prepared to present a use case. If your idea really is
straightforward, simple, and obvious this should be fairly easy. It is
possible that your idea is so simple and obvious that everyone will
agree with it, do not expect this to be the case no matter how simple
and obvious it seems to you.

Be prepared to defend your use case. If people show reasons why your
use case is invalid, be prepared to consider that you may be wrong. If
you're still sure that you aren't, present a different use case -
don't expect other people to imagine one for you.

If you *really* want a language feature changed, be prepared to
present a patch for it. If you aren't willing or able to implement it
yourself, you must convince someone else that not only is your change
a good idea, but that it's a good enough idea that they should work on
it, which is always more of an uphill battle.

There may be different subjective or conceptual reasonings at work -
like you wanting to treat tuples as first class sequences while others
(like Guido) want to treat them otherwise. There's no right answer in
a subjective argument, so be prepared to present practical support,
and, unless you're the BDFL, be prepared to be ignored. If it bothers
you enough, you know what your options are.

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


RE: Making immutable instances

2005-11-30 Thread Delaney, Timothy (Tim)
Was it *really* necessary to send 4 separate emails to reply to four
sections of the same email?

Good netiquette is to intersperse your comments with quoted sections in
a single email.

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


Re: Making immutable instances

2005-11-30 Thread bonono

Mike Meyer wrote:
> And again, *what's the use case*? A number of people have asked why we
> shouldn't allow this, but none of them been able to come up with a use
> case better than "I think doing that is bad style."
>
oh, that is the usual argument anyway. It is nothing but style, most of
the time. Making a style thing into a right/wrong, better/worse
argument is really for time killing, there would never be real answer.

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


Re: Making immutable instances

2005-11-30 Thread bonono

Mike Meyer wrote:
> [EMAIL PROTECTED] writes:
> > Well, in this case, would it be simple for the OP that if he wants to
> > disallow this attaching additional things, just use __slot__.
>
> That's *documented* as an implementation-dependent behavior. Using it
> to get that effect is abuse of the feature, and may well quit working
> in the future.
>
I don't see it mention as implementation-dependent behaviour on this
page, and this is supposed to be "(for language lawyers)".

http://www.python.org/doc/2.4.2/ref/slots.html

If it really is implementation detail but not a binding to the language
feature, I think someone need to change the doc, at least make it more
clear on this page.

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


The pythonic way

2005-11-30 Thread Somesh
Hi,
I have started reWriting the stuffs under header 'The Pythonic way !',
the small code segments are kept at http://guruvision.in/ , pl let me
know more topics ideas to write, work. is there anyone who has worked
with python in geometry/maths domain ?

- somesh

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


Python CGI

2005-11-30 Thread jbrewer
I need to update a CGI script I have been working on to perform
validation of input files.  The basic idea is this:

1.) HTML page is served
2.) User posts file and some other info
3.) Check file for necessary data
* If data is missing, then post a 2nd page requesting needed data
* If data is present, continue to 4
4.) Process input file and display results (processing path depends on
whether data from 3 was present in file or had to be input by user)

I'm unsure of the best way to implement step 3.  Is it even possible to
put all of this into one script?  Or should I have one script check the
file for the data, then pass the info on to a 2nd script?  The
cgi.FieldStorage() function should only be called once, so it seems
like it's not possible to read a form and then repost another one and
read it.  If this is true and I need 2 scripts, how do I pass on the
information in step 3 automatically if the file has the proper data and
no user input is needed?

Sorry if this is a dumb question (or unclear), but this is my
(ever-growing) first CGI script.  Thanks.
Jeremy

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


Re: Making immutable instances

2005-11-30 Thread bonono

Mike Meyer wrote:
> [EMAIL PROTECTED] writes:
> > Well, in this case, would it be simple for the OP that if he wants to
> > disallow this attaching additional things, just use __slot__.
>
> That's *documented* as an implementation-dependent behavior. Using it
> to get that effect is abuse of the feature, and may well quit working
> in the future.
>
In this case, it seems to be fine. As the intend is just "not
allowing". Even it changes in the future, the worst case is just
"allowing", that fits your needs :-)

It still won't affect what is working, so it is harmless side effect,
if it ever changes in the future.

Abuse or not doesn't matter so long it fits the needs, IMO.

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


Re: improving pypi / setuptools

2005-11-30 Thread Alia Khouri
It is still early days for setuptools... still, we are lagging behind
the ruby world in this regards.

I definitely agree with you that the so-called megaframeworks need to
be packaged better (especially all versions of the different components
being updated on almost daily basis).

AK

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


Re: Making immutable instances

2005-11-30 Thread bonono

Mike Meyer wrote:
> > If the authors go to the length of not allowing it, so be it. They
> > are afterall define it for their use and how someone else will use
> > it don't matter.
>
> I take it you never distribute your code, or otherwise expect other
> people to reuse it?
>
No, distribute when necessary. But I define it and code it the way I
want, how and others will use it, curse it doesn't matter to me.

Of course, I would give suggestion(wish list bug as in debian term)
when I use other people's stuff, and see a particular usage that is not
there. But it ends just there, wish list.

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


Re: How to list currently defined classes, methods etc

2005-11-30 Thread Alex Martelli
Deep <[EMAIL PROTECTED]> wrote:

> yes that works.
> but, it gives one list, which contains everything.
> now about inferring types? :)

You may want to look at module inspect in the standard library.


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


Re: Making immutable instances

2005-11-30 Thread Mike Meyer
[EMAIL PROTECTED] writes:
> Well, in this case, would it be simple for the OP that if he wants to
> disallow this attaching additional things, just use __slot__.

That's *documented* as an implementation-dependent behavior. Using it
to get that effect is abuse of the feature, and may well quit working
in the future.

> What I wan to say though is, if we can live with the inability of not
> able to attach to built-in types, why is it so difficult for other user
> defined class ?

Because not being able to do it for built-in types is an
implementation detail, and a wart in the language.

And again, *what's the use case*? A number of people have asked why we
shouldn't allow this, but none of them been able to come up with a use
case better than "I think doing that is bad style."

> If the authors go to the length of not allowing it, so be it. They
> are afterall define it for their use and how someone else will use
> it don't matter.

I take it you never distribute your code, or otherwise expect other
people to reuse it?

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: HTML parsing/scraping & python

2005-11-30 Thread Mike Meyer
Sanjay Arora <[EMAIL PROTECTED]> writes:

> We are looking to select the language & toolset more suitable for a
> project that requires getting data from several web-sites in real-
> timehtml parsing/scraping. It would require full emulation of the
> browser, including handling cookies, automated logins & following
> multiple web-link paths. Multiple threading would be a plus but not
> requirement.

Believe it or not, everything you ask for can be done by Python out of
the box. But there are limitations.

For one, the HTML parsing module that comes with Python doesn't handle
invalid HTML very well. Thanks to Netscape, invalid HTML is the rule
rather than the exception on the web. So you probably want to use a
third party module for that. I use BeautifulSoup, which handles XML,
HTML, has a *lovely* API (going from BeautifulSoup to DOM is always a
major dissapointment), and works well with broken X/HTML.

That sufficient for my needs, but I haven't been asked to do a lot of
automated form filling, so the facilities in the standard library work
for me. There are third party tools to help with that. I'm sure
someone willsuggest them.

> Can you suggest solutions for python? Pros & Cons using Perl vs. Python?
> Why Python?

Because it's beautiful. Seriously, Python code is very readable, by
design. Of course, some of the features that make that happen drive
some people crazy. If you're one of them, then Python isn't the
language for you.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: wxPython - processes

2005-11-30 Thread novitk
ccahoon wrote:
> In wxPython, I want to be able to start downloading a file and have the
> window doing such remain interactive, so that the user can cancel
> downloading the next file.  Also, if there is a way to cancel a
> downloading process, what is it?
>
> I am using urllib.urlretrieve.  Thanks for any help, in advance.

Look into 'threading' module. You want to do downloading in a separate
thread, which you'd control from the main (GUI) thread. There is a
threading example in wxPython demo.

KN

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


Re: Making immutable instances

2005-11-30 Thread bonono

Mike Meyer wrote:
> Built-in types don't have a real dictionary. They have a C struct that
> holds the various methods.  The entries in the struct are called
> "slots", hence the __slots__ magic attribute. That __slots__ makes it
> impossible to add an attribute is documented as an implementation
> detail. This makes me think that the same restriction on the builtin
> types is the same.
>
> FWIW, dir returns a list built from a number of source. But if you
> look at, for example, list.__dict__, you'll notice that it's not a
> dict.
>
Well, in this case, would it be simple for the OP that if he wants to
disallow this attaching additional things, just use __slot__.

What I wan to say though is, if we can live with the inability of not
able to attach to built-in types, why is it so difficult for other user
defined class ? If the authors go to the length of not allowing it, so
be it. They are afterall define it for their use and how someone else
will use it don't matter.

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


Re: Making immutable instances

2005-11-30 Thread Mike Meyer
[EMAIL PROTECTED] writes:
> Mike Meyer wrote:
>> [EMAIL PROTECTED] writes:
>> > I am puzzled, and could have read what you want wrong. Are you saying
>> > you want something like this :
>> > a={}
>> > a.something = "I want to hang my stuff here, outside the intended use
>> > of dict"
>> Exactly. For a use case, consider calling select.select on lists of
>> file objects. If the processing is simple enough, the clearest way to
>> associate a handler with each socket is just to add it as an
>> attribute. But that doesn't work - sockets are bulitin types. So you
>> consider less light-weight solutions, like subclassing socket (now
>> that that's possible), or a dictionary of handlers keyed by socket.
>> This works by default with classes written in Python. That it doesn't
>> work for builtins is inconsistent, non-orthogonal, and
>> incomplete. However, it's easy to work around, and the obvious fix -
>> adding a dictionary to every builtin - is rather costly. So we'll live
>> with it since practicality beats purity.
> While I agree with the use case(I want it sometimes too), it seems that
> the language creator may also deliberately disallow that, not because
> it is not doable or costly. So how, the built-in types still need to
> have some form of dictionary or else how would dir(a) of the above
> dictionary work ?

Built-in types don't have a real dictionary. They have a C struct that
holds the various methods.  The entries in the struct are called
"slots", hence the __slots__ magic attribute. That __slots__ makes it
impossible to add an attribute is documented as an implementation
detail. This makes me think that the same restriction on the builtin
types is the same.

FWIW, dir returns a list built from a number of source. But if you
look at, for example, list.__dict__, you'll notice that it's not a
dict.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Recursion bug...

2005-11-30 Thread ex_ottoyuhr

[EMAIL PROTECTED] wrote:
> ex_ottoyuhr wrote:
> > class TreeCommand:
> > opcode = 0
> > children = []
> > def __init__(self, anOpcode) :
> > opcode = anOpcode
> >
> opcode and children in this case is more like "class" variable in C++.
> If you want "instance" variable, you need to do it as self.opcode,
> self.children, in all methods.

Thanks a lot. I'm sorry to have bothered you and the newsgroup with
such a simple problem, but then again, I'm glad it was simple, and I
suppose that's what newsgroups are for... :)

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


Re: Recursion bug...

2005-11-30 Thread ex_ottoyuhr

Devan L wrote:


> Well, for one, in your __init__ method, you never do anything with
> anOpcode. You simply assign the name 'opcode' to anOpcode. The reason
> why everything is the same is that you're accessing
> TreeCommand.children or Treecommand.opcode, which is shared by all
> instances unless you assign to it.

OK, _that's_ what I was doing wrong... Thanks a lot. I suspected it
might be a product of C++-isms and being self-taught in the language...

> And you never increment generated,
> so I don't see why the while loop would ever end, unless you
> intentionally wanted that.

I just forgot to add that part -- I was demi-transcribing it, you might
put it, as opposed to actually copying. There were a few bugs in that
part... :P

> Try this code instead:
> 


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


Re: wxPython installation issues on Debian

2005-11-30 Thread Chris Mellon
On 11/30/05, Robert Kern <[EMAIL PROTECTED]> wrote:
> Paul McNett wrote:
> > Robert Kern wrote:
> >
> >>Although Ubuntu is a Debian derivative, it does have different packages.
> >>At the moment, Debian's default Python is 2.3 although one can also
> >>install Python 2.4, and most Python packages in Debian have been built
> >>for both (that's why I erroneously recommended installing the apparently
> >>nonexistant python2.4-wxgtk2.4). However, it appears that the maintainer
> >>of the Debian wxPython is not building packages for both Python 2.3 and
> >>2.4. The maintainer of the Ubuntu wxPython package apparently is.
> >
> > As far as I know, the maintainer of the wxPython package is the same (Ron) 
> > and
> > Ubuntu just uses the upstream wxPython from Debian. However, I see above 
> > that
> > you are referencing wxPython 2.4 and not 2.6. It is very possible that for
> > wxPython 2.4, there is only a Python 2.3 package.
> >
> > wxPython 2.4 is obsolete. If possible, wxPython 2.6 should be used. But, I 
> > don't
> > know if it is available for Python 2.4 under Debian (or Ubuntu, for that 
> > matter).
>
> Still only available for Python 2.3 it seems.
>
> http://packages.debian.org/testing/python/python-wxgtk2.6
> http://packages.qa.debian.org/w/wxwidgets2.6.html
>

The ubuntu patch available from the second link seems to provide
support for Python 2.4 (judging from a quick skim). If you're feeling
adventurous, maybe you could try applying that and installing. Or
perhaps just installing the ubuntu package manually, or try using
alien on one of the official RPMs.

> --
> Robert Kern
> [EMAIL PROTECTED]
>
> "In the fields of hell where the grass grows high
>  Are the graves of dreams allowed to die."
>   -- Richard Harter
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list


Pydoc: restrict base class doc?

2005-11-30 Thread Tony Nelson
I'd like to prevent Pydoc from adding base class documentation for some 
of my classes.  Specifically, I have a couple of classes that derive 
from GTK widgets, and dumping all that documentation in doesn't have 
much benefit.  Is there some thing I can do in my source, or to Pydoc, 
to tell it to skip some base classes?

TonyN.:'[EMAIL PROTECTED]
  '  
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Recursion bug...

2005-11-30 Thread bonono

ex_ottoyuhr wrote:
> class TreeCommand:
> opcode = 0
> children = []
> def __init__(self, anOpcode) :
> opcode = anOpcode
>
opcode and children in this case is more like "class" variable in C++.
If you want "instance" variable, you need to do it as self.opcode,
self.children, in all methods.

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


Re: Newbie: Python & Serial Port question

2005-11-30 Thread Kinsley Turner


[EMAIL PROTECTED] wrote on 
30/11/2005 07:48:39 PM:

> Am a python newbie. Does python have a native way to communicate with a
> PC serial port? I found that pyserial needs java.
> 
> I am using Linux..CentOS 4.2, to be exact, no java installed and
> zilch/no/none/maybe never experience of java too.
> 
> I have an application where I want to resd logs from the serial port of
> an EPABX and log them to a postgreSQL database. What's the best way to
> do this using python? Does anyone know of an existing software/python
> library/module for this?


You can't just open the serial port like a file?

Perhaps you'd need to set the correct port parameters
with some other app, but it should be do-able.


-kt



















(non-removable, sorry)
--


Please consider our environment before printing this email.

WARNING - This email and any attachments may be confidential. If received in 
error, please delete and inform us by return email. Because emails and 
attachments may be interfered with, may contain computer viruses or other 
defects and may not be successfully replicated on other systems, you must be 
cautious. Westpac cannot guarantee that what you receive is what we sent. If 
you have any doubts about the authenticity of an email by Westpac, please 
contact us immediately.

It is also important to check for viruses and defects before opening or using 
attachments. Westpac's liability is limited to resupplying any affected 
attachments.


This email and its attachments are not intended to constitute any form of 
financial advice or recommendation of, or an offer to buy or offer to sell, any 
security or other financial product. We recommend that you seek your own 
independent legal or financial advice before proceeding with any investment 
decision.

Westpac Institutional Bank is a division of Westpac Banking Corporation, a 
company registered in New South Wales in Australia under the Corporations Act 
2001 (Cth). Westpac is authorised and regulated in the United Kingdom by the 
Financial Services Authority and is registered at Cardiff in the United Kingdom 
as Branch No. BR 106. Westpac operates in the United States of America as a 
federally chartered branch, regulated by the Office of the Comptroller of the 
Currency.

Westpac Banking Corporation ABN 33 007 457 141.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: How to list currently defined classes, methods etc

2005-11-30 Thread Deep
Awesome just what i was looking for
now sheepishly i shall RTFM :)

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


Re: importing a method

2005-11-30 Thread Alex Martelli
Martin Miller <[EMAIL PROTECTED]> wrote:

> You're not missing anything -- it's my own [mis-]understanding that
> descriptors would only work with new-style classes, not the old-style
> ones used in the OP's example.
> 
> However your example certainly proves that is not the case, even if you
> go one step further and call the bound method/function:
> >>> o.z()
> <__main__.old instance at 0x009D5F30>
> 
> So I stand corrected -- thank you.

You're welcome.  Your previous misunderstanding may be due to the fact
that (differently from __get__) the special method __set__ doesn't work
when the descriptor is held in an old-style class... to be more precise,
it's not even given a chance, since assigning to an instance attribute
(where the instance's old-style) just blithely sets the value in the
instance's __dict__, without even checking for the existence of a
descriptor by that name in the class.


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


Re: Recursion bug...

2005-11-30 Thread Devan L
ex_ottoyuhr wrote:
> To start with, I'm new at Python, so if this is something relatively
> ordinary or a symptom of thinking in C++, I apologize...
>
> Anyhow, I'm currently trying to write a means of generating
> genetic-programming functions in Python; the details would be a little
> much for a Usenet post, but suffice it to say that it would involve
> trees of objects with an opcode and a variable number, between in this
> case 0 and 3, of 'arguments' -- also objects of the same sort. As a
> function to implement them, I'm doing something to the effect of this:
>
> [ex_ottoyuhr's code]
>
> Sorry to have given such a long example... But anyways, the problem is
> that, while I think this should generate a number of children for each
> toRet equivalent to the required number of children, it's actually
> appending all children generated in the function to the 'root' toRet
> rather than to child functions -- so that if I ask for a tree with
> depth 2, and the root would have 2 arguments, the first child would
> have 1, and the second child would have 2, the result is a root with a
> 5-argument-long children and two child functions with 0-argument ones.
> There's some other strange stuff going on here, too; in particular,
> with one particular opcode, toRet is assigned a member 'value' which is
> randomly generated between 0 and 10,000. All toRets assigned value seem
> to be ending up with the same result...
>
> Could anyone explain what I'm doing wrong? I'm beginning to suspect
> that Python scope rules must not work like my native C++; have I made a
> common mistake?

Well, for one, in your __init__ method, you never do anything with
anOpcode. You simply assign the name 'opcode' to anOpcode. The reason
why everything is the same is that you're accessing
TreeCommand.children or Treecommand.opcode, which is shared by all
instances unless you assign to it. And you never increment generated,
so I don't see why the while loop would ever end, unless you
intentionally wanted that. Try this code instead:

max_opcode = 20
max_with_args = 15

class TreeCommand:
def __init__(self, opcode) :
self.opcode = opcode
self.children = []

def MakeTreeCommand(depth, maxdepth) :
if depth == 0:
command = TreeCommand(random.randint(0, max_with_args)
elif depth == maxdepth:
command = TreeCommand(random.randint(max_with_args+1,
max_opcode))
else:
command = TreeCommand(random.randint(0, max_opcode))

if command.opcode <= max_with_args:
children_required = something_greater_than_0
else:
children_required = 0

generated = 0

for i in range(children_required):
command.children.append(MakeTreeCommand(depth+1, maxdepth))

return command

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


HTML parsing/scraping & python

2005-11-30 Thread Sanjay Arora
We are looking to select the language & toolset more suitable for a
project that requires getting data from several web-sites in real-
timehtml parsing/scraping. It would require full emulation of the
browser, including handling cookies, automated logins & following
multiple web-link paths. Multiple threading would be a plus but not
requirement.

Some solutions were suggested:

Perl:

LWP::Simple
WWW::Mechanize
HTML::Parser

Curl & libcurl:

Can you suggest solutions for python? Pros & Cons using Perl vs. Python?
Why Python?

Pointers to  various other tools & their comparisons  with python
solutions will be most appreciated. Anyone who is knowledgeable about
the application subject, please do share your knowledge to help us do
this right.

With best regards.
Sanjay.

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


Newbie: Python & Serial Port question

2005-11-30 Thread Sanjay Arora
Am a python newbie. Does python have a native way to communicate with a
PC serial port? I found that pyserial needs java.

I am using Linux..CentOS 4.2, to be exact, no java installed and
zilch/no/none/maybe never experience of java too.

I have an application where I want to resd logs from the serial port of
an EPABX and log them to a postgreSQL database. What's the best way to
do this using python? Does anyone know of an existing software/python
library/module for this?

Please help.

With best regards.
Sanjay.


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


Re: How to list currently defined classes, methods etc

2005-11-30 Thread Bengt Richter
On Wed, 30 Nov 2005 20:55:46 -0500, Peter Hansen <[EMAIL PROTECTED]> wrote:

>Deep wrote:
>> If i start a python shell. Is there a way to list the currently defined
>> classes, methods,
>> variables?
>
>Does this work?
>
> >>> dir()
>
  >>> help(__name__)

might be interesting for the OP too ;-)

Regards,
Bengt Richter
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Is Python string immutable?

2005-11-30 Thread Chris Mellon
On 11/30/05, could ildg <[EMAIL PROTECTED]> wrote:
> In java and C# String is immutable, str=str+"some more" will return a new
> string and leave some gargabe.
> so in java and C# if there are some frequent string operation,
> StringBuilder/StringBuffer is recommanded.
>
> Will string operation in python also leave some garbage? I implemented a
> net-spider in python which includes many html string procession. After it
> running for sometime, the python exe eats up over 300M memory. Is this
> because the string garbages?
>
> If String in python is immutable, what class should I use to avoid too much
> garbages when processing strings frequently?

Python strings are immutable. The StringIO class provides a buffer
that you can manipulate like a file, and then convert to a string and
is probably most suitable for your purposes.

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


Recursion bug...

2005-11-30 Thread ex_ottoyuhr
To start with, I'm new at Python, so if this is something relatively
ordinary or a symptom of thinking in C++, I apologize...

Anyhow, I'm currently trying to write a means of generating
genetic-programming functions in Python; the details would be a little
much for a Usenet post, but suffice it to say that it would involve
trees of objects with an opcode and a variable number, between in this
case 0 and 3, of 'arguments' -- also objects of the same sort. As a
function to implement them, I'm doing something to the effect of this:

max_opcode = ( 20, )
max_with_arguments = ( 15, )

class TreeCommand:
opcode = 0
children = []
def __init__(self, anOpcode) :
opcode = anOpcode

def MakeTreeCommand( maxdepth, currdepth ) :
if ( currdepth == 0 ) :
toRet = TreeCommand(random.randint(0, max_with_arguments[0])
elif ( maxdepth == currdepth ) :
toRet = TreeCommand(random.randint(max_with_arguments[0]+1,
max_opcode[0]))
else :
toRet = TreeCommand(random.randint(0, max_opcode[0]))

if ( toRet.opcode <= max_with_arguments[0] ) :
childrenRequired = something_greater_than_0
else :
childrenRequired = 0

generated = 0

while ( generated < childrenRequired ) :
toRet.children.append(MakeTreeCommand(maxdepth, currdepth + 1))

return toRet

Sorry to have given such a long example... But anyways, the problem is
that, while I think this should generate a number of children for each
toRet equivalent to the required number of children, it's actually
appending all children generated in the function to the 'root' toRet
rather than to child functions -- so that if I ask for a tree with
depth 2, and the root would have 2 arguments, the first child would
have 1, and the second child would have 2, the result is a root with a
5-argument-long children and two child functions with 0-argument ones.
There's some other strange stuff going on here, too; in particular,
with one particular opcode, toRet is assigned a member 'value' which is
randomly generated between 0 and 10,000. All toRets assigned value seem
to be ending up with the same result...

Could anyone explain what I'm doing wrong? I'm beginning to suspect
that Python scope rules must not work like my native C++; have I made a
common mistake?

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


Re: General question about Python design goals

2005-11-30 Thread Chris Mellon
On 11/30/05, Christoph Zwerschke <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Paul Rubin wrote:
> >>Look at the list.count() example at the start of this thread.
> >>Diagnosing it isn't hard.  Curing it isn't hard.  It doesn't bloat
> >>Python by an order of magnitude.  A suitably factored implementation
> >>might handle lists and strings with the exact same code and not incur
> >>any extra cost at all.  That type of thing happens all the time here.
> >
> > I believe the language creator use the "lack of" as a way to
> > prevent/discourage that kind of usage. Just like the ternary
> > operator(still don't know why it is finally accepted). It is not a
> > problem(not having), it is a feature(to teach you program better), so
> > what cure are we talking about ?
>
> Sorry, but I still do not get it. Why is it a feature if I cannot count
> or find items in tuples? Why is it bad program style if I do this? So
> far I haven't got any reasonable explanation and I think there is no.
>
> -- Christoph


I'd have to say this:

First, remember that while your idea is obvious and practical and
straightforward to you, everybodys crummy idea is like that to them.
And while I'm not saying your idea is crummy, bear in mind that not
everyone is sharing your viewpoint.

If you want to make changes to the language, you need to be prepared
to convince other people that your idea really is a good one.
Therefore:

Be prepared to present a use case. If your idea really is
straightforward, simple, and obvious this should be fairly easy. It is
possible that your idea is so simple and obvious that everyone will
agree with it, do not expect this to be the case no matter how simple
and obvious it seems to you.

Be prepared to defend your use case. If people show reasons why your
use case is invalid, be prepared to consider that you may be wrong. If
you're still sure that you aren't, present a different use case -
don't expect other people to imagine one for you.

If you *really* want a language feature changed, be prepared to
present a patch for it. If you aren't willing or able to implement it
yourself, you must convince someone else that not only is your change
a good idea, but that it's a good enough idea that they should work on
it, which is always more of an uphill battle.

There may be different subjective or conceptual reasonings at work -
like you wanting to treat tuples as first class sequences while others
(like Guido) want to treat them otherwise. There's no right answer in
a subjective argument, so be prepared to present practical support,
and, unless you're the BDFL, be prepared to be ignored. If it bothers
you enough, you know what your options are.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: How to list currently defined classes, methods etc

2005-11-30 Thread Deep
yes that works.
but, it gives one list, which contains everything.
now about inferring types? :)

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


Re: (newbie) N-uples from list of lists

2005-11-30 Thread bonono
Interesting, I found a reduce one liner(just one step further of
Raymond's) easiest to understand and match my thinking about what the
problem is about.

That once again tell me that different people think and approach the
problem differently. It is possible to talk about one "fastest" way,
but many times there isn't such a thing of one "best" way.

Martin Miller wrote:
> FWIW, I found Steven Taschuk's solution easiest to understand regarding
> the question posed in your original post -- namely how to solve the
> problem non-recursively with generators -- because it was similar to my
> own thinking about how to do it -- but suspect that Raymond Hettinger's
> is the likely the "best" (as is usually the case ;-).
>
> Best,
> -Martin
>
>
> [EMAIL PROTECTED] wrote:
> > great thanks to all.
> >
> > actually i have not seen it was a cross product... :) but then there
> > are already few others ideas from the web, i paste what i have found
> > below...
> >
> > BTW i was unable to choose the best one, speaking about performance
> > which one should be prefered ?
> >
> > ### --
> >
> > ### from title: variable X procuct - [(x,y) for x in list1 for y in
> > list2]
> > ### by author:  steindl fritz
> > ### 28 mai 2002
> > ### reply by:   Jeff Epler
> >
> > def cross(l=None, *args):
> > if l is None:
> > # The product of no lists is 1 element long,
> > # it contains an empty list
> > yield []
> > return
> > # Otherwise, the product is made up of each
> > # element in the first list concatenated with each of the
> > # products of the remaining items of the list
> > for i in l:
> > for j in cross(*args):
> > yield [i] + j
> >
> > ### reply by:   Raymond Hettinger
> >
> > def CartesianProduct(*args):
> > ans = [()]
> > for arg in args:
> > ans = [ list(x)+[y] for x in ans for y in arg]
> > return ans
> >
> > """
> > print CartesianProduct([1,2], list('abc'), 'do re mi'.split())
> > """
> >
> > ### from:
> > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/159975
> > ### by: Raymond Hettinger
> >
> > def cross(*args):
> > ans = [[]]
> > for arg in args:
> > ans = [x+[y] for x in ans for y in arg]
> > return ans
> >
> > ### from:
> > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/159975
> > ### by: Steven Taschuk
> > """
> > Iterator version, Steven Taschuk, 2003/05/24
> > """
> > def cross(*sets):
> > wheels = map(iter, sets) # wheels like in an odometer
> > digits = [it.next() for it in wheels]
> > while True:
> > yield digits[:]
> > for i in range(len(digits)-1, -1, -1):
> > try:
> > digits[i] = wheels[i].next()
> > break
> > except StopIteration:
> > wheels[i] = iter(sets[i])
> > digits[i] = wheels[i].next()
> > else:
> > break

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


Re: Making immutable instances

2005-11-30 Thread bonono

Mike Meyer wrote:
> [EMAIL PROTECTED] writes:
> > I am puzzled, and could have read what you want wrong. Are you saying
> > you want something like this :
> >
> > a={}
> > a.something = "I want to hang my stuff here, outside the intended use
> > of dict"
>
> Exactly. For a use case, consider calling select.select on lists of
> file objects. If the processing is simple enough, the clearest way to
> associate a handler with each socket is just to add it as an
> attribute. But that doesn't work - sockets are bulitin types. So you
> consider less light-weight solutions, like subclassing socket (now
> that that's possible), or a dictionary of handlers keyed by socket.
>
> This works by default with classes written in Python. That it doesn't
> work for builtins is inconsistent, non-orthogonal, and
> incomplete. However, it's easy to work around, and the obvious fix -
> adding a dictionary to every builtin - is rather costly. So we'll live
> with it since practicality beats purity.
>
While I agree with the use case(I want it sometimes too), it seems that
the language creator may also deliberately disallow that, not because
it is not doable or costly. So how, the built-in types still need to
have some form of dictionary or else how would dir(a) of the above
dictionary work ?

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


Re: General question about Python design goals

2005-11-30 Thread bonono

Christoph Zwerschke wrote:
> [EMAIL PROTECTED] wrote:
> > Paul Rubin wrote:
> >>Look at the list.count() example at the start of this thread.
> >>Diagnosing it isn't hard.  Curing it isn't hard.  It doesn't bloat
> >>Python by an order of magnitude.  A suitably factored implementation
> >>might handle lists and strings with the exact same code and not incur
> >>any extra cost at all.  That type of thing happens all the time here.
> >
> > I believe the language creator use the "lack of" as a way to
> > prevent/discourage that kind of usage. Just like the ternary
> > operator(still don't know why it is finally accepted). It is not a
> > problem(not having), it is a feature(to teach you program better), so
> > what cure are we talking about ?
>
> Sorry, but I still do not get it. Why is it a feature if I cannot count
> or find items in tuples? Why is it bad program style if I do this? So
> far I haven't got any reasonable explanation and I think there is no.
>
I have no idea, I can understand their view, not necessarily agree. And
reasonable explanation is not something I usually find on this group,
for issues like this.

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


Re: How to list currently defined classes, methods etc

2005-11-30 Thread Peter Hansen
Deep wrote:
> If i start a python shell. Is there a way to list the currently defined
> classes, methods,
> variables?

Does this work?

 >>> dir()

-Peter

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


Is Python string immutable?

2005-11-30 Thread could ildg
In java and C# String is immutable, str=str+"some more" will return a new string and leave some gargabe. 
so in java and C# if there are some frequent string operation, StringBuilder/StringBuffer is recommanded.
 
Will string operation in python also leave some garbage? I implemented a net-spider in python which includes many html string procession. After it running for sometime, the python exe eats up over 300M memory. Is this because the string garbages? 

 
If String in python is immutable, what class should I use to avoid too much garbages when processing strings frequently?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ANN: Dao Language v.0.9.6-beta is release!

2005-11-30 Thread sszmidt
Please trim replies... ; )

-- 

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


How to list currently defined classes, methods etc

2005-11-30 Thread Deep
If i start a python shell. Is there a way to list the currently defined
classes, methods,
variables?

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


Re: How could I ask Thread B to call B().Method() from inside Thread A's run?

2005-11-30 Thread could ildg
Thank you.On 30 Nov 2005 09:30:23 -0800, NavyJay <[EMAIL PROTECTED]> wrote:
I agree with jmj's solution, you would want to send a signal of somesort to Thread B from A when some event occurs in A.  A queue is oneway to do it, but keep in mind that there are numerous ways tocommunicate between threads/processes (queue, pipe, exit status,
TCP/UDP message, etc.).  I believe one of the first couple chapters inO'Reilly's "Programming Python" book discusses most of these methods.Choose the simplest one that meets your needs.--
http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

One module cannot be found by the interpreter

2005-11-30 Thread Anthony Liu
I downloaded and built the python/c++ maxent package (
http://homepages.inf.ed.ac.uk/s0450736/maxent_toolkit.html
). 

I don't know what happened, the interpreter cannot
find the cmaxent module, whereas cmaxent.py is right
under the current directory.

>>> from maxent import *
cmaxent module not found, fall back to python
implementation.
>>> 

Could you please kindly advise?

Thanks a lot.



__ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free. 
http://music.yahoo.com/unlimited/
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: wxPython installation issues on Debian

2005-11-30 Thread Robert Kern
Paul McNett wrote:
> Robert Kern wrote:
> 
>>Although Ubuntu is a Debian derivative, it does have different packages.
>>At the moment, Debian's default Python is 2.3 although one can also
>>install Python 2.4, and most Python packages in Debian have been built
>>for both (that's why I erroneously recommended installing the apparently
>>nonexistant python2.4-wxgtk2.4). However, it appears that the maintainer
>>of the Debian wxPython is not building packages for both Python 2.3 and
>>2.4. The maintainer of the Ubuntu wxPython package apparently is.
> 
> As far as I know, the maintainer of the wxPython package is the same (Ron) 
> and 
> Ubuntu just uses the upstream wxPython from Debian. However, I see above that 
> you are referencing wxPython 2.4 and not 2.6. It is very possible that for 
> wxPython 2.4, there is only a Python 2.3 package.
> 
> wxPython 2.4 is obsolete. If possible, wxPython 2.6 should be used. But, I 
> don't 
> know if it is available for Python 2.4 under Debian (or Ubuntu, for that 
> matter).

Still only available for Python 2.3 it seems.

http://packages.debian.org/testing/python/python-wxgtk2.6
http://packages.qa.debian.org/w/wxwidgets2.6.html

-- 
Robert Kern
[EMAIL PROTECTED]

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

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


Re: wxPython installation issues on Debian

2005-11-30 Thread Paul McNett
Robert Kern wrote:
> Although Ubuntu is a Debian derivative, it does have different packages.
> At the moment, Debian's default Python is 2.3 although one can also
> install Python 2.4, and most Python packages in Debian have been built
> for both (that's why I erroneously recommended installing the apparently
> nonexistant python2.4-wxgtk2.4). However, it appears that the maintainer
> of the Debian wxPython is not building packages for both Python 2.3 and
> 2.4. The maintainer of the Ubuntu wxPython package apparently is.

As far as I know, the maintainer of the wxPython package is the same (Ron) and 
Ubuntu just uses the upstream wxPython from Debian. However, I see above that 
you are referencing wxPython 2.4 and not 2.6. It is very possible that for 
wxPython 2.4, there is only a Python 2.3 package.

wxPython 2.4 is obsolete. If possible, wxPython 2.6 should be used. But, I 
don't 
know if it is available for Python 2.4 under Debian (or Ubuntu, for that 
matter).

-- 
Paul McNett
http://paulmcnett.com
http://dabodev.com

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


Re: an intriguing wifi http server mystery...please help

2005-11-30 Thread Istvan Albert
> But if it's a problem with the software,  why does the server work
> great when wired (i.e. not wireless)...that's the weird part.

Don't be  so quick to eliminate software error ... when it comes to
bugs there are few rules. You are using a recipe that is *known* to
produce weird behavior. Make sure to eliminate that source before
moving to more esoteric reasons such as bad routing table. For example
run some other simple webservers that  were written in some other
language and see if you get the same behavior (tinyhttpd or its ilk) .

Istvan.

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


Re: Code returns error when not supposed to

2005-11-30 Thread amfr
Never mind, figured out

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


Code returns error when not supposed to

2005-11-30 Thread amfr
This code always returns a ValueError when it is not supposed to:
i = rest.rfind('?')

Error:
ValueError: need more than 0 values to unpack

rfind is not supposed to generate an erro, just return -1. Any ideas?

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


Re: wxPython installation issues on Debian

2005-11-30 Thread Robert Kern
Paul McNett wrote:
> [EMAIL PROTECTED] wrote:
> 
>>Thanks a lot for the clarification. I don't have a compelling reason
>>not to use 2.3 other than having to install the modules I've already
>>set up for 2.4. Not really a big deal. Looks like I'll be switching to
>>2.3.
> 
> Umm, for what it's worth: I'm on Ubuntu (a Debian derivative), using Python 
> 2.4.2 and wxPython 2.6. The wxPython was installed using 'apt-get install 
> python-wxGtk2.6'.
> 
> So I don't know why you say you need to use Python 2.3 as I don't even have 
> that 
> on my system.

Although Ubuntu is a Debian derivative, it does have different packages.
At the moment, Debian's default Python is 2.3 although one can also
install Python 2.4, and most Python packages in Debian have been built
for both (that's why I erroneously recommended installing the apparently
nonexistant python2.4-wxgtk2.4). However, it appears that the maintainer
of the Debian wxPython is not building packages for both Python 2.3 and
2.4. The maintainer of the Ubuntu wxPython package apparently is.

-- 
Robert Kern
[EMAIL PROTECTED]

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

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


Re: wxPython installation issues on Debian

2005-11-30 Thread Paul McNett
[EMAIL PROTECTED] wrote:
> Thanks a lot for the clarification. I don't have a compelling reason
> not to use 2.3 other than having to install the modules I've already
> set up for 2.4. Not really a big deal. Looks like I'll be switching to
> 2.3.

Umm, for what it's worth: I'm on Ubuntu (a Debian derivative), using Python 
2.4.2 and wxPython 2.6. The wxPython was installed using 'apt-get install 
python-wxGtk2.6'.

So I don't know why you say you need to use Python 2.3 as I don't even have 
that 
on my system.

-- 
Paul McNett
http://paulmcnett.com
http://dabodev.com

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


Python Guru Needed Fast!!!!

2005-11-30 Thread j-rock
Talking Panda LLC is looking for a programmer to take over building
applications for the iPod.
Required skills below.
Please email me personally.
[EMAIL PROTECTED]

- Expertise in text parsing and formatting.  Specifically,
developing parsers to extract meaningful information from freeform
text, XML, HTML, SGML, spreadsheets and translate it to other
formats.
- Experience with and ideally preference for Python
- The creativity required to come up with solutions that work
within the constraints of the iPod Note Reader (up to 1000 notes
at 4kb each, limited formatting options, etc.).

The following skills are also a bonus:
- Tkinter and/or Win32 API programming
- COM
- Apple Events
- PyObjC / Cocoa
- Web development

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


Re: importing a method

2005-11-30 Thread Martin Miller
You're not missing anything -- it's my own [mis-]understanding that
descriptors would only work with new-style classes, not the old-style
ones used in the OP's example.

However your example certainly proves that is not the case, even if you
go one step further and call the bound method/function:
>>> o.z()
<__main__.old instance at 0x009D5F30>

So I stand corrected -- thank you.

Best,
-Martin

==
Alex Martelli wrote:
> Martin Miller <[EMAIL PROTECTED]> wrote:
>
> > I'd like to point out to the OP that using a function's __get__ method
> > this way only works with new-style classes and their instances...not
> > with the example in the shown in original post.
>
> Uh, why not?
>
> >>> class old: pass
> ...
> >>> def f(self): print self
> ...
> >>> o=old()
> >>> o.z = f.__get__(o, old)
> >>> o.z
> >
> >>>
>
> There's a million reason to avoid using old-style classes in new code,
> but it doesn't seem to me that this is one of them.  What am I missing?
> 
> 
> Alex

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


Re: importing a method

2005-11-30 Thread Martin Miller
Sorry, I seldom look at the built-in __doc__ strings or use the
'help()' function.  Instead I usually refer to the html or winhelp
versions of the documentation, and for Python 2.4.1 there's nothing in
section 3.28 on the 'new' module that mentions that it deprecated -- so
thanks to you and Flávio for the information.

Using help on MethodType gave me the following somewhat surprising
output [truncated here]:
>>> import types
>>> help(types.MethodType)
Help on class instancemethod in module __builtin__:

class instancemethod(object)
 |  instancemethod(function, instance, class)
 |
 |  Create an instance method object.
[snip]

Which I take to mean that 'instancemethod' is no longer [just] a
function in the deprecated 'new' module but is also a built-in class.

However and somewhat confusingly (to me anyway), a search in the help
docs file turns up the following:

> 7.5.3  Method Objects
> There are some useful functions that are useful for working with method 
> objects.
>
> PyTypeObject  PyMethod_Type
>   This instance of PyTypeObject represents the Python method type. This is
>   exposed to Python programs as types.MethodType.
>   ...
[snip]

Which, as you can see, claims that types.MethodType is actually an
instance of a PyTypeObject (not the class instancemethod that
help(types.MethodType) indicated).

Best,
-Martin


Steven D'Aprano wrote:
> On Mon, 28 Nov 2005 08:16:12 -0800, Martin Miller wrote:
>
> > First of all,why do you think the new module is deprecated?  (I can't
> > find anything in the docs to indicate this.)
>
> Did you try help(new) from an interactive prompt?
>
>
> py> new.__doc__.splitlines()[0]
> 'Create new objects of various types.  Deprecated.'
>
>
> --
> Steven.


Flávio wrote:
> > First of all,why do you think the new module is deprecated?  (I can't
> > find anything in the docs to indicate this.)
>
> Its in the docs of python 2.4. I dont know about older versions:
>
> Help on module new:
>
> NAME
> new - Create new objects of various types.  Deprecated.
>
> FILE
> /usr/lib/python2.4/new.py
>
> MODULE DOCS
> /usr/share/doc/python-docs-2.4.2/html/module-new.html
>
> DESCRIPTION
> This module is no longer required except for backward
> compatibility.
> Objects of most types can now be created by calling the type
> object.
>
> > As for using MethodType in the types module:  There's nothing in the
> > module documentation that suggests that you can call MethodType as a
> > function as you suggest, only that it is the name of the type of
> > methods of user-defined class instances..  So, while calling it might
> > work, it sounds like you are using an undocumented feature...
>
> If you look at new.py, all it does is import the functions from types
> and rename them. For MethodType is goes like this
>
> from types import MethodType as instancemethod
>
> so instance method *is* Methodtype.
>
> Moreover, I tried and it works ;-)
>
> So this solution is perfect once adapted not to depend on "new".
> 
> Thanks,
> 
> Flávio

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


Re: cheese shop registration error

2005-11-30 Thread skip

>> smtplib.SMTPRecipientsRefused: {u'tgreenwoodgeer.yahoo.com': (550,
>> ': Recipient address rejected: User unknown
>> in local recipient table')}

richard> The error displayed here is complaining about the email address
richard> you supplied, 'tgreenwoodgeer.yahoo.com'. This is different
richard> from the session details you have supplied. I can't reconcile
richard> these. I suggest you try again, and be careful when typing your
richard> email address.

Just a wild-ass guess, but should the recipient should have been
'[EMAIL PROTECTED]'?

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


A bug in struct module on the 64-bit platform?

2005-11-30 Thread [EMAIL PROTECTED]
Hi,

I have a user who complained about how "struct" module computes C
struct data size on Itanium2 based 64-bit machine.

His first reproducer was
--
#!/usr/local/bin/python
import struct
fmthead = '12id5i5d7id5i3di12i3di'
fmtsize = struct.calcsize(fmthead)
print fmthead,fmtsize
--
And it prints 12id5i5d7id5i3di12i3di 292

And he further provided
   >>struct.calcsize('idi')
   16
   >>struct.calcsize('idid')
   24
   >>struct.calcsize('did')
   20

In response to those, I created corresponding C struct and computed the
data size using "sizeof" operation (gcc was used for compilation), but
they don't seem to match.

Is this a known problem?

Best,
-Dong

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


help python swig problem

2005-11-30 Thread [EMAIL PROTECTED]
Hi,

I tried to follow the example in swig homepage.
I found error which I don't understand.
I use bcc32, I already include directory where my python.h exist in
bcc32.cfg.

 /* File : example.c */

 #include 
 double My_variable = 3.0;

 int fact(int n) {
 if (n <= 1) return 1;
 else return n*fact(n-1);
 }

 int my_mod(int x, int y) {
 return (x%y);
 }

 char *get_time()
 {
 time_t ltime;
 time(

Re: how to handle two forms in cgi?

2005-11-30 Thread Dan M
>   My question is: How let these two form works together? I try to use
> two codes for these two forms, e.g. Login.py for login form and
> search.py for search form. But when user input data in search form and
> click its submit button, it just comes back to login form. Second form
> doesn't work.
> 
> Any help is appriciated!

It sounds like the "action" attribute in the 2nd form's  tag is not
pointing to search.py.

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


Re: python speed

2005-11-30 Thread [EMAIL PROTECTED]

Isaac Gouy wrote:
> Peter Hansen wrote:
> > Isaac Gouy wrote:
> > > Peter Hansen wrote:
> > >>Judging by the other posts in this thread, the gauntlet is down: Python
> > >>is faster than Java.  Let those who believe otherwise prove their point
> > >>with facts, and without artificially handcuffing their opponents with
> > >>non-real-world "purity" requirements.
> >
> > > That form of argument is listed as one of the principal forms of
> > > illogical thinking in "Being Logical" D.Q.McInerny - "An Inability to
> > > Disprove Does Not Prove"
> >
> > Good thing this is the form of argument *against* which I was arguing,
> > rather than that which I choose to use myself.  (Read very carefully, if
> > you really think I was saying otherwise, and point out exactly where I
> > made any such claims for my own part.  In fact, I was referencing the
> > arguments of others -- who *were* supporting their arguments with facts,
> > as near as I can tell -- and I was calling on the opposition to do the
> > same, and without changing the rules mid-discussion.)
> >
> > > "The fact that there is no concrete proof against a position does not
> > > constitute an argument in favour of the position. I cannot claim to be
> > > right simply because you can't prove me to be wrong."
> >
> > Isn't that what I was saying?  That those who claim Python isn't faster
> > were not supporting their arguments with actual facts?
> >
> > -Peter
>
> *Python is faster than Java.  Let those who believe otherwise prove
> their point with facts*
>
> We must be looking at different threads :-)
>
> afaict the only posting that provided something like "facts" was
> http://groups.google.com/group/comp.lang.python/msg/309e439697279060
>
> Which stated "Python is doing the heavy lifting with GMPY which is a
> compiled C program with a Python wrapper" - but didn't seem to compare
> that to GMPY with a Java wrapper?

Is there such an animal? I only know about Java's BigInteger.
And if there is, it just proves my point that benchmarks are
worthless.

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


Re: cheese shop registration error

2005-11-30 Thread richard
Todd Greenwood-Geer wrote:
> I'd like to publish to PyPI. I'm assuming that this is open to anyone.

Correct.


> REPRO:
> - - open cheeseshop reg form
> http://cheeseshop.python.org/pypi?%3Aaction=register_form
> 
> - - fill out registration form as follows:
> Username: tgreenwood
> Password: some password
> Confirm: some password (same as above)
> Email Address: [EMAIL PROTECTED]
> PGP Key ID: (see below)
> 
> - - i don't have a lot of experience with pgp, so i installed kpgp, a gui
> frontend to gnupg. i created a pgp key as follows:
> - -- install kpgp
> - -- create a new key pair for me : Todd Greenwood-Geer,
> [EMAIL PROTECTED], etc.
> - -- publish the key to hkp://subkeys.pgp.net
> - -- dblclick the new key in kpgp to get the properties dialog, copy down
> the key id, and paste that into the web field for PGP Key ID (above)
> - - submit form
> 
> Error...
> 
> There's been a problem with your request
> 
> smtplib.SMTPRecipientsRefused: {u'tgreenwoodgeer.yahoo.com': (550,
> ': Recipient address rejected: User unknown in
> local recipient table')}

The error displayed here is complaining about the email address you
supplied, 'tgreenwoodgeer.yahoo.com'. This is different from the session
details you have supplied. I can't reconcile these. I suggest you try
again, and be careful when typing your email address.


 Richard

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


Re: (newbie) N-uples from list of lists

2005-11-30 Thread Martin Miller
FWIW, I found Steven Taschuk's solution easiest to understand regarding
the question posed in your original post -- namely how to solve the
problem non-recursively with generators -- because it was similar to my
own thinking about how to do it -- but suspect that Raymond Hettinger's
is the likely the "best" (as is usually the case ;-).

Best,
-Martin


[EMAIL PROTECTED] wrote:
> great thanks to all.
>
> actually i have not seen it was a cross product... :) but then there
> are already few others ideas from the web, i paste what i have found
> below...
>
> BTW i was unable to choose the best one, speaking about performance
> which one should be prefered ?
>
> ### --
>
> ### from title: variable X procuct - [(x,y) for x in list1 for y in
> list2]
> ### by author:  steindl fritz
> ### 28 mai 2002
> ### reply by:   Jeff Epler
>
> def cross(l=None, *args):
> if l is None:
> # The product of no lists is 1 element long,
> # it contains an empty list
> yield []
> return
> # Otherwise, the product is made up of each
> # element in the first list concatenated with each of the
> # products of the remaining items of the list
> for i in l:
> for j in cross(*args):
> yield [i] + j
>
> ### reply by:   Raymond Hettinger
>
> def CartesianProduct(*args):
> ans = [()]
> for arg in args:
> ans = [ list(x)+[y] for x in ans for y in arg]
> return ans
>
> """
> print CartesianProduct([1,2], list('abc'), 'do re mi'.split())
> """
>
> ### from:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/159975
> ### by: Raymond Hettinger
>
> def cross(*args):
> ans = [[]]
> for arg in args:
> ans = [x+[y] for x in ans for y in arg]
> return ans
>
> ### from:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/159975
> ### by: Steven Taschuk
> """
> Iterator version, Steven Taschuk, 2003/05/24
> """
> def cross(*sets):
> wheels = map(iter, sets) # wheels like in an odometer
> digits = [it.next() for it in wheels]
> while True:
> yield digits[:]
> for i in range(len(digits)-1, -1, -1):
> try:
> digits[i] = wheels[i].next()
> break
> except StopIteration:
> wheels[i] = iter(sets[i])
> digits[i] = wheels[i].next()
> else:
> break

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


Re: python speed

2005-11-30 Thread Paul Boddie
Carsten Haese wrote:
> On Wed, 2005-11-30 at 14:53, Paul Boddie wrote:
> > [...] the Java virtual machine
> > is suitably designed/specified to permit just-in-time complication.
>
> +1 Freudian slip of the week :)

Well, I never said it was easy. ;-)

Paul

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


Re: python speed

2005-11-30 Thread Peter Hansen
Donn Cave wrote:
> I read yesterday morning in the paper that the Goto Basic Linear
> Algebra Subroutines, by a Mr. Kazushige Goto, are still the most
> efficient library of functions for their purpose for use in
> supercomputing applications.  Apparently hand-optimized assembler
> for specific processors.
> http://seattlepi.nwsource.com/business/250070_goto29.html
> (actually from the NY Times, apparently)

"Goto No Longer Considered Harmful"  ?

;-)

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


Re: Oracle 9i client for Linux

2005-11-30 Thread Damjan
This is a list of files I use to compile cx_Oracle, php-oci amd perl
DB::OCI on Linux.
I set ORACLE_HOME to /usr/lib/oracle and symlink the *.so files in
/usr/lib so that I don't need to set LD_LIBRARY_PATH.
I guess this list can be reduced some more... but I got tired of
experimenting

And the instant client 10.0 will work with a 9i database, but will not
work with some 8.0 and 8.1 databases.

/usr/lib/oracle/lib/classes12.jar
/usr/lib/oracle/lib/libclntsh.so.10.1
/usr/lib/oracle/lib/libnnz10.so
/usr/lib/oracle/lib/libocci.so.10.1
/usr/lib/oracle/lib/libociei.so
/usr/lib/oracle/lib/libocijdbc10.so
/usr/lib/oracle/lib/ojdbc14.jar
/usr/lib/oracle/lib/libclntsh.so
/usr/lib/oracle/lib/libocci.so
/usr/lib/oracle/rdbms/
/usr/lib/oracle/rdbms/public/
/usr/lib/oracle/rdbms/public/nzerror.h
/usr/lib/oracle/rdbms/public/nzt.h
/usr/lib/oracle/rdbms/public/occi.h
/usr/lib/oracle/rdbms/public/occiAQ.h
/usr/lib/oracle/rdbms/public/occiCommon.h
/usr/lib/oracle/rdbms/public/occiControl.h
/usr/lib/oracle/rdbms/public/occiData.h
/usr/lib/oracle/rdbms/public/occiObjects.h
/usr/lib/oracle/rdbms/public/oci.h
/usr/lib/oracle/rdbms/public/oci1.h
/usr/lib/oracle/rdbms/public/oci8dp.h
/usr/lib/oracle/rdbms/public/ociap.h
/usr/lib/oracle/rdbms/public/ociapr.h
/usr/lib/oracle/rdbms/public/ocidef.h
/usr/lib/oracle/rdbms/public/ocidem.h
/usr/lib/oracle/rdbms/public/ocidfn.h
/usr/lib/oracle/rdbms/public/ociextp.h
/usr/lib/oracle/rdbms/public/ocikpr.h
/usr/lib/oracle/rdbms/public/ocixmldb.h
/usr/lib/oracle/rdbms/public/odci.h
/usr/lib/oracle/rdbms/public/oratypes.h
/usr/lib/oracle/rdbms/public/ori.h
/usr/lib/oracle/rdbms/public/orid.h
/usr/lib/oracle/rdbms/public/orl.h
/usr/lib/oracle/rdbms/public/oro.h
/usr/lib/oracle/rdbms/public/ort.h
/usr/lib/oracle/rdbms/public/xa.h
/usr/lib/oracle/rdbms/demo/
/usr/lib/oracle/rdbms/demo/cdemo81.c
/usr/lib/oracle/rdbms/demo/demo.mk
/usr/lib/oracle/rdbms/demo/occidemo.sql
/usr/lib/oracle/rdbms/demo/occidemod.sql
/usr/lib/oracle/rdbms/demo/occidml.cpp

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


how to handle two forms in cgi?

2005-11-30 Thread lli
Hi Guys,

I am a new cgi programmer. Now I need to design a web application:
1. first, user login by their username and password in a form (login
form). When users click submit button it connect to database and check
user name and password in a table. If it match in a table, form1.py
should show second form for users in their browser. I have finish this
form. It works well.
2. second form (search form) which contain last name, and first name
which users input data. When user click submit button, it connect
database and search in a table. And the search result need to show in a
list or table in users' browser.

  My question is: How let these two form works together? I try to use
two codes for these two forms, e.g. Login.py for login form and
search.py for search form. But when user input data in search form and
click its submit button, it just comes back to login form. Second form
doesn't work.

Any help is appriciated!

Thanks,

LLI

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


Re: Nested loop

2005-11-30 Thread Bengt Richter
On 30 Nov 2005 00:37:43 -0800, [EMAIL PROTECTED] wrote:

>
>viewcharts wrote:
>> I am reading two text files comparing the values in one to the other,
>> this requires two loops. The problem is that when the inner loop is
>> finished, it never goes back into the loop. Any suggestions?
>>
>>
>> for refSymbol in symbols.readlines():
>> for lookupSymbol in myfile.readlines():
>> showme = lookupSymbol.split('\t')
>> if showme[3] == refSymbol.strip():
>> priceNew.write(refSymbol.strip()+" "+showme[10])
>As another poster said, you have "used up" the inner iterable in the
>first round, it is an iterable, just not like a list where you can use
>multiple times.
>
>Either turn it into a list(so you can reuse it) or better yet, turn it
>into a dict which would speed up the matching process. Either way, it
>better be done outside of the outer loop.
>
Yes, and unless there is an ordering requirement that can't be ignored or 
achieved
by sorting afterwards, symbols seems like it could be a set. E.g., (untested)

refSymbolSet = set(refSymbol.strip() for refSymbol in symbols)
for showme in (lookupSymbol.split('\t') for lookupSymbol in myfile):
if showme[3] in refSymbolSet:
priceNew.write(showme[3]+" "+showme[10])

It would probably be more robust to check for blank lines and showme missing 
fields
and symbol duplicates also.

Regards,
Bengt Richter
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: python speed

2005-11-30 Thread Isaac Gouy

Peter Hansen wrote:
> Isaac Gouy wrote:
> > Peter Hansen wrote:
> >>Judging by the other posts in this thread, the gauntlet is down: Python
> >>is faster than Java.  Let those who believe otherwise prove their point
> >>with facts, and without artificially handcuffing their opponents with
> >>non-real-world "purity" requirements.
>
> > That form of argument is listed as one of the principal forms of
> > illogical thinking in "Being Logical" D.Q.McInerny - "An Inability to
> > Disprove Does Not Prove"
>
> Good thing this is the form of argument *against* which I was arguing,
> rather than that which I choose to use myself.  (Read very carefully, if
> you really think I was saying otherwise, and point out exactly where I
> made any such claims for my own part.  In fact, I was referencing the
> arguments of others -- who *were* supporting their arguments with facts,
> as near as I can tell -- and I was calling on the opposition to do the
> same, and without changing the rules mid-discussion.)
>
> > "The fact that there is no concrete proof against a position does not
> > constitute an argument in favour of the position. I cannot claim to be
> > right simply because you can't prove me to be wrong."
>
> Isn't that what I was saying?  That those who claim Python isn't faster
> were not supporting their arguments with actual facts?
>
> -Peter

*Python is faster than Java.  Let those who believe otherwise prove
their point with facts*

We must be looking at different threads :-)

afaict the only posting that provided something like "facts" was
http://groups.google.com/group/comp.lang.python/msg/309e439697279060

Which stated "Python is doing the heavy lifting with GMPY which is a
compiled C program with a Python wrapper" - but didn't seem to compare
that to GMPY with a Java wrapper?

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


Re: python speed

2005-11-30 Thread Donn Cave
In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> 
wrote:

> "Harald Armin  Massa" <[EMAIL PROTECTED]> writes:
> >>Faster than assembly? LOL... :)
> > why not? Of course, a simple script like "copy 200 bytes from left to
> > right" can be handoptimized in assembler and run at optimum speed.
> > Maybe there is even a special processor command to do that.
> 
> Chances are, version 1 of the system doesn't have the command. Version
> 2 does, but it's no better than the obvious hand-coded loop. Version 3
> finally makes it faster than the hand-coded loop, if you assume you
> have the instruction. If you have to test to see if you can use it,
> the hand-coded version is equally fast. Version 4 makes it faster even
> if you do the test, so you want to use it if you can. Of course, by
> then there'll be a *different* command that can do the same thing,j and
> is faster in some conditions.
> 
> Dealing with this in assembler is a PITA. If you're generating code on
> the fly, you generate the correct version for the CPU you're running
> on, and that's that. It'll run at least as fast as hand-coded
> assembler on every CPU, and faster on some.

Actually I think the post you quote went on to make a similar
point.

I read yesterday morning in the paper that the Goto Basic Linear
Algebra Subroutines, by a Mr. Kazushige Goto, are still the most
efficient library of functions for their purpose for use in
supercomputing applications.  Apparently hand-optimized assembler
for specific processors.
http://seattlepi.nwsource.com/business/250070_goto29.html
(actually from the NY Times, apparently)

   Donn Cave, [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: wxPython installation issues on Debian

2005-11-30 Thread [EMAIL PROTECTED]
Hi Ken,

Thanks a lot for the clarification. I don't have a compelling reason
not to use 2.3 other than having to install the modules I've already
set up for 2.4. Not really a big deal. Looks like I'll be switching to
2.3.

Thanks again,
Aaron

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


Re: Distutils postinstall script: useless?

2005-11-30 Thread Thomas Heller
Mardy <[EMAIL PROTECTED]> writes:

> Le die Wed, 30 Nov 2005 15:46:43 +, Mardy ha scribite:
>>   the bdist_wininst command of distutils allows me to specify a script to
>> be executed at the end of the installation. That's great, but how can I
>> know the installation path from inside the script?
>
> Answering to myself, sys.prefix combined with the dictionary
> INSTALL_SCHEMES from distutils.commands.install might do the work.

See also the functions in distutils.sysconfig.

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


Re: python speed

2005-11-30 Thread Mike Meyer
"Harald Armin  Massa" <[EMAIL PROTECTED]> writes:
>>Faster than assembly? LOL... :)
> why not? Of course, a simple script like "copy 200 bytes from left to
> right" can be handoptimized in assembler and run at optimum speed.
> Maybe there is even a special processor command to do that.

Chances are, version 1 of the system doesn't have the command. Version
2 does, but it's no better than the obvious hand-coded loop. Version 3
finally makes it faster than the hand-coded loop, if you assume you
have the instruction. If you have to test to see if you can use it,
the hand-coded version is equally fast. Version 4 makes it faster even
if you do the test, so you want to use it if you can. Of course, by
then there'll be a *different* command that can do the same thing,j and
is faster in some conditions.

Dealing with this in assembler is a PITA. If you're generating code on
the fly, you generate the correct version for the CPU you're running
on, and that's that. It'll run at least as fast as hand-coded
assembler on every CPU, and faster on some.

If you wire everything down, you can always hand-code assembler that
will be faster than HLL code (though even sharp programmers can miss
tricks the compiler won't). But things don't stay wired down - the CPU
gets upgraded, caches change size, pages change size, the data gets
bigger, etc. Hand-tuned code doesn't deal well with such, whereas
generated code can be made to do just that.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: python speed

2005-11-30 Thread Peter Hansen
Isaac Gouy wrote:
> Peter Hansen wrote:
>>Judging by the other posts in this thread, the gauntlet is down: Python
>>is faster than Java.  Let those who believe otherwise prove their point
>>with facts, and without artificially handcuffing their opponents with
>>non-real-world "purity" requirements.

> That form of argument is listed as one of the principal forms of
> illogical thinking in "Being Logical" D.Q.McInerny - "An Inability to
> Disprove Does Not Prove"

Good thing this is the form of argument *against* which I was arguing, 
rather than that which I choose to use myself.  (Read very carefully, if 
you really think I was saying otherwise, and point out exactly where I 
made any such claims for my own part.  In fact, I was referencing the 
arguments of others -- who *were* supporting their arguments with facts, 
as near as I can tell -- and I was calling on the opposition to do the 
same, and without changing the rules mid-discussion.)

> "The fact that there is no concrete proof against a position does not
> constitute an argument in favour of the position. I cannot claim to be
> right simply because you can't prove me to be wrong."

Isn't that what I was saying?  That those who claim Python isn't faster 
were not supporting their arguments with actual facts?

-Peter

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


Re: wxPython installation issues on Debian

2005-11-30 Thread Kenneth Pronovici
> Thanks for the suggestion, but an apt-cache search python2.4-wxgtk2.4
> returns no results for a package with that name. 

As you observed, the Debian wxPython packages currently only support one
version of Python at a time.  That decision ripples down and ends up
affecting a number of other things -- for instance, it's also the reason
that the Pythoncard Debian packages I maintain are only supported for a
single version of Python.

I'm sure that Ron (the Debian wxWidgets maintainer) has a good reason
for supporting only one Python version, but I don't personally know what
it is.  This package does seem to be rather difficult to maintain, and
that could be why he chose to do things this way.  Or, it might just be
that the default version of Python in Debian (even in etch) is still
2.3, and he's decided to support only the default version.  You could
try writing him to find out for sure.

If you really can't live with using Python 2.3, then I guess you have
two choices -- you can either download, modify and rebuild the Debian
package (apt-get source and dpkg-buildpackage) or try to get an upstream
binary distribution for your platform (which I guess could be
problematic unless you also get binaries for the underlying libraries,
etc.).  

Or, of course, you can also try building from the upstream source and
install to /usr/local or something.  Using that option, you might get
away with installing the underlying wxWidgets shared libraries from the
Debian package, and only the Python parts from source (if you're lucky).

I imagine that's not the answer you're looking for, but I hope that
helps a little,

KEN

-- 
Kenneth J. Pronovici <[EMAIL PROTECTED]>
http://www.cedar-solutions.com/
-- 
http://mail.python.org/mailman/listinfo/python-list


ANN: Dabo 0.5 released!

2005-11-30 Thread Ed Leafe
We are pleased to announce Dabo 0.5, the fifth major release of our  
data application framework. The Dabo framework is a true 3-tier  
design, with data access and UI code separated from your business  
logic. And since it's Python, and uses wxPython for its UI, it is  
completely cross-platform, having been tested on Linux, Windows and  
OS X.

Download from http://dabodev.com/download

Anyone interested in contributing to Dabo, or who just want to find  
out what it is all about is encouraged to join our mailing lists:  
dabo-users: for those interested in learning how to work with Dabo to  
create applications, and for general help with Dabo. http://leafe.com/ 
mailman/listinfo/dabo-users dabo-dev: for those interested in the  
ongoing development of Dabo. This list contains lots of lively  
discussion on design issues, as well as notices of all commits to the  
code repository. http://leafe.com/mailman/listinfo/dabo-dev


Here is a brief summary of what's new/changed in Dabo 0.5:

Dabo Framework:

Added a new class, DataSet, which lets you issue SQL queries against  
local Dabo data, not just against the backend. You can query, sort,  
and update individual DataSets, and even join multiple DataSets - all  
without making a call to the backend database server.

Began the work of making an embedded, internal, database engine  
(SQLite). Currently SQLite is an option; starting with future  
releases, it will be an integral part of Dabo.

Automatic binding of events to method code! If you have a button  
class with an onHit method, it will automatically be bound to the  
button's Hit event. Simply by naming your methods 'onBleh()', if  
there is a 'Bleh' event that is raised by the object, the onBleh()  
method will be bound to it. You can still bind manually using  
bindEvent(), of course, but auto-binding of events now works so well  
that it is the default.

Added a basic framework for drawing shapes on any window. Once  
created, the shapes are accessible with an object reference. This  
should make dealing with wx.DC's a thing of the past for most uses.  
Way cool!

Sorted out MDI/SDI issues. By default, dForm on Windows MDI children  
and dFormMain on Windows will be MDI parents. On other platforms,  
both dForm and dFormMain will be SDI by default. The above statement  
is true for datanav applications (ones generated by the AppWizard).  
The pure-Dabo default is for SDI forms. In any case, you may change  
this by setting dabo.MDI.

Improved the datanav Quick Report feature, which can print a list of  
the current records, mimicing the browse page, or a whole page of  
information on one record, mimicing the edit page. Added the ability  
for the user to save the generated report form for editing with the  
Report Designer or editing the rfxml directly.

Improved showContextMenu(), and sorted out the difference between  
MouseRightClick and ContextMenu events.

dCheckBox now supports 3 state mode, (True, False and None).

dForms now know how to read in cdxml files, created by the upcoming  
UI Designer.

Improved the handling of broken database connections.

Added middle button and scroll mouse events.

Added some hooks to datanav.Form that allow developers to control the  
select options for given fields. This would allow you to put, for  
example, a radiogroup with a few choices instead of the default textbox.

Added connection manager to dApp, which maintains a set of open  
database connections that your forms can reference by name. Added  
Connection property to dForm.

Improved report writer's paragraph handling.

And, of course, more bug fixes than we'd like to say!



Dabo Demo:

Added several small programs to the tutorial section. Instead of  
emphasizing actual complex, working apps in Dabo, such as the games,  
these show smaller, bite-sized examples of Dabo code.

Began work on a demo app that mirrors the wxPython demo, which  
includes all of the controls, some sample code for each along with a  
brief explanation of how that control is used. This is the work of  
Adi J. Sieker, who has already added several Dabo controls, and who  
will be adding more as time goes on.

The Bubblet game has been completely re-written to use the new Draw  
objects. This is an excellent way to learn how to control images  
drawn on your UI surfaces.



Dabo IDE:
-
The AppWizard has been overhauled significantly, and now creates apps  
that are much more easily customized, and scales much better to non- 
trivial applications.

The Class Designer has improved greatly - it now supports extremely  
complex layouts, such as multiply-nested sizers, paged controls  
inside other paged controls, etc. It can save these designs into XML  
files that can then be used to create runtime forms that have the  
same structure as the original design. The next step will be added  
soon: integration of code to bind to events, so that not only will  
you be able to control how your form

Re: Python as Guido Intended

2005-11-30 Thread Mike Meyer
Antoon Pardon <[EMAIL PROTECTED]> writes:
> On 2005-11-29, Mike Meyer <[EMAIL PROTECTED]> wrote:
>> Antoon Pardon <[EMAIL PROTECTED]> writes:
 You see, you can make languages more powerful by *removing* things
 from it.
>>> You cast this in way to general terms. The logic conclusion
>>> from this statements is that the most powerfull language
>>> is the empty language.
>> The only way you reach that conclusion is if you read the statement as
>> saying that removing things *always* makes a langauge more
>> powerful. That's not what I said,
> I would say it is the common interpretation for such a sentence.

You'd be wrong. "Can" denotes a possibility, not a certainty. If I'd
say "You *will* make languages more powerful by removing features",
then you'd be right. But that isn't what I said.

 Wrong. There are some thing which there should *not* be a way to do.
 For instance, there should not be a way to produce a segmentation
 fault - which means certain features common to other languages will
 never be added.
>>> Then C-extentions shouldn't be allowed.
>> C-extensions aren't part of Python.
> As far as I understand, if you implement a class with a C-extension,
> then that class is understood to be part of Python. So if you
> think there should be no way to produce a segmentation fault in
> python you shouldn't allow such classes.

You understand wrong.

 We don't talk much about how you produce buffer
 overfows in Python, but people have asked for that as well. Adding
 ways to write hard-to-read code is frowned upon. And so on.
>>> Do you mean people have asked for the possibility that a buffer
>>> overflow would overwrite other variables?
>> Buffer overflows don't have to overwrite variables. They just asked
>> how you create buffer overflows in Python.
> I do wonder what they mean with a buffer overflow. Would the following
> classify:
>   buf = range(10)
>   buf[10] = 10

Well, you'd have to ask them. Personsally, I wouldn't count that,
because no data outside the scope of buf got written to.

 I won't speak for others, but I wouldn't reject it out of hand.  You
 haven't provided enough information. Accepting it just because it adds
 a way to do something is wrong. First, you have to ask whether or not
 that something is something we want in Python at all. Then you
 consider whether how the way proposed fits with the language: is it
 ugly?
>>> That is a highly subjective question, answering it says more about
>>> the person then about the proposal.
>> True. But whether or not a language is good is a highly subjective
>> question. Since the goal - keeping python good to the people who
>> already consider it good - is subjective, it's only natural that part
>> of the evaluation process be sujectie.
 Is it prone to abuse?
>>> I don't see why this is always brought up, given the number of
>>> features that can be abused in python.
>> Just because Python isn't perfect is no reason to make it worse.
> Why is it worse. You seem to think that if one has a toolbox, which
> lacks a hammer, that the fact that the hammer can be abused makes
> your toolbox less usefull if you add a hammer to it.

Look again. I never said it would make Python less useful, I said it
would make it worse. Those aren't the same thing. It's possible to
make a language both more useful and worse at the same time. For
instance, Python would clearly be more useful if it could interpret
perl 6 scripts. Personally, I think adding the features required to do
that would make the language (much, much) worse. Oddly enough, I think
adding the features to Perl so it could interpret Python scripts would
make it better as well as more useful :-).

> We have a toolbox, full of equipment that can be abused, yet
> that something else can be abused too, seems to be a mayor
> stumbling block for adding it.

"Major" is your word, not mine. I just listed it as something to
consider. It may be there's an obscure corner case that's really
abusive, but chances are no one would ever stumble over it. That's not
a major problem. On the other hand, if there's an obvious and
attractive use that's abusive, that's a reason for looking for another
way to add that functionality.

 In summary, the design philosophy is that it's better to do without
 some facility than to add it in a way that doesn't fit with the
 language, and the process reflects that.
>>> I don't mind that a proposal is worked on and that counter-proposals
>>> can be made. But some people just seem to counter any new proposal,
>>> while other are more interrested in searching for ways to make
>>> the new proposal fit the language. Now sometimes a proposal can't
>>> be fitted and gets rejected, so be it. But maybe more could be
>>> fitted in the langauge if more people were willing to look for
>>> ways to fit something, instead of rejecting it simply because
>>> the current proposal doesn't fit properly yet.
>> The only way this w

Re: After migrating from debian to ubuntu, tkinter "hello world" doesn't work

2005-11-30 Thread Mandus
30 Nov 2005 04:23:37 -0800 skrev [EMAIL PROTECTED]:
>
> Mandus ha escrito:
>
>> works just fine on my ubunty 5.10. Make sure you have the python2.4-tk
>> package installed (sudo apt-get install python2.4-tk).
>>
>
> yes, i got it.
> It's a fresh instalation from a cd in a brand new laptop. I tried to
> reinstall python2.4-tk and many other packeges  :-(
>

If you think it may help, I can drop you my complete 
'dpkg --get-selections'. Just tell me where you want it.

mvh,
-- 
Mandus - the only mandus around.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: General question about Python design goals

2005-11-30 Thread Christoph Zwerschke
[EMAIL PROTECTED] wrote:
> Paul Rubin wrote:
>>Look at the list.count() example at the start of this thread.
>>Diagnosing it isn't hard.  Curing it isn't hard.  It doesn't bloat
>>Python by an order of magnitude.  A suitably factored implementation
>>might handle lists and strings with the exact same code and not incur
>>any extra cost at all.  That type of thing happens all the time here.
> 
> I believe the language creator use the "lack of" as a way to
> prevent/discourage that kind of usage. Just like the ternary
> operator(still don't know why it is finally accepted). It is not a
> problem(not having), it is a feature(to teach you program better), so
> what cure are we talking about ?

Sorry, but I still do not get it. Why is it a feature if I cannot count 
or find items in tuples? Why is it bad program style if I do this? So 
far I haven't got any reasonable explanation and I think there is no.

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


Re: Distutils postinstall script: useless?

2005-11-30 Thread Mardy
Le die Wed, 30 Nov 2005 15:46:43 +, Mardy ha scribite:
>   the bdist_wininst command of distutils allows me to specify a script to
> be executed at the end of the installation. That's great, but how can I
> know the installation path from inside the script?

Answering to myself, sys.prefix combined with the dictionary
INSTALL_SCHEMES from distutils.commands.install might do the work.


-- 
Saluti,
Mardy
http://interlingua.altervista.org

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


Re: Python as Guido Intended

2005-11-30 Thread Ben Finney
Antoon Pardon <[EMAIL PROTECTED]> wrote:
> On 2005-11-29, Mike Meyer <[EMAIL PROTECTED]> wrote:
> > Antoon Pardon <[EMAIL PROTECTED]> writes:
> >> Mike Meyer wrote:
> >>> You see, you can make languages more powerful by *removing*
> >>> things from it.
> >> You cast this in way to general terms. The logic conclusion from
> >> this statements is that the most powerfull language is the empty
> >> language.
> > The only way you reach that conclusion is if you read the
> > statement as saying that removing things *always* makes a langauge
> > more powerful. That's not what I said,
> I would say it is the common interpretation for such a sentence.

You'd be wrong. "you can do X by doing foo" does not exclude "you can
do the opposite of X by doing foo".

Stating "you can make a lot of money by investing in the stock market"
does not imply that is the only possible outcome, nor even the most
likely.

> > Just because Python isn't perfect is no reason to make it worse.
> 
> Why is it worse. You seem to think that if one has a toolbox, which
> lacks a hammer, that the fact that the hammer can be abused makes
> your toolbox less usefull if you add a hammer to it.

I see Mike arguing that the debate before adding the hammer is a good
thing. It ensures that only the *really* good tools -- the ones that
are so beneficial that they outweigh complicating the toolset --
actually get added; and only when they are in a form that they
overcome many objections.

> > The only way this would be good is if "more features" were
> > inherently better. That's simply not true. So the change in
> > behavior you're looking for isn't clearly good.
> 
> No, this is good while there are still possible features that could
> make python a better language

Then let's subject those possible features -- with their real use
cases and implementations -- to harsh scrutiny, over an extended time,
before deciding they'll be a net benefit.

-- 
 \ "Unix is an operating system, OS/2 is half an operating system, |
  `\   Windows is a shell, and DOS is a boot partition virus."  -- |
_o__)  Peter H. Coffin |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: python speed

2005-11-30 Thread Isaac Gouy

Peter Hansen wrote:
> David Rasmussen wrote:
> > Frithiof Andreas Jensen wrote:
> >>From the speed requirement: Is that correspondance chess by any chance??
> >
> > Regular chess at tournament time controls requires speed too. Any pure
> > Python chess program would lose badly to the best C/C++ programs out
> > there now.
> >
> > I would also like to see Half Life 2 in pure Python.
>
> True, but so what?  Why did you suddenly change the discussion to
> require "pure" Python?  And please define "pure" Python, given that the
> interpreter and many builtins, not to mention many widely used extension
> modules, are coded in C?  And are you not allowed to use any of the
> performance-boosting techniques available for Python, like Pyrex or
> Psyco?  Why such restrictions, when these are things Python programs use
> on a daily basis: these are *part* of Python, as much as the -O switch
> on the compiler is part of C/C++.
>
> Okay, let's compare a "pure" Python program (if you can define it in any
> meaningful, practical way) with a "pure" Java program, running on a
> non-JIT interpreter and with optimizations turned off (because, of
> course, those optimizations are umm... somehow.. not "pure"...?).
>
> Judging by the other posts in this thread, the gauntlet is down: Python
> is faster than Java.  Let those who believe otherwise prove their point
> with facts, and without artificially handcuffing their opponents with
> non-real-world "purity" requirements.
>
> -Peter

That form of argument is listed as one of the principal forms of
illogical thinking in "Being Logical" D.Q.McInerny - "An Inability to
Disprove Does Not Prove"

"The fact that there is no concrete proof against a position does not
constitute an argument in favour of the position. I cannot claim to be
right simply because you can't prove me to be wrong."

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


Re: Making immutable instances

2005-11-30 Thread Mike Meyer
[EMAIL PROTECTED] writes:
> I am puzzled, and could have read what you want wrong. Are you saying
> you want something like this :
>
> a={}
> a.something = "I want to hang my stuff here, outside the intended use
> of dict"

Exactly. For a use case, consider calling select.select on lists of
file objects. If the processing is simple enough, the clearest way to
associate a handler with each socket is just to add it as an
attribute. But that doesn't work - sockets are bulitin types. So you
consider less light-weight solutions, like subclassing socket (now
that that's possible), or a dictionary of handlers keyed by socket.

This works by default with classes written in Python. That it doesn't
work for builtins is inconsistent, non-orthogonal, and
incomplete. However, it's easy to work around, and the obvious fix -
adding a dictionary to every builtin - is rather costly. So we'll live
with it since practicality beats purity.

   http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: python speed

2005-11-30 Thread igouy

Paul Boddie wrote:
> Steven Bethard wrote:
> > David Rasmussen wrote:
> > Faster than assembly? LOL... :)
> >
> Faster than physics? ;-)
>
> > I think the claim goes something along the lines of "assembly is so
> hard
> > to get right that if you can automatically generate it from a HLL,
> not
> > only will it be more likely to be correct, it will be more likely to
> be
> > fast because the code generator can provide the appropriate
> optimizations".
> >
> I think this is just a restatement of existing motivations for using
> high-level languages and compilers. My impression is that PyPy takes
> inspiration from work which showed that run-time knowledge can
> sometimes produce code that is better optimised than that produced by
> a
> compiler.
>
> That said, when everyone starts showing off their favourite
> benchmarks,
> it might be more interesting not to parade some festival of arithmetic
> yet again. Where more recent versions of the Java virtual machines
> have
> improved is in their handling of object memory allocation, amongst
> other things, and merely scoffing that Java is slow (by pulling
> specific/specialised extension packages out of the hat) fails to
> acknowledge the potential for similar improvements (and others) in
> Python, especially where programs involving plain objects - as opposed
> to numbers, and where no conveniently available and wrapped C/C++
> package exists for the task - are concerned.
>
> Paul

For example, binary trees
http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&lang=all

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


Re: Which License Should I Use?

2005-11-30 Thread Robert Kern
Paul Boddie wrote:
> Paul Rubin wrote:
> 
>>That is the guy who claims it is impossible to release anything into
>>the public domain, other than by dying and then waiting 70 years.
> 
> Is that an indirect reference to the following article?
> 
> http://www.linuxjournal.com/article/6225

Among other places where Rosen has said it, like his book.

-- 
Robert Kern
[EMAIL PROTECTED]

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

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


Re: Making immutable instances

2005-11-30 Thread Mike Meyer
Paul Rubin  writes:
> Mike Meyer <[EMAIL PROTECTED]> writes:
>> Letting the class author declare whether or not the client can add
>> attributes is wrong for the same reasons - and in the same places -
>> that letting the class author declare that the client shouldn't be
>> allowed to access specific attributes, and so on, is wrong.
> The same logic can apply to what the class operations should do.  The
> answer is the same in both cases.  That's why subclassing and
> inheritance were invented.

Exactly. Adding an attribute is isomorphic to subclassing, except it
doesn't' take any boilerplate. Unless you do something to prevent
people from subclassing, they can always write the boilerplate and
pretty much continue as before. I don't believe there's a good reason
for preventing the boilerplate free method, and repeated requests for
a use case for this have gone unsatisied.

Have you got a use case?

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: General question about Python design goals

2005-11-30 Thread Mike Meyer
Paul Rubin  writes:
> Mike Meyer <[EMAIL PROTECTED]> writes:
>> > An awful lot of the time in this newsgroup, "practicality beats
>> > purity" translates as "the programmer can just be a lazy slob".
>> You post that as if it were a bad thing.
> Yes.  The idea of using a program that someone else wrote, is that
> they do the work so I don't have to.  If their doing less work means
> that I have to do more, the program isn't as good as it might be.

No, it's not as good *for your purpose* as it might be. But they
didn't write it for your purpose, they wrote it for theirs. The latter
is really the only standard of judgement.

> A program like Python intended for wide distribution and use by large
> numbers of people whose needs aren't known in advance, should do as
> much to help its users as development resources allow.

True. You seem to disagree about how they choose to allocate the
resources. The fix for that is well-known.

> Are you familiar with R. Gabriel's piece "Worse is better"?  That's
> not what I see "practicality beats purity" as being intended to mean.

Why not? That seems to summarise a couple of the points in the more
successful design philosophy, most notably:

The design most not be overly inconsistent.
The design must cover as many important situations as is practical.

If these don't reflet what you think "Practicality beats purity"
means, then what do you think it means?

Actually, I've been thinking about that bit recently, and noting that
a number of things from "import this" seem to espouse the more
successful approach from that section:

Simple is better than complex.
Complex is better than complicated.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.

>> > If following POLA costs that much, at least in the kinds of examples
>> > we talk about all the time here, something is probably wrong with the
>> > implementation (or the design) to begin with.
>> True, but not constructive. Knowing that something is wrong is
>> easy. Diagnosing the problem is harder. Curing it is even harder.
> Look at the list.count() example at the start of this thread.
> Diagnosing it isn't hard.  Curing it isn't hard.  It doesn't bloat
> Python by an order of magnitude. 

Did somebody actually use "Practicality beats purity" as an excuse for
not making list.count and string.count have the same arguments? If so,
I missed it. I certainly don't agree with that - count ought to work
right in this case.

> A suitably factored implementation might handle lists and strings
> with the exact same code and not incur any extra cost at all.  That
> type of thing happens all the time here.

If it happens all the time, you shouldn't have any trouble nameing a
number of things that a majority of users think are misfeatures that
aren't being fixed. Could you do that?

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: XML and namespaces

2005-11-30 Thread A.M. Kuchling
On 30 Nov 2005 07:22:56 -0800, 
[EMAIL PROTECTED] <[EMAIL PROTECTED]> quoted:
> >>> element = document.createElementNS("DAV:", "href")

This call is incorrect; the signature is createElementNS(namespaceURI,
qualifiedName).  If you call .createElementNS('whatever', 'DAV:href'),
the output is the expected:


It doesn't look like there's any code in minidom that will
automatically create an 'xmlns:DAV="whatever"' attribute for you.  Is
this automatic creation an expected behaviour?  

(I assume not.  Section 1.3.3 of the DOM Level 3 says "Similarly,
creating a node with a namespace prefix and namespace URI, or changing
the namespace prefix of a node, does not result in any addition,
removal, or modification of any special attributes for declaring the
appropriate XML namespaces."  So the DOM can create XML documents that
aren't well-formed w.r.t. namespaces, I think.)

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


Re: python speed

2005-11-30 Thread Carsten Haese
On Wed, 2005-11-30 at 14:53, Paul Boddie wrote:
> [...] the Java virtual machine
> is suitably designed/specified to permit just-in-time complication.

+1 Freudian slip of the week :)

-Carsten Haese


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


Re: an intriguing wifi http server mystery...please help

2005-11-30 Thread jojoba

Thanks Istvan,

But if it's a problem with the software,  why does the server work
great when wired (i.e. not wireless)...that's the weird part.

Thanks again,
jojoba

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


Re: python speed

2005-11-30 Thread Paul Boddie
Peter Hansen wrote:
> True, but so what?  Why did you suddenly change the discussion to
> require "pure" Python?

Well, comments about Python's speed usually come in the following two
forms: some Python-based solution isn't fast enough; programs written
in Python aren't fast enough. In other words, they arise either from
specific situations or from general observations gained from running
programs written only in Python (from the author's perspective, without
having written C/Pyrex/Boost extensions).

> And please define "pure" Python, given that the interpreter and many 
> builtins, not
> to mention many widely used extension modules, are coded in C?

>From the point of view of an application developer, a "pure" Python
solution could be one where they only wrote Python code. Of course, I
can claim to deliver various solutions in "pure" Python, knowing that
some extension module that I didn't write will be doing all the hard
work, but it's useful to think of deployment complications: how easy
would it be for me to deploy my application on some obscure platform
that Python runs on? A "pure" Python solution would have limited
extension module dependencies and thus be relatively easy to deploy,
whereas a reliance on a module that hasn't been ported to RISC OS, for
example, would severely impair portability.

> And are you not allowed to use any of the performance-boosting techniques
> available for Python, like Pyrex or Psyco?

Well, from the point of view of an application developer, writing Pyrex
isn't quite the same as writing Python. There are variants of Java that
change the semantics of the language in order to achieve better
performance or certain run-time guarantees, but no-one would honestly
claim that they would be writing "pure" Java if they were really coding
for those variants.

Psyco is admittedly a tool that provides improved performance with
compatible semantics within the Python toolset. I'm not familiar with
its effect on all kinds of programs, however, but if performance was a
critical factor for a system, I wouldn't begrudge anyone from using
Psyco.

[...]

> Okay, let's compare a "pure" Python program (if you can define it in any
> meaningful, practical way) with a "pure" Java program, running on a
> non-JIT interpreter and with optimizations turned off (because, of
> course, those optimizations are umm... somehow.. not "pure"...?).

This remark is somewhat ridiculous given that the Java virtual machine
is suitably designed/specified to permit just-in-time complication.
Running Java programs on some interpreter seems like an arbitrary and
absurd exercise, especially when, by engaging in the process of writing
Java, one has already abandoned some high-level language semantics in
order to exploit the performance benefits of the virtual machine
architecture.

Sure, Python-oriented systems can be faster than Java-oriented systems,
or indeed many other kinds of systems, but such posturing on the notion
of "purity" would seem to suggest a denial of any need for an
investigation into the benefits of improved run-time performance for
programs written in Python - a view which contradicts the work done by
the most prominent project in this field, whilst reinforcing various
community perceptions and attitudes that unjustifiably consign
worthwhile work on this topic to the fringes.

Paul

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


  1   2   3   >