[asyncio] Suggestion for a major PEP

[Christophe Bailly]

Hello,

I copy paste the main idea from an article I have written:
contextual async


"

Imagine you have some code written for monothread. And you want to include
your code in a multithread environment.  Do you need to adapt all your code
which is what you do when you want to migrate to async code ? The answer is
no.

Functionnally these constraints are not justified neither technically

Do we have the tools to do this ? Yes because thanks to boost::context we
can switch context between tasks. When a task suspends, it just calls a
function (the event loop or reactor) to potentially switch to another task.
Just like threads switch contexts…

Async/Await logic has introduced a symetric relation wich introduces
unnecessary contraints. We should just the same logic as thread logic.

"

Read the examples in the article I have developped a prototype in C++ and
everything works perfectly.

My opinion is that sooner or later, it will have to switch to this logic
because chaining async/aswait is a huge contraints and does not make sense
in my opinion.

Maybe I am missing something,

Feel free to give me your feedback.

Regards,


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

Re: deque and thread-safety

[Christophe Vandeplas]

Ok sorry for the mail,
I found the solution by using deque.count(url) that's available
starting from python 2.7


On Fri, Oct 12, 2012 at 2:40 PM, Christophe Vandeplas
 wrote:
> Hello,
>
> I have a question about deque and thread-safety.
>
> My application has multiple threads running concurrently and doing the
> same action (downloading pages)
> To know what has already been downloaded I created the variable:
>   seen = deque('', 1000)   (keeps list of max 1000 urls in memory)
>
> In one place of the code I do:  seen.append(url)
>
> And another place:
> def seenPage()
>   if url in seen:
> return True
>   return False
>
> From the documentation I understand that deques are thread-safe:
>> Deques are a generalization of stacks and queues (the name is pronounced 
>> “deck”
>> and is short for “double-ended queue”). Deques support thread-safe, memory
>> efficient appends and pops from either side of the deque with approximately 
>> the
>> same O(1) performance in either direction.
>
> It seems that appending to deques is indeed thread-safe, but not
> iterating over them.
> I've seen a similar, but different, situation here:
> http://comments.gmane.org/gmane.comp.python.devel/85487
>
> Forgetting the above url, and considering my situation this behavior
> screws up the concept I need:
> - Keeping a thread-safe collection of seen urls,
> - Being able to check if something is in that collection
> - No need to clean the collection to prevent the memory from filling up
>
> So I know I could work around this problem by using a lock.
> But then I don't only need to use the lock around the iterator, but
> also around the append(), but that defeats the purpose of deque being
> thread-safe.
>
> In short, what's your advice:
>
> 1/ build a lock around the .append() and the iterator. Using the
> already-existing lock in the deque. But HOW?
>
> 1/ simply build a lock around the .append() and the iterator.
> Defeating the build-in thread-safety.
>
> 2/ use another collection that does what I need
>
>
> Thanks for your expertise.
>
> Christophe
-- 
http://mail.python.org/mailman/listinfo/python-list

deque and thread-safety

[Christophe Vandeplas]

Hello,

I have a question about deque and thread-safety.

My application has multiple threads running concurrently and doing the
same action (downloading pages)
To know what has already been downloaded I created the variable:
  seen = deque('', 1000)   (keeps list of max 1000 urls in memory)

In one place of the code I do:  seen.append(url)

And another place:
def seenPage()
  if url in seen:
return True
  return False

From the documentation I understand that deques are thread-safe:
> Deques are a generalization of stacks and queues (the name is pronounced 
> “deck”
> and is short for “double-ended queue”). Deques support thread-safe, memory
> efficient appends and pops from either side of the deque with approximately 
> the
> same O(1) performance in either direction.

It seems that appending to deques is indeed thread-safe, but not
iterating over them.
I've seen a similar, but different, situation here:
http://comments.gmane.org/gmane.comp.python.devel/85487

Forgetting the above url, and considering my situation this behavior
screws up the concept I need:
- Keeping a thread-safe collection of seen urls,
- Being able to check if something is in that collection
- No need to clean the collection to prevent the memory from filling up

So I know I could work around this problem by using a lock.
But then I don't only need to use the lock around the iterator, but
also around the append(), but that defeats the purpose of deque being
thread-safe.

In short, what's your advice:

1/ build a lock around the .append() and the iterator. Using the
already-existing lock in the deque. But HOW?

1/ simply build a lock around the .append() and the iterator.
Defeating the build-in thread-safety.

2/ use another collection that does what I need


Thanks for your expertise.

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

Re: Floating point multiplication in python

[Christophe Chong]

here we have reached the point where the maximum precision is reached -
> a doesn't change anymore, although it should. The error is about 1E-16.
>
> Now if you multiply two values with an error, the error also propagates
> into the result - PLUs the result can have its own error source - in the
> same order of magnitude.
>
> (a+e) * (a+e) = a*a + 2*a*e + e*e. So your new error term is 2*a*e + e*e or
> (2*a + e) * e.
>
> --
> http://mail.python.org/**mailman/listinfo/python-list<http://mail.python.org/mailman/listinfo/python-list>
>



-- 
Christophe Chong
Department of Economics
Stanford University
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ten rules to becoming a Python community member.

[Christophe Chong]

I can't tell which comments are sarcastic

On Aug 14, 2011, at 18:35, rantingrick  wrote:

> On Aug 14, 5:01 pm, Dave Angel  wrote:
> 
>> Interesting that when you complain about other's grammatical typos,
>> you're so careless with your own.
>> 
>> know -> now
>> i -> I
>> accustom -> accustomed
>> the this -> this
>> 
>> I'm inclined to ignore typos in emails except in the case where the
>> intent is to abuse others.
> 
> My intent is NOT to abuse, but to enlighten. And you need to look up
> the definition of typo because i am not complaining about typos. Typos
> are accidents. Even the best of us suffer from accidents.
> 
> What i AM complaining about is the adoption of a collectively foolish
> consistency. "Used to" and "supposed to" is the verbiage of children
> and idiots. I am trying to break these people out of such foolish
> loops. You should be thanking me instead of trolling my posts.
> -- 
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to find out the version of a certain installed package

[Christophe]

great! thanks for you fast response.

Christophe

On Tue, Sep 30, 2008 at 6:30 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:

> On 2008-09-30 18:17, Christophe wrote:
> > Hi,
> >
> > In a projecet I'm making using pycrypto, I need to find out the
> > current installed version of pycrypto. After looking around, I found
> > out that "pkg_resources.requires("pycrypto") will give me a string
> > containing the version number, but is this the only way to do it or
> > are there other ways?
>
> Most packages have a .__version__ attribute in their top-level
> package dir which you can query.
>
> You do have to import the base package, though, in order to find
> out.
>
> Thanks,
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source  (#1, Sep 30 2008)
> >>> Python/Zope Consulting and Support ...http://www.egenix.com/
> >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
> >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
> 
>
>  Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 
>
>
>   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>   Registered at Amtsgericht Duesseldorf: HRB 46611
>
--
http://mail.python.org/mailman/listinfo/python-list

how to find out the version of a certain installed package

[Christophe]

Hi,

In a projecet I'm making using pycrypto, I need to find out the
current installed version of pycrypto. After looking around, I found
out that "pkg_resources.requires("pycrypto") will give me a string
containing the version number, but is this the only way to do it or
are there other ways?

thanks,

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

PyCon FR - Journées Python

[Christophe Combelles]

PyCon FR will take place in Paris, France, 17-18 May 2008.
The French Python Association (AFPY) is organizing this event called "Journées
Python" for the second time.

We expect most talks to be in french, but any proposal in english is also 
greatly welcome! You may submit your idea of talks and presentations now,
either here if you speak french: 
http://fr.pycon.org/actualites/appel-a-propositions/ ,
or here if you don't : pycon -at- afpy.org

Topics:

We're expecting talks about anything related to the Python programming
language, including:

 * the language and its libraries
 * the web technologies
 * Python in scientific computing
 * game programming
 * development environnement setup
 * agile programmnig and tests

The expected audience will span on any level, from the beginner to the
expert. Thus, your talk may fit even to beginners and will be welcome.

Other formats:

As well as regular talks, we will host tutorials about Python
programming for beginners, and we may include 15-minutes lightning
talks on any topic you want to talk about (e.g.: a project you're
working on).

You may submit debate topics for open discussions too.

Important dates:

 * March, 7th : Call for papers
 * March, 30th : Paper submissions are closed
 * April 4th : Final schedule publication

How to get involved?

If you want to attend as a simple visitor, please register on this
page to help us count the expected audience:

 * http://fr.pycon.org/inscription

To submit a talk, tutorial, etc., please register with the link above,
and fill the following form:

 * http://fr.pycon.org/contact/proposition-de-presentation

For any information about the event, go to:

 * http://fr.pycon.org

get in touch with the organization team via: pycon -at- afpy.org

See you soon!

--'AFPy Team.
-- 
http://mail.python.org/mailman/listinfo/python-list

PyCon FR - Journées Python

[Christophe Combelles]

PyCon FR will take place in Paris, France, 17-18 May 2008.
The French Python Association (AFPY) is organizing this event called "Journées
Python" for the second time.

We expect most talks to be in french, but any proposal in english is also 
greatly welcome! You may submit your idea of talks and presentations now,
either here if you speak french: 
http://fr.pycon.org/actualites/appel-a-propositions/ ,
or here if you don't : pycon -at- afpy.org

Topics:

We're expecting talks about anything related to the Python programming
language, including:

 * the language and its libraries
 * the web technologies
 * Python in scientific computing
 * game programming
 * development environnement setup
 * agile programmnig and tests

The expected audience will span on any level, from the beginner to the
expert. Thus, your talk may fit even to beginners and will be welcome.

Other formats:

As well as regular talks, we will host tutorials about Python
programming for beginners, and we may include 15-minutes lightning
talks on any topic you want to talk about (e.g.: a project you're
working on).

You may submit debate topics for open discussions too.

Important dates:

 * March, 7th : Call for papers
 * March, 30th : Paper submissions are closed
 * April 4th : Final schedule publication

How to get involved?

If you want to attend as a simple visitor, please register on this
page to help us count the expected audience:

 * http://fr.pycon.org/inscription

To submit a talk, tutorial, etc., please register with the link above,
and fill the following form:

 * http://fr.pycon.org/contact/proposition-de-presentation

For any information about the event, go to:

 * http://fr.pycon.org

get in touch with the organization team via: pycon -at- afpy.org

See you soon!

--'AFPy Team.

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

Re: Is PEP-8 a Code or More of a Guideline?

[Christophe]

Joe Riopel a écrit :
>> Each requires exactly the same number of key strokes when I do the
>> math. (Too lazy to explain further...)
> 
> foo_bar
> f, o, o, shift + underscore, b, a, r = 8
> fooBar
> f, o, o, shift + b, a, r = 7

f, o, o, _, b, a, r = 7
f, o, o, shift + b, a, r = 8

Also the shift+b is much more work than 2 keypresses IMHO. On the other 
hand, the underscore is done by pressing the 8 key without any other 
modifier which is very easy and accessible. Yeap, french layout rules 
for that naming convention :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Christophe Cavalaria]

Istvan Albert wrote:

> On May 19, 3:33 am, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> 
>> >That would be invalid syntax since the third line is an assignment
>> > with target identifiers separated only by spaces.
>>
>> Plus, the identifier starts with a number (even though ６ is not DIGIT
>> SIX, but FULLWIDTH DIGIT SIX, it's still of category Nd, and can't
>> start an identifier).
> 
> Actually both of these issues point to the real problem with this PEP.
> 
> I knew about them (note that the colon is also missing) alas I
> couldn't fix them.
> My editor would could not remove a space or add a colon anymore, it
> would immediately change the rest of the characters to something
> crazy.
> 
> (Of course now someone might feel compelled to state that this is an
> editor problem but I digress, the reality is that features need to
> adapt to reality, moreso had I used a different editor I'd be still
> unable to write these characters).

The reality is that the few users who care about having chinese in their
code *will* be using an editor that supports them.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Christophe]

René Fleschenberg a écrit :
> Christophe schrieb:
>> You should know that displaying and editing UTF-8 text as if it was
>> latin-1 works very very well.s
> 
> No, this only works for those characters that are in the ASCII range.
> For all the other characters it does not work well at all.

This alone shows you don't know enouth about UTF-8 to talk about it. 
UTF-8 will NEVER use < 128 chars to describe multibyte chars. When you 
parse a UTF-8 file, each space is a space, each \n is an end of line and 
each 'Z' is a 'Z'.

>> Also, Terminals have support for UTF-8 encodings already. 
> 
> Some have, some have not. And you not only need a terminal that can
> handle UTF-8 data, you also need a font that has a glyph for all the
> characters you need to handle, and you may also need a way to actualy
> enter those characters with your keyboard.

Ever heard of the famous "cut/paste"? I use it all the time, even when 
handling standard ASCII english code. It greatly cuts down my ability to 
make some typo while writing code.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Christophe]

[EMAIL PROTECTED] a écrit :
> Christophe wrote:
>> [EMAIL PROTECTED] a ecrit :
>>> Steven D'Aprano wrote:
>>>> I would find it useful to be able to use non-ASCII characters for heavily
>>>> mathematical programs. There would be a closer correspondence between the
>>>> code and the mathematical equations if one could write D(u*p) instead of
>>>> delta(mu*pi).
>>> Just as one risk here:
>>> When reading the above on Google groups, it showed up as "if one could
>>> write ?(u*p)..."
>>> When quoting it for response, it showed up as "could write D(u*p)".
>>>
>>> I'm sure that the symbol you used was neither a capital letter d nor a
>>> question mark.
>>>
>>> Using identifiers that are so prone to corruption when posting in a
>>> rather popular forum seems dangerous to me--and I'd guess that a lot
>>> of source code highlighters, email lists, etc have similar problems.
>>> I'd even be surprised if some programming tools didn't have similar
>>> problems.
>> So, it was google groups that continuously corrupted the good UTF-8
>> posts by force converting them to ISO-8859-1?
>>
>> Of course, there's also the possibility that it is a problem on *your*
>> side
> 
> Well, that's part of the point isn't it?  It seems incredibly naive to
> me to think that you could use whatever symbol was intended and have
> it show up, and the "well fix your machine!" argument doesn't fly.  A
> lot of the time programmers have to look at stack traces on end-user's
> machines (whatever they may be) to help debug.  They have to look at
> code on the (GUI-less) production servers over a terminal link.  They
> have to use all kinds of environments where they can't install the
> latest and greatest fonts.  Promoting code that becomes very hard to
> read and debug in real situations seems like a sound negative to me.

Who displays stack frames? Your code. Whose code includes unicode 
identifiers? Your code. Whose fault is it to create a stack trace 
display procedure that cannot handle unicode? You. Even if you don't 
make use of them, you still have to fix the stack trace display 
procedure because the exception error message can include unicode text 
*today*

You should know that displaying and editing UTF-8 text as if it was 
latin-1 works very very well.

Also, Terminals have support for UTF-8 encodings already. Or you could 
always use kate+fish to edit your script on the distant server without 
such problems (fish is a KDE protocol used to access a computer with ssh 
as if it was a hard disk and kate is the standard text/code editor) It's 
a matter of tools.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Christophe]

[EMAIL PROTECTED] a écrit :
> Steven D'Aprano wrote:
>> I would find it useful to be able to use non-ASCII characters for heavily
>> mathematical programs. There would be a closer correspondence between the
>> code and the mathematical equations if one could write D(u*p) instead of
>> delta(mu*pi).
> 
> Just as one risk here:
> When reading the above on Google groups, it showed up as "if one could
> write ?(u*p)..."
> When quoting it for response, it showed up as "could write D(u*p)".
> 
> I'm sure that the symbol you used was neither a capital letter d nor a
> question mark.
> 
> Using identifiers that are so prone to corruption when posting in a
> rather popular forum seems dangerous to me--and I'd guess that a lot
> of source code highlighters, email lists, etc have similar problems.
> I'd even be surprised if some programming tools didn't have similar
> problems.

So, it was google groups that continuously corrupted the good UTF-8 
posts by force converting them to ISO-8859-1?

Of course, there's also the possibility that it is a problem on *your* 
side so, to be fair I've launched google groups and looked for this 
thread. And of course the result was that Steven's post displayed 
perfectly. I didn't try to reply to it of course, no need to clutter 
that thread anymore than it is.

-- 
Δ(µ*π)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Christophe]

Stefan Behnel a écrit :
> George Sakkis wrote:
>> After 175 replies (and counting), the only thing that is clear is the
>> controversy around this PEP. Most people are very strong for or
>> against it, with little middle ground in between. I'm not saying that
>> every change must meet 100% acceptance, but here there is definitely a
>> strong opposition to it. Accepting this PEP would upset lots of people
>> as it seems, and it's interesting that quite a few are not even native
>> english speakers.
> 
> But the positions are clear, I think.
> 
> Open-Source people are against it, as they expect hassle with people sending
> in code or code being lost as it can't go public as-is.

I'm an Open-Source guy too but I'm for that proposal. Anyway, this is a 
bad argument as was show already. When accepting code in a project, you 
already HAVE to make some rule as to how the code is writen, and 99% of 
the time those rules include "All identifiers in correct english (or 
rather, american) and all comments in english". Recieving a patch 
containing identifiers you cannot read is simple enouth to reject.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[Christophe]

Nigel Rowe a écrit :
> On Thu, 19 Apr 2007 19:11, Antoon Pardon wrote in comp.lang.python:
>> On 2007-04-19, Michael Bentley <[EMAIL PROTECTED]> wrote:
> 
> 
> 
>>> The learning curve is rather steep IMO, but worth it.
>> Just a throw in remark, that  you may ignore if you wish, but a steep
>> learning curve means that the subject is easily familiarized and that
>> the learning period is short.
>>
>> You seem to use it as if it is the opposite.
>>
> 
> Who says the axes are labeled "familiarity" and "learning period"?   I
> just assume they are labeled (y-axis) "Effort" and (x-axis) "Knowledge"
> (or "skill" or ).  
> 
> Which means that something with a 'steep learning curve' requires a lot
> of effort to achieve a small amount of knowledge (or skill or ...).

Funny, I would have placed on the x axis the time, and on the y axis 
"Knowledge". And Effort = lambda*time where lambda is the amount of 
effort per minute you are able to produce. Thus I always found it weird 
to call a steep learning curve something hard to learn.

Disclaimer: I have never made any study in that field, never read any 
reports or anything like that. It just feels much more natural for me to 
place the time on the x axis.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pop() clarification

[Christophe]

Carl Banks a écrit :
> On Apr 11, 3:10 pm, "7stud" <[EMAIL PROTECTED]> wrote:
>> On Apr 11, 10:44 am, "Scott" <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>>> As said before I'm new to programming, and I need in depth explaination to
>>> understand everything the way I want to know it, call it a personality quirk
>>> ;p.
>>> With pop() you remove the last element of a list and return its value:
>>> Now I know list is a bad name, but for the sake of arguement lets assume its
>>> not a built in sequence>
>> list = ['this', 'is', 'an', 'example']
>> list.pop()
>>> 'example'
>> list
>>> ['this', 'is', 'an']
>>> I understand all that.  What I don't understand is why all the documentation
>>> I see says, "When removing a specific element from a list using pop() it
>>> must be in this format: list.pop([i]).
>>> At first I took that to mean that list.pop(i) would return some type of
>>> error, but it doesn't.
>> It's understandable that the definition of pop() is confusing in that
>> way.  It looks like the argument should be a list.  As others have
>> said, that is not what the brackets mean when the documents show the
>> formal definition of a function.
> 
> I wonder if the documentation could take advantage of Python 3000
> annotation syntax.  So
> 
> pop([x])
> 
> would be replaced in the docs by
> 
> pop(x: OPTIONAL)
> 
> Just a thought, probably not a good one.  The brackets are so
> pervasive that it's probably better to just let newbies be confused
> for a little bit.

I'd rather go for the overloading syntax. ie:


pop(i)
pop()

Remove the item at the given position in the list, and return it. If no 
index is specified, a.pop() removes and returns the last item in the list.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why NOT only one class per file?

[Christophe]

Chris Lasher a écrit :
> A friend of mine with a programming background in Java and Perl places
> each class in its own separate file in . I informed him that keeping
> all related classes together in a single file is more in the Python
> idiom than one file per class. He asked why, and frankly, his valid
> question has me flummoxed.

In Java, you HAVE to place a class in it's own file. That's how the 
language works. But in Java, you do not have to place each class in it's 
own module/package, in fact, it would be bad.

It's the same in Python: you do not want to have one class per 
module/package.

Unfortunately, in Python, a module/package is a file, and in Java, it's 
a directory. Also, Python doesn't really have the notion of a "root 
package/module".




Translation: "import foo; foo.foo()" sucks so avoid having only one 
class per module :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python QT or python-GTK

[Christophe]

Dennis Lee Bieber a écrit :
>   Not enough experience here... I do know I never liked applications
> targeted to the "Gnome" look, preferring KDE... So... which toolkit did
> those desktops favor?
> 
>   wxWidgets, as I recall, is supposed to attempt to look "native" on
> each OS.

Well, wxWidgets targets the Gnome look ( it means it uses GTK on Linux ) 
and not the KDE look so I guess you wouldn't like wxWidgets either :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pep 3105: the end of print?

[Christophe]

Martin v. Löwis a écrit :
> Neil Cerutti schrieb:
>> On 2007-02-23, I V <[EMAIL PROTECTED]> wrote:
>>> While that's true, C++ compiler vendors, for example, take
>>> backwards compatibility significantly less seriously, it seems
>>> to me. 
>> Compiler vendors usually take care of their customers with
>> compiler switches that enable backwards compatibility.
> 
> That's a bold statement, after I V already gave two examples
> (g++ and MSVC 2005) of compilers that broke backwards compatibility
> without providing compiler switches to bring it back. These two
> aren't "minor" compilers.

In C++ land, people are expected to fix their code and not use broken 
compilers in such situations.

They have some kind of moral high ground because they do not break 
compatibility just for that but to be more standards compliant. And the 
fact that all the C++ code I've written with g++ recently compiled 
perfectly on Visual 2005 without a single change ( except fixing new 
warnings ) shows that standard compliance in C++ compilers is a good 
thing to have. That same code had some major and very annoying breakage 
with Visual 6. The fix? Updating that outdated compiler.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to ping and shutdown a remote computer?

[Christophe]

[EMAIL PROTECTED] a écrit :
> I am working on a Python script to perform as a remote computer
> manager. So far I have a WOL function working and I would like to add
> the ability to show if a machine is on or off (I figured I would do so
> by pinging the machine and seeing if I get a response). I would also
> like to add the ability to remotely shutdown a computer from the
> python script. Does anyone have a code snippet for pinging an IP, a
> code snippet for shutting down a remote Windows XP machine, and a code
> snippet for sending a HTTP request?
> 
> Here is my current setup:
> 
> - PC  running python script
> - FreeNAS (media server running on FreeBSD. Can be shutdown from web
> interface so I planned on just sending that same web button click from
> the python script to shutdown the FreeNAS server)
> - Windows XP machine with folder share (What packet is sent over the
> network to remotely shutdown a Windows XP machine?)

import os
os.system("shutdown -s -f")
Try other switches if you want. Requires Windows XP at the minimum.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help me understand this

[Christophe]

James Stroud a écrit :
> Beej wrote:
> (2).__add__(1)
> 
> Nice. I would have never thought to put parentheses around an integer to 
> get at its attributes.
> 
> James

You can also do it like that :

 >>> 2 .__add__(1)
3
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sorting on multiple values, some ascending, some descending

[Christophe]

[EMAIL PROTECTED] a écrit :
> Raymond Hettinger:
>> The simplest way is to take advantage of sort-stability and do
>> successive sorts.  For example, to sort by a primary key ascending and
>> a secondary key decending:
>>L.sort(key=lambda r: r.secondary, reverse=True)
>>L.sort(key=lambda r: r.primary)
> 
> That's probably the faster and simpler way.
> The following solution is probably slow, memory-hungry, and it's not
> tested much so it may be buggy too, but it shows my idea, and bugs can
> be fixed:
> 
> class Inverter:
> def __init__(self, item, reversed=False):
> self.item = item
> self.reversed = reversed
> def __cmp__(self, other):
> if self.reversed:
> return cmp(other.item, self.item)
> else:
> return cmp(self.item, other.item)
> 
> data = [[1, "a", "b"], [1, "b", "d"], [1, "d", "a"]]
> reverses = [True, False, False]
> 
> print sorted(data, key=lambda subseq: map(Inverter, subseq, reverses))

Nice trick, but don't get too caught up using classes ;) Try that one 
instead for much better performance :

class Inverter:
 def __init__(self, item):
 self.item = item
 def __cmp__(self, other):
 return cmp(other, self.item)

def invert_if(item, reversed=False):
 if reversed:
 return Inverter(item)
 return item

data = [[1, "a", "b"], [1, "b", "d"], [1, "d", "a"]]
reverses = [True, False, False]

print sorted(data, key=lambda subseq: map(invert_, subseq, reverses))
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python , Boost and straight (but complex) C code

[Christophe Cavalaria]

Osiris wrote:

> On Sat, 30 Dec 2006 13:19:28 -0800, Erik Max Francis <[EMAIL PROTECTED]>
> wrote:
> 
>>Osiris wrote:
>>
>>> I have these pieces of C-code (NOT C++ !!) I want to call from Python.
>>> I found Boost.
>>> I have MS Visual Studio 2005 with C++.
>>> 
>>> is this the idea:
>>> I write the following C source file:
>>> 
>>> #include 
>>> #include 
>>> 
>>> namespace { // Avoid cluttering the global namespace.
>>
>>iostream and namespaces are both most definitely C++ features, not C.
> 
> yes, but C can be compiled with a C++ compiler,  One can put C code in
> C++ source Boost should not complain... should it ?
> Boost text is all about C++.. so... C should not be a problem...

Not all C code can be compiled by a C++ compiler. And anyway, this is
definitively NOT C code.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Can I beat perl at grep-like processing speed?

[Christophe Cavalaria]

js  wrote:

> Just my curiosity.
> Can python beats perl at speed of grep-like processing?
> 
> 
> $ wget http://www.gutenberg.org/files/7999/7999-h.zip
> $ unzip 7999-h.zip
> $ cd 7999-h
> $ cat *.htm > bigfile
> $ du -h bigfile
> du -h bigfile
> 8.2M  bigfile
> 
> -- grep.pl --
> #!/usr/local/bin/perl
> open(F, 'bigfile') or die;
> 
> while() {
>   s/[\n\r]+$//;
>   print "$_\n" if m/destroy/oi;
> }
> -- END --
> -- grep.py --
> #!/usr/bin/env python
> import re
> r = re.compile(r'destroy', re.IGNORECASE)
> 
> for s in file('bigfile'):
>   if r.search(s): print s.rstrip("\r\n")
> -- END --
> 
> $ time perl grep.pl  > pl.out; time python grep.py > py.out
> real  0m0.168s
> user  0m0.149s
> sys   0m0.015s
> 
> real  0m0.450s
> user  0m0.374s
> sys   0m0.068s
> # I used python2.5 and perl 5.8.6
I'm thankful for the Python version or else, I'd never have guessed what
that code was supposed to do!

Try that :
-- grep.py --
#!/usr/bin/env python
import re
def main():
search = re.compile(r'destroy', re.IGNORECASE).search

for s in file('bigfile'):
  if search(s): print s.rstrip("\r\n")

main()
-- END --

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

Re: DOS, UNIX and tabs

[Christophe Cavalaria]

Felix Benner wrote:

> Christophe Cavalaria schrieb:
>> Steven D'Aprano wrote:
> 
>> You gave the reason in your post : because other people who are using
>> software that doesn't understand tabs as YOU expect them to have problems
>> with your code.
>> 
>> Tabs aren't a problem at all as long as nobody else than you edit your
>> code.
> 
> Sorry, but that's a silly argument. With the same argument we should
> stop using python alltogether since the usual MBA will understand
> nothing but VBA.

No it isn't. If you have to work with some MBA that understands nothing but
VBA, why the hell are you writing Python code in the first place?

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

Re: DOS, UNIX and tabs

[Christophe Cavalaria]

Steven D'Aprano wrote:

> On Thu, 28 Dec 2006 09:26:28 +0100, Sebastian 'lunar' Wiesner wrote:
> 
>> It is, and especially the problems with tabs shows you, why it is good
>> practice to follow the standard in your own code, too...
> 
> I don't know what "problems" with tabs you are talking about. I never have
> problems with tabs. *Other people* who choose to use software that doesn't
> understand tabs have problems.
> 
> I've spent a lot of time reading both sides of the tabs versus spaces
> argument, and I haven't found anything yet that explains why tabs are, in
> and of themselves, bad.

You gave the reason in your post : because other people who are using
software that doesn't understand tabs as YOU expect them to have problems
with your code.

Tabs aren't a problem at all as long as nobody else than you edit your code.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Good Looking UI for a stand alone application

[Christophe Cavalaria]

Vincent Delporte wrote:

> On Sun, 17 Dec 2006 09:37:04 +0100, [EMAIL PROTECTED] (Luc Heinrich)
> wrote:
>>Crossplatform toolkits/frameworks suck. All of them. No exception. If
>>you want your app to look *AND* feel great on all platform, abstract the
>>core of your application and embed it in platform native GUI code.
> 
> +1. Applications beyond very basic GUI's are better off rewriting the
> GUI for each application, while keeping the business logic separate.
> Even something as basic as QuickTime sucks on Windows.
Read my second reply before reading that part again ;)

> I'd be curious to see the source code to Skype: I just installed the
> Linux version, and it looks very nice. Maybe it was recompiled with
> Kylix.
They use QT. Back to read the first part of your post.

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

Re: Good Looking UI for a stand alone application

[Christophe Cavalaria]

Sandra-24 wrote:

> On 12/16/06, The Night Blogger <[EMAIL PROTECTED]> wrote:
>> Can someone recommend me a good API for writing a sexy looking (Rich UI
>> like WinForms) shrink wrap application
> 
>> My requirement is that the application needs to look as good on Windows
>> as on the Apple Mac
> 
> wxPython or something layered on it would be the way to go. I tried all
> the popular toolkits (except qt) and nothing else comes close for cross
> platform gui work. Don't let people persuade you otherwise, that caused
> me a lot of trouble.

Well, you should try qt too ;)

BTW, does wxWindow/wxPython have something that allows you to switch the OK
and Cancel button position according to the current machine GUI guidelines?

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

Re: merits of Lisp vs Python

[Christophe Cavalaria]

Paul Rubin wrote:

> Kirk  Sluder <[EMAIL PROTECTED]> writes:
>> Personally, I've always preferred use the imperative to describe
>> basic math rather than the passive. This would seem to map better to
>> RPN than infix.
> 
> For writing down complicated, nested expressions too?  That's very
> unusual.  E.g.
> 
>   n! = (n/e)**n * sqrt(2*pi*n) * (1 + (1/12n)) * ...
> 
> vs. the same thing in Lisp notation, and that's not even so complicated.

Yes, infix is better ( and note that Math uses primarly infix notation for
common operators ) because you have a clear view of the evaluation tree
that way. With prefix or postfix notation, you need to parse the full
expression to find what goes to the first parameter of that +, and what
goes to the second parameter.

I would say that prefix/postfix is somewhat easier to write, but that infix
is far far far easier to read.

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

Re: merits of Lisp vs Python

[Christophe Cavalaria]

Paul Rubin wrote:

> André Thieme <[EMAIL PROTECTED]> writes:
>> def nif(num, pos, zero, neg):
>>if num > 0:
>>  return pos
>>else:
>>  if num == 0:
>>return zero
>>  else:
>>return neg
> 
> def nif(num, pos, zero, neg):
>return (neg, zero, pos)[cmp(num, 0)+1]
Since we are in one liners, let's be even smarter and do it like that :

def nif(num, pos, zero, neg):
   return (zero, pos, neg)[cmp(num, 0)]

;)

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

Re: merits of Lisp vs Python

[Christophe]

Robert Uhl a écrit :
> Ken Tilton <[EMAIL PROTECTED]> writes:
>> meanwhile, I have not seen how Python lets you avoid revisiting dozens
>> of instances when changes to a mechanism are required.
> 
> I think his solution would have been to use:
> 
>   def foo(**args):
> 
> everywhere, and call it like this
> 
>   foo(bar=baz)
> 
> Of course that makes calls pretty verbose, but it would prevent having
> to visit every function/method every time the signature changes.  As
> long they'd all been set up initially to use keyword args like that.
> And of course one would lose some of the compile-time benefits of
> compiler signature checking.
> 
> It's not optimal, but I think it'd get the job done.
> 

More along the lines of :

def foo(*args, **kwds):
 pass_params(*args, **kwds)

def pass_params(hi, there):
 print "hi :", hi
 print "there :", there

foo("first", there="second")
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Christophe]

[EMAIL PROTECTED] a écrit :
> Christophe wrote:
>> Call us when you have an editor that reads your mind and writes the ()
>> for you.
> 
> This is an irrelevancy. Typos that drop printing characters in either
> language will generally cause changes to the semantics. Lisp
> programmers, incidentally, will see that their editor indented things
> in a funky way and recognize "hey, I dropped a paren somewhere in that
> copy-paste." (And, if so, it is usually at the end, and can be
> recovered using automatic matching when typing the ')' ). And,
> honestly, the punctuation is no harder to type in Lisp than in other
> languages, they just occur in different (and more consistent) places.
> 
> The point of Python is that changing white-space to
> different-white-space changes the semantics. At best an editor can
> notice "hey, funky white-space here, please correct" as IDLE did when I
> wrote my first Python in a non-Python-aware editor, and somehow had
> swapped tabs and spaces; when I moved it to IDLE---the indentation
> *looked fine* but was invisibly weird. At worst, an editor can go
> "sure, I'll let you change your program."
> 
> I'm not saying the worst case is typical. The annoying case is more
> likely. I will even admit that white-space significance does not
> materially increase errors among experienced Pythonistas. What it isn't
> is some kind of miraculous invention that saves programmers from ever
> making mistakes that are common in other languages, or that reduces
> effort in copy-paste, as Bjoern seemed to be claiming.

So, you are more or less saying that, using a smart Lisp editor, you'll 
easily catch block errors when you misplace a bracket, but using dumb 
Python editors allows inconsistent tab-space usage to go unnoticed?

Yeah, nothing wrong in what you said but hardly relevant I say :)

For the Python side, I just hope that -tt becomes the default option one 
day ( interpreter causes errors when mixing spaces and tabs )
-- 
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

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: 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]

[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]

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]

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]

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: 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: 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: 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: 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: 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: 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]

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: 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: 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]

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: 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: 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: 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 :
> 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]

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]

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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]

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]

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: #!/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: 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: 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: __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: 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: 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]

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: 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: 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: 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: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Christophe Cavalaria]

Christopher Weimann wrote:

> On 05/19/2006-07:18AM, Duncan Booth wrote:
>> 
>> My experience of programming with either spaces or tabs has taught me
>> that tabs are evil not for themselves, but simply because no matter how
>> hard you try they always end up being mixed with spaces.
>> 
> 
> Swap the word 'tabs' for the word 'spaces' and you get...
> 
>   My experience of programming with either tabs or spaces has taught me
>   that spaces are evil not for themselves, but simply because no matter
>   how hard you try they always end up being mixed with tabs.
> 
> Which is just as vaild as the un-swapped paragraph. Both versions
> express a bias. The first is biased in favor of spaces. The second is
> biased in favor of tabs. Neither have any useful content. Mixing is bad
> but that fact doesn't favor spaces OR tabs.

The difference is that you cannot code without spaces but you can do it
without tabs.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: open file with whitespaces

[Christophe]

mardif a écrit :
> Hi guys.
> I've a very big big big problem:
> 
> I've in my windows computer a file named cicciobello.html, located in
> c:\documents and settings\username\desktop\cicciobello.html.
> 
> Now, I MUST open this file with os.spawn(os.P_WAIT , because I must
> wait the user cancel the explorer window, ok?
> And so, I write:
> 
> import os
> os.spawnl(os.P_WAIT, "c:\programmi\internet explorer\iexplorer.exe",
> "c:\documents and settings\username\desktop\cicciobello.html")
> 
> the python process don't fail, but explorer don't visualize correctly
> the file opened: i receive an "not found" error message.
> 
> I've found that the whitespaces in file path are the problem.
> If you see to explorer address bar, you will find the address
> completely wrong...
> 
> I've found no solution!
> Can you help me, please??
> 
> thx very very very much!!!
> 

And I thought the problem where the incorrectly used \ :) Try that first :

os.spawnl(os.P_WAIT, r"c:\programmi\internet explorer\iexplorer.exe",
r"c:\documents and settings\username\desktop\cicciobello.html")
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about exausted iterators

[Christophe]

Terry Reedy a écrit :
> "Christophe" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> 
>>Instead of saying that all works as intended could you be a little
>>helpful and tell me why it was intended in such an obviously broken way
>>instead ?
> 
> 
> I answered both your explicit and implied questions in good faith.  But you 
> seem to be too attached to your pre-judgment to have benefited much, so I 
> won't waste my time and yours saying more.  Instead I suggest that you try 
> this:
> 
> 1. Write a specification for your an alternate, more complicated, iterator 
> protocol.

Specification : same as now except iterators raise once StopIteration 
and any subsequent call to next raises ExaustedIteratorError.

> 2. Write a simple class with .next method that implements your 
> specification.

class ExaustedIteratorError(Exception):
 pass

class safe_iter(object):
 def __init__(self, seq):
 self.it = iter(seq)
 def __iter__(self):
 return self
 def next(self):
 try:
 return self.it.next()
 except StopIteration:
 del self.it
 raise
 except AttributeError:
 raise ExaustedIteratorError

> 3. Test your class with your example.

 >>> it = safe_iter(range(10))
 >>> print list(it)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
 >>> print list(it)
Traceback (most recent call last):
   File "safe_iter_test.py", line 20, in ?
 print list(it)
   File "safe_iter_test.py", line 13, in next
 raise ExaustedIteratorError
__main__.ExaustedIteratorError

> 4. Consider how you would persuade people to add the extra machinery 
> needed.

Well, the main reason for such change is and will always be to catch 
bugs. The fact is, using duct typing is something very common with the 
Python language. And as such, considering a lot of functions which take 
sequences as parameters work as well with an iterator instead, you can 
say that it's an application of duct typing.

The problem is of course the same as for cases. Even if those two objets 
( iterator and container ) look alike from a certain point of view, they 
have some fundamental differences.

So, we have quite a few functions which take freely either a container 
or an iterator, until someone changes that function a little. At that 
point there are three kind errors which happen :
- the function expected a sequence and tries to access it's [] operator 
which fails. Standard duct typing behaviour.
- the function uses the iterator more than once and so, sometimes it 
works without errors but produces an incorrect result.
- the function uses the iterator more than once but never exhausts it's 
values. Same result as above but much harder to catch.

In the sake of avoiding behaviour which lets obvious errors pass and 
produces incorrect results, I propose to change the standard behaviour 
of all the iterators in the standard Python. The change will be so that 
they refuse to be used anymore once they have been exausted. Thus it'll 
help catch the second class. The other procedure used to catch such bugs 
would require explicit typing of the function parameters but this is for 
some other proposal.

> 5. Consider what you would do when people don't.

I'm already doing it. Cleaning up the code, changing parameters names 
around so that it is clear such parameter is an iterator and that other 
one is not, making some functions explicitly refuse iterators etc ... It 
should not that that last feature will be useful even without the 
exhausted iterator guard I propose.

> If you want, post a report on your experiment, and I will read it if I see 
> it.

I suppose I could add safe_iter to the builtins in my project and use it 
around. It would be easy to catch all usages of that one once we settle 
on something different then.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Complex evaluation bug

[Christophe]

Fredrik Lundh a écrit :
> Christophe wrote:
> 
>>> So, putting them together, you could expect
>>>eval(repr(a))
>>> to reproduce a, and in fact it does so.
>>
>>
>> Says who ?
>>
>> Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] 
>> on win32
>> Type "help", "copyright", "credits" or "license" for more information.
>>  >>> repr(1+3j)
>> '(1+3j)'
>>  >>> complex(repr(1+3j))
>> Traceback (most recent call last):
>>File "", line 1, in ?
>> ValueError: complex() arg is a malformed string
>>  >>>
> 
> 
> in what language is "eval" spelled "complex" ?
> 
> 
> 

Oups, I was too fast to read what was written. I though you only changed 
one of the terms ( str -> repr ).

You'll note that repr and str produce the exact same result for complex. 
And also, I'm not sure using eval anywhere is a good idea so it probably 
doesn't help for what the OP wants to do.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Christophe]

PoD a écrit :
> Maybe what Python should do (but never will given the obsession with using
> spaces) is only allow one level of indentation increase per block so that
> 
> def foo():
> return 'bar'
> 
> would return a syntax error

Which would make  mandatory for indentation. What about some 
freedom of choice ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Complex evaluation bug

[Christophe]

Gary Herron a écrit :
> of wrote:
> 
>> a = 1+3j
>> complex(str(a))
>>
>> Why does this not work ? It should
>>  
>>
> Says who?
> By normal conventions in Python, "str" attempts only to make a "nice" 
> human readable representation.  The function "repr" is usually expected 
> to provide output that can be parsed back into the original object.  
> (Although for the  numeric complex type the two produce identical results.)
> 
> Further, constructors are rarely expected to parse a string 
> representation to return an object.  The function "eval" is usually 
> expected to provide that functionality.
> 
> So, putting them together, you could expect
>eval(repr(a))
> to reproduce a, and in fact it does so.

Says who ?

Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> repr(1+3j)
'(1+3j)'
 >>> complex(repr(1+3j))
Traceback (most recent call last):
   File "", line 1, in ?
ValueError: complex() arg is a malformed string
 >>>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about exausted iterators

[Christophe]

Fredrik Lundh a écrit :
> Christophe wrote:
> 
>> Maybe I've used more iterables than most of you. Maybe I've been doing 
>> that wrong.
> 
> 
> your problem is that you're confusing iterables with sequences.  they're 
> two different things.

Yes, I know perfectly well that the bugs were my fault. But this doesn't 
prevent me from asking for a feature that will have ( in my opinion ) a 
negligible effect of current valid code and will help all of us catch 
errors earlier.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about exausted iterators

[Christophe]

Roel Schroeven a écrit :
> Fredrik Lundh schreef:
>> so what is a valid answer?
> 
> 
> I think he wants to know why the spec has been written that way.
> 
> The rationale mentions exhausted iterators:
> 
> "Once a particular iterator object has raised StopIteration, will
> it also raise StopIteration on all subsequent next() calls?
> Some say that it would be useful to require this, others say
> that it is useful to leave this open to individual iterators.
> Note that this may require an additional state bit for some
> iterator implementations (e.g. function-wrapping iterators).
> 
> Resolution: once StopIteration is raised, calling it.next()
> continues to raise StopIteration."
> 
> This doesn't, however, completey answer the OP's question, I think. It 
> is about raising or not raising StopIteration on subsequent next() calls 
> but doesn't say anything on possible alternatives, such as raising 
> another exception (I believe that's what the OP would like).

Exactly !

> Not that I know of use cases for other exceptions after StopIteration; 
> just clarifying what I think the OP means.

There are no use cases yet for me. I want those exceptions as an hard 
error for debuging purposes.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about exausted iterators

[Christophe]

Diez B. Roggisch a écrit :
> Christophe wrote:
> 
> 
>>Fredrik Lundh a écrit :
>>
>>>Christophe wrote:
>>>
>>>
>>>>Because I'm still waiting for a valid answer to my question. The
>>>>answer "Because it has been coded like that" or is not a valid one.
>>>
>>>
>>>it's been coded like that because that's what the specification says:
>>>
>>>http://www.python.org/dev/peps/pep-0234/
>>
>>I didn't though I had to mention that "Because the spec has been writen
>>like that" wasn't a valid answer either.
> 
> 
> The important thing is: it _is_ specified. And what about code like this:
> 
> 
> iterable = produce_some_iterable()
> 
> for item in iterable:
> if some_condition(item)
>break
> do_something()
> 
> for item in iterable:
> do_something_with_the_rest()
> 
> 
> If it weren't for StopIteration raised if the iterable was exhausted, you'd
> have to clutter that code with something like
> 
> try:
>for item in iterable:
>   do_something_with_the_rest()
> except IteratorExhausted:
>pass

It would be ugly but you could do that instead :

iterable = produce_some_iterable()

for item in iterable:
 if some_condition(item)
 break
 do_something()
else:
 iterable = []

for item in iterable:
 do_something_with_the_rest()

I'll admit that the else clause in for/while loops isn't the most common 
and so some people might be a little troubled by that.

There's also that :

iterable = produce_some_iterable()

for item in iterable:
 if some_condition(item)
 for item in iterable:
 do_something_with_the_rest()
 break
 do_something()

> What makes you say that this is better than the above? Just because _you_
> had some cornercases that others seems not to have (at least that
> frequently, I personally can't remember I've ever bitten by it) isn't a
> valid reason to _not_ do it as python does.

Maybe I've used more iterables than most of you. Maybe I've been doing 
that wrong. But I'd like to think that if I've made those mistakes, 
others will make it too and would benefit for some help in debugging 
that from the interpreter :)

> Besides that: it would be a major change of semantics of iterators that I
> seriously doubt it would make it into anything before P3K. So - somewhat a
> moot point to discuss here I'd say.

It wouldn't be such a big semantic change I think. You could add that 
easily[1] as deprecation warning at first and later on switch to a full 
blown error.

[1] "Easily" provided you can easily code what I ask itself ;)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about exausted iterators

[Christophe]

Fredrik Lundh a écrit :
> Christophe wrote:
> 
>>>> Because I'm still waiting for a valid answer to my question. The 
>>>> answer "Because it has been coded like that" or is not a valid one.
>>>
>>>
>>> it's been coded like that because that's what the specification says:
>>>
>>> http://www.python.org/dev/peps/pep-0234/
>>
>>
>> I didn't though I had to mention that "Because the spec has been 
>> writen like that" wasn't a valid answer either.
> 
> 
> so what is a valid answer?

Some valid use case for that behaviour, some example of why what I ask 
could cause problems, some implementation difficulties etc ...

Saying it's like that because someone said so isn't exactly what I was 
expecting as an answer :) People sometimes can be wrong you know.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about exausted iterators

[Christophe]

Fredrik Lundh a écrit :
> Christophe wrote:
> 
>> Because I'm still waiting for a valid answer to my question. The 
>> answer "Because it has been coded like that" or is not a valid one.
> 
> 
> it's been coded like that because that's what the specification says:
> 
> http://www.python.org/dev/peps/pep-0234/

I didn't though I had to mention that "Because the spec has been writen 
like that" wasn't a valid answer either.
-- 
http://mail.python.org/mailman/listinfo/python-list