Re: Alternatives to Stackless Python?

[Christophe]

[EMAIL PROTECTED] a écrit :
>>I found LGT http://lgt.berlios.de/ but it didn't seem as if the
>>NanoThreads module had the same capabilites as stackless.
> 
> 
> What specific capabilities of Stackless are you looking for, that are
> missing from NanoThreads?

Capabilities of the different "threadlike" systems are somewhat muddy. 
What myself I like in stackless is :
- you can put context switching instuctions anywhere in the callstack 
without having to explicitely chain the operation
- pickle support

Not sure if greenlets support pickling yet. There are no info on that 
point and my tests weren't succesful.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Alternatives to Stackless Python?

[Christophe]

Olivier Dormond a écrit :
> Christophe wrote:
> 
>> [EMAIL PROTECTED] a écrit :
>>
>>>> I found LGT http://lgt.berlios.de/ but it didn't seem as if the
>>>> NanoThreads module had the same capabilites as stackless.
>>>
>>>
>>> What specific capabilities of Stackless are you looking for, that are
>>> missing from NanoThreads?
>>
>>
>> Capabilities of the different "threadlike" systems are somewhat muddy. 
>> What myself I like in stackless is :
>> - you can put context switching instuctions anywhere in the callstack 
>> without having to explicitely chain the operation
>> - pickle support
>>
>> Not sure if greenlets support pickling yet. There are no info on that 
>> point and my tests weren't succesful.
> 
> 
> The greenlets play with the underlying CPU stack directly so I don't
> think they could ever be pickled.

Then they are useless for nearly all the uses cases I need them :/ And 
that's why stackless is still relevant here. Or maybe pypy too but it's 
still a long time to go.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What does pygame.Movie mean by `an MPEG file'?

[Christophe]

Kilian A. Foth a écrit :
> I just found this amazing video puzzle game written with the pygame
> library, which promises to be infinite fun - but I can't get it to
> decode any video file I own, except the game's own example .mpg. All I
> have is lots and lots of useless .avi, .mp2, .wmv, and so on...
> 
> Now, the pygame.Movie documentation says the Movie class can decode
> `MPEG movie files'. I know little about multimedia, but I thought
> divx/xvid video was a variant of MPEG4, and mp3 audio a variant of 
> MPEG1 Layer 3. So obviously, `MPEG movie files' means something more
> specific than just `contains MPEG streams'. Does anyone know what
> precisely it means? Even better, how should I instruct transcode or
> similar programs to re-encode existing files so that Movie objhects
> can be created from them?

An mpeg file is a file with the .mpg or .mpeg extension. IIRC, it's a 
raw mpeg 1 or 2 stream dumped in a file. Not sure about the raw stream 
but I'm sure it can only be mpeg 1 or 2.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

[Christophe]

Steven D'Aprano a écrit :
> For some reason, the original post never made it to my newsreader, so
> apologies for breaking threading by replying to a reply when I mean to
> answer the original post.
> 
> On Wed, 28 Sep 2005 12:05:21 +0100, Simon Brunning wrote:
> 
> 
>>On 9/28/05, could ildg <[EMAIL PROTECTED]> wrote:
> 
> 
>>>Python is wonderful except that it has no real private and protected
>>>properties and methods.
> 
> 
> Do you know any language that has real private and protected attributes?
> 
> There may be some. I don't know. But anyone who says "C++" is fooling
> themselves:
> 
> #define private public

#undef private

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

Re: [Info] PEP 308 accepted - new conditional expressions

[Christophe]

Michael a écrit :
> Rocco Moretti wrote:
> 
> 
>>That is, what would happen with the following constructs:
>>
>>A if B else C if D else F
>>A if B if C else D else F
> 
> 
> The correct answer should be the person who wrote it would get told off
> for writing code that a person reading would have no idea what the code
> was doing (without understanding the precedence).
> 
> Whilst it's good to have clear understandable, well defined rules for
> these things, that's no excuse for having unreadable code that other
> people can't read and understand without having to remember obscure
> rules.
> 
> Personally, I'd hope that any code-linting tools would flag such expressions
> as potentially bad because they're not clear. (Whereas bracketed expressions
> instantly help here).

Actually, you don't need to know operator precedence here because the 
notation isn't ambiguous in those 2 examples. Of course, it takes some 
time to understand the thing but it has more to do with the excessive 
amount of "logic" in one line than with the syntax.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Christophe]

Steven D'Aprano a écrit :
> On Mon, 03 Oct 2005 06:59:04 +, Antoon Pardon wrote:
> 
> 
>>Well I'm a bit getting sick of those references to standard idioms.
>>There are moments those standard idioms don't work, while the
>>gist of the OP's remark still stands like:
>>
>>  egold = 0:
>>  while egold < 10:
>>if test():
>>  ego1d = egold + 1
> 
> 
> for item in [x for x in xrange(10) if test()]:
> 
> But it isn't about the idioms. It is about the trade-offs. Python allows
> you to do things that you can't do in other languages because you
> have much more flexibility than is possible with languages that
> require you to declare variables before using them. The cost is, some
> tiny subset of possible errors will not be caught by the compiler. But
> since the compiler can't catch all errors anyway, you need to test for
> errors and not rely on the compiler. No compiler will catch this error:
> 
> x = 12.0 # feet
> # three pages of code
> y = 15.0 # metres
> # three more pages of code
> distance = x + y
> if distance < 27:
> fire_retro_rockets()
> 
> And lo, one multi-billion dollar Mars lander starts braking either too
> early or too late. Result: a new crater on Mars, named after the NASA
> employee who thought the compiler would catch errors.
> 
> 
> Declared variables have considerable labour costs, and only marginal
> gains. Since the steps you take to protect against other errors will also
> protect against mistyping variables, declarations of variables is of
> little practical benefit.

As a matter of fact, doing that one on a HP48 calculator with unit 
anotated values would have worked perfectly, except for the distance < 
27 check which would have raised one error.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: So far

[Christophe]

CppNewB a écrit :
> I am absolutely loving my experience with Python.  Even vs. Ruby, the syntax 
> feels very clean with an emphasis on simplification.
> 
> My only complaint is that there doesn't appear to be a great commercial IDE 
> for the language.  I've tried Komodo, etc and they are nice applications, 
> but they don't feel like they give me the "power" like a Visual Studio or 
> Delphi (I wish I could articulate better the differences).Finding a 
> descent GUI builder has been a challenge as well.  Most of them have support 
> for Dialogs, but what about more complex UI's?  I may need a resizable frame 
> within a resizable frame? I haven''t found a GUI builder with a great feel 
> yet.
> 
> Other than that, my experience has been wonderful.  Even after my 
> complaints, I plan on sticking with Python for a while. 

Try PyQT with eric3 as an IDE.

http://www.die-offenbachs.de/detlev/eric3.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Christophe]

Roy Smith a écrit :
> There's more to it than just that.  Python's type checking is not just not 
> done at compile time, it's done as late in run time as possible.  One might 
> call it just-in-time type checking.

It's more of a "Nearly too late" type checking I would say. Not that I 
complain but it would be great if there were also some automatic type 
checking to catch a few errors as soon as possible.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Christophe]

Fredrik Lundh a écrit :
> "Christophe" wrote:
> 
> 
>>It's more of a "Nearly too late" type checking I would say. Not that I
>>complain but it would be great if there were also some automatic type
>>checking to catch a few errors as soon as possible.
> 
> 
> use assert as the soonest possible point.  implementing "type gates" is
> trivial, if you think you need them.

Still, it would be great if there were also some automatic type checking 
  in place. Using assert is hardly automatic and non intrusive.

I mean, why not ? Why does the compiler let me do that when you know 
perfectly that that code is incorrect :
def f():
  return "a" + 5

Of course the system can't be perfect but it doesn't need to be. It 
doesn't need to constrain us in any way but if it can detect some errors 
early, then it is worth it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: passing variable arguments to a function

[Christophe]

Ryan Wilcox a écrit :
> Hello all,
> 
> I want to be able to pass a variable number of parameters into a Python
> function. Now, I know how to _receive_ variable arguments, but I don't
> know how to _send_ them.
> 
> def myFunction(*args):
> print args
> 
> myList = [1, 2, 3, 4]
> myFunction(myList)
> 
> this function will print out ([1, 2, 3, 4]).
> 
> Except that's not what I want. I want the equivalent to:
> 
> myFunction(1, 2, 3, 4)
> 
> So, given an array, how can I unpack the array and pass all of the
> elements into a Python function as parameters?
> 
> Thanks in advance!,
> _Ryan Wilcox
> 

myFunction(*myList)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Yes, this is a python question, and a serious one at that (moving to Win XP)

[Christophe]

Kenneth McDonald a écrit :
> For unfortunate reasons, I'm considering switching back to Win XP  (from 
> OS X) as my "main" system. Windows has so many annoyances that  I can 
> only compare it to driving in the Bay Area at rush hour (OS X  is like 
> driving in Portland at rush hour--not as bad, but getting  there), but 
> there are really only a couple of things that are really,  absolutely 
> preventing me from making the switch. Number one is the  lack of a 
> decent command line and command-line environment, and I'm  wondering 
> (hoping) if perhaps someone has written a "Python shell"-- something 
> that will look like a regular shell, let users type in  commands, maybe 
> have some of the nice features of bash etc. like tab  completion, etc, 
> and will then execute an underlying python script  when the command is 
> entered. I'm not thinking of IDLE, but something  that is really aimed 
> more at being a system terminal, not a Python- specific terminal.
> 
> Yes, I know that Cygwin is out there, but last I looked, they still  
> went through the Win command-line window, which imposes a lot of  
> restrictions.
> 
> More generally, has anyone written any python programs to administer  
> various Win settings for which one must otherwise delve deep into  mazes 
> of twisty little dialogs, all alike? Or to help out with other  
> annoyances? I know there are a lot of general utilities, but if  they're 
> in Python, I can also use them as a starting base for my own  needs.
> 
> Finally, a significant incentive in doing this is that I could avoid  a 
> lot of installation hassle, since virtually everything has at least  a 
> decent installation package for Win. (I'd hoped this would happen  for 
> OS X, but it never has). Can anyone think of important python- related 
> packages (release level, not cutting edge alphas) for which  this might 
> not be the case?
> 
> Many thanks,
> Ken

Last time I checked, you could install a native win32gui version of rxvt 
with cygwin. This would give you a better terminal window than that 
crappy thing you get in XP.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question on class member in python

[Christophe]

Johnny Lee a écrit :
> Alex Martelli 写道：
> 
> 
>>Johnny Lee <[EMAIL PROTECTED]> wrote:
>>
>>
>>>But I still wonder what's the difference between the A().getMember and
>>>A().member besides the style
>>
>>Without parentheses after it, getMember is a method.  The difference
>>between a method object and an integer object (which is what member
>>itself is in your example) are many indeed, so your question is very
>>strange.  You cannot call an integer, you cannot divide methods, etc.
>>
>>
>>Alex
> 
> 
> Sorry, I didn't express myself clear to you. I mean:
> b = A().getMember()
> c = A().member
> what's the difference between b and c? If they are the same, what's the
> difference in the two way to get the value besides the style.
> 

Second form is better because it makes it easier to refactor.

Like, at first A had a direct access to the member member. But later you 
want to control the access to it. So you change it into a property and 
you don't need to change client code.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: UI toolkits for Python

[Christophe]

Mike Meyer a écrit :
> [EMAIL PROTECTED] (Alex Martelli) writes:
> 
>>Maybe that's the key difference between the mindset of a
>>mathematician and that of an engineer -- I consider reaching over
>>95% of visitors to be _quite good indeed_,
> 
> 
> Oh? So you'd consider an SMTP/IMAP/POP/DNS/NFS/etc server that
> rejected 5% of the systems connecting to be _quite good indeed_? I
> think I'm glad that the internet wasn't built by people who agreed
> with that.
> 
> If you know what you're doing, you can have the best of both worlds
> for a lot of web applications. Yes, it won't be as rich or functional
> for the five percent who worry about security (or whatever), but it'll
> still work. And yes, you can't do it for every application. For those,
> anyone vaguely competent will add a warning.
> 
> What surprises me is that marketing types will accept turning away -
> what's the current internet user base? 200 million? - 10 million
> potential customers without a complaint. Or maybe they just don't get
> told that that's what's going on.
> 
>   http://mail.python.org/mailman/listinfo/python-list

Re: UI toolkits for Python

[Christophe]

Mike Meyer a écrit :
> [EMAIL PROTECTED] (Alex Martelli) writes:
> 
>>Maybe that's the key difference between the mindset of a
>>mathematician and that of an engineer -- I consider reaching over
>>95% of visitors to be _quite good indeed_,
> 
> 
> Oh? So you'd consider an SMTP/IMAP/POP/DNS/NFS/etc server that
> rejected 5% of the systems connecting to be _quite good indeed_? I
> think I'm glad that the internet wasn't built by people who agreed
> with that.
> 
> If you know what you're doing, you can have the best of both worlds
> for a lot of web applications. Yes, it won't be as rich or functional
> for the five percent who worry about security (or whatever), but it'll
> still work. And yes, you can't do it for every application. For those,
> anyone vaguely competent will add a warning.
> 
> What surprises me is that marketing types will accept turning away -
> what's the current internet user base? 200 million? - 10 million
> potential customers without a complaint. Or maybe they just don't get
> told that that's what's going on.
> 
>   http://mail.python.org/mailman/listinfo/python-list

Re: wxPython Licence vs GPL

[Christophe]

Ed Jensen a écrit :
>>Well, despite your protestations, I think the GPL and LGPL are fairly
>>easy and safe choices for a lot of developers who know enough about
>>Free Software (ie. haven't just seen the name and thought "that's the
>>thing for me"), know what the characteristics of those licences are,
>>and who don't have the time or legal experience to "performance due
>>diligence".
> 
> 
> To be honest, I don't dislike the LGPL that much.  The static vs.
> dynamic linking issues bother me somewhat (which is why I like the
> modified LGPL used by wxWidgets), but all in all, I can live (albeit
> uncomfortably) with LGPL.  It seems much more sane.  Whereas including
> one line of GPL code into your 10,000,000,000 line project can have
> disasterous consequences (which I find ridiculous), at least with LGPL
> you're only asked to share the changes you've made to that particular
> library.

If you don't like the GPL, then by all means, *do not use GPL code !*

Please, I mean, when you use without authorisation some code in your 
project, you are in trouble, no matter what licence the code was using.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Death to tuples!

[Christophe]

Antoon Pardon a écrit :
> On 2005-11-30, Duncan Booth <[EMAIL PROTECTED]> wrote:
> 
>>Antoon Pardon wrote:
>>
>>>But lets just consider. Your above code could simply be rewritten
>>>as follows.
>>>
>>>  res = list()
>>>  for i in range(10):
>>> res.append(i*i)
>>>
>>
>>I don't understand your point here? You want list() to create a new list 
>>and [] to return the same (initially empty) list throughout the run of the 
>>program?
> 
> 
> No, but I think that each occurence returning the same (initially empty)
> list throughout the run of the program would be consistent with how
> default arguments are treated.

What about that :
def f(a):
 res = [a]
 return res

How can you return the same list that way ? Do you propose to make such 
construct illegal ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is there no compression support for large sized strings in Python?

[Christophe]

Gerald Klix a écrit :
> Did you consider the mmap library?
> Perhaps it is possible to avoid to hold these big stings in memory.
> BTW: AFAIK it is not possible in 32bit windows for an ordinary programm 
> to allocate more than 2 GB. That restriction comes from the jurrasic 
> MIPS-Processors, that reserved the upper 2 GB for the OS.

As a matter of fact, it's Windows which reserved the upper 2 GB. There a 
simple setting to change that value so that you have 3 GB available and 
another setting which can even go as far as 3.5 GB available per process.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why my modification of source file doesn't take effect when debugging?

[Christophe]

infidel a écrit :
>>I'm using the Windows version of Python and IDLE. When I debug my .py
>>file, my modification to the .py file does not seem to take effect
>>unless I restart IDLE. Saving the file and re-importing it doesn't help
>>either. Where's the problem?
> 
> 
> "import" only reads the file the first time it's called.  Every import
> call after that looks up the module in memory.  This is to prevent
> circular dependencies between modules from creating infinite loops.
> You need to use the reload() function:

As a matter of fact, it would help a lot if that stupid behaviour of 
Idle was dropped. I'm sure I'm not the only one who lost lots of time 
because of that bug. Yes I call it a bug.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why my modification of source file doesn't take effect whendebugging?

[Christophe]

Fredrik Lundh a écrit :
> Christophe wrote:
> 
> 
>>>"import" only reads the file the first time it's called.  Every import
>>>call after that looks up the module in memory.  This is to prevent
>>>circular dependencies between modules from creating infinite loops.
>>>You need to use the reload() function:
>>
>>As a matter of fact, it would help a lot if that stupid behaviour of
>>Idle was dropped. I'm sure I'm not the only one who lost lots of time
>>because of that bug. Yes I call it a bug.
> 
> 
> in the version of IDLE I have on this machine, if I modify my script and
> run it again (using F5), things work exactly as expected.
> 
> if I modify my script and import it into a clean shell (ctrl-F6), things work
> exactly as expected.
> 
> the only way to get the "buggy" behaviour you're describing is to attempt
> to run your program by importing it as a module more than once into an
> existing python shell process.  in that case, import works in the same way
> as it always works.
> 
> after all, "import" isn't designed to run programs, it's designed to import
> modules.  if you want to run stuff in IDLE, why not just use the "run"
> command ?

F5 is designed to run the current open file. Sane people won't assume 
that pressing twice the F5 key will yield different. Sane people will 
assume that when you edit file1.py and press F5, it reparses the file, 
but when you edit file2.py and press F5 with file1.py it won't work. Why 
make it different ? Why make is so that I have to select the shell 
window, press CTRL+F6, select the file1.py and press F5 just so that it 
works as expected ?

Idle is ok when you edit a single .py file. As soon as I need to edit 2 
.py files with one using the other, I'm glad I have other editors which 
spanw a clean shell each time I run the current file.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why my modification of source file doesn't take effectwhendebugging?

[Christophe]

Fredrik Lundh a écrit :
> "Christophe" wrote:
> 
> 
>>F5 is designed to run the current open file. Sane people won't assume
>>that pressing twice the F5 key will yield different. Sane people will
>>assume that when you edit file1.py and press F5, it reparses the file,
>>but when you edit file2.py and press F5 with file1.py it won't work. Why
>>make it different ? Why make is so that I have to select the shell
>>window, press CTRL+F6, select the file1.py and press F5 just so that it
>>works as expected ?
> 
> 
> I'm not sure I follow here: in the version of IDLE I have here, pressing
> F5 will save the current file and run it.  If you've edit other parts of the
> application, you have to save those files (Control-S) and switch to the
> main script before pressing F5, but that's only what you'd expect from
> a "run this module" command.
> 
> (being able to bind F5 to a specific script might be practical, of course,
> but I'm don't think that's what you're complaining about.  or is it?)
> 
> 
>>Idle is ok when you edit a single .py file. As soon as I need to edit 2
>>.py files with one using the other, I'm glad I have other editors which
>>spanw a clean shell each time I run the current file.
> 
> 
> In the version of IDLE I have, that's exactly what happens (that's what
> the RESTART lines are all about).
> 
> Is there some secret setting somewhere that I've accidentally managed
> to switch on or off to get this behaviour?

What I remember ( but maybe it was changed in recent Idle versions ) was 
that when your project has a main.py which imports a module.py, when you 
run your project once, any later changes you make in module.py won't be 
taken into account.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why my modification of source file doesn't take effect when debugging?

[Christophe]

Dave Hansen a écrit :
> On Fri, 02 Dec 2005 18:04:15 +0100 in comp.lang.python, Christophe
> <[EMAIL PROTECTED]> wrote:
> 
> 
>>infidel a écrit :
>>
>>>>I'm using the Windows version of Python and IDLE. When I debug my .py
>>>>file, my modification to the .py file does not seem to take effect
>>>>unless I restart IDLE. Saving the file and re-importing it doesn't help
>>>>either. Where's the problem?
>>>
>>>
>>>"import" only reads the file the first time it's called.  Every import
>>>call after that looks up the module in memory.  This is to prevent
>>>circular dependencies between modules from creating infinite loops.
>>>You need to use the reload() function:
>>
>>As a matter of fact, it would help a lot if that stupid behaviour of 
>>Idle was dropped. I'm sure I'm not the only one who lost lots of time 
>>because of that bug. Yes I call it a bug.
> 
> 
> But, if you are editing a Python Module in Idle, and press F5 to run
> the module, the interpreter is restarted for you.  So what's the
> problem?
> 
> I would consider it a far greater problem if Idle _didn't_ do that --
> it could mean you module worked when you were debuggining it because
> of some initialization that doesn't get performed in a clean start.
> 
> Regards,
> -=Dave
> 

Well, I'm happy to see that Idle now restarts the interpreter by default 
when you press F5. I guess I might consider using it again after all 
that time :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs bad

[Christophe]

Paul McNett a écrit :
> Björn Lindström wrote:
> 
>> Paul Rubin  writes:
>>
>>
>>> [EMAIL PROTECTED] (Björn Lindström) writes:
>>>
 Actually using tabs for eight spaces and then filling out with 
 spaces to
 the correct indentation is the convention for Emacs Lisp. Of course,
 since everyone coding Emacs Lisp does it with the same editor, it's no
 problem.
>>>
>>>
>>> The variable `indent-tabs-mode' controls this.  I like no tabs.
>>
>>
>>
>> Same here. It's still the convention for Emacs code, regrettably.
> 
> 
> I don't use Emacs, I do indent with tabs, and I do fill in the extra 
> spaces of continuation lines with spaces. Therefore, I break all the 
> commandments and do everything wrong. ;)
> 
> FWIW, I've long struggled with my opinion on tabs versus spaces. When I 
> started programming in 1995, tabs seemed the logical choice because I 
> was using different editors all the time and I could tell each editor 
> how many spaces to give each tab. But then as I started reading more 
> people's code I started seeing patterns in source code that I couldn't 
> emulate using pure tabs. This comes down to horizontal "lining up" 
> continuation lines with prior lines. Examples:
> 
> select customer.cfirst,
>customer.clast
>   from customer
>  where customer.cstate in ("CA", "OR")
>  order by customer.clast
> 
> win = dabo.ui.dDialog(self, NameBase="frmRulesDialog",
>   Caption="Minesweeper Rules", 
> SaveRestorePosition=True,
>   Centered=True, Modal=False)
> 
> Everyone that was writing "beautiful code" like this was using spaces 
> only. So I switched. But it was a real PITA to not be able to use any 
> old editor, only ones that could set how many hard spaces to make for 
> each hard tab. And, I had to remember to make that setting because I 
> prefer 2 spaces per tab.
> 
> So now I'm back to tabs for indentation and spaces for lining up 
> continuation lines. Example:
> 
> win = dabo.ui.dDialog(self, NameBase="frmRulesDialog",
>   Caption="Minesweeper Rules", 
> SaveRestorePosition=True,
>   Centered=True, Modal=False)
> 
> (if that didn't come over email correctly, that is one tab for 
> indentation on all three lines, followed by several spaces on lines 2 
> and 3 for getting the arguments lined up with the previous line.)
> 
> I've been reluctant to admit to doing this since it violates the NEVER 
> MIX TABS AND SPACES commandment, but there you go. I found a way to 
> reconcile the best of both worlds, because let's face it, tabs do make 
> slightly more sense.

This is the only sane way to mix tabs with spaces anyway. Keep tabs as 
an indentation counter and use spaces to fill up the remaining space for 
the looks of the code.
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Christophe]

Zeljko Vrba a écrit :
> On 2005-12-02, Micah Elliott <[EMAIL PROTECTED]> wrote:
> 
>>On Dec 02, Dave Hansen wrote:
>>
>>>Python recognizes the TAB character as valid indentation.  TAB
>>>characters are evil.  They should be banned from Python source code.
>>
>>AGREE!  AGREE!  AGREE! 
>>
> 
> The day TABs are banned from the source, I drop python forever. It took me
> too long to get used to indentation in the first place, now if you ban TABs
> (which make code formatting a whole lot easier), I'm dropping python.

Editors make code formatting easier, not TABs. Maybe it's time to leave 
the 80s and use a code editor that works with you and not against you ;)
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Christophe]

Paul Rubin a écrit :
> Antoon Pardon <[EMAIL PROTECTED]> writes:
> 
>>But lately I have been wondering about doing the following:
>>end = None
>>...
>>  if ...:
>>...
>>  end
>>IMO it looks better, but I'm reluctant because it suggest
>>some checking by the compilor, which just doesn't happen.
> 
> 
> I don't think you can always do that.
> 
> try:
>   ...
> end
> except blah:
>...
> 
> looks syntactically invalid.

You shouldn't put "end" before the except but after :

try:
   ...
except blah:
   ...
end
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Christophe]

David Rasmussen a écrit :
> Antoon Pardon wrote:
> 
>>>
>>> Write shorter functions ;)
>>
>>
>> This has little to do with long functions. A class can contain
>> a large number of methods, whitch are all rather short, and your
>> class will still be spread over several pages.
>>
> 
> Write classes with a smaller interface ;-)
> 
> /David

What about an editor that will reserve the first lines in the edit 
window to show the current class ? Could be a cool feature here :) 
You'll see something like that when you scroll too far :

FileEdit   OptionsAbout
---
class do_something(object):
...
 return 1

def do_it(self):
 print self.what_now
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pretty windows installer for py scripts

[Christophe]

rbt a écrit :
> Any recommendations on a windows packager/installer that's free? I need
> it to allow non-tech users to install some python scripts... you know,
> "Click Next"... "Click Next"... "Click Finish"... "You're Done!" and
> everything just magically works ;)

Isn't that already available in the distutils module ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pretty windows installer for py scripts

[Christophe]

Paul Rubin a écrit :
> Christophe <[EMAIL PROTECTED]> writes:
> 
>>>Any recommendations on a windows packager/installer that's free? I need
>>>it to allow non-tech users to install some python scripts... you know,
>>>"Click Next"... "Click Next"... "Click Finish"... "You're Done!" and
>>>everything just magically works ;)
>>
>>Isn't that already available in the distutils module ?
> 
> 
> No not really.  There's a thing like that for installing library
> modules but AFAIK it doesn't make an easy way to install desktop
> applications with start menu icons and all that kind of stuff.  Inno
> Setup does do those things.

I'll take your word on that. If you want to create a fully contained 
installer, you should use py2exe and on the samples there's an exemple 
in how to integrate InnoSetup.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Inconsistent reaction to extend

[Christophe]

Antoon Pardon a écrit :
>>Because creating a new list is potentially very time-consuming and
>>expensive of memory. Imagine you have a list of 100,000 large objects, and
>>you want to add one more object to it. The way Python works is that append
>>and extend simply add that new object to the end of the existing list. The
>>way you imagined it would work would require Python to duplicate the
>>entire list, all 100,000 large objects, plus the extra one.
> 
> 
> This has nothing to do with the need to create a new list.
> 
> The extend method could just have returned self. Just as sort and reverse 
> could 
> have done so. This would have made it possible to do things like the 
> following:
> 
>   lst.sort().reverse()
> 
> instead of having to write:
> 
>   lst.sort()
>   lst.reverse()

This was done on purpose to avoid a second class of problems. The one 
where you forget that reverse modifies the list in place. That second 
class of problems was deemed more dangerous because it works without 
immediate errors.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: help in simplification of code [string manipulation]

[Christophe]

John a écrit :
> How could I simplify the code to get libs out of LDFLAGS
> or vice versa automatically in the following python/scons code?
> 
> if sys.platform[:5] == 'linux':
>   env.Append (CPPFLAGS = '-D__LINUX')
>   env.Append (LDFLAGS  = '-lglut -lGLU -lGL -lm')
>   env.Append(CPPPATH=['include', 'include/trackball'])
>   libs = ['glut', 
>   'GLU',
>   'GL',
>   'm',]
> 
> 
> Thanks,
> --j
> 

Why don't you use the LIBS var in the environment instead of the LDFLAGS 
? And what use would be the libs var for you ?

if sys.platform[:5] == 'linux':
libs = ['glut',
'GLU',
'GL',
'm',]
env.Append (CPPFLAGS = '-D__LINUX')
env.Append (LIBS = Split(libs))
env.Append(CPPPATH=['include', 'include/trackball'])
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyGTK or wXPython?

[Christophe]

Peter Decker a écrit :
> On 9/13/05, Rod W <[EMAIL PROTECTED]> wrote:
> 
>>I'm just starting out on Python but my primary goal is to provide
>>applications with some user interface (GUI).
>>
>>Can someone point me to a good comparison of whether I should use
>>wxPython (with wxGlade I assume) or PyGTK (with Glade I assume)?
>>
>>I'd prefer open source (not necessarily GPL though) tools.
> 
> 
> I looked at both, and preferred wxPython's look. I hated its C-like
> feeling, with some very un-Pythonic code that failed to hide its C
> roots very well, but I used it because the results were so good.
> 
> Since then I've discovered Dabo, which is a complete application
> framework, and which wraps wxPython for its UI. Apparently, the
> authors of Dabo also didn't like the style of wxPython code, and have
> created their own classes that expose a cleaner, much more Pythonic
> API. I've been using Dabo for some small GUI apps, and I still can't
> believe how much easier it is to create the UI with Dabo than with
> plain wxPython. You should definitely check it out if you decide to go
> the wxPython route.
> 

There's Wax which is a cleaner pythonic API on top of wxPython.

Myself, I would go the PyQT way because the API is very clean and 
there's one less abstraction layer on top of it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: help in simplification of code [string manipulation]

[Christophe]

John a écrit :
> Thanks for your replies...
> Solved my problem.

Even so, I made a big mistake here. The Split function is of no use 
because there is already a list of flags. Better do it like that :
libs = Split('glut GLU GL m')
env.Append (LIBS = libs)

BTW, Split is a scons function.

> Christophe wrote:
> 
>>John a écrit :
>>
>>>How could I simplify the code to get libs out of LDFLAGS
>>>or vice versa automatically in the following python/scons code?
>>>
>>>if sys.platform[:5] == 'linux':
>>> env.Append (CPPFLAGS = '-D__LINUX')
>>> env.Append (LDFLAGS  = '-lglut -lGLU -lGL -lm')
>>> env.Append(CPPPATH=['include', 'include/trackball'])
>>> libs = ['glut',
>>> 'GLU',
>>> 'GL',
>>> 'm',]
>>>
>>>
>>>Thanks,
>>>--j
>>>
>>
>>Why don't you use the LIBS var in the environment instead of the LDFLAGS
>>? And what use would be the libs var for you ?
>>
>>if sys.platform[:5] == 'linux':
>>  libs = ['glut',
>>  'GLU',
>>  'GL',
>>  'm',]
>>  env.Append (CPPFLAGS = '-D__LINUX')
>>  env.Append (LIBS = Split(libs))
>>  env.Append(CPPPATH=['include', 'include/trackball'])
> 
> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: 32bit install on 64bit system

[Christophe]

Peter Hartmann a écrit :
> Hello,
> I could really use some help.  I'm trying to install a python program
> on centos4 x86_64.  When I run 'python setup.py' it ends up in
> /usr/lib64/python2.3/site-packages/  instead of
> /usr/lib/python2.3/site-packages.  It's a problem because the program
> I'm trying to install is a dependency for something that is only
> 32bit.  How can I specify a 32bit install?What I've tried so far: 
> When I try 'python setup.py build --build-lib
> /usr/lib/python2.3/site-packages'  and  'python setup.py install
> --install-lib /usr/lib/python2.3/site-packages', it installs the 64bit
> version into the 32bit library.Can anyone help me?

Try using the 32bit version of python to run setup.py
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: IDE, widget library

[Christophe]

Alessandro Bottoni a écrit :
> Try wxPython (Based on wxWidgets). Really "free" (LGPL'ed = MIT license) on
> all platforms, well-engineered, documented and supported, native look&feel
> on all platform. Need anything else? ;-)

Some people have that weird notion that GTK is native look and feel on 
all Linux platforms. Unfortunately for you, I have no GTK applications 
running on *my* system and all wxPython apps look so outlandish :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: p2exe using wine/cxoffice

[Christophe]

Tim Roberts a écrit :
> James Stroud <[EMAIL PROTECTED]> wrote:
> 
>>I think the motivation is to ween people off of M$ products altogether, 
> 
> 
> Well, CrossOver Office doesn't really do that.  You're still running
> Microsoft Office.
> 
> 
>>...to get 
>>them used to working an a unix environment and to the idea of using open 
>>alternatives rather than thinking that commercial software is somehow 
>>"better".
> 
> 
> Regardless of your opinion on their operating systems, only a religious
> zealot would try to argue that Microsoft Office is not better than any of
> the open source alternatives.

Some significant parts of Microsoft Office are worse than what you get 
in OO.o Mainly, you could easily argue that OOWriter is better than 
Word. I wouldn't try to make the same claim for the other parts of OO.o 
though :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: C#3.0 and lambdas

[Christophe]

Wolfgang Langner a écrit :
> Hello,
> 
>> "Is anyone truly attached to nested tuple function parameters; 'def
>> fxn((a,b)): print a,b'?  /.../
>>
>> Would anyone really throw a huge fit if they went away?  I am willing
>> to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
>> people are up for it."
> 
> 
> First I missed the def and thought "Oh no don't remove it
> sometimes I pass a tuple to my functions".
> But the I saw the "def" keyword and realized I never
> used such a function syntax.
> 
> So, in one line (my mailer truncated it):
> 
> def fxn((a,b)): print a,b'
> 
> for removal, not:
> 
> 'fxn((a,b)' function calls
> 
> 
> I'm ok with removal.
> 
> 
> bye by Wolfgang

I use them a lot myself and I wouldn't want to see them removed. It is 
just so convenient to have 2D coordinates be simple tuples and have 
functions which alternatively take pos or (x,y) as a parameter.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: C#3.0 and lambdas

[Christophe]

Max M a écrit :
> Steven D'Aprano wrote:
> 
>> On Mon, 19 Sep 2005 10:31:48 +0200, Fredrik Lundh wrote:
>>
>> How many items should you pass in the tuple? If it takes variable
>> arguments, then that works, but if you always expect a fixed number, then
>>
>> def func((x, y))
>>
>> is more explicit.
>>
>> The only problem I have is that once you unroll the tuple like that, 
>> it is
>> hardly necessary to pass the argument as a tuple. Why not just pass x and
>> y as two arguments?
>>
>> def func(x, y)
> 
> 
> 
> why not just pass the tuple as arguments then?
> 
> def func(*(x, y))
> 
> or as it would normally look:
> 
> def func(*arg)
> 
> That should work just as well for those cases.

I don't want to unroll x, y in the function API because the function 
signature is that it takes a position object. The fact that the position 
object just happens to be a 2 element tuples as no incidence on that. I 
want the function API to be that. Why would you ask ? Because it make 
sense to do it like that when I create a second function which takes 2 
posiiton objets.

Why should I call the first with that sytnax : f(*pos) and the second 
with that one : g(pos1, pos2)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: C#3.0 and lambdas

[Christophe]

Serhiy Storchaka a écrit :
> Roel Schroeven wrote:
> 
>> Fredrik Lundh schreef:
>>
>>> meanwhile, over in python-dev land:
>>>
>>>"Is anyone truly attached to nested tuple function parameters; 'def
>>>fxn((a,b)): print a,b'?  /.../
>>>
>>>Would anyone really throw a huge fit if they went away?  I am willing
>>>to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
>>>people are up for it."
>>
>>
>> I for one would not like to see that disappear. I like being able to
>> write, for example:
>>
>> def drawline((x1, y1), (x2, y2)):
>> # draw a line from x1, y1 to x2, y2
>> foo(x1, y1)
>> bar(x2, y2)
>>
>> instead of
>>
>> def drawline(p1, p2):
>> x1, y1 = p1
>> x2, y2 = p2
>> # draw a line from x1, y1 to x2, y2
>> foo(x1, y1)
>> bar(x2, y2)
>>
>> or
>>
>> def drawline(p1, p2):
>> # draw a line from p1[0], p1[1] to p2[0], p2[1]
>> foo(p1[0], p1[1])
>> bar(p2[0], p2[1])
> 
> 
>  def drawline(p1, p2):
>  # draw a line from p1 to p2
>  foo(*p1)
>  bar(*p2)
> 

That one is stupid. I don't see how you can make it work without some 
global storing the p1 information in foo which I would consider as very 
ugly code.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: C#3.0 and lambdas

[Christophe]

Fredrik Lundh a écrit :
> Christophe wrote:
> 
> 
>>> def drawline(p1, p2):
>>> # draw a line from p1 to p2
>>> foo(*p1)
>>> bar(*p2)
>>>
>>
>>That one is stupid. I don't see how you can make it work without some
>>global storing the p1 information in foo which I would consider as very
>>ugly code.
> 
> 
> if you cannot see how that can work, you clearly haven't done much graphics
> programming in your days...

You should probably notice that graphics library have changed a lot in 
the last 20 years. Also, that one was an example but it could have been :

def draw_circle(c, p):
 """Draws a circle centered on c and which goes through p"""
 pass
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: C#3.0 and lambdas

[Christophe]

Steve Holden a écrit :
> Christophe wrote:
> 
>> Serhiy Storchaka a écrit :
>>
>>> Roel Schroeven wrote:
> 
> [...]
> 
>>>> or
>>>>
>>>> def drawline(p1, p2):
>>>># draw a line from p1[0], p1[1] to p2[0], p2[1]
>>>>foo(p1[0], p1[1])
>>>>bar(p2[0], p2[1])
>>>
>>>
>>>
>>> def drawline(p1, p2):
>>> # draw a line from p1 to p2
>>> foo(*p1)
>>> bar(*p2)
>>>
>>
>>
>> That one is stupid. I don't see how you can make it work without some 
>> global storing the p1 information in foo which I would consider as 
>> very ugly code.
> 
> 
> In which case perhaps you should actually try the code. Then once you 
> realise it works you can start to figure out why :-). Hint: f(*p1) 
> appears as len(p1) separate arguments to the called function.

You should also notice that foo knows the starting point of the line but 
not the ending point and so it can't draw the line. On the other hand, 
bar knows the end point but not the starting point so it can't do the 
job either.

And what about a function which computes the line length ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: C#3.0 and lambdas

[Christophe]

Steve Holden a écrit :
> Christophe wrote:
> 
>> Steve Holden a écrit :
>>
>>> Christophe wrote:
>>>
>>>
>>>> Serhiy Storchaka a écrit :
>>>>
>>>>
>>>>> Roel Schroeven wrote:
>>>
>>>
>>> [...]
>>>
>>>
>>>>>> or
>>>>>>
>>>>>> def drawline(p1, p2):
>>>>>>   # draw a line from p1[0], p1[1] to p2[0], p2[1]
>>>>>>   foo(p1[0], p1[1])
>>>>>>   bar(p2[0], p2[1])
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> def drawline(p1, p2):
>>>>># draw a line from p1 to p2
>>>>>foo(*p1)
>>>>>bar(*p2)
>>>>>
>>>>
>>>>
>>>> That one is stupid. I don't see how you can make it work without 
>>>> some global storing the p1 information in foo which I would consider 
>>>> as very ugly code.
>>>
>>>
>>>
>>> In which case perhaps you should actually try the code. Then once you 
>>> realise it works you can start to figure out why :-). Hint: f(*p1) 
>>> appears as len(p1) separate arguments to the called function.
>>
>>
>>
>> You should also notice that foo knows the starting point of the line 
>> but not the ending point and so it can't draw the line. On the other 
>> hand, bar knows the end point but not the starting point so it can't 
>> do the job either.
>>
> This is rubbish.
> 
>   foo(*p1)
> 
> is *exactly* equivalent to
> 
>   foo(p1[0], p1[1])
> 
> and similarly
> 
>   bar(p2)
> 
> is *exactly* equivalent to
> 
>   bar(p2[0], p2[1])
> 
> and consequently the second version of drawline is exactly equivalent to 
> the first. So, if the second one is useless then so is the first.

Well, sorry about that but you are perfectly right. The point I was 
trying to defend though was that such construct is very uncommon. It 
isn't always possible to unpack the tuples like that because you usually 
need all the info at once.

>> And what about a function which computes the line length ?
> 
> 
> I'm not sure what point you are trying to make here. Can you explain?

As I said, the point was that in that specific case, you can do it like 
that, but most of the time you need the unpack info for all the data in 
the same function. For example to compute the line length.

def length((x1,y1),(x2,y2)):
 return math.hypot(x1-x2,y1-y2)

No unpack trick ( that I know of ) can be used here. You only have 1 way 
to do it without the unpack in function parameters syntax :

def length(p1, p2):
 x1, y1 = p1
 x2, y2 = p2
 return math.hypot(x1-x2,y1-y2)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: C#3.0 and lambdas

[Christophe]

Dennis Lee Bieber a écrit :
> On Wed, 21 Sep 2005 17:08:14 +0200, Christophe <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
> 
> 
> 
>>No unpack trick ( that I know of ) can be used here. You only have 1 way 
>>to do it without the unpack in function parameters syntax :
>>
>>def length(p1, p2):
>> x1, y1 = p1
>> x2, y2 = p2
>> return math.hypot(x1-x2,y1-y2)
> 
> 
>>>>import math
>>>>def length(p1, p2):
> 
> ... return math.hypot(p1[0] - p2[0], p1[1] - p2[1])
> ...
> 
>>>>length((1,2),(4,6))
> 
> 5.0
> 
> 
>   Still no need for intermediate variables, you can index the tuple at
> need.

Well, I prefer the explicit tuple unpack anyway. It gives better results 
than using tuple indexing ( and better performance too most of the time )
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: C#3.0 and lambdas

[Christophe]

Steven Bethard a écrit :
> Steven D'Aprano wrote:
> 
>> I would love to see your test code and profiling results that demonstrate
>> that explicit tuple unpacking in the body of a function is faster than
>> tuple unpacking (implicit or explicit) in the header of a function.
> 
> 
> Should be pretty close.  I believe the byte-code is nearly identical:

You forgot the most important function : f3

 >>> def f1((x,y)):
... print x,y
...
 >>> def f2(x_y):
... x,y = x_y
... print x,y
...
 >>> def f3(x_y):
... print x_y[0], x_y[1]
...
 >>> import dis
 >>> dis.dis(f1)
   1   0 LOAD_FAST0 (.0)
   3 UNPACK_SEQUENCE  2
   6 STORE_FAST   1 (x)
   9 STORE_FAST   2 (y)

   2  12 LOAD_FAST1 (x)
  15 PRINT_ITEM
  16 LOAD_FAST2 (y)
  19 PRINT_ITEM
  20 PRINT_NEWLINE
  21 LOAD_CONST   0 (None)
  24 RETURN_VALUE
 >>> dis.dis(f2)
   2   0 LOAD_FAST0 (x_y)
   3 UNPACK_SEQUENCE  2
   6 STORE_FAST   2 (x)
   9 STORE_FAST   1 (y)

   3  12 LOAD_FAST2 (x)
  15 PRINT_ITEM
  16 LOAD_FAST1 (y)
  19 PRINT_ITEM
  20 PRINT_NEWLINE
  21 LOAD_CONST   0 (None)
  24 RETURN_VALUE
 >>> dis.dis(f3)
   2   0 LOAD_FAST0 (x_y)
   3 LOAD_CONST   1 (0)
   6 BINARY_SUBSCR
   7 PRINT_ITEM
   8 LOAD_FAST0 (x_y)
  11 LOAD_CONST   2 (1)
  14 BINARY_SUBSCR
  15 PRINT_ITEM
  16 PRINT_NEWLINE
  17 LOAD_CONST   0 (None)
  20 RETURN_VALUE
 >>>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: putenv

[Christophe]

Mike Meyer a écrit :
> Terry Hancock <[EMAIL PROTECTED]> writes:
> 
>>On Tue, 20 Dec 2005 05:35:48 -
>>Grant Edwards <[EMAIL PROTECTED]> wrote:
>>
>>>On 2005-12-20, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>>>wrote:
>>>
I have csh script that calls a bunch of python programs
and I'd like to use env variables as kind of a global
variable that I can pass around to the pythong scripts.
>>>
>>>You can't change the environment of the parent process.
>>>
>>>IOW, the python programs can't change the environment of
>>>the calling csh script (or, by extenstion, the environment
>>>of subsequent python programs that are called by the csh
>>>script).
>>
>>There is an evil trick, however:
>>
>>Instead of setting the environment directly, have the python
>>program return csh code to alter the environment the way you
>>want, then call the python code by "sourcing" its output:
>>
>>source `my_script.py`
> 
> 
> Does this actually work? It looks to me like you need two levels:
> my_script.py creates a file, then outputs the name of the file, as the
> csh source command reads commands from the file named as an argument.

Should work, even in basic sh. IIRC, source means the shell should 
execute the data itself. I've always used it with an intermediate file 
but I wouldn't be surprised if there was a way to make it work with a 
command output.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: OOP: method overriding works in mysterious ways?

[Christophe]

John M. Gabriele a écrit :
> Consider the following:
> 
> #!/usr/bin/python
> 
> #-
> class Grand_parent( object ):
> 
> def speak( self ):
> print 'Grand_parent.speak()'
> self.advise()
> 
> def advise( self ):
> print 'Grand_parent.advise()'
> self.critique()
> 
> def critique( self ):
> print 'Grand_parent.critique()'
> 
> 
> #-
> class Parent( Grand_parent ):
> 
> def speak( self ):
> print '\tParent.speak()'
> self.advise()
> 
> def advise( self ):
> print '\tParent.advise()'
> self.critique()
> 
> # ATM, the Parent is at a loss for words, and has no critique.
> 
> 
> #-
> class Child( Parent ):
> 
> def speak( self ):
> print '\t\tChild.speak()'
> self.advise()
> 
> # Currently, the Child has no really useful advice to give.
> 
> def critique( self ):
> print '\t\tChild.critique()'
> 
> 
> #-
> print 'speak() calls advise(), then advise() calls critique().'
> print
> 
> people = [ Grand_parent(), Parent(), Child() ]
> for person in people:
> person.speak()
> print
> 
> 
> 
> 
> The output is:
> 
> speak() calls advise(), then advise() calls critique().
> 
> Grand_parent.speak()
> Grand_parent.advise()
> Grand_parent.critique()
> 
> Parent.speak()
> Parent.advise()
> Grand_parent.critique()
> 
> Child.speak()
> Parent.advise()
> Child.critique()
> 
> 
> What's going on here with that last "Child.critique()"? The
> Parent called self.critique(), and since it *had* no critique()
> method, it should've deferred to it's parent's critique()
> method, right? But instead, somehow Child.critique() got called.
> Why?
> 
> ---J
> 
Because that's the way virtual methods are supposed to work. When you 
can a methon foo on an object, you always start your search from the 
current object class and not the class of the current function.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Coding style

[Christophe]

Patrick Maupin a écrit :
> The perverse wish, expressed in the specific example, that SOME piece
> of code SOMEWHERE should PLEASE throw an exception because some idiot
> passed a generator expression rather than a list into a function, is
> not apt to be well received by an audience which strives for generality
> when it makes sense

Well then, you haven't beed using enouth generator expressions or else, 
that kind of mistake would have bitten you badly by now and you would 
agree with that remark !

> confronted with the wished-for exception, would fix the function so
> that it quite happily accepted generator expressions, rather than
> changing a conditional to use len() just so that an equivalent
> exception could happen a bit earlier.

Thanks but NO. If that function needs to iterate twice on the 
expression, then it needs to iterate twice and passing it a generator 
will only cause strange bugs.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: #!/usr/bin/python or #!/usr/bin/env python?

[Christophe]

Stephan Kuhagen a écrit :
>> Always prefer to use env over a hardcoded path, because that hardcoded
>> path will invariably be wrong.  (Yes, for those about to nitpick, it's
>> conceivable that env might be somewhere other than /usr/bin.  However,
>> that is very rare and results in a no-win situations regardless of the
>> issue of where Python is installed.)
> 
> Don't yell at me for bringing in another language, but I really like the
> trick, Tcl does:
> 
>>#!/bin/sh
>># The next line starts Tcl \
>>exec tclsh "$0" "$@"
> 
> This works by the somewhat weird feature of Tcl, that allows comments to be
> continued in the next line with "\" at the end of the comment-line. It
> looks unfamiliar, but has several advantages, I think. First it's really
> VERY unlikely, that there is no /bin/sh (while I found systems with
> different places for env), and you can add some other features at or before
> the actual call of the interpreter, i.e. finding the right or preferred
> version... - This way I coded a complete software-installer, that runs
> either as a Tcl/Tk-Script with GUI, or as bash-script, when no Tcl is
> available. - I really would like to have something like that for python,
> but I did not find a way to achieve that, yet.
> 
> Regards
> Stephan
> 

What about that one ( windows .bat file ) :

@echo off
rem = """-*-Python-*- script
rem  DOS section 
rem You could set PYTHONPATH or TK environment variables here
python -x %~f0 %*
goto exit

"""
#  Python section 
import sys
print sys.argv


DosExitLabel = """
:exit
rem """


I'm sure it can be updated to work on Unix too :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Christophe]

Jeremy Sanders a écrit :
> Licheng Fang wrote:
> 
>> I was using VC++.net and IDLE, respectively. I had expected C++ to be
>> way faster. However, while the python code gave the result almost
>> instantly, the C++ code took several seconds to run! Can somebody
>> explain this to me? Or is there something wrong with my code?
> 
> It must be the debugging, the compiler or a poor STL implementation. With
> gcc 4 it runs instantly on my computer (using -O2), even with 10x the
> number of values.
> 
> If the problem is that C++ has to make lots of new strings, as other posters
> have suggested, then you could do something like
> 
> const string foo = "What do you know?";
> 
> for (long int i=0; i<1 ; ++i){
>a.push_back(foo);
>...
> }
> 
> as many C++ implementations use reference counting for identical strings.
> 
> Jeremy
> 

As a matter of fact, do not count on that. Use a vector just in 
case.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Dive Into Java?

[Christophe]

Diez B. Roggisch a écrit :
> The code _generated_ by the java compiler, and the C++ compiler, is not the
> issue here. If you as a programmer can write "a" + "b", its fine. Which is
> a thing to reach in C++, a bazillion of string-classes have been
> written
> 
> 
> and in C++, you can do:
> 
> char *a = "1";
> char *b = "2";
> char *c = a + b;
> 
> But with a totally different, unexpected outcome.. I know where *I* start
> laughing here.

That code doesn't even compile. And you shouldn't be using the char* 
compatibility strings in C++ if possible.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Dive Into Java?

[Christophe]

Diez B. Roggisch a écrit :
> Christophe wrote:
> 
>> Diez B. Roggisch a écrit :
>>> The code _generated_ by the java compiler, and the C++ compiler, is not
>>> the issue here. If you as a programmer can write "a" + "b", its fine.
>>> Which is a thing to reach in C++, a bazillion of string-classes have been
>>> written
>>>
>>>
>>> and in C++, you can do:
>>>
>>> char *a = "1";
>>> char *b = "2";
>>> char *c = a + b;
>>>
>>> But with a totally different, unexpected outcome.. I know where *I* start
>>> laughing here.
>> That code doesn't even compile. And you shouldn't be using the char*
>> compatibility strings in C++ if possible.
> 
> It was out of my head. I remember producing some wicked pointer arithmetic
> example of similar ridicule. 
> 
> And the whole argument is about java having a lot of design decisions that
> make it easier to work with is actually strengthened when you say that "you
> shouldn't use the char* ..." - because its not forbidden, and maybe someone
> else didn't follow that suggestion. I remember quite a few times calling
> the stl-string-to-char-function (no idea how that is called now)

Well, char* really is a compatibility feature in my mind. And it IS 
useful. How else would you interface C++ with existing C code and 
libraries :) That was the most probable reason you were using the STL to 
char* function.

Same for the const_cast. You shouldn't use it, but sometimes, you have 
to interface with a C api that takes a non const char* as paramter, 
despite the fact that it won't modify it in any way.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tertiary Operation

[Christophe]

abcd a écrit :
> x = None
> result = (x is None and "" or str(x))
> 
> print result, type(result)
> 
> ---
> OUTPUT
> ---
> None 
> 
> 
> y = 5
> result = (y is 5 and "it's five" or "it's not five")
> 
> print result
> 
> -
> OUTPUT
> -
> it's five
> 
> ...what's wrong with the first operation I did with x?  I was expecting
> "result" to be an empty string, not the str value of None.
> 

the " and  or " is NOT a ternary operator 
but an ugly hack that breaks in some situations. It just happens that 
you stumbled on one of those situations :  must never evaluate 
as False. Please, do not use that ugly hack anymore and do a proper if 
block.

Or use Python 2.5 with the official ternary operator ;)

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

Re: Python Web Site?

[Christophe]

*% a écrit :
> Is there a problem with the Python and wxPython web sites?  I cannot
> seem to get them up, and I am trying to find some documentation...
> 
>   Thanks,
>   Mike

All the sites hosted on sourceforge that rely on their vhost computer ( 
ie, site hosted on sourceforge that do not display the sourceforge.net 
address ) are broken. You get a blank page instead.

http://wxpython.sourceforge.net/ works
http://wxpython.org/ doesn't work


It has been like that for a few hours already.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter--does anyone use it for sophisticated GUI development?

[Christophe]

Kevin Walzer a écrit :
> Am I better off biting the bullet and learning wxPython--a different GUI
> paradigm to go with the new language I'm trying to learn? I had hoped to
> reduce my learning curve, but I'm very concerned that I simply can't do
> what I want to do with Tkinter. What do other Tkinter developers think?

Nobody mentionned it, but I think you should try PyQT and PyGTK before 
wxPython. Myself, I do not like wx : it looks too much like the MFC.

PyGTK is good, but GTK doesn't work that well on windows. PyQT is very 
good but you need Qt4 to get a free version for Windows. And it is GPL 
so it might not be what you are looking for. Or you can pay for it and 
get the non GPL version.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: FOR statement

[Christophe]

Lad a écrit :
> If I have a list
> 
> Mylist=[1,2,3,4,5]
> I can print it
> 
> for i in Mylist:
>print i
> 
> and results is
> 1
> 2
> 3
> 4
> 5
> 
> 
> But how can I  print it in a reverse order so that I get
> 5
> 4
> 3
> 2
> 1
> 
> 
> 
> ?
> 
> 
> Thanks.
> L
> 

for i in reversed(Mylist):
 print i
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python GUIs comparison (want)

[Christophe]

Kevin Walzer a écrit :
> [EMAIL PROTECTED] wrote:
>> Now i began to learn GUI programming. There are so many
>> choices of GUI in the python world, wxPython, pyGTK, PyQT,
>> Tkinter, .etc, it's difficult for a novice to decide, however.
>> Can you draw a comparison among them on easy coding, pythonish design,
>> beautiful and generous looking, powerful development toolkit, and
>> sufficient documentation, .etc.
>> It's helpful for a GUI beginner.
>> Thank you.
>>
>>
>> :)Sorry for my poor english.
>>
> 
> Tkinter:
> Pro: Default GUI library for Python; stable; well-supported
> Con: Needs extension for complex/rich GUI's; core widgets are dated in
> look and feel; many modern extensions in Tcl/Tk have not made it into
> Tkinter or are not widely used (Tile, Tablelist)
Also, the Tkinter API is far less elegant than the others.

> wxPython:
> Pro: Popular, actively developed, wraps native widgets, looks great on
> Windows, commercial-friendly license
> Con: Based on C++ toolkit; docs assume knowledge of C++; some think
> coding style is too much like C++; complex to build and deploy on Linux
>  (wraps Gtk)
See PyQt remarks. And I would add that the coding style is too much like 
MFC and Win32 as a con.

> PyQt:
> Pro: Powerful, cross-platform, sophisticated GUI's
> Con: Based on C++ toolkit; docs assume knowledge of C++; commercial
> deployment is expensive; free deployment must be GPL; smaller
> development and user community than wxPython
Since when is "based on C++ toolkit" a con?

> PyGtk:
> Pro: Sophisticated GUI's, cross-platform (Linux and Win32); very popular
> on some platforms; active development community
> Con: Not native on OS X

You forgot that it is rather buggy on Win32 ( in my experience )
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python GUIs comparison (want)

[Christophe]

Kevin Walzer a écrit :
> Christophe wrote:
> 
>> Since when is "based on C++ toolkit" a con?
>>
> 
> If you don't know C++ (as is the case with me), then it's difficult to
> do a C++-to-Python translation in looking at code examples.

As if a toolkit based on C would be much easier.

In fact, I would even say that C++ -> Python is much much easier than C 
-> Python for GUI toolkits.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python GUIs comparison (want)

[Christophe]

Fredrik Lundh a écrit :
> David Boddie wrote:
> 
>>> commercial deployment is expensive; free deployment must be GPL;
>>
>> Opinions differ on the first one of these.
> 
> even if you define "expensive" as "costs more money than the others" ?
Even if you consider that the huge time saving you get out of using Qt 
is worth more than what you pay to acquire a licence?

That's the idea anyway.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python GUIs comparison (want)

[Christophe]

Fredrik Lundh a écrit :
> Christophe wrote:
> 
>> Also, the Tkinter API is far less elegant than the others.
> 
> huh?  create object, display object, create object, display object. sure 
> looks like plain old Python to me...

Let's see :

.pack(side = "left")

fred = Button(self, fg = "red", bg = "blue")
fred["fg"] = "red"

fred.bind("", turnRed)

Yep, unelegant API I mantain it.

And no modern layout manager available. Only those old school 
left/right/up/down pack and anchors are available.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python GUIs comparison (want)

[Christophe]

Fredrik Lundh a écrit :
> Christophe wrote:
> 
>>>> Also, the Tkinter API is far less elegant than the others.
>>> huh?  create object, display object, create object, display object. 
>>> sure looks like plain old Python to me...
>>
>> Let's see :
>>
>> .pack(side = "left")

>> fred = Button(self, fg = "red", bg = "blue")
>> fred["fg"] = "red"

>> fred.bind("", turnRed)

>> Yep, unelegant API I mantain 
> 
> yuck.  if that's the kind of UI programs you're writing, we sure have 
> different design ideals.
Those are all small code examples you find in the Python manual! They 
are not a working program in itself and should not be taken so. I just 
state my point about an ugly API with them.

> and arguing that Tkinter is unelegant when you're doing silly things in 
> a silly way is a bit like arguing that Python is unelegant because your 
> first attempt to write a "hello world" program resulted in:
> 
>  import sys
>  # .stdout.write("Hello World") # gives unusable error message
>  from sys import stdout as glah
>  glah.writelines(iter(" ".join(["h3110", "W0rlD"])))
> 
>> And no modern layout manager available. Only those old school 
>> left/right/up/down pack and anchors are available.
> 
> huh?  when did you last look at Tk?  1994?
Yesterday. In fact, I could find no mention at all of layout managers 
others than those working with anchors. Anchors are s old school 
nowadays :)

Honestly, I can't stand using anchors or the Packer anymore. The systems 
used in wx, Qt are much better. Use them once and you cannot live 
without them anymore.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Assertion failure on hotshot.stats.load()

[Christophe]

Yang a écrit :
> Note: I realize hotshot is obsoleted by cProfile, but 2.5 breaks
> several packages I depend on. I'm using Python 2.4.3.
> 
> I'm getting an AssertionError on "assert not self._stack" when calling
> hotshot.stats.load() on my app's hotshot profile. The app consistently
> causes hotshot to generate such a problematic profile, but I have no
> idea what's causing it. Anybody know what's wrong?
> 
> Here's the profile:
> 
> http://www.filefactory.com/file/76fdbd/
> 
> Potentially relevant bugs:
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=900092&group_id=5470&atid=105470
>  
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=1019882&group_id=5470&atid=105470
>  
> 
> 
> Thanks in advance for any help.

I had the exact same problem as the second bug in an embeded 
application. I solved it by ignoring any function return without a 
corresponding function start in the profiler but I'm sure it can be be 
made more precise.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: other ways to check for ?

[Christophe]

Sybren Stuvel a écrit :
> elderic enlightened us with:
>> are there other ways than the ones below to check for > 'function'> in a python script?
> 
> First of all, why would you want to? If you want to call the object
> as a function, just do so. Handle the exception that is raised when
> it's raised.

I don't think it's a good idea because when you place a try catch block 
around a function call, you'll catch any exception thrown by the 
function itself and not only the "cannot be called" exception.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: other ways to check for ?

[Christophe]

Sybren Stuvel a écrit :
> Christophe enlightened us with:
>> I don't think it's a good idea because when you place a try catch
>> block around a function call, you'll catch any exception thrown by
>> the function itself and not only the "cannot be called" exception.
> 
> That depends on the exception you're catching, doesn't it?

And what if the function has an error and calls a non callable object ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: other ways to check for ?

[Christophe]

Christophe a écrit :
> Sybren Stuvel a écrit :
>> Christophe enlightened us with:
>>> I don't think it's a good idea because when you place a try catch
>>> block around a function call, you'll catch any exception thrown by
>>> the function itself and not only the "cannot be called" exception.
>>
>> That depends on the exception you're catching, doesn't it?
> 
> And what if the function has an error and calls a non callable object ?
Or even worse. Since we have :

 >>> None()
Traceback (most recent call last):
   File "", line 1, in ?
TypeError: 'NoneType' object is not callable
 >>> 1+""
Traceback (most recent call last):
   File "", line 1, in ?
TypeError: unsupported operand type(s) for +: 'int' and 'str'
 >>> ""+1
Traceback (most recent call last):
   File "", line 1, in ?
TypeError: cannot concatenate 'str' and 'int' objects

All of them are TypeError exceptions. It is extremly dangerous to put a 
try except TypeError clause around a function call to catch the case 
where the function object isn't a callable :/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to choose the right GUI toolkit ?

[Christophe]

Nick Craig-Wood a écrit :
> There is also PyQT which we wrote off as we wanted to write commercial
> applications too.  As it happens we have a commercial QT licence, but
> we decided we didn't want to have to incurr the additional expense of
> renewing it.
Note: Nothing in the GPL prevents you from writting commecial software ;)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sorted list - how to change it

[Christophe]

Lad a écrit :
> I have a sorted list for example [1,2,3,4,5] and I would like to change
> it in a random way
> e.g [2,5,3,1,4] or [3,4,1,5,2]  or in any other way except being
> ordered.
> What is the best/easiest
>  way how to do it?
> 
> Thank you for help
> L.
Not accepting that the shuffle outputs the same list as entered would 
make the random less random :)

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

Re: How to choose the right GUI toolkit ?

[Christophe]

Dan Lenski a écrit :
> Nick and John S., thank you for the tip on wxPython!  I'll look into it
> for my next project.  I too would avoid Qt, not because of the GPL but
> simply because I don't use KDE under Linux and because Qt is not well
> supported under Cygwin or on native Windows.
Qt is very well supported under Windows! Avoid spreading lies please ;)


( and I must admit one of the reasons I avoid wx if possible, is because 
I don't use Gnome under Linux and the look and feel of wx applications 
is really horrible under KDE )
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: explicit self revisited

[Christophe]

Simon Brunning a écrit :
> On 11/13/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>>
>> > I suppose that in his view, language advocacy is a zero-sum game, so
>> > positive comments about Python can be considered as FUD against his own
>> > project.  He's even invented his own del.icio.us tag for this purpose:
>> >
>> >  http://del.icio.us/tag/pythonfud
>>
>> now at:
>>
>>  http://del.icio.us/tag/python-fud
>>
>> 
> 
> Hey, Fredrik, you have your own tag!
>  I wish *I* had my own
> tag. ;-)
> 
> I notice that, as you predicted, Python's lack of a goto is in there too.

Hey, this is fun :D I also found that one : 
http://del.icio.us/dholton/python-fud-by-fredrik-lundh

But is seems they all point to the same article than yours so you get 
the points for it ;)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py3K idea: why not drop the colon?

[Christophe]

Stephen Eilert a écrit :
> Well, I *hate* underscores with a passion. So it is kinda frustrating
> that I *have* to say "__init__". The fact that the coding conventions
> for Python suggest things such as methods_called_this_or_that do not
> help. Everything else seems fine, since if there's voodoo involved, it
> had best be sticking out from the text in big, bloody, blinking, red
> letters.
> 
> I know, there's noone preventing me from doing otherwise (except for
> that blasted __init__). I'd like to follow the pack here, tho.
I'm sure a carefully crafted metaclass can be used to automaticaly 
convert any init function to __init__ ;)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Function mistaken for a method

[Christophe]

Eric Brunel a écrit :
> On Thu, 01 Jun 2006 13:34:53 +0200, Peter Otten <[EMAIL PROTECTED]> wrote:
> 
>> Eric Brunel wrote:
>>
>>> My actual question is: why does it work in one case and not in the  
>>> other?
>>> As I see it, int is just a function with one parameter, and the 
>>> lambda  is
>>> just another one. So why does the first work, and not the second? What
>>> 'black magic' takes place so that int is not mistaken for a method 
>>> in  the
>>> first case?
>>
>> A python-coded function has a __get__ attribute, a C-function doesn't.
>> Therefore C1.f performs just the normal attribute lookup while C2.f also
>> triggers the f.__get__(C2(), C2) call via the descriptor protocol which
>> happens to return a bound method.
> 
> 
> Thanks for your explanations, Peter. I'll have to find another way to 
> do  what I want...

You have 2 ways to do it already, here's a third :

class C:
   f = None
   def __init__(self):
 if self.__class__.f is not None:
   self.x = self.__class__.f(0)
 else:
   self.x = 0
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Function mistaken for a method

[Christophe]

Maric Michaud a écrit :
> Le Jeudi 01 Juin 2006 15:36, Christophe a écrit :
> 
>>   self.x = self.__class__.f(0)
> 
> nope, this will result in a TypeError "unbound method must be called with 
> instance as first argument"

Your right :(

staticmethod it is then.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Writing to a certain line?

[Christophe]

bruno at modulix a écrit :
> Tommy B wrote:
> 
>>bruno at modulix wrote:
> 
> 
> (snip)
> 
> 
>>>import os
>>>old = open("/path/to/file.txt", "r")
>>>new = open("/path/to/new.txt", "w")
>>>for line in old:
>>> if line.strip() == "Bob 62"
>>>   line = line.replace("62", "66")
>>> new.write(line)
>>>old.close()
>>>new.close()
>>>os.rename("/path/to/new.txt", "/path/to/file.txt")
>>>
> 
> (snip)
> 
>>Umm... I tried using this method and it froze. Infiinite loop, I'm
>>guessing.
> 
> 
> Wrong guess - unless, as Fredrik suggested, you have an infinite disk
> with an infinite file on it. If so, please share with, we would be
> *very* interested !-)

Use /dev/zero as source and /dev/null as destination :D
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numerics, NaNs, IEEE 754 and C99

[Christophe]

Grant Edwards a écrit :
> The division by zero trap is really annoying.  In my world the
> right thing to do is to return Inf.

Your world is flawed then, this is a big mistake. NaN is the only 
aceptable return value for a division by zero.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numerics, NaNs, IEEE 754 and C99

[Christophe]

Grant Edwards a écrit :
> On 2006-06-14, Christophe <[EMAIL PROTECTED]> wrote:
> 
>>Grant Edwards a écrit :
>>
>>>The division by zero trap is really annoying.  In my world the
>>>right thing to do is to return Inf.
>>
>>Your world is flawed then, this is a big mistake. NaN is the
>>only aceptable return value for a division by zero.
> 
> 
> You're probably right if you're talking about math, but I'm not
> doing math.  I'm doing engineering.  In all of the situations
> I've ever encountered, Inf was a much better choice.

You should have been more precise then : "In my ideal world, when 
dividing a non zero value by a zero value, the result should be +Inf or 
-Inf according the the sign rules"

On that point, you should also note that +0 and -0 are sometimes 
considered two different floating point numbers in Python :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Numerics, NaNs, IEEE 754 and C99

[Christophe]

Nick Maclaren a écrit :
> Now, can you explain why 1/0 => -Inf wouldn't work as well?  I.e. why
> are ALL of your zeroes, INCLUDING those that arise from subtractions,
> are known to be positive?

I would say that the most common reason people assume 1/0 = Inf is 
probably because they do not make use of negative numbers or they forgot 
they exist at all.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: __lt__ slowing the "in" operator even if not called

[Christophe]

Emanuele Aina a écrit :
> Maric Michaud continuò:
> 
> 
>>>But I hoped in a more exaustive answer: why python has to do this
>>>lookup when the __lt__ method is not involved at all?
>>
>>It is not the case, that's what my program shows :
>>
>>
>>
>>in operator at the beginning of list: 173
>>in operator at the end of list: 28249 <- here
>>
>>converting to dict : 79
>>in operator for a dict for 6 elements: 14
>>
>>
>>
>>in operator at the beginning of list: 202
>>in operator at the end of list: 30472 <- and here
> 
> 
> It is very obvious that these two have similiar timings, as both call
> __eq__.
> 
> I asked why the State and StateLT don't give similar results, but
> StateLT is noticeably slower.
> 

Maybe because when python tries to compare 2 elements, checks if __lt__ 
is defined, and if it is, it checks for __gt__ ( or maybe __lteq__ ) but 
since it isn't defined, it fallbacks on __cmp__. So for each comparison, 
if you define only __lt__ you have some additional lookups to go through.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Psyco performance

[Christophe]

[EMAIL PROTECTED] wrote:
> I'm not seeing much benefit from psyco (only 5-10% faster). Maybe this
> example is too trivial? Can someone give me some pointers as to what
> kind of code would see a dramatic benefit?
> 
> Here's the code:
> 
> import time
> import psyco
> 
> n = 10
> 
> t1 = time.clock()
> l = list(range(0,n))
> l2 = [x**2 for x in l]
> t2 = time.clock()
> no_psyco = t2 - t1
> 
> psyco.log()
> psyco.full()
> 
> t1 = time.clock()
> l = list(range(0,n))
> l2 = [x**2 for x in l]
> t2 = time.clock()
> 
> with_psyco = t2 - t1
> 
> print 'without psyco = ',no_psyco
> print 'with psyco = ',with_psyco
> print 'delta = ',(((no_psyco - with_psyco)/no_psyco) * 100),'%'
> 

Place all the code in a function. Even without psyco you might get 
somewhat better performances then. And I doubt psyco can optimise code 
that isn't in a function anyway.

And lastly, most of the code is probably spend computing x**2 which is 
already optimised C code.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pros/Cons of Turbogears/Rails?

[Christophe]

Paul Boddie a écrit :
> [comp.lang.ruby snipped]
> 
> Ray wrote:
>> I've met a number of
>> people who've told me they'd program in Eiffel if they could. And hey,
>> perhaps in its day Eiffel *was* the best OO language out there.
>> Certainly it looked cleaner than C++! :)
> 
> So why don't they? Management pressure? Why don't people write more
> Python in their day job? Any suggestions?


Probably because of the extreme Bondange And Disciplineness of Eiffel, 
the incredible cost of each user license, lack of generic programing ( 
you know, the thing easy to do in Python/Ruby but requires templates in 
C++ ) and the complete lack of a correct debugger.

By now, it seems that some of those problems have been fixed in various 
ways but we now have even better : incompatible implementations of the 
language!

Eiffel is for all purposes a niche language only used by some fanatics 
here and there :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pros/Cons of Turbogears/Rails?

[Christophe]

Jaroslaw Zabiello a écrit :
> Python is maybe faster, but with YARM (which is not stable yet) Ruby
> will be about 10x faster. YARM is full virtual machine like Java.

Google doesn't find YARM and so, YARM does not exist. Care to provide an 
URL or something?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: When is it a pointer (aka reference) - when is it a copy?

[Christophe]

John Henry a écrit :
> Hi list,
> 
> Just to make sure I understand this.
> 
> Since there is no "pointer" type in Python, I like to know how I do
> that.
> 
> For instance, if I do:
> 
>...some_huge_list is a huge list...
>some_huge_list[0]=1
>aref = some_huge_list
>aref[0]=0
>print some_huge_list[0]
> 
> we know that the answere will be 0.  In this case, aref is really a
> reference.
> 
> But what if the right hand side is a simple variable (say an int)?  Can
> I "reference" it somehow?  Should I assume that:
> 
>aref = _any_type_other_than_simple_one
> 
> be a reference, and not a copy?
> 
> Thanks,
> 

That's easy. In Python, every variable is a depth one pointer. Every 
variable is of the type (PyObject*)

Of course, since numbers and strings are immutable, that pointer is 
useless to push back the modifications you've done.

You need a PyObject** ? Use a one element list instead and manipulate it 
like that : number_ref[0] = new_value
instead of that : number_ref = [new_value]

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

Re: UDP packets to PC behind NAT

[Christophe]

Janto Dreijer a écrit :
> This is probably more of a networking question than a Python one, but
> it would be nice to know if someone has done this with Python's socket
> module. And besides one usually gets more information from c.l.py than
> anywhere else :)
> 
> I have a server with a static "public" IP and a client behind a NAT. I
> would like to send UDP packets from the server to the client. So what I
> need to do is open up a "hole" in the NAT and let the server know the
> target IP and port of the client where it can send its packets.
> 
> Now I have read somewhere that you can have TCP and UDP running on the
> same port. Not sure if this is true. Would it be a reasonable solution
> to initiate a TCP connection from the client to the server and somehow
> (?) let the server figure out how the client is connecting? And then
> send UDP to client over the same (IP, port)?

Initiate an UDP connection from the client to the server and have the 
server send back the UDP packets to the address you get in the 
"recvfrom" result.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: add without carry

[Christophe]

Bruno Desthuilliers a écrit :
> Bryan Olson wrote:
>> Hugh wrote:
>>> Sorry, here's an example...
>>>
>>> 5+7=12
>>>
>>> added without carrying, 5+7=2
>>>
>>> i.e the result is always less than 10
>> Are you looking for bitwise exclusive or? In Python it's
>> the '^' operator. For example:
>>
>> print 5 ^ 7
>>
>>
 10 ^ 21
> 31
> 
> Not really "less than 10"...

But you must use numbers smaller than 10 as input! Still :

 >>> 8 ^ 2
10

:D

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

Re: Evaluation of Truth Curiosity

[Christophe]

James Stroud a écrit :
> Hello All,
> 
> I'm curious, in
> 
> py> 0 | (1 == 1)
> 1
> py> False | (1 == 1)
> True
> 
> What is the logic of the former expression not evaluating to True (or 
> why the latter not 1?)? Is there some logic that necessitates the first 
> operand's dictating the result of the evaluation? Or is this an artefact 
> of the CPython implementation?
> 
> James

| is the binary or operator, not the truth value operator. Also, True == 
1 and False == 0. Always use the "or" and "and" keywords for truth 
operations.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.5 WinXP AMD64

[Christophe]

Brendan a écrit :
> Hello,
> I just tried to use the Windows XP installer for Python 2.5 AMD64 but I
> get the error message: "Installation package not supported by processor
> type"
> 
> I am running Windows XP Pro on an AMD Athon 64 Processor.
> 
> Do I need to have a 64-bit OS to use this version?

To be exact, you need a 64bit Windows OS on a 64bit cpu.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.5 WinXP AMD64

[Christophe]

Bjoern Schliessmann a écrit :
> Christophe wrote:
> 
>> To be exact, you need a 64bit Windows OS on a 64bit cpu.
> 
> Is there a reason that can be explained in a less-than-2-KB
> posting? :) I mean why Python depends on the processor type that
> much.
> 
> Regards,

Easy : a 64bit version of Windows cannot be installed on a non 64bit CPU :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verify an e-mail-adress - syntax and dns

[Christophe]

Steven D'Aprano a écrit :
> By memory, in an thread about the same topic just a few days ago, Fredrik
> Lundh posted a link to Perl's FAQs that suggests a method for "validating"
> email addresses: treat it like a password and ask the user to type it
> twice. That will protect against simple typos and input errors.

I hate that thing. When I see that, I type my email once and copy/paste 
into the second edit box. This is useless AND annoying at the same time.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verify an e-mail-adress - syntax and dns

[Christophe]

Georg Brandl a écrit :
> Christophe wrote:
>> Steven D'Aprano a écrit :
>>> By memory, in an thread about the same topic just a few days ago, 
>>> Fredrik
>>> Lundh posted a link to Perl's FAQs that suggests a method for 
>>> "validating"
>>> email addresses: treat it like a password and ask the user to type it
>>> twice. That will protect against simple typos and input errors.
>>
>> I hate that thing. When I see that, I type my email once and 
>> copy/paste into the second edit box. This is useless AND annoying at 
>> the same time.
> 
> It may be for you, but there certainly are users that misspel their
> e-mail address more frequently, just like passwords. And therefore it's a
> nice touch to spare both the original submitter and the owner of the
> misspelled address more work.

Which proportion of the people that sometimes misspell their e-mail also 
use cut&paste when faced with "please type your e-mail twice" web pages?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verify an e-mail-adress - syntax and dns

[Christophe]

Steve Holden a écrit :
> Christophe wrote:
>> Steven D'Aprano a écrit :
>>
>>> By memory, in an thread about the same topic just a few days ago, 
>>> Fredrik
>>> Lundh posted a link to Perl's FAQs that suggests a method for 
>>> "validating"
>>> email addresses: treat it like a password and ask the user to type it
>>> twice. That will protect against simple typos and input errors.
>>
>>
>> I hate that thing. When I see that, I type my email once and 
>> copy/paste into the second edit box. This is useless AND annoying at 
>> the same time.
> 
> Probably safe to say it's a little less useful when the text field 
> contents are visible, but the classic validator for hidden fields.
> 
> It might surprise you to realise that not everyone in the world is a 
> touch typist, and for them (since they are often looking at the keyboard 
> rather than the screen) it's not an unreasonable validator.

Well, if they have a hard time using a keyboard, I've no doubts they 
will love using cut&paste to cut nearly in half the time needed to fill 
out your form :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Verify an e-mail-adress - syntax and dns

[Christophe]

Steven D'Aprano a écrit :
> On Mon, 25 Sep 2006 16:11:38 +0200, Christophe wrote:
>> This is useless AND annoying at the same time.
> 
> But people like us don't screw up our email address in the first place,
> and if we do, we know how to fix it. Not everybody is like us.

So you say that the better answer is not to teach them to be careful 
when they fill those forms. It's to annoy them and teach them to 
copy&paste mistakes instead!

Besides, what is so special with electronic forms that we have to go 
through all kind of tricks to make sure the user doesn't make mistakes 
when regular paper forms just assume the user will be careful when he 
fills it? Must be some kind of IQ draining field emited by all the 
computers which only computer experts are immune to :D
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Surprise using the 'is' operator

[Christophe]

codefire a écrit :
> I thought the 'is' operator was used to identify identical objects,
> whereas the '==' operator checked equality. Well, I got a surprise
> here:
> 
> IDLE 1.1.3
 a = 10
 b = a
 a is b
> True
 a == b
> True
 c = 10
 a == c
> True
 a is c
> True
> 
> I was NOT expecting the last statement to return True!

The answer is : Why not? Does it even matter for integers? Never use 
"is" on integers, always == ( and on strings too for that matter )
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critique of cgi.escape

[Christophe]

Sion Arrowsmith a écrit :
> Jon Ribbens  <[EMAIL PROTECTED]> wrote:
>> In article <[EMAIL PROTECTED]>, Duncan Booth wrote:
>>> I guess you've never seen anyone write tests which retrieve some generated 
>>> html and compare it against the expected value. If the page contains any 
>>> unescaped quotes then this change would break it.
>> You're right - I've never seen anyone do such a thing. It sounds like
>> a highly dubious and very fragile sort of test to me, of very limited
>> use.
> 
> So what sort of test would you use, that doesn't involve comparing
> actual output against expected output?

Well, one could say that the expected output is the one as it'll be 
interpreted by the HTLM navigator. And thus, the test should un HTLM 
escape the string and compare it to the original string instead of 
mandating a specific encoding.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Surprise using the 'is' operator

[Christophe]

codefire a écrit :
> Haha!
> 
> OK thanks guys.
> 
> I was just trying to check if objects were the same (object), didn't
> know Integers were a special case.

They are not a special case so much. It's just that "is" is extremly 
unreliable unless you're the one who created the objects. In the case of 
integers, it's the CPython implementation which constructs them as it 
sees fit and so, you cannot expect any kind of reliable "is" behavior.

When you are manipulating let's say lists, it gets much more reliable. 
You do know that the list you create by doing a = [] is not and will 
never be the same than the one you'll create later by doing b = []
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sockets in python

[Christophe]

OneMustFall a écrit :
> 
>> What's your set-up and which cord are you pulling?
>>
> 
> Well i now i think the clue is in the OS, i have sniffed and it seems
> that Twisted have no magic.
> It is seems that i simply tested things in a wrong way -
> when i pulled cord from ethernet card windows determined that network
> lost and started to closing all sockets opened to that network (and so
> EINVAL or other OS error raised when twisted tryed to read wrom that
> socket),
> while the server did had a network - and it was right thing that server
> was thinking that socket is alive.

Stupid Windows behaviour btw! I hate that, it makes testing code 
stability for temporary network lags much much harder to do.

And don't get me started on when we reboot the switch which causes all 
open sockets on my computer to fail, even though the reboot only takes a 
few seconds and though the internet connection doesn't change.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python Noob - basic setup question / problem

[Christophe]

Lilavivat a écrit :
> Running SUSE 10.1 on an AMD64.  When I try and run a python program I get
> the following error:
> 
>   /usr/bin/python2: bad interpreter: No such file or directory
> 
>   "which python" gives me "/usr/local/bin/python"
> 
>   "which python2.4" gives me "/usr/local/bin/python2.4"
> 
>   But /usr/bin/python is symlinked to python2.4 "python -> python2.4"
> 
>   "which python2" and nothing comes up.
> 
> Basically I have no idea what's going on... help please!
> 
> Thanks,
> SETH
Fault of the Python program : it hardcodes that the Python interpreter 
is /usr/bin/python2

Check the first line of the executable ( I bet it is a simple text file 
so go away and edit it with emacs/vim/joe/ed ... ). It should be ( with 
maybe a few spaces here and there ) :
#!/usr/bin/python2

replace it with :
#!/usr/bin/python
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Am I stupid or is 'assert' broken in Python 2.5??

[Christophe]

antred a écrit :
> I've noticed something odd in Python 2.5, namely that the 2 argument 
> version of 'assert' is broken. Or at least it seems that way to me.
> 
> Run the following code in your Python interpreter:
> 
> myString = None
> 
> assert( myString, 'The string is either empty or set to the None
> type!' ) assert( myString )
> 
> 
> 
> You'll notice that the first assert doesn't do anything, whereas the 
> second assert correctly recognizes that myString does not evaluate to
>  true. That doesn't seem right. Surely Python should have raised an 
> assertion error on the first assert statement, right??

That behaviour has been present in Python for a long time. Just know
that assert is NOT a function, and thus it doesn't require parenthesis (
just the same as print doesn't require them ) Try without them and it'll 
work.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Christophe]

André Thieme a écrit :
> You don't even need to say   'function
> (memoize function)   would be enough.
> And yes, you can memoize functions while the program is running.
> And you don't need a tool like slime for it. Lisp already offers ways
> for doing that.

In Python while the program is running :

import module
module.function = memoize(module.function)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Christophe]

André Thieme a écrit :
> Paul Rubin schrieb:
>> André Thieme <[EMAIL PROTECTED]> writes:
 import module
 module.function = memoize(module.function)
>>> Yes, I mentioned that a bit earlier in this thread (not about the
>>> "during runtime" thing).
>>> I also said that many macros only save some small bits of code.
>>> Your python example contains 4 tokens / brain units.
>>> The Lisp version only has 2.
>>
>> You shouldn't count the import statement, since you'd need the
>> equivalent in Lisp as well.
> 
> I didn't count it.
> 
> 1P) module.function
> 2P) =
> 3P) memoize(
> 4P) module.function)
> 
> vs
> 1L) (memoize
> 2L) function)
> 
> I counted 1P and 4P only as one (each) although it should have been 2
> for each. But it would have worked too if we didn't need the "module.":
> function = memoize(function).

If you really need to : memoize('module.function') but it's ugly.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Christophe]

Robert Uhl a écrit :
> [EMAIL PROTECTED] (Aahz) writes:
>> Consider this: Lisp has had years of development, it has had millions of
>> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
>> programmers.  Think about it.
> 
> The argument from popularity is invalid.  French units have overtaken
> standard units,
Never heard of that French unit thing. Unless you talk about that 
archaic unit system that was in use before the metric system was created.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Christophe]

[EMAIL PROTECTED] a écrit :
> Bjoern Schliessmann wrote:
>> Robert Uhl wrote:
>>
>>> Because it's the language for which indentation is automatically
>>> determinable.  That is, one can copy/paste a chunk of code, hit a
>>> key and suddenly everything is nicely indented.
>> Cool, so in other languages I need to set block marks like () and {}
>> and also indent the code for readability, and in Python I indent
>> only. From my POV that's less work.
> 
> Try reading again. In Lisp, you use () and *your editor* automatically
> indents according to the universal standard, or you leave it sloppy
> until other folks reading your code convince you to get a proper
> programming editor. Indentation does not get out of sync with semantics
> because the editor virtually never misses parentheses that the Lisp
> compiler sees. Expressions keep the same meaning even if you have to
> start breaking them across lines, etc.
> 
> In Python, you group in your mind, and press indentation keys to make
> it happen in your editor. The editor cannot help that much, because it
> cannot read your mind. White space screwups in copy-paste cannot be
> fixed by the editor automatically, because it cannot read the original
> programmer's mind, and you have to fix it manually, and risk screwing
> it up.

Call us when you have an editor that reads your mind and writes the () 
for you.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Christophe]

Pascal Bourguignon a écrit :
> Christophe <[EMAIL PROTECTED]> writes:
> 
>> Robert Uhl a écrit :
>>> [EMAIL PROTECTED] (Aahz) writes:
>>>> Consider this: Lisp has had years of development, it has had millions of
>>>> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
>>>> programmers.  Think about it.
>>> The argument from popularity is invalid.  French units have overtaken
>>> standard units,
>> Never heard of that French unit thing. Unless you talk about that
>> archaic unit system that was in use before the metric system was
>> created.
> 
> Who invented the metric system?

That system is called the metric system, not French units. French units 
refer to the archaic system used before the metric system was invented ( 
at least according to google )

So, let's admit that French Units refer to the metric system. I suppose 
then that the so called "standard" units refer to the imperial system.

Saying that the French units are technically worse than standard units 
is a troll of very poor quality and a very weak argument.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Christophe]

Robert Uhl a écrit :
> Christophe <[EMAIL PROTECTED]> writes:
>> Saying that the French units are technically worse than standard units
>> is a troll of very poor quality and a very weak argument.
> 
> It was just an example that the argument from popularity is invalid.
> However, I (and many others) would argue that optimisation for unit
> conversion is the wrong choice when designing a system of measures.  But
> this is not the venue for such a discussion, so I'll stop now:-)

Well, I spent some time on Wikipedia looking up metric systems and 
things like that because of you, and I found a page that shows how to 
improve the current SI system by reducing the number of fundamental 
units to only two ( S for space and T for time ), and it was a great 
read. It even went so far as give a theory for the disapearance of the 
dinosaurs!

Thank you for that it was a great read.

Here it is : http://www.blazelabs.com/f-u-suconv.asp
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: speed of python vs matlab.

[Christophe]

Chao a écrit :
> My Bad,  the time used by python is 0.46~0.49 sec,
> I tried xrange, but it doesn't make things better.
> 
> import time
> tic = time.time()
> a = 1.0
> 
> array = range(1000)
> 
> for i in array:
> for j in array:
>   a = a + 0.1
> 
> toc = time.time()
> print toc-tic,' has elapsed'

Place all your code inside functions please. IIRC, local variable access 
is much faster that way, and you do a lot of lookup for the a local 
variable in that code.


import time

def main():
 a = 1.0

 array = range(1000)

 for i in array:
 for j in array:
 a = a + 0.1

tic = time.time()
main()
toc = time.time()
print toc-tic,' has elapsed'
-- 
http://mail.python.org/mailman/listinfo/python-list