Re: python-dev Summary for 2004-11-16 through 2004-11-30

[Stelios Xanthakis]

[EMAIL PROTECTED] wrote:
Would you like the source with your function?

Yes, since I asked for this feature something like two years ago ;-)
Well, the main objection seemed to be that we can get the source of a
function one way or another.  For functions with a file (1) with
"inspect" , for functions defined dynamically with "exec"(2), by
"knowing what we pass to exec and storing it", and for functions defined
in the interactive prompt (3), by using a higher level IDE/shell that is
not the pure raw_input, but does sophisticated analysis of code fed to
it and which will be responsible for storing functions (!!).  Still I
believe it's the job of the core python parser to get this info and
attach it to function objects.
The other problem was whether the source attribute should be saved to
pyc files (or more generally marhsaled together with the function
object).  Logically it should.  OTOH, for the application I had using
this, I didn't need marshalling source because it stored all the code
(initial functions + functions defined while the application was
running) in python source form.  So, I think that in practice one will
use either bytecode or the __source__ feature and not both, but I can't
prove it. 8)
There's a PEP and an --ugly- patch for 2.3.4
+10 ?
Stelios
--
http://mail.python.org/mailman/listinfo/python-list

Asyncore

[export]

Is there any tutorial and docs with samples how to use asyncore module?
Thanks 
Lad

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

Apple creator on Python

[Marco Aschwanden]

One of the "creators" of Apple has written a book and mentions Python in  
the interview:

http://www.macdevcenter.com/pub/a/mac/2005/01/04/hertzfeld.html
After writing around 20 stories, I shifted gears and worked on the  
web software to publish them, writing a simple authoring system in Python,  
which I love to program in.

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

Re: Securing a future for anonymous functions in Python

[Alan Gauld]

On Thu, 06 Jan 2005 21:02:46 -0600, Doug Holton <[EMAIL PROTECTED]> wrote:
> used, but there are people who do not like "lambda":
> http://lambda-the-ultimate.org/node/view/419#comment-3069
> The word "lambda" is meaningless to most people.  Of course so is "def", 
> which might be why Guido van Robot changed it to "define": 
> http://gvr.sourceforge.net/screen_shots/

The unfamiliar argument doesn't work for me. After all most
people are unfamiliar with complex numbers (or imaginary) numbers
but python still provides a complex number type. Just because the
name is unfamiliar to some doesn't mean we shouldn't use the
term if its the correct one for the concept.

Hopefully anyone who wants to use anonymous functions will know
that such are called lambdas and hopefully will have studied
lambda calculus to at least some level - certainly CS majors and
software engineering types should have...

> Python is easier for beginners to learn than other mainstream 
> programming languages 

Absolutely, but it has to decide (and soon I think) how important
that role is in the development of the language. Many of the more
recent features are beginner hostile - slots, properties, meta
classes, decorators etc... So is Python going to consciously try
to remain beginner friendly (which it remains by simply ignoring
the newer fatures!) or deliberately go for the "fully featured"
general purpose audience?

> Yes, I agree, and either keep the "lambda" keyword or else reuse the 
> "def" keyword for anonymous methods.  See this page Steven Bethard 
> created: http://www.python.org/moin/AlternateLambdaSyntax

I agree, I'm much more concerned about the idea of losing
anonymous functions (aka lambdas) than about losing the name
lambda, its just that the name is so descriptive of what it does!
( In fact it was seeing the name lambda appearing in a Lisp
programme I was reading that got me started in Lambda calculus
many years ago...)

> By the way, you've done great work with your learning to program site 
> and all the help you've given on the python-tutor list:

Aw shucks! Thanks ;-)

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Industry choice

[Alex Martelli]

Paul Rubin  wrote:

> [EMAIL PROTECTED] (Alex Martelli) writes:
> > Yes, apart from libraries and similar cases (frameworks etc), it's no
> > doubt rare for closed-source "end-user packages" to be sold with
> > licenses that include source and allow you to "do anything with it".
> > 
> > However, allowing customization (at least for internal use within the
> > customer organization), while rare, is far from unheard of.
> 
> There's no obstacle to doing that with GPL'd software either.

Absolutely -- as long as you don't redistribute, np.  But Roel was not
asking about GPL, he was asking about closed-source licenses -- whether
any of them "allow using the [[source]] code *at all*" -- and the answer
is that, yes, quite a few do, in specifically constrained ways.


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

Re: Excluded and other middles in licensing

[Alex Martelli]

Robert Kern <[EMAIL PROTECTED]> wrote:
   ...
> >>While most people may not think of such programs as "closed source",
> >>they most definitely ARE: the definition of open source is very strict
> >>about this aspect.
   ...
> > With my mathematical background, I'm consistent about calling
> > these "non-open" rather than "closed".  I don't insist others
> > adopt my nomenclature ...
> 
> I'm with Cameron on this one.

There is no "official" definition of closed-source as there is of
open-source, but I'm with the Wikipedia:

http://en.wikipedia.org/wiki/Closed_source

"any program whose licensing terms do not qualify as open source".

I'm not disputing it would be useful to draw many distinctions within
the universe of programs with non-opensource licenses, just pointing out
that such distinctions are not currently reflected in a popular
definition.  Since it's a wiki, it may be worthwhile editing it to add
some materials to start influencing popular usage and perception, maybe.


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

Re: OT: spacing of code in Google Groups

[Jacek Generowicz]

Peter Hansen <[EMAIL PROTECTED]> writes:

> Jacek Generowicz wrote:
> > Peter Hansen <[EMAIL PROTECTED]> writes:
> >>Why the heck would I ever have to do "rectangle operations" on a
> >>regular basis?  ;-)
> > Well, given that all editors are cat equivalent[*], you don't _have_
> > to use any of their features :-)
> 
> This "cat equivalent" thing is a red-herring.  I can rarely type more
> than a line of code without making a typographical error.  Sometimes
> I won't catch that error until a bit later.  Using "cat" alone would
> provide me little opportunity to fix the error, so I would never
> be able to produce a working program longer than a few lines.

And have you ever tried to write a serious program on a Turing Machine?

This is exactly my point: Turing Equivalence is only theoretical. In
practise some languages are more powerful than others. Same goes for
editors.

> But the whole argument is fairly moot...  I've needed a rectangle
> operation only once in the last ten years,

Whereas I use rectangle operations, on average, a few times every day
... because they are part of my standard toolbox, they suggest
themselves as the right solution to many a problem.

There are plenty of programmers out there who "have only needed
classes once in the last ten years".

More powerful editors, just like more powerful languages, can make
their users more productive. Complicated editors, just like
complicated programming languages, can make their users less
productive[*]. The optimal point in complexity-expressiveness space
will be different for different individuals, be it for editors or
programming languages.


[*] I suspect that there are a few around here who would interpret
this as an indictment against the direction in which Python is
going :-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Industry choice

[Alex Martelli]

Bulba! <[EMAIL PROTECTED]> wrote:

> Suppose they want to ensure "no forking" or that "bugfixes
> and enhancements of original software are given back". 
> 
> OK, LGPL is fine for this goal. When you say "they see it

Neither LGPL nor GPL can ``ensure "no forking"'', nor can any other
open-source license.


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

Re: The Industry choice

[Alex Martelli]

Jeff Shannon <[EMAIL PROTECTED]> wrote:

> Note that the so-called 'viral' nature of GPL code only applies to 
> *modifications you make* to the GPL software.  The *only* way in which
> your code can be 'infected' by the GPL is if you copy GPL source.
   ...
> (Problems may come if someone licenses a library under the GPL; that's
> what the LGPL was invented for.  But the issue here is not that the 
> GPL is bad, it's that the author used the wrong form of it.)

Stallman now says that you should use GPL, not Lesser GPL.

http://www.gnu.org/licenses/why-not-lgpl.html

Specifically, he wants library authors to use GPL to impose the viral
nature of GPL on other programs just USING the library -- the very
opposite of what you say about "only applies ... if you copy"!

Quoting RMS from that URL (about Readline, a GPL library):
'''
Releasing it under the GPL and limiting its use to free programs gives
our community a real boost. At least one application program is free
software today specifically because that was necessary for using
Readline.
'''

Until some judge passes some judgment, the intent and effect of GPL must
remain a matter of opinion.  But RMS's opinion is probably more
meaningful than mine or yours -- certainly regarding intent, given his
role in designing that license.  If he's badly erred, and one day a
judge endorses your opinion and says that a program which copies no GPL
source cannot be infected by GPL, ah well -- then I guess GPL is badly
designed as to putting its intents into practice.  But until there is
some strong basis to think otherwise, I believe it's prudent to assume
RMS is probably right, and your statement therefore badly wrong.


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

Re: Excluded and other middles in licensing

[Robert Kern]

Alex Martelli wrote:
Robert Kern <[EMAIL PROTECTED]> wrote:
   ...
While most people may not think of such programs as "closed source",
they most definitely ARE: the definition of open source is very strict
about this aspect.
   ...
With my mathematical background, I'm consistent about calling
these "non-open" rather than "closed".  I don't insist others
adopt my nomenclature ...
I'm with Cameron on this one.

There is no "official" definition of closed-source as there is of
open-source, but I'm with the Wikipedia:
http://en.wikipedia.org/wiki/Closed_source
"any program whose licensing terms do not qualify as open source".
A definition with a nice big "This article may need to be reworded to 
conform to a neutral point of view" warning at the top. ;-)

I'm not disputing it would be useful to draw many distinctions within
the universe of programs with non-opensource licenses, just pointing out
that such distinctions are not currently reflected in a popular
definition.  Since it's a wiki, it may be worthwhile editing it to add
some materials to start influencing popular usage and perception, maybe.
There seems to be such an edit on the way:
http://en.wikipedia.org/wiki/Talk:Closed_source
--
Robert Kern
[EMAIL PROTECTED]
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[adamc]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2005-01-07, Paul Rubin  wrote:
> Roman Suzi <[EMAIL PROTECTED]> writes:
>> I do not like the idea of having stubs. Once I had an experience working with
>> CPAN (I tried to install SpamAssassin and it required some specific modules.)
>> "Magic" install shell, provided by Perl, upgraded half the Perl distro,
>> including newer version of Perl!
>> 
>> So, I do like Python distutils better. it is not a major problem to
>> install something even if it required something else. Of course,
>> this depends on the package authors.
>
> But distutils don't help the problem that the module requires stuff
> that's missing.  That's what happened with the thing I downloaded last
> week, that needed wxPython.  I don't understand why the author felt he
> had to use wxPython instead of tkinter, since it wasn't a really fancy
> gui, but after already-described hassles trying to instead wxPython, I
> just used the application's command line interface instead, which
> worked fine.  But if wxPython is so much better, maybe it's time for
> Python to include it.
>
> I want to start using Audacity pretty soon, which I think really does
> depend on wxPython, so I'm going to have to deal with this wxPython
> installation problem which is definitely not completely trivial.  What
> a pain.  
>

I've not experienced problems installing wxPython on Debian (unstable).
It just *works* out of the box with apt-get. Perhaps this is more of a
problem with the package maintainers? 

Adam
- -- 
http://www.monkeez.org
PGP key: 7111B833
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFB3lgd9F0IVXERuDMRAu49AJ4lBRrF10nHLtBK9NBVuznOnfJH/QCgx0vV
Oqk8Vx/nASKJXvakVEYtHII=
=kThY
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Paul Rubin]

adamc <[EMAIL PROTECTED]> writes:
> I've not experienced problems installing wxPython on Debian (unstable).
> It just *works* out of the box with apt-get. Perhaps this is more of a
> problem with the package maintainers? 

I think the problem I encountered was that the version of WxWidgets
currently on the WxWidgets.com site was trying to use some obsolete
function in GTK.  If Debian is using an older version of GTK than what
comes with FC3, then it might work.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Excluded and other middles in licensing

[Paul Rubin]

Robert Kern <[EMAIL PROTECTED]> writes:
> > http://en.wikipedia.org/wiki/Closed_source
> > "any program whose licensing terms do not qualify as open source".
> 
> A definition with a nice big "This article may need to be reworded to
> conform to a neutral point of view" warning at the top. ;-)
> ...
> There seems to be such an edit on the way:
> http://en.wikipedia.org/wiki/Talk:Closed_source

After they're done defining closed source, maybe they can work on
"compact source" (a bounded closed-source program, i.e. one that,
unlike Windows, doesn't try to take over every computer in the world).
Note also from the Heine-Borel theorem that every closed source
program can be covered by some finite collection of open source
programs.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python reading/writing ms-project files?

[Simon Brunning]

On 6 Jan 2005 16:05:07 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> any existing or pointers on how to do this?

If you are running on Windows and have a copy of Project, then COM
automation is probably your best bet. See
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/279003 for a
very basic example of COM scripting.

-- 
Cheers,
Simon B,
[EMAIL PROTECTED],
http://www.brunningonline.net/simon/blog/
-- 
http://mail.python.org/mailman/listinfo/python-list

Locale confusion

[Jorgen Grahn]

[Long posting due to the examples, but pretty simple question.]

I'm sitting here with a Debian Linux 'Woody' system with the default Python
2.2 installation, and I want the re module to understand that
re.compile(r'\W+'. re.LOCALE) doesn't match my national, accented
characters.

I don't quite understand how the locale module reasons about these things,
and Python doesn't seem to act as other programs on my system. Bug or my
mistake?  Here's my environment:

frailea> env |grep -e LC -e LANG
LC_MESSAGES=C
LC_TIME=C
LANG=sv_SE
LC_NUMERIC=C
LC_MONETARY=C
frailea> locale
LANG=sv_SE
LC_CTYPE="sv_SE"
LC_NUMERIC=C
LC_TIME=C
LC_COLLATE="sv_SE"
LC_MONETARY=C
LC_MESSAGES=C
LC_PAPER="sv_SE"
LC_NAME="sv_SE"
LC_ADDRESS="sv_SE"
LC_TELEPHONE="sv_SE"
LC_MEASUREMENT="sv_SE"
LC_IDENTIFICATION="sv_SE"
LC_ALL=

This seems to indicate that $LANG acts as a fallback when other things (e.g.
LC_CTYPE isn't defined) and that's also what the glibc setlocale(3) man page
says. Works well for me in general, too.  However, consider this tiny Python
program:

frailea> cat foo
import locale
print locale.getlocale()
locale.setlocale(locale.LC_CTYPE)
print locale.getlocale()

When I paste it into an interactive Python session, the locale is already
set up correctly (which is what I suppose interactive mode /should/ do):

>>> import locale
>>> print locale.getlocale()
['sv_SE', 'ISO8859-1']
>>> locale.setlocale(locale.LC_CTYPE)
'sv_SE'
>>> print locale.getlocale()
['sv_SE', 'ISO8859-1']
>>> 

When I run it as a script it isn't though, and the setlocale() call does not
appear to fall back to looking at $LANG as it's supposed to(?), so my
LC_CTYPE remains in the POSIX locale:

frailea> python foo
(None, None)
(None, None)

The corresponding program written in C works as expected:

frailea> cat foot.c
#include 
#include 
int main(void) {
printf("%s\n", setlocale(LC_CTYPE, 0));
printf("%s\n", setlocale(LC_CTYPE, ""));
printf("%s\n", setlocale(LC_CTYPE, 0));
return 0;
}
frailea> ./foot
C
sv_SE
sv_SE

So, is this my fault or Python's?  I realize I could just adapt and set
$LC_CTYPE explicitly in my environment, but I don't want to capitulate for a
Python bug, if that's what this is.

BR,
Jorgen

-- 
  // Jorgen GrahnR'lyeh wgah'nagl fhtagn!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pre/Postconditions with decorators

[George Sakkis]

"Robert Brewer" <[EMAIL PROTECTED]> wrote:

> Ian Bicking was just talking about @require decorators:
> http://blog.ianbicking.org/already-under-our-noses.html
>
> @require(int, int)
> def gcd(a, b):
> ...
>
> If we made a "checker" module for such things in the stdlib, we could
> write most of that:
>
> from checker import *
>
> @args((list, itemsnotNone, ))
> @returns((any, ))
> def my_sum(seq):
> tmp=0
> for element in seq:
> tmp+=element
> return tmp


I recently wrote a similar checker module; apart from regular python types and 
classes, it supports
'parameterized types', such as 'list of ints', 'container of floats', 'mapping 
with str keys and
tuples of int values', etc. Here's a demo:

# >>> from typecheck import *
# >>> @returnType(listOf(int, size=3))
# >>> @argTypes(x=str, y=containerOf(int))
# ... def f(x,y):
# ... return [len(x)] + list(y)
# >>> f('1',[2,3])
# [1, 2, 3]
# >>> f('1',(2,3))
# [1, 2, 3]
# >>> f(1,[2,3])
# (...)
# TypeError: str expected (int given)
# >>> f('1',[2,'3'])
# (...)
# TypeError: container expected ([2, '3'] given)
# >>> f('1',[2,3,4])
# (...)
# TypeError: Container of size 3 expected ([1, 2, 3, 4] given)

I can make it available somewhere (e.g. Vaults of Parnassus) if there's enough 
interest.

George


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

Tkinter Puzzler

[Tim Daneliuk]

I am trying to initialize a menu in the following manner:
for entry in [("Up", KeyUpDir), ("Back", KeyBackDir), ("Home", KeyHomeDir), ("Startdir", KeyStartDir), ("Root", 
KeyRootDir)]:

func = entry[1]
UI.ShortBtn.menu.add_command(label=entry[0], command=lambda: func(None))
However, at runtime, each of the menu options binds to the *last* function
named in the list (KeyStartDir).
Explicitly loading each entry on its own line works fine:
UIcommand=lambda:KeyWHATEVERDir(None)
Any ideas why the first form does not fly?
TIA,

Tim Daneliuk [EMAIL PROTECTED]
PGP Key: http://www.tundraware.com/PGP/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Excluded and other middles in licensing

[Alex Martelli]

Paul Rubin  wrote:

> Note also from the Heine-Borel theorem that every closed source
> program can be covered by some finite collection of open source
> programs.

Every _compact_ one, surely?  Quoting by heart from old memories, but,
isn't Heine-Borel about (being able reduce any open covering of X to a
finite subcovering) <-> (X is compact) ...?


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

Re: Pre/Postconditions with decorators

[rittersporn]

Hi Stephen
I have not read anything about the
"framehack lambda replacement" yet,
but I do compile the pre- and
postconditions. Syntax erros e.g.
will be raised if the module
is compiled. Although I must admit
that your code snippets look more like
compiled code ;-)

Hi Robert
thanks for the link to the Ian Bicking blog.

Hi George,
it would be nice to see how you have tackled
the task.
Maybe we will have a checker
module in Python one day... ;-)

Well, I have attached my latest attempt
to model pre/postconditions (without "framehack
lambda replacement") which does wrap the
original function with a class which delegates
attribute access. Now I can split my
"condition" into pre- and postcondition
and the "tracer" prints the original
function name.
I have also fixed a bug
with keyword arguments.
Major difference compared to
other examples is probably
only that I can refer to function
arguments by name:

class Delegate(object):
def __init__(self,function):
self.function=function
def __getattr__(self,key):
return getattr(self.function,key)


def condition(pretext,posttext=""):
precode=compile(pretext or "True","","eval")
postcode=compile(posttext or "True","","eval")

# function -> decorated(function)
def decorate_condition(function):
argcount=function.func_code.co_argcount
var=function.func_code.co_varnames[0:argcount]
class EvalCond(Delegate):
def __call__(self,*args,**kargs):
# FIXME: check if "var" always contains
ordered list of arguments
# map arguments and
args_seq=[(argname,args[pos]) for
pos,argname in \
enumerate(var) if (argname not
in kargs)]
# key-arguments to value
kargs_seq=[(k,v) for k,v in
kargs.iteritems()]
environment=args_seq+kargs_seq

# precondition
assert
eval(precode,{},dict(environment)),pretext
tmp=function(*args,**kargs)

environment2=environment+[('result',tmp)]

# postcondition
assert
eval(postcode,{},dict(environment2)),posttext
return tmp
return  EvalCond(function)
return decorate_condition

def trace(function):
class Trace(Delegate):
def __call__(self,*args,**kargs):
print "enter function %s with " % \
self.function.func_name,args,kargs
result=self.function(*args,**kargs)
print "leave function %s with " % \
self.function.func_name,args,kargs
return result
return Trace(function)

def precondition(prgtext):
return condition(prgtext)

def postcondition(prgtext):
return condition("",prgtext)


@precondition("number>0 and number<2")
@postcondition("result>=0")
def sqrt(number):
import math
return math.sqrt(number)

@trace
@precondition("len(seq)>0 is not None and str(more)")
@postcondition("sum(seq)==result")
def my_sum(seq,more):
tmp=0
for element in seq:
tmp+=element
return tmp

print sqrt(1.2)
print my_sum([1,2,3],more="more")

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

missing sys.setappdefaultencoding

[Uwe Mayer]

Hi,

well, I wrote a nice python program which won't work if the default encoding
has not been set from ascii to latin-1 or latin-15.

However, the command sys.setappdefaultencoding is missing on a Python
installation with Python 2.3.4 on Gentoo where it is present on Debian.

Any ideas how to deal with this?

Thanks in advance,
Ciao
Uwe 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Industry choice

[Robert Kern]

Alex Martelli wrote:
Until some judge passes some judgment, the intent and effect of GPL must
remain a matter of opinion.  But RMS's opinion is probably more
meaningful than mine or yours -- certainly regarding intent, given his
role in designing that license. 
But it may not have practical effect in an actual dispute. I believe 
that in some jurisdictions[1], the important piece of information in 
interpreting a license is the common understanding of what the license 
means between the disputing parties. The author of the license, if he is 
not one of the disputing parties, has no say in what the license means 
for that dispute.

[1] IANAL; TINLA. This is from my memory of what I read in Lawrence 
Rosen's book[2] that I don't have in front of me right now. See his 
book, chapter 12, I think, for more details.

[2] http://www.rosenlaw.com/oslbook.htm
If he's badly erred, and one day a
judge endorses your opinion and says that a program which copies no GPL
source cannot be infected by GPL, ah well -- then I guess GPL is badly
designed as to putting its intents into practice.  But until there is
some strong basis to think otherwise, I believe it's prudent to assume
RMS is probably right, and your statement therefore badly wrong.
I've always found, especially in light of what I wrote above, the best 
thing to do is to ask the author himself what he wants. If he subscribes 
to an unreasonable interpretation of the license, it's better that you 
found out quickly and avoid getting sued even though you might end up 
winning. You also avoid inadvertantly stepping on anyone's toes and 
garnering ill-will even if you never go to court.

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

Re: Python evolution: Unease

[Alex Martelli]

Paul Rubin  wrote:

> Really, I just want to buy a new
> computer, turn it on, and have everything there.  That's generally
> impossible without running satanware from Redmond

The princes of insufficient light from Cupertino will in fact be very
happy to sell you such computers, and _their_ definition of "everything"
includes a bit more than the Redmonders' (e.g., Python is there, perl is
there, gcc is there, so is Apache, a good development GUI-based IDE,
emacs, a solid firewall, a _usable_ Terminal/commandline program to run
bash or tcsh on, ...), though it's no doubt still missing many pieces
that you or I might want as parts of *our* "everything" (gvim rather
than just vim, GUI/IDEs for Python, Python add-ons such as numarray,
gmpy, ctypes, ...) -- all of those you still have to download and
install, just as you would for the satanware.


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

Re: Tkinter Puzzler

[Eric Brunel]

Tim Daneliuk wrote:
I am trying to initialize a menu in the following manner:
for entry in [("Up", KeyUpDir), ("Back", KeyBackDir), ("Home", 
KeyHomeDir), ("Startdir", KeyStartDir), ("Root", KeyRootDir)]:

func = entry[1]
UI.ShortBtn.menu.add_command(label=entry[0], command=lambda: 
func(None))

However, at runtime, each of the menu options binds to the *last* function
named in the list (KeyStartDir).
Explicitly loading each entry on its own line works fine:
UIcommand=lambda:KeyWHATEVERDir(None)
Any ideas why the first form does not fly?
This has nothing to do with Tkinter, but only with the way nested scopes work: 
to put it roughly, your "lambda: func(None)" only knows about the *name* func, 
which is not actually evaluated until the button is pressed. And when the button 
is pressed, the name func is bound to the last command in the loop.

To do what you want, change your code to:
for entry in (...):
  UI.ShortBtn.menu.add_command(
label=entry[0],
command=lambda func=entry[1]: func(None)
  )
This way, the value for the func parameter is evaluated when the function is 
defined and not when it is called.

HTH
--
- Eric Brunel  -
PragmaDev : Real Time Software Development Tools - http://www.pragmadev.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter Puzzler

[F. Petitjean]

Le 07 Jan 2005 05:28:31 EST, Tim Daneliuk a écrit :
> I am trying to initialize a menu in the following manner:
> 
> for entry in [("Up", KeyUpDir), ("Back", KeyBackDir), ("Home", KeyHomeDir), 
> ("Startdir", KeyStartDir), ("Root", 
> KeyRootDir)]:
> 
>  func = entry[1]
>  UI.ShortBtn.menu.add_command(label=entry[0], command=lambda: func(None))
The problem is that you *call* the callback : the command parameter is
bound to the result of func(None)
> 
> However, at runtime, each of the menu options binds to the *last* function
> named in the list (KeyStartDir).
> 
> Explicitly loading each entry on its own line works fine:
> 
> UIcommand=lambda:KeyWHATEVERDir(None)
> 
> Any ideas why the first form does not fly?
I would simplify the code like ;

add_cmd = UI.ShortBtn.menu.add_command
for label, func in (("Up", KeyUpDir),  ):
add_cmd(label=label, command=func)

And have
def KeyUpDir(arg=None):
# whatever

> 
> 
> TIA,
> 
> Tim Daneliuk [EMAIL PROTECTED]
> PGP Key: http://www.tundraware.com/PGP/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Alex Martelli]

Terry Reedy <[EMAIL PROTECTED]> wrote:
   ...
> Even though I currently only have 80 megs (about the minimum one can 

You probably mean 80 gigs.  You can get smaller disks, say 30 gigs, in
entry-point laptops.  But for a few dozen megs I think you'd have to go
for solid-state "disks", say USB keys with flash memory -- while 128
megs is around the minimum one can easily find in shops, there are
plenty of smaller cuts, such as 64 or even 32 megs, sold e.g. as part of
other gadgets such as mice, remote-control receivers, &c.

> serious stuff is obsolete.  (My first hard disk was 5 or 10 megs.)  A

Here I suspect you do mean megs -- 5 and 10 megs were indeed the sizes
of the first affordable "winchester" hard-disks 20/25 years ago.


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

Re: missing sys.setappdefaultencoding

[Alex Martelli]

Uwe Mayer <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> well, I wrote a nice python program which won't work if the default encoding
> has not been set from ascii to latin-1 or latin-15.

Then your program is not very nice...;-)

> However, the command sys.setappdefaultencoding is missing on a Python
> installation with Python 2.3.4 on Gentoo where it is present on Debian.
> 
> Any ideas how to deal with this?

The site.py module in the standard Python library deliberately REMOVES
the setdefaultencoding entry from the sys module (with a del statement)
just before it finishes initializing your site-specific environment.

This is meant as a very strong indication that you SHOULDN'T rely on
setdefaultencoding in your applications.  Being more explicit about the
codings to/from Unicode is way, way better.  I strongly suggest you only
use Unicode *within* your programs and transcode only at I/O time (if
needed: some good GUI toolkits, including Tkinter which comes with
Python by default, use Unocide too).  On the activestate's cookbook site
you'll find a nice recipe by your compatriot Holger Krekel pointing out
the practical course to follow, IMHO (I expand on that in the version of
this and other recipes I've edited for the forthcoming 2nd printed
edition of the Python Cookbook, but Holger's online recipe already has
the salient practical points you'd be well advised to follow).

If nevertheless you want to subvert the design intent of Python, Python
does give you enough rope to shoot yourself in the foot:
import sys
reload(sys)
and now, after reloading, sys.setdefaultencoding will be there anew.


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

_Re Pre/Postconditions with decorators

[Rittersporn]

# Google-News won't let be post a follow-up right now!
# Google-Beta-News destroys the formatting :-(
# So I'll start a new thread.

Hi Stephen
I have not read anything about the
"framehack lambda replacement" yet,
but I do compile the pre- and
postconditions. Syntax erros e.g.
will be raised if the module
is compiled. Although I must admit
that your code snippets look more like
compiled code ;-)

Hi Robert
thanks for the link to the Ian Bicking blog.

Hi George,
it would be nice to see how you have tackled
the task.
Maybe we will have a checker
module in Python one day... ;-)

Well, I have attached my latest attempt
to model pre/postconditions (without "framehack
lambda replacement") which does wrap the
original function with a class which delegates
attribute access. Now I can split my
"condition" into pre- and postcondition
and the "tracer" prints the original
function name.
I have also fixed a bug
with keyword arguments.
Major difference compared to
other examples is probably
only that I can refer to function
arguments by name:

class Delegate(object):
def __init__(self,function):
self.function=function
def __getattr__(self,key):
return getattr(self.function,key)


def condition(pretext,posttext=""):
precode=compile(pretext or "True","","eval")
postcode=compile(posttext or "True","","eval")

# function -> decorated(function)
def decorate_condition(function):
argcount=function.func_code.co_argcount
var=function.func_code.co_varnames[0:argcount]
class EvalCond(Delegate):
def __call__(self,*args,**kargs):
# FIXME: check if "var" always contains ordered 
list of arguments
# map arguments and
args_seq=[(argname,args[pos]) for pos,argname 
in \
enumerate(var) if (argname not in 
kargs)]
# key-arguments to value
kargs_seq=[(k,v) for k,v in kargs.iteritems()]
environment=args_seq+kargs_seq

# precondition
assert 
eval(precode,{},dict(environment)),pretext
tmp=function(*args,**kargs)
environment2=environment+[('result',tmp)]

# postcondition
assert 
eval(postcode,{},dict(environment2)),posttext
return tmp
return  EvalCond(function)
return decorate_condition

def trace(function):
class Trace(Delegate):
def __call__(self,*args,**kargs):
print "enter function %s with " % \
self.function.func_name,args,kargs
result=self.function(*args,**kargs)
print "leave function %s with " % \
self.function.func_name,args,kargs
return result
return Trace(function)

def precondition(prgtext):
return condition(prgtext)

def postcondition(prgtext):
return condition("",prgtext)


@precondition("number>0 and number<2")
@postcondition("result>=0")
def sqrt(number):
import math
return math.sqrt(number)

@trace
@precondition("len(seq)>0 is not None and str(more)")
@postcondition("sum(seq)==result")
def my_sum(seq,more):
tmp=0
for element in seq:
tmp+=element
return tmp

print sqrt(1.2)
print my_sum([1,2,3],more="more")
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter Puzzler

[Alex Martelli]

Tim Daneliuk <[EMAIL PROTECTED]> wrote:

> I am trying to initialize a menu in the following manner:
> 
> for entry in [("Up", KeyUpDir), ("Back", KeyBackDir), ("Home",
> KeyHomeDir), ("Startdir", KeyStartDir), ("Root", KeyRootDir)]:
> 
>  func = entry[1]
>  UI.ShortBtn.menu.add_command(label=entry[0], command=lambda: func(None))
> 
> However, at runtime, each of the menu options binds to the *last* function
> named in the list (KeyStartDir).
> 
> Explicitly loading each entry on its own line works fine:
> 
> UIcommand=lambda:KeyWHATEVERDir(None)
> 
> Any ideas why the first form does not fly?

One word: late binding.  Well, two, pedantically speaking;-).

The lambda you're passing as the value for 'command' is a closure: it
knows it will have to look up name 'func' in the environment in which
it's embedded -- but also that it's meant to do that lookup as late as
possible, each time it's called.

If you wanted to do the lookup just once, at the time lambda executes
and created an anonymous function rather than each time said anonymous
function is called, you could have expressed that...:
command=lambda func=func: func(None)
Here, func is a local variable (argument) of the anonymous function, and
its "default value" is set ONCE, when the anon function is created.

Back to your code, when your anon function is called, it looks up name
'func' in the surrounding environment... and there it finds it bound to
whatever it was RE-bound to the LAST time...


Point to remember: a closure looks up free-variable names in its
surrounding environment *as late as possible*, i.e., when the function
object is called; while default argument values are evaluated *at
function creation time* (when lambda or def executes, not when the
resulting function object gets called).


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

Re: Tkinter Puzzler

[Tim Daneliuk]

Tim Daneliuk wrote:
I am trying to initialize a menu in the following manner:
for entry in [("Up", KeyUpDir), ("Back", KeyBackDir), ("Home", 
KeyHomeDir), ("Startdir", KeyStartDir), ("Root", KeyRootDir)]:

func = entry[1]
UI.ShortBtn.menu.add_command(label=entry[0], command=lambda: 
func(None))

However, at runtime, each of the menu options binds to the *last* function
named in the list (KeyStartDir).
Explicitly loading each entry on its own line works fine:
UIcommand=lambda:KeyWHATEVERDir(None)
Any ideas why the first form does not fly?
TIA,
 

Tim Daneliuk [EMAIL PROTECTED]
PGP Key: http://www.tundraware.com/PGP/
Thanks All - great responses!
--

Tim Daneliuk [EMAIL PROTECTED]
PGP Key: http://www.tundraware.com/PGP/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Excluded and other middles in licensing

[Paul Rubin]

[EMAIL PROTECTED] (Alex Martelli) writes:
> > Note also from the Heine-Borel theorem that every closed source
> > program can be covered by some finite collection of open source
> > programs.
> 
> Every _compact_ one, surely?  Quoting by heart from old memories, but,
> isn't Heine-Borel about (being able reduce any open covering of X to a
> finite subcovering) <-> (X is compact) ...?

Yeah, whoops, that's what I meant; your old memories are clearer than
mine.  Actually sometimes the definitions and theorems interchange.

I do remember something about Tikhonov's Theorem that says that no
matter how often bounded closed source programs multiply, the product
is still closed source.  So, for example, Adobe Acrobat is still
closed source even if you can download it from Adobe's web site
infinitely often.  But that theorem doesn't apply to noncompact
(i.e. unbounded) closed source programs.  So ordering Microsoft to
release parts of Windows as open source was one of the potential
remedies discussed in the penalty phase of the US Justice Dept's
antitrust suit.  Unfortunately, the DoJ lawyers were not good
topologists so they didn't give enough consideration to this
possibility.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Other notes

[Steve Holden]

Andrew Dalke wrote:
Bengt Richter:
But it does look ahead to recognize += (i.e., it doesn't generate two
successive also-legal tokens of '+' and '=')
so it seems it should be a simple fix.

But that works precisely because of the greedy nature of tokenization.
Given "a+=2" the longest token it finds first is "a" because "a+"
is not a valid token.  The next token is "+=".  It isn't just "+"
because "+=" is valid.  And the last token is "2".
[...]
You're absolutely right, of course, Andrew, and personally I don't think 
that this is worth trying to fix. But the original post I responded to 
was suggesting that an LL(1) grammar couldn't disambiguate "1." and 
"1..3", which assertion relied on a slight fuzzing of the lines between 
lexical and syntactical analysis that I didn't want to leave unsharpened.

The fact that Python's existing tokenizer doesn't allow multi-character 
tokens beginning with a dot after a digit (roughly speaking) is what 
makes the whole syntax proposal infeasibly hard to adapt to.

regards
 Steve
--
Steve Holden   http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC  +1 703 861 4237  +1 800 494 3119
--
http://mail.python.org/mailman/listinfo/python-list

Re: Asyncore

[Steve Holden]

[EMAIL PROTECTED] wrote:
Is there any tutorial and docs with samples how to use asyncore module?
Thanks 
Lad

Well, here's a very simple web server from Chapter 7 of "Python Web 
Programming" which might help get you started.

You can see a few more examples if you download the code from the book, 
which you can do at

http://pydish.holdenweb.com/pwp/download.htm

import socket
import asyncore
import time
class http_server(asyncore.dispatcher):
def __init__(self, ip, port):
self.ip= ip
self.port = port
self.count = 0
asyncore.dispatcher.__init__(self)
self.create_socket(socket.AF_INET, socket.SOCK_STREAM)
self.bind((ip, port))
self.listen(5)
def writable(self):
return 0
def handle_read(self):
pass
def readable(self):
return self.accepting
def handle_connect(self):
pass
def handle_accept(self):
try:
conn, addr = self.accept()
except socket.error: # rare Linux error
print "Socket error on server accept()"
return
except TypeError: # rare FreeBSD3 error
print "EWOULDBLOCK exception on server accept()"
return
self.count += 1
handler = http_handler(conn, addr, self, self.count)
def decrement(self):
self.count -= 1
class http_handler(asyncore.dispatcher):
def __init__(self, conn, addr, server, count):
asyncore.dispatcher.__init__(self, sock=conn)
self.addr = addr
self.buffer = ""
self.time = time.time()
self.count = count
self.server = server
def handle_read(self):
rq = self.recv(1024)
self.buffer = """HTTP/1.0 200 OK Canned Response Follows
Content-Type: text/html


Response from server


This is socket number %d

""" % self.count
def writable(self):
if time.time()-self.time > 10:
return len(self.buffer) > 0
else:
return 0
def handle_write(self):
sent = self.send(self.buffer)
self.buffer = self.buffer[sent:]
if len(self.buffer) == 0:
self.close()
self.server.decrement()
server = http_server('', 8080)
asyncore.loop(timeout=4.0)

regards
 Steve
--
Steve Holden   http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC  +1 703 861 4237  +1 800 494 3119
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python C Object Comparison

[Anand K Rayudu]

Dear Craig,

Thanks a lot for the suggestions.
I am just considering to create a user defined data type to  wrap the C
pointer.
I can add compare method for that data type. 
So all my APIs returns the new data type rather than PythonC Object.

But hoping that it is not lot of over head with respect to memory usage
and performance .
I guess that's what you suggested me!!
Probably any way to add my own comparison function to pythonC object
will be simpler for me,
as it calls for very less change, with out disturbing my existing C 
APIS and python customization code.

Thanks again for the suggestion
Regards,
Anand

Craig Ringer wrote:

  On Thu, 2005-01-06 at 18:34, Anand K Rayudu wrote:

  
  
Here is my python code

import myModule

a=myModule.myAPI1("1")
b=myModule.myAPI2("name")

# basically both above functions return same C pointer.
# so i want to compare
if(a==b): print "They are same"
else : print "They are different"

python always prints they are different,
I guess this is because in python layer we create PythonCObject for 
every C pointer, and that is how it is exposed to python. Though both 
the APIs are returning the same C pointer, they are different instances 
of PythonCObject.

  
  
That sounds likely to me.

  
  
So i guess that is the reason comparison is failing.
How ever is it possible to make python to compare actual C pointer, 
rather than the PythonCObject Pointer.

  
  
You might be able to subclass PyCObject and work with your subclassed
version (that adds a __eq__ method). In the end, though, I don't think
that's the right path to proceed down.

My understanding is that CObjects are for passing pointers through
Python code in a safe way. I don't think they're really intended for
uses where the Python code is actually working with the objects, only
pass them around as opaque objects.

If you want to actually work with the objects you're passing around, I'd
think about implementing my own type that better fits the API my
extension module wants to present to Python code.

I'm using PyCObjects as a temporary ugly hack in an embedded app I'm
working on... but it's seriously ugly. What I should do, and will soon
do now that I've tested the concept of what I'm doing and it works, is
move all my functions into a class and make the class own and manage the
C++ object (and pointer to it) that it owns.

Perhaps that's a better solution for you too? 

If you want any opinions from folks here about the best way to solve
your problem, you'll probably need to explain a bit more of your problem
- like what your extension module is doing that makes it have to pass
PyCObjects around and get Python code to work with them.

--
Craig Ringer
  



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

Re: Securing a future for anonymous functions in Python

[Anna]

Okay, I tried to post this previously but ran into the new Google
groups system which appears to have sent my original response into the
ether... Oops. Trying again.

Alan Gauld wrote:
> On Thu, 30 Dec 2004 23:28:46 +1000, Nick Coghlan
> <[EMAIL PROTECTED]> wrote:
>
> > GvR has commented that he want to get rid of the lambda keyword for
Python 3.0.
> > Getting rid of lambda seems like a worthy goal,
>
> Can I ask what the objection to lambda is?
> 1) Is it the syntax?
> 2) Is it the limitation to a single expression?
> 3) Is it the word itself?
>
> I can sympathise with 1 and 2 but the 3rd seems strange since a
> lambda is a well defined name for an anonymous function used in
> several programming languages and originating in lambda calculus
> in math. Lambda therefore seems like a pefectly good name to
> choose.
>
> So why not retain the name lambda but extend or change the syntax
> to make it more capable rather than invent a wholly new syntax
> for lambdas?
>
> Slightly confused, but since I only have time to read these
> groups regularly when I'm at home I have probably missed the bulk
> of the discussion over the years.
>
> Alan G.
> Author of the Learn to Program website
> http://www.freenetpages.co.uk/hp/alan.gauld

Hi Alan:

Having taken some calculus (derivatives, limits, some integrals) but
never even heard of lambda calculus, to me, lambda means absolutely
NOTHING. Less than nothing.

Actually, in my encounters with others code in Python (including
reading near 1000 recipes for the recent edition of the Cookbook), what
I've discovered is that what lambda mostly means to me is:
"I don't wanna write clear, elegant Python - I wanna write fancy,
clever, obfuscated code, and lambda lets me do that!"

I've seen maybe 1 case in 10 where lambda appears, to me, to allow
clearer, cleaner code than defining a function. Most cases-it's an
ugly, incomprehensible hack.

So, if people really need anonymous functions in Python (and
apparently, they do), then at least lets get a word that actually
*means* something. Every other word in Python has an obvious meaning.
lambda doesn't.

So, I guess I don't like the word itself - any more than I like how
it's (mostly) used.

Anna Martelli Ravenscroft

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

Re: Securing a future for anonymous functions in Python

[Paul Rubin]

"Anna" <[EMAIL PROTECTED]> writes:
> Having taken some calculus (derivatives, limits, some integrals) but
> never even heard of lambda calculus, to me, lambda means absolutely
> NOTHING. Less than nothing.

Lambda calculus is from mathematical logic, but more to the point
"lambda" has been the term used in Lisp for this operation since time
immemorial.  Since the kinds of programmers who want to use anonymous
functions have probably been exposed to Lisp at one time or another,
"lambda" should not cause any confusion.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[Steve Holden]

Paul Rubin wrote:
"Anna" <[EMAIL PROTECTED]> writes:
Having taken some calculus (derivatives, limits, some integrals) but
never even heard of lambda calculus, to me, lambda means absolutely
NOTHING. Less than nothing.

Lambda calculus is from mathematical logic, but more to the point
"lambda" has been the term used in Lisp for this operation since time
immemorial.  Since the kinds of programmers who want to use anonymous
functions have probably been exposed to Lisp at one time or another,
"lambda" should not cause any confusion.
That's probably not the most enthusiastic evangelical approach to 
functional programming I've ever heard :-)

Perhaps what we really need is a good Lisp subsystem for Python?
regards
 Steve
--
Steve Holden   http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC  +1 703 861 4237  +1 800 494 3119
--
http://mail.python.org/mailman/listinfo/python-list

embedded scripts debugging

[Andrey Tatarinov]

Hi all.
I have custom resource editor and wish python to be scripting language 
in it. But I don't want to lose ability of debugging which I currently 
have implementing all logic in C++.

So the question is: Is there suitable library for simple python gui 
debugger, or may be there are some other techniques for debugging 
embedded scripts?
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Bulba!]

On 06 Jan 2005 18:46:00 -0800, Paul Rubin
 wrote:

>"Terry Reedy" <[EMAIL PROTECTED]> writes:
>> Would it be possible, at least for Windows, to write a Python script 
>> implementing a 'virtual distribution'?  IE, download Python, install it, 
>> download next package, install it, etc.  -- prefereably table driven?

>I just don't understand why you'd want to do that, instead of putting
>all the files in the distro in the first place.

Plus there would be maddening dependencies - "oh, in order 
to  use this I need dl that". "oh, that package is missing", "why 
that doesn't work?" - and time gets wasted. 

On Linux, quite a lot of code had to be written to resolve
dependencies like "a.rpm depends on b.rpm depends on 
c.rpm ...".  Sure, apt is a wonderful tool for resolving 
such stuff - but I've seen even apt choking sometimes on 
dependencies it couldn't resolve, esp. when the package you 
attempt to dl is broken in some way. Reason - apt-get says 
"sorry, what this package depends on is broken and I can't 
find anything else in your /etc/apt/sources.list that would
be appropriate". Result? Nobody gets to use Pine on this 
machine, unless I compile it myself (which I finally did). 

Sure it _can_ be done, but essentially it's a waste of 
time that this person could devote to doing smth else. 

It doesn't happen often, but it happens.  Why get into 
resolving such complexity if you don't have to? 

There are good reasons to use tools like apt-get or yum or 
up2date on Linux: you can't fit the bugfixes on a CD that
come every day, obviously, there's too much of it all to 
fit simply everything anybody could ever need on the media, 
etc, etc. However, with Python that's not a problem, because 
distro is smaller and it doesn't change _that_ often, as lots 
of packages on Linux are updated almost daily. 

One of the options for Python could be to have two distributions: 
one standard, basic distribution, and the "Stuffed Python" based
on the standard, created simply by piling all the good stuff on top of
standard distro. 



--
It's a man's life in a Python Programming Association.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Paul Rubin]

[EMAIL PROTECTED] (Alex Martelli) writes:
> Paul Rubin  wrote:
> > Really, I just want to buy a new
> > computer, turn it on, and have everything there.  That's generally
> > impossible without running satanware from Redmond
> 
> The princes of insufficient light from Cupertino will in fact be very
> happy to sell you such computers,

I actually do sometimes advise nontechnical people to buy those things
and run the installed software since GNU/Linux is really not there yet
with a number of types of apps, and is more of a maintenance headache.
But if I bought one myself, I'd feel oblige to reformat the hard drive
to get rid of the darkware (= no source) just like I do with a PC.
I've played with that notion at different times since the hardware is
actually rather nice.

> and _their_ definition of "everything"
> includes a bit more than the Redmonders' (e.g., Python is there, perl is
> there, gcc is there, so is Apache, a good development GUI-based IDE,

Oh cool, you mean emacs/gud/gdb.

> emacs, a solid firewall, a _usable_ Terminal/commandline program to run
> bash or tcsh on, ...),

Yes, shell mode in Emacs works fine, I haven't had much need to use
anything else.  Xterm also works.  

> though it's no doubt still missing many pieces
> that you or I might want as parts of *our* "everything" (gvim rather
> than just vim,

I'm not sure what the difference is supposed to be... I remember
someone explaining "you can't spell vile without vi".

> GUI/IDEs for Python, 

I remember there was a gud interface for Python but it didn't work
pretty well.  There's also IDLE which is pretty crude and flaky.  I
think I'll just wait for Pypy deployment before worrying about this
situation too much.  Is there something else I can download?

> Python add-ons such as numarray,
> gmpy, ctypes, ...) -- all of those you still have to download and
> install, just as you would for the satanware.

That's unfortunate, that stuff should be included with Python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[Paul Rubin]

Steve Holden <[EMAIL PROTECTED]> writes:
> Perhaps what we really need is a good Lisp subsystem for Python?

I've thought the other way around, it would be nice to have a Python
subsystem for Lisp.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: get the IP address of a host

[Jorge Luiz Godoy Filho]

Kartic, Quarta 05 Janeiro 2005 14:08, wrote:

> socket.gethostbyaddr(socket.gethostname())
> 
> will return a tuple containing fully qualified hostname,  alternative
> hostnames, ip addresses (>1 if multihomed).
>
> or
> 
> socket.gethostbyname(socket.gethostname())

None of these work with computers with more than one interface...  They get
only one of them.  It would be safer, then, to specify the desired
interface or use an alternative method.

-- 
Godoy. <[EMAIL PROTECTED]>

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

Re: The Industry choice

[Paul Rubin]

Bulba! <[EMAIL PROTECTED]> writes:
> From the viewpoint of looking at availability of source code A, 
> it's completely irrelevant if those guys are fishmongers or 
> make derived work A' and redistribute only binary of A'. Not 
> a single line of publicly available source code appeared or
> disappeared as the result of whatever they do. Amounts of
> binaries - yes, that is affected. But not the source code.

>From the viewpoint of the availability of Adobe Photoshop, it's
completely irrelevant if I run off a few hundred thousand copies on CD
in a warehouse by the waterfront and then sell them out of the back of
a truck at the flea market.  Not a single shrink-wrapped retail copy
of Photoshop disappeared from any stores as the result.  But Adobe
will still send the US Marshals to raid my operation with guns and
stuff.  I don't think you would approve of my illicit Photoshop
replication either.

So why should the situation be any different with GPL code?  If
someone wants to copy it, they need to do so according to the license.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Bulba!]

On Thu, 6 Jan 2005 23:42:40 -0500, "Terry Reedy" <[EMAIL PROTECTED]>
wrote:
>>> Would it be possible, at least for Windows, to write a Python script 
>>> implementing a 'virtual distribution'?  IE, download Python, install it, 
>>> download next package, install it, etc.  -- prefereably table driven?
>>
>> How would you run the script in the first place?
>
>Duh... with my existing version of Python (which I have had some version of 
>for so long that I had forgotten what it is to not have one handy) ;-).

>Ok, 2 step process for first timers.

That is not a problem. The problem is "complex dependencies
of stuff you use on plethora of stuff you never even heard of,
some of which is missing or WRONG VERSION or broken". 

Sometimes it gets on the nerves of the developers, too - I
remember Vietse Venema, author of Postfix, pulling his 
hair out, because RedHat was systematically shipping the
broken package with DB library that Postfix relied on. 

The significant problem was, even if you tried to rip out 
broken DB package (it was Berkeley  DB IIRC), and replace 
with fixed version, packages X, Y and Z from RH whined 
that they needed previous version. Arrrgh.. (finally, not 
wanting to break dependencies with using things like --nodeps, 
I compiled Postfix entirely myself, with everything in custom
directories - doesn't that defeat the very purpose of having 
the package system in the first place?).

This problem doesn't appear around that often, but when it 
does, it stinks, has warts, and bites you in the bottom.

Now suppose you have a single tree that Vietse blesses or 
not. The problem would never arise in the first place. 
You can't do it in Linux, but you (probably) can do it with
Python.

When you have it ALL in the single distro, released from time
to time, you can easily test it _together_. You don't 
get _temporal dependencies between various versions_.
The released, stable distro has the same things on the
same days, and either it all works together or it doesn't. 

When you depend on a tree of packages, some of which are present 
and some are not,  you _have_ to resolve dependencies like
above on the user's side. Which means development has to be
done for this, like with a dozen or so of online update programs for
Linux (went through it all, from small and primitive programs to
using rpmfind.net almost daily to up2date to yum, to finally arrive
in the near-paradise of apt). Which means some of the precious
and scarce time of developers has to be devoted to solving
unnecessary problem. 




--
It's a man's life in a Python Programming Association.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Embedding a restricted python interpreter

[Peter Maas]

Paul Rubin schrieb:
Best solution would probably be to create
a thread for each request that can operate only with the id of an
authenticated user. But this seems to be a problem with Apache or
with Linux?

Threads wouldn't do it--you'd need separate processes.  For example,
multiple threads in the same process can access each other's file
descriptors.  
You are probably talking about Unix-like systems. I googled for that
and found that on Windows threads inherit the security context of
their parent processes but can impersonate as another user after
being created. So it seems to be an OS issue.
--
---
Peter Maas,  M+R Infosysteme,  D-52070 Aachen,  Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
---
--
http://mail.python.org/mailman/listinfo/python-list

Getting rid of "self."

[BJörn Lindqvist]

I think it would be cool if you could refer to instance variables
without prefixing with "self." I know noone else thinks like me so
Python will never be changed, but maybe you can already do it with
Python today?

.import sys
.
.def magic():
.s = ""
.for var in sys._getframe(1).f_locals["self"].__dict__:
.s += var + " = self." + var + "\n"
.return s
.
.class A:
.def __init__(self):
.self.hi = "yo"
.
.def meth(self):
.exec(magic())
.print hi
.
.a = A()
.a.meth()

It works! exec(magic()) does the needed hi = self.hi. Not so
impressive in this case but much cooler when there is more instance
variables around. But the solution is very ugly because you have to
write exec(magic()) in every method. So I'm asking here if someone
knows a better way, maybe using decorators or metaclasses or other
black magic?


-- 
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list

Python application extending, plugins

[John Pote]

Hi,

Has anyone any thoughts on structuring a program so that it can be extended 
simply and elegantly by a user who only has a compiled (.pyc) version of the 
application?

I wish to write an application, myApp, that provides a GUI to, amongst other 
things, a simulator implimented as a class. myApp's simulator may then be 
extended by more python code to produce what is effectively 'myApp2'. The 
simulator might then be further extended from myApp2 to myApp3 in a similar 
manor. Don't think there would be much call, if at all, to go beyond myApp3 
level. But who knows!

Any thoughts would be appreciated.

John Pote 


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

Re: 2 versions of python on 1 machine

[flupke]

Peter Hansen wrote:

On my machine, I have a folder called c:\bin where I put useful
batch files.  I have a python23.bat and a python24.bat file,
which basically just call c:\python23\python.exe or
c:\python24\python.exe as required.  For various reasons which
may or may not apply to you as well, I also have each of them
set the PYTHONHOME variable to point to the right folder
as well.
The content of each batch file is like this:
@echo off
c:\python23\python.exe %1 %2 %3 %4 %5 %6 %7 %8 %9
-Peter
I used the 2 batch files technique and removed c:\python23 from my
path var and all is fine now.
Where did you find more info on PYTHONHOME and PYTHONPATH because
the docs don't seem to contain a whole lot of info.
Thanks
Benedict
--
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[Jacek Generowicz]

"Anna" <[EMAIL PROTECTED]> writes:

> Having taken some calculus (derivatives, limits, some integrals) but
> never even heard of lambda calculus, to me, lambda means absolutely
> NOTHING. Less than nothing.

And before you took calculus, the chances are that derivatives, limits
and integrals meant less than nothing to you.

But now, I am quite sure, you know that in Python lambda is a keyword
which creates anonymous functions. Now that you know what lambda does,
what's the problem with it? (It certainly doesn't mean "Less than
nothing" to you now.)

> So, I guess I don't like the word itself

Fair enough. I guess there are people out there who might have a
distaste for the word "class" or "def" or any of the other words which
are keywords in Python.

> Every other word in Python has an obvious meaning.  lambda doesn't.

Obvious to whom?

The meaning of every word is obvious, once you have been taught it;
and a complete mystery if you have not.

What do you make of "seq[2:-2]"? It means "less than nothing" to the
uninitiated. Just like lambda.

Getting students in my Python courses to understand "seq[2:-2]" takes
about as much (maybe even a bit more) effort as getting them to
understand lambda[*]. But once they have been taught these features,
they can handle them just fine.


[*] Funnily enough, getting them to understand that "lambda x: fn(x)"
is just a very silly way of writing "fn", can be quite a struggle
at times ... but that's probably a consequence of the context in
which lambda is introduced.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Operating System???

[Stephen Kellett]

In message <[EMAIL PROTECTED]>, Christopher 
Koppler <[EMAIL PROTECTED]> writes
Still, Java feels like C++ done right, while being more wrong >:-[
Couldn't disagree more. Just about anything you want to do that is 
low-level, is impossible in Java. Anyway this is off-topic.

Stephen
--
Stephen Kellett
Object Media Limitedhttp://www.objmedia.demon.co.uk
RSI Information:http://www.objmedia.demon.co.uk/rsi.html
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python Operating System???

[Stephen Kellett]

In message <[EMAIL PROTECTED]>, Arich 
Chanachai <[EMAIL PROTECTED]> writes
think).  Or what about D?
Digital Mars have a D compiler.
http://www.digitalmars.com
Stephen
--
Stephen Kellett
Object Media Limitedhttp://www.objmedia.demon.co.uk
RSI Information:http://www.objmedia.demon.co.uk/rsi.html
--
http://mail.python.org/mailman/listinfo/python-list

Re: Getting rid of "self."

[Bruno Desthuilliers]

BJörn Lindqvist a écrit :
I think it would be cool if you could refer to instance variables
without prefixing with "self." I know noone else thinks like me so
Python will never be changed, but maybe you can already do it with
Python today?
(snip code)
It works! exec(magic()) does the needed hi = self.hi. Not so
impressive in this case but much cooler when there is more instance
variables around. But the solution is very ugly because you have to
write exec(magic()) in every method. So I'm asking here if someone
knows a better way, maybe using decorators or metaclasses or other
black magic?
The better way is definitively to forget about black magic and 
understand why mandatory 'self' is Good Thing (tm).

(Tip : even when [this|self|@|whatsoever] is not mandatory, using it 
makes for much more readable code.)

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

Re: Python evolution: Unease

[Alex Martelli]

Paul Rubin  wrote:
   ...
> > GUI/IDEs for Python, 
> 
> I remember there was a gud interface for Python but it didn't work
> pretty well.  There's also IDLE which is pretty crude and flaky.  I
> think I'll just wait for Pypy deployment before worrying about this
> situation too much.  Is there something else I can download?

eric3 seems pretty good.


> > Python add-ons such as numarray,
> > gmpy, ctypes, ...) -- all of those you still have to download and
> > install, just as you would for the satanware.
> 
> That's unfortunate, that stuff should be included with Python.

numarray aims to be, WHEN they will be sufficiently complete and stable.
As for predictions of when that will be, I'm not qualified to offer one.

I think ctypes would be a _great_ addition to the standard Python
library in 2.5, if Thomas Heller agrees.

gmpy is LGPL (because so is the GMP library that gmpy wraps and
extends), so that including it with the standard Python library is very
iffy/problematic.  As gmpy's author I'd be delighted to do anything
possible to help this happen, but it just doesn't seem likely.  Besides,
I wonder how large a fraction of Python's user base really needs
something as specialized as gmpy -- unlimited-precision integers which
are _slightly_ faster than Python 2.4's built-in longs and offer a few
more highly specialized functions, etc.

Even if all of these were included in Python 2.5, how long will it be
before standard distributions and operating systems start including 2.5?

I don't agree with your general stance that the standard Python
distribution should be "sumo", including _everything_ that could
possibly be of _some_ interest to _some_ Python users, or thereabouts.
"Sumo distributions" have their place; enthought currently makes an
excellent one for scientific use of Python on Windows, and, I hear, it
is planning a similar one for Macintosh.  But the vast majority of
what's in it will be of no interest to somebody who doesn't care for
scientific applications -- and it will STILL be missing something that
some scientific users might like, such as gmpy.

Moreover, it's important to distinguish between standard Python, and
enriched distributions made of components that grow and change at
different speeds and with different groups of maintainers -- just the
same important distinction that must be drawn between Linux, and any of
the many distributions based on and including Linux.  Asking standard
Python to include dozens of third-party modules is just as silly as
asking the Linux kernel to be distributed with, say, gimp... anybody's
free to make a distribution including several components, but it's best
for the various components, including the core ones, to stay separate.


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

Re: Asyncore

[Jp Calderone]

On 7 Jan 2005 00:14:26 -0800, [EMAIL PROTECTED] wrote:
>Is there any tutorial and docs with samples how to use asyncore module?

  See these threads:
http://mail.python.org/pipermail/python-list/2004-March/214105.html

http://mail.python.org/pipermail/python-dev/2004-November/049819.html

  Then check out:

http://www.twistedmatrix.com/

  Hope this helps,

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

countint words from an input string

[Øystein Western]

Hello!

Try to write som code that will get an input string from the user. Futher 
more, I'd like to have the program to count all the word the user has 
written.

Startet out like this:

/-
s = raw_input("Write a text line")
print s.split()
/

How can I count the words in the split function. Do I have to use the split 
function to count the words in the S variable?

Regards
Frengky

-- 
Organisation nr: 983063349
Frengky, Olsokveien 65,1727 Sarpsborg, Norway
Tel: +47 92611725
Fax: +47 69152017
Email: [EMAIL PROTECTED]
Web: www.frengky.no


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

Re: countint words from an input string

[Simon Brunning]

On Fri, 7 Jan 2005 15:58:06 +0100, Øystein Western <[EMAIL PROTECTED]> wrote:
> Try to write som code that will get an input string from the user. Futher
> more, I'd like to have the program to count all the word the user has
> written.
> 
> Startet out like this:
> 
> /-
> s = raw_input("Write a text line")
> print s.split()
> /
> 
> How can I count the words in the split function.

print 'You've entered', len(s.split()), 'words.'

BTW, though newbie questions are quite welcome here, you might find it
beneficial to run through the Python tutorial (at
http://docs.python.org/tut/tut.html and included in the standard
distribution), and to join the tutor mailing list (at
http://mail.python.org/mailman/listinfo/tutor/).

-- 
Cheers,
Simon B,
[EMAIL PROTECTED],
http://www.brunningonline.net/simon/blog/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Getting rid of "self."

[Nick Coghlan]

BJörn Lindqvist wrote:
So I'm asking here if someone
knows a better way, maybe using decorators or metaclasses or other
black magic?
Wait for Python 3k when this will work:
class c:
  def __init__(self):
with self:
  .x = 1
  .y = 2
  .hi = "Hi there!"
Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: 2 versions of python on 1 machine

[Nick Coghlan]

flupke wrote:
Peter Hansen wrote:
The content of each batch file is like this:
@echo off
c:\python23\python.exe %1 %2 %3 %4 %5 %6 %7 %8 %9
More recent versions of Windows should allow you to use %* for "all the 
arguments to the batch file".

Where did you find more info on PYTHONHOME and PYTHONPATH because
the docs don't seem to contain a whole lot of info.
I think PYTHONPATH is discussed in the tutorial. PYTHONHOME, I'm not so sure on 
(PYTHONPATH and PYTHONSTARTUP are the only two you're likely to care about, 
though - and I think the Tutorial covers both of them).

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: sorting on keys in a list of dicts

[Nick Coghlan]

Jeff Shannon wrote:
I suppose that your version has the virtue that, if the sortkey value is 
equal, items retain the order that they were in the original list, 
whereas my version will sort them into an essentially arbitrary order. 
 Is there anything else that I'm missing here?
Stability in sorting is a property not to be sneezed at - it means switching to 
sorting by a second key gives the effect of "sort by key 1, then by key 2", 
whereas that doesn't hold with an unstable sort algorithm. If you've ever used 
an application with an unstable sorting process and that only allows sorting a 
table on one column at a time, you'll appreciate the frustration that can cause :)

Also, it's required to match the behaviour of the Python 2.4 version (which gets 
to take advantage of the stability of the builtin sort).

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[Steven Bethard]

Alan Gauld wrote:
On Thu, 06 Jan 2005 21:02:46 -0600, Doug Holton <[EMAIL PROTECTED]> wrote:
used, but there are people who do not like "lambda":
http://lambda-the-ultimate.org/node/view/419#comment-3069
The word "lambda" is meaningless to most people.  Of course so is "def", 
which might be why Guido van Robot changed it to "define": 
http://gvr.sourceforge.net/screen_shots/

The unfamiliar argument doesn't work for me. After all most
people are unfamiliar with complex numbers (or imaginary) numbers
but python still provides a complex number type. Just because the
name is unfamiliar to some doesn't mean we shouldn't use the
term if its the correct one for the concept.
I'm not sure this is really a fair comparison.  What's the odds that if 
you're unfamiliar with complex numbers that you're going to have to read 
or write code that uses complex numbers?  Probably pretty low.  I don't 
think I've ever had to read or write such code, and I *do* understand 
complex numbers.  Lambdas, on the other hand, show up in all kinds of 
code, and even though I hardly ever use them myself, I have to 
understand them because other people do (over-)use them.

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

Re: Securing a future for anonymous functions in Python

[Nick Coghlan]

Jacek Generowicz wrote:
[*] Funnily enough, getting them to understand that "lambda x: fn(x)"
is just a very silly way of writing "fn", can be quite a struggle
at times ... but that's probably a consequence of the context in
which lambda is introduced.
If you genuinely taught them that, you may have done them a disservice:
Py> def f(x):
...print x
...
Py> f1 = f
Py> f2 = lambda x: f(x)
Py> f1("hi")
hi
Py> f2("hi")
hi
Py> def f(x):
...   print x * 2
...
Py> f1("hi")
hi
Py> f2("hi")
hihi
Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: Calling Function Without Parentheses!

[Kamilche]

Yeah, but still. If they even had the most basic check, like 'an object
is being referred to on this line, but you're not doing anything with
it' would be handy in catching that. When you use an object like that,
usually you're doing something with it, like assigning it to a variable.

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

Re: Securing a future for anonymous functions in Python

[Nick Coghlan]

Paul Rubin wrote:
"Anna" <[EMAIL PROTECTED]> writes:
Having taken some calculus (derivatives, limits, some integrals) but
never even heard of lambda calculus, to me, lambda means absolutely
NOTHING. Less than nothing.

Lambda calculus is from mathematical logic, but more to the point
"lambda" has been the term used in Lisp for this operation since time
immemorial.
I think that's part of the problem though - people familiar with lambda calculus 
and Lisp's lambdas want Python's lambdas to be equally capable, and they just 
plain *aren't*.

If you have a complex function, the Pythonic way is to give it a meaningful 
name. Having a way to defer evaluation of a simple expression *is* quite handy, 
but 'lambda' is the wrong name for it - the parallels to lambda calculus and 
Lisp's lambda functions are likely to be misleading, rather than helpful.

Add in the fact that there are many, many Python programmers with non-CS 
backgrounds, and the term 'lambda' sticks out like a sore thumb from amongst 
Python's other English-based keywords. 'def' is probably the second-most cryptic 
when you first encounter it, but it is a good mnemonic for "define a function", 
so it's still easy to parse. "Lambda is the term mathematicians use to refer to 
an anonymous function" is nowhere near as grokkable ;)

For me, the alternative syntax discussion is based on 3 of the 4 mentioned 
reasons:
1. The syntax
  I don't like re-using colons as something other than suite delimiters - it 
breaks up the affected expression too much (particularly function calls). Code 
with dict literals inside function calls bugs me for the same reason (it's OK 
when the literal is separated out into an assignment statement for the dict).
  It's also too easy to write lambdas which look ambiguous, even though they 
technically aren't.
  Finally, Python has a reputation as "executable pseudocode". Lambda 
expressions don't read like any sort of psuedocode you're likely to see outside 
a maths department.

2. The limitation to a single expression
  I consider this no more of a problem than the restriction to a single 
expression in the main loop of a generator expression or a list comprehension. 
When those get too complicated, you switch to using a real for loop somewhere. 
Deferred expressions are no different - when the guts get too complicated, 
switch to a named function.

3. The word 'lambda' itself
  This _is_ one of my objections for the reasons stated above: for people 
unfamiliar with the term, they don't know what it is; for people familiar with 
the term, it isn't what they think it should be.
  Python already has a perfectly good keyword for functions, which has the 
additional virtue of being half the length of lambda (this matters, since this 
is a keyword that gets embedded in expressions - all the other keywords 
currently in that category are three letters or less: and, or, is, in, for)

4. People complaining about 2
  Oh hell yes, this bugs me. And I think changing the syntax and calling them 
"deferred expressions" instead of "lambdas" would go a long way towards 
eliminating the griping.

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: missing sys.setappdefaultencoding

[Craig Ringer]

On Fri, 2005-01-07 at 19:06, Alex Martelli wrote:
> Uwe Mayer <[EMAIL PROTECTED]> wrote:

> > well, I wrote a nice python program which won't work if the default encoding
> > has not been set from ascii to latin-1 or latin-15.
> 
> Then your program is not very nice...;-)

Agreed. I prefer to use explicit str.encode(), str.decode() and
unicode() calls where appropriate.

On a side note, PEP 263 handles the text encoding interpretation of
Python program source, and is well worth reading and following.

http://python.org/peps/pep-0263.html

--
Craig Ringer

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

[Pyro] Newbie Question Regarding Pyro

[John French]

I'm putting together a new project which I'm using to learn Python and have 
questions about pyro. I like the idea of the abstraction that pyro offers 
from sockets programming but I cannot determine if I'm giving up some 
possibly needed functionality.

If the server needs to send an unsolicited ad hoc message to a given client, 
is this possible? (New message or a reminder, for instance) I suppose I 
could poll a server side list from the client but I'm wondering if the 
server can initiate the exchange.

Also, if a client wishes to converse with another particular client (in a 
chat or IM situation, for instance). What's a good mechanism for this?

Does pyro create a persistent client/server connection? What happens if a 
pyro client goes down hard? Does it's process continue or is there a cleanup 
mechanism?

Thanks in advance.


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

Re: Getting rid of "self."

[Luis M. Gonzalez]

You can do it easier now without any black magic:

class c:
def __init__(s):
s.x = 1
s.y = 2
s.hi = "Hi there!"

The word "self" is not mandatory. You can type anything you want
instead of self, as long as you supply a keyword in its place (it can
be "self", "s" or whatever you want).

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

Re: Getting rid of "self."

[Simon Brunning]

On 7 Jan 2005 08:10:14 -0800, Luis M. Gonzalez <[EMAIL PROTECTED]> wrote:
> The word "self" is not mandatory. You can type anything you want
> instead of self, as long as you supply a keyword in its place (it can
> be "self", "s" or whatever you want).

You *can*, yes, but please don't, not if there's any chance that
anyone other than you are going to have to look at your code.
'self.whatever' is clearly an instance attribute. 's.whatever' isn't
clearly anything - the reader will have to go off and work out what
the 's' object is.

The self prefix is a perfectly good convention. Let's stick to it.

-- 
Cheers,
Simon B,
[EMAIL PROTECTED],
http://www.brunningonline.net/simon/blog/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Please Contribute Python Documentation!

[Nick Coghlan]

Skip Montanaro wrote:
Fred Drake releases new development versions of the docs frequently
(typically once every month or two).  I normally use the development docs
instead of the regular ones for my day-to-day work.  They are available
here:
http://www.python.org/dev/doc/devel/
It's useful to check to see the most current status of the docs.  The only
thing more current is the source in CVS.
Although, when working this way, and Python's behaviour seems to contradict the 
documentation, don't forget to check the docs specific to your version of Python 
before submitting a bug report :)

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Scott David Daniels]

Terry Reedy wrote:
Even though I currently only have 80 ... I realize that my stinginess
> with disk space for more serious stuff is obsolete.  A gigabyte would
> cover Python + Wxpython + numarray + scipy + pygame + a lot
of other stuff.
Would it be possible, at least for Windows, to write a Python script 
implementing a 'virtual distribution'?  
> IE, download Python, install it, download next package, install it,
> etc. -- prefereably table driven?
I would suggest looking to the Enthought distribution as a reasonable
base (gets you an awful lot).  Enthought has a _large_ collection,
covering a lot of stuff that has general utility.  Their production
stuff is still at Python 2.3.3, but I believe they have a 2.4 version
coming soon.  The list of what they put in the 2.3.3 package is truly
impressive:
wxPython, PIL, VTK, MayaVi, Numeric, SciPy, ScientificPython,
F2PY, Chaco, Traits, PyCrust, ZODB, Gadfly, PySQLite, and ctypes.
All for one sub-90-Meg download.  I add VPython to get dirt-simple 3-D
stuff; you'd probably add pygame.  The key to this is Enthought's
attention to testing a stable "sumo" collection.  I add a few packages
that are much more anachronistic.  My thought basically is that, since
I want at least four of the packages, getting a "blessed" superset eases
my installation woes.
If you can wait, the plan for MacEnthon (Python 2.4 on Mac) looks great:
http://www.scipy.org/wikis/featurerequests/MacEnthon
I seem to remember discussion about synchronizing with the windows 2.4
version to have essentially the same list.
--Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

RE: [Pyro] Newbie Question Regarding Pyro

[Tim Golden]

[John French]
| I'm putting together a new project which I'm using to learn 
| Python and have questions about pyro. 

You're welcome to ask here, but you might find that
posting on Pyro's own mailing list produces answers
from people who don't follow c.l.py's higher traffic.

| If the server needs to send an unsolicited ad hoc message to 
| a given client, is this possible? 
| (New message or a reminder, for instance) I suppose I 
| could poll a server side list from the client but I'm 
| wondering if the server can initiate the exchange.

I think you want to look at the Pyro's Event server, 
but be careful with terms like Server and Client, because 
they aren't always so straightforward in the Pyro context.

| Also, if a client wishes to converse with another particular 
| client (in a chat or IM situation, for instance). 
| What's a good mechanism for this?

There are two things here: finding out what "client" (Pyro
object) is out there; and communicating with it. To take
the second one first, once you've found it, you *are*
talking directly to it, so that's fine. To address the
first point, though, finding it can either be through the
nameserver, which is generally preferable since that's
what it's there for, or -- if you know the other object's
location and name -- by using the PYROLOC:// mechanism.

The only thing with this second approach is that you're
likely to find yourself reinventing the name server as
you try to keep track of who's "on-line" etc. (assuming
your typical IM situation). So I'd recommend going for
the nameserver if possible.

| Does pyro create a persistent client/server connection? What 
| happens if a pyro client goes down hard? Does it's process 
| continue or is there a cleanup mechanism?

Hmmm. A little bit involved the answer to this one. In essence, 
once you've got hold of another object via Pyro it's down to 
the network to get the message through. If the other end goes
down, you can trap the Exceptions coming back and clean up
as you see fit. The Pyro plumbing does support an auto-reconnect 
mechanism for Pyro objects. The details escape me now -- I've
never used it myself -- but I seem to remember that you restart
your object and its daemon (ie server bit) telling it to reconnect
as well as it can. There's no persistence involved (unless you've
implemented something yourself) so you'll have to clean up whatever
mess there was left over as you come back up.

Hope all that helps.

TJG


This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk

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

Re: sorting on keys in a list of dicts

[It's me]

What does it mean by "stability in sorting"?

Can somebody please give a sample for using the code posted?  I am a little
lost here and I like to know more about the use of keys

Thanks,

"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Jeff Shannon wrote:
> > I suppose that your version has the virtue that, if the sortkey value is
> > equal, items retain the order that they were in the original list,
> > whereas my version will sort them into an essentially arbitrary order.
> >  Is there anything else that I'm missing here?
>
> Stability in sorting is a property not to be sneezed at - it means
switching to
> sorting by a second key gives the effect of "sort by key 1, then by key
2",
> whereas that doesn't hold with an unstable sort algorithm. If you've ever
used
> an application with an unstable sorting process and that only allows
sorting a
> table on one column at a time, you'll appreciate the frustration that can
cause :)
>
> Also, it's required to match the behaviour of the Python 2.4 version
(which gets
> to take advantage of the stability of the builtin sort).
>
> Cheers,
> Nick.
>
> -- 
> Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
> ---
>  http://boredomandlaziness.skystorm.net


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

Re: Getting rid of "self."

[Roy Smith]

Simon Brunning  <[EMAIL PROTECTED]> wrote:
>On 7 Jan 2005 08:10:14 -0800, Luis M. Gonzalez <[EMAIL PROTECTED]> wrote:
>> The word "self" is not mandatory. You can type anything you want
>> instead of self, as long as you supply a keyword in its place (it can
>> be "self", "s" or whatever you want).
>
>You *can*, yes, but please don't, not if there's any chance that
>anyone other than you are going to have to look at your code.
>'self.whatever' is clearly an instance attribute. 's.whatever' isn't
>clearly anything - the reader will have to go off and work out what
>the 's' object is.

+1.

If there is one coding convention which is constant through the Python
world, it's that the first argument to a class method is named
"self".  Using anything else, while legal, is just being different for
the sake of being different.
-- 
http://mail.python.org/mailman/listinfo/python-list

function field in logging formatting

[vmalloc]

Hi all.

I don't know if this topic has been proposed yet, but I'll try anyways.
I thought it would be nice for the built-in version of the logging
package (which, I might add, is excellent) to contain a "function"
formatting field for log output. It wouldn't be so hard to implement,
and it certainly can serve all those out there who've been using this
package for debugging, too.
What do you think? can this make a PEP?

Rotem

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

Re: Getting rid of "self."

[John Roth]

"BJörn Lindqvist" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
I think it would be cool if you could refer to instance variables
without prefixing with "self." I know noone else thinks like me so
Python will never be changed, but maybe you can already do it with
Python today?

...
It works! exec(magic()) does the needed hi = self.hi. Not so
impressive in this case but much cooler when there is more instance
variables around. But the solution is very ugly because you have to
write exec(magic()) in every method. So I'm asking here if someone
knows a better way, maybe using decorators or metaclasses or other
black magic?
[response]
Having to specify the instance explicitly is something that
Python needs because it isn't a statically typed language.
In a statically typed language, all variables are pre-declared,
so the compiler knows where they all are.
Python's compiler knows about local variables. It
doesn't know where any other variables are, so it
has to search. Including the instance as one of the
method parameters means that the search splits
right at the front: either it starts looking up the
instance, or it goes up the definition chain (usually
empty) to the module namespace and then the
builtins.
Eliminating "self" would mean it would have to
either search the instance before the module and
builtins, or search the module and builtins before
the instance. This is both a performance issue
and a maintenance issue because of the increased
possibility of one shadowing the other.
This is distinct from the issue of how to spell
"self". As another responder has already said,
you can spell it any way you want; it's simply
whatever you choose to call the first paramteter
to the method.
Going the other way, the word "self" could become
a keyword, removing the necessity of specifying it
among the method parameters. While I like the idea,
there's enough dislike of the notion that it's not going
to happen.
John Roth
--
mvh Björn 

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

Re: Getting rid of "self."

[Michael Hobbs]

Nick Coghlan <[EMAIL PROTECTED]> wrote:
> 
> Wait for Python 3k when this will work:
> 
> class c:
>   def __init__(self):
> with self:
>   .x = 1
>   .y = 2
>   .hi = "Hi there!"

Python is looking more like JavaScript every day...

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

Packaging, dependencies and rates of development

[Nick Coghlan]

Bulba! wrote:
When you have it ALL in the single distro, released from time
to time, you can easily test it _together_. You don't 
get _temporal dependencies between various versions_.
The released, stable distro has the same things on the
same days, and either it all works together or it doesn't. 
Except that the difference between the distro maintainers' opinion of what is 
"stable enough" for inclusion, and the updated version of that module which has 
some stability problems in areas you don't use but fixes a critical bug in the 
areas you *do* use is always going to be a problem that has to be dealt with.

That's one of the reasons numarray hasn't hit the standard library yet - the 
Python version release and uptake cycle is too slow for the pace of development 
they currently require.

Similarly, this is also part of the reason IDLE went the way of IDLEFork before 
being merged back in 2.3 - the development outside the core tree let Kurt and 
everyone else involved get it up to speed more quickly.

There's also the fact that monolithic approaches just plain don't scale - 
imagining that they can is exactly what leads to the version conflicts that bug 
you so much, since developers assume that they don't need to care about 
versioning issues, because the packagers will take care of them. In reality, all 
it does is move the version conflicts currently noticed by end users and make 
the packagers try to deal with them instead - and for some of the problems, 
side-by-side installation of multiple version is the only solution, and that's 
impossible in the general case without the modules in question providing some 
versioning mechanism. And so, once again, we're left with developers having to 
worry about dependency issues.

For an example of a well-thought out approach to the versioning issue, take a 
look at the work that was done for the recent wxPython release:
http://wiki.wxpython.org/index.cgi/MultiVersionInstalls

What would be ideal is if distutils itself was able to offer a standard package 
versioning system. Then all module developers would have to do is be aware of 
how to use the distutils versioning system, and installing side-by-side versions 
of packages would be create straightforward.

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: Getting rid of "self."

[BJörn Lindqvist]

Thank you for your replies. But they don't deal with my original
question. :) I have read the thousands of posts all saying "self is
good" and they are right. But this time I want to be different m-kay?
I figure that there might be some way to solve my problem by doing
this:

.def instancevar2locals(method):
.# Do something magic here so that exec(magic()) is automagically
run each time
.# the function is invoked.
.newmethod = method
.return newmethod

And then in the class definition something like this:

.class A:
.def __init__(self):
.self.hi = "hi"
.def meth(self):
.print hi
.meth = instancevar2locals(meth)

But beyond that, I have no idea and I would be grateful if someone
would like to help me with it.
-- 
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[Jacek Generowicz]

Nick Coghlan <[EMAIL PROTECTED]> writes:

> Jacek Generowicz wrote:
> > [*] Funnily enough, getting them to understand that "lambda x: fn(x)"
> > is just a very silly way of writing "fn", can be quite a struggle
> > at times ... but that's probably a consequence of the context in
> > which lambda is introduced.
> 
> If you genuinely taught them that, you may have done them a disservice:

Yes, I was wondering whether I should add lots of caveats to the above.

> Py> def f(x):
> ...print x
> ...
> Py> f1 = f
> Py> f2 = lambda x: f(x)
> Py> f1("hi")
> hi
> Py> f2("hi")
> hi
> Py> def f(x):
> ...   print x * 2
> ...
> Py> f1("hi")
> hi
> Py> f2("hi")
> hihi

There are far less contrived situations in which my original statement
(taken at face value) is wrong. Functions with optional arguments, for
example.

What actually happens is that some of them end up writing:

lambda x: int(x)

in a situation where they want to specify something which will perform
conversions of the type:

"123" -> 123   

ie, string to integer conversions.

Usually one or two have trouble grasping that "int" would be perfectly
adequate in this situation.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Getting rid of "self."

[John Roth]

"Roy Smith" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Simon Brunning  <[EMAIL PROTECTED]> wrote:
On 7 Jan 2005 08:10:14 -0800, Luis M. Gonzalez <[EMAIL PROTECTED]> wrote:
The word "self" is not mandatory. You can type anything you want
instead of self, as long as you supply a keyword in its place (it can
be "self", "s" or whatever you want).
You *can*, yes, but please don't, not if there's any chance that
anyone other than you are going to have to look at your code.
'self.whatever' is clearly an instance attribute. 's.whatever' isn't
clearly anything - the reader will have to go off and work out what
the 's' object is.
+1.
If there is one coding convention which is constant through the Python
world, it's that the first argument to a class method is named
"self".  Using anything else, while legal, is just being different for
the sake of being different.
Didn't you mean instance method? Class methods are a different
beast, and the few examples I've seen seem to use the word "klas".
John Roth 

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

Re: Python Operating System???

[Michael Hobbs]

David Brown <[EMAIL PROTECTED]> wrote:
> Hello. I recently came across a free operating system called Unununium (or
> something like that) and it was developed in Python and Assembly.
> 
> Now, I have been looking for a way to make an operating system for a long
> long time and the only possibilities I could find were C++ and assembly. 

The problem when using Python instead of C for OS development is that
C was *specifically designed* to create an OS, while Python was designed
for completely different purposes. If you want to write an OS, it would
be wise to use a language that is suited for that purpose. If you
dislike C so much and prefer Python so much more, your first step should
be to design a Python dialect that is more appropriate for writing OS's.

(I know that you mentioned C++, not C, but I decided to setup C as a
straw-man to make my argument.)

- Mike

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

Re: sorting on keys in a list of dicts

[Craig Ringer]

On Sat, 2005-01-08 at 00:26, It's me wrote:
> What does it mean by "stability in sorting"?

If I understand correctly, it means that when two sorts are performed in
sequence, the keys that are equal to the second sort end up ordered the
way they were left by the first sort.

I'm far from certain of this, but at least I'm presenting an opportunity
for someone to yell "no, you're wrong!" and in the process definitively
answer the question.

For example, given the list:

.>>> l = [(1,2), (8,2), (2,2), (3,2), (4,3), (5,3), (8,9)]

if we sort by the first element of each tuple then the second (the
default), we get:

.>>> l.sort()
.>>> l
[(1, 2), (2, 2), (3, 2), (4, 3), (5, 3), (8, 2), (8, 9)]

Now, if we sort based on the second element we get:

.>>> def seconditem(x):
 return x[1]

.>>> l.sort(key=seconditem)
.>>> l
[(1, 2), (2, 2), (3, 2), (8, 2), (4, 3), (5, 3), (8, 9)]

You'll note that there are several correct answers to the request "sort
the list 'l' by the second element of each item", including:

[(1, 2), (2, 2), (3, 2), (8, 2), (4, 3), (5, 3), (8, 9)]
[(2, 2), (1, 2), (8, 2), (3, 2), (4, 3), (5, 3), (8, 9)]
[(1, 2), (2, 2), (3, 2), (8, 2), (5, 3), (4, 3), (8, 9)]

and many others. Because we didn't specify that the first item in the
value tuples should be used in the sort key, so long as the second key
is equal for a group of items it doesn't matter what order items in that
group appear in.

Python (at least 2.4), however, returns those groups where the order
isn't defined in the same order they were before the sort. Look at this,
for example:

.>>> l.sort()
.>>> l.reverse()
.>>> l
[(8, 9), (8, 2), (5, 3), (4, 3), (3, 2), (2, 2), (1, 2)]
.>>> l.sort(key=seconditem)
.>>> l
[(8, 2), (3, 2), (2, 2), (1, 2), (5, 3), (4, 3), (8, 9)]

See how the exact same sort command was used this time around, but
because the list was reverse-sorted first, the elements are in reverse
order by first item when the second item is equal?

In the first case we used the same result as the stable sort could be
obtained with:

.>>> def revitem(x):
 return (x[1], x[0])
>>> l.sort(key=revitem)
>>> l
[(1, 2), (2, 2), (3, 2), (8, 2), (4, 3), (5, 3), (8, 9)]

(in other words, saying "use the value tuple as the sort key, but sort
by the second element before the first")

That doesn't extend to more complex cases very well though. Imagine you
had 3-tuples not 2-tuples, and wanted to maintain the previous sort
order of equal groupings when re-sorting by a different key... but you
didn't know what key was last used for sorting. A stable sort algorithm
means you don't need to care, because the order will be maintained for
you not randomized.

Well, that's several hundred more words than were probably required, but
I hope I made sense.

--
Craig Ringer

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

how to extract columns like awk $1 $5

[Anand S Bisen]

Hi
Is there a simple way to extract words speerated by a space in python 
the way i do it in awk '{print $4 $5}' . I am sure there should be some 
but i dont know it.

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

Re: sorting on keys in a list of dicts

[Nick Coghlan]

It's me wrote:
What does it mean by "stability in sorting"?
Can somebody please give a sample for using the code posted?  I am a little
lost here and I like to know more about the use of keys
It's the jargon for what Jeff said - if you are sorting by some value calculated 
from each list entry, and different list entries may give the same value, then a 
stable sort guarantees that the order of entries giving the same value will be 
preserved from the original list.

Consider:
Py> from operator import itemgetter as item
Py> seq = [(1, 1), (2, 1), (2, 3), (1, 5)]
Py> seq.sort(key=item(1))
Py> seq #1
[(1, 1), (2, 1), (2, 3), (1, 5)]
Py> seq.sort(reverse=True)
Py> seq #2
[(2, 3), (2, 1), (1, 5), (1, 1)]
Py> seq.sort(key=item(1))
Py> seq #3
[(2, 1), (1, 1), (2, 3), (1, 5)]
This snippet sorts the tuples according to the second item, then sorts them in 
reverse order of the whole tuple, then resorts them according to the second item.

Notice that the order of the first two items is different between point #1 and 
point #3. This is because sorting by the second item makes no distinction 
between these two tuples, and they retain whatever order they had before the 
sort began.

This is what it means to have a stable sort, and it makes expressing complex 
sorting quite easy by chaining different sort operations together.

Python 2.3 has a stable sort, and Python 2.4 brought the guarantee that it shall 
remain that way. I'm not sure about Python 2.2 and earlier.

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: The Industry choice

[Bulba!]

On 6 Jan 2005 19:01:46 -0500, [EMAIL PROTECTED] (Aahz) wrote:

>>Note that the so-called 'viral' nature of GPL code only applies to 
>>*modifications you make* to the GPL software.  The *only* way in which 
>>your code can be 'infected' by the GPL is if you copy GPL source.

>That's not true -- consider linking to a GPL library.

Will someone please explain to me in simple terms what's
the difference between linking to LGPLed library and linking
to GPLed library - obviously in terms of consequences of
what happens to _your_ source code?

Because if there isn't any, why bother with distinguishing 
between the two?

Oh, and by the way - since Python bytecode can be relatively
easily decompiled to source, could it interpreted to "really" 
count as source code and not binary? What are the consequences 
of releasing code  _written in Python_  as GPLed?

Licenses are frigging cans of worms..




--
It's a man's life in a Python Programming Association.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Getting rid of "self."

[Roy Smith]

In article <[EMAIL PROTECTED]>,
John Roth <[EMAIL PROTECTED]> wrote:
>
>"Roy Smith" <[EMAIL PROTECTED]> wrote in message 
>news:[EMAIL PROTECTED]
>> Simon Brunning  <[EMAIL PROTECTED]> wrote:
>>>On 7 Jan 2005 08:10:14 -0800, Luis M. Gonzalez <[EMAIL PROTECTED]> wrote:
 The word "self" is not mandatory. You can type anything you want
 instead of self, as long as you supply a keyword in its place (it can
 be "self", "s" or whatever you want).
>>>
>>>You *can*, yes, but please don't, not if there's any chance that
>>>anyone other than you are going to have to look at your code.
>>>'self.whatever' is clearly an instance attribute. 's.whatever' isn't
>>>clearly anything - the reader will have to go off and work out what
>>>the 's' object is.
>>
>> +1.
>>
>> If there is one coding convention which is constant through the Python
>> world, it's that the first argument to a class method is named
>> "self".  Using anything else, while legal, is just being different for
>> the sake of being different.
>
>Didn't you mean instance method? Class methods are a different
>beast, and the few examples I've seen seem to use the word "klas".

Sorry, yes.  My bad.

I used to work with a C++ guy who always used "class" when he should
have used "instance".  It drove me crazy. :-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Notification of PEP Updates

[Nick Coghlan]

I can't recall which thread this came up in, so I'm starting a new one. . .
Barry Warsaw has kindly added a "peps" topic to the python-checkins mailing 
list. If you want to be notified only when PEP's get updated, then subscribe to 
python-checkins and edit your settings to select just the 'peps' topic.

Let us know if it does anything odd (e.g. sending updates about other checkins)
The URL for the mailing list is:
http://mail.python.org/mailman/listinfo/python-checkins
I believe the mail you receive should contain the checkin messages, along with a 
summary of the differences between the old version and the new version (handy if 
you can read a context diff, not so handy otherwise).

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: sorting on keys in a list of dicts

[Tim Peters]

[Nick Coghlan]
...
> Python 2.3 has a stable sort, and Python 2.4 brought the guarantee that it 
> shall
> remain that way. I'm not sure about Python 2.2 and earlier.

No list.sort() implementation before 2.3 was stable.  It was
confusing, though, because the samplesort/binary_insertion_sort hybrid
Python used for the 4 years preceding 2.3 *was* stable for all "small
enough" lists.  More than one person got fooled by guessing that
stability observed in small test cases meant it was always stable.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: sorting on keys in a list of dicts

[Nick Coghlan]

Craig Ringer wrote:
Well, that's several hundred more words than were probably required, but
I hope I made sense.
Remarkably similar to what I just posted. . . I guess numeric 2-tuples are just 
too good to pass up when discussing sorting :)

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: how to extract columns like awk $1 $5

[Craig Ringer]

On Sat, 2005-01-08 at 01:15, Anand S Bisen wrote:
> Hi
> 
> Is there a simple way to extract words speerated by a space in python 
> the way i do it in awk '{print $4 $5}' . I am sure there should be some 
> but i dont know it.

The 'str.split' method is probably what you want:

.>>> x = "The confused frog mumbled something about foxes"
.>>> x.split()
['The', 'confused', 'frog', 'mumbled', 'something', 'about', 'foxes']
.>>> x.split(" ")[4:6]
['something', 'about']

so if 'x' is your string, the rough equivalent of that awk statement is:

.>>> x_words = x.split()
.>>> print x_words[4], x_words[5]

or perhaps

.>>> print "%s %s" % tuple(x.split()[4:6])

--
Craig Ringer

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

Re: sorting on keys in a list of dicts

[Scott David Daniels]

Jeff Shannon wrote:
Jp Calderone wrote:
L2 = [(d[key], i, d) for (i, d) in enumerate(L)]
L2.sort()
L = [d for (v, i, d) in L2]
Out of curiosity, any reason that you're including the index?
Others have already remarked that this preserves sort stability
(which is, in fact a lovely property).  There is another property
which hasn't been mentioned:
As written, only the key and the index are compared.
Try sorting:
tricky = [dict(a=5j, b=1), dict(a=4j, b=1)]
or:
similar = [(5j, 1), (4j, 1)]
without the index.
--Scott David Daniels
[EMAIL PROTECTED]

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

Re: how to extract columns like awk $1 $5

[beliavsky]

It takes a few more lines in Python, but you can do something like

for text in open("file.txt","r"):
words = text.split()
print words[4],words[5]
(assuming that awk starts counting from zero -- I forget).

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

Re: how to extract columns like awk $1 $5

[Jeremy Sanders]

On Fri, 07 Jan 2005 12:15:48 -0500, Anand S Bisen wrote:

> Is there a simple way to extract words speerated by a space in python 
> the way i do it in awk '{print $4 $5}' . I am sure there should be some 
> but i dont know it.

mystr = '1 2 3 4 5 6'
parts = mystr.split()
print parts[3:5]

Jeremy

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

Re: Securing a future for anonymous functions in Python

[Nick Coghlan]

Jacek Generowicz wrote:
Yes, I was wondering whether I should add lots of caveats to the above.
I thought that might be the case. When teaching, I guess I can understand the 
need to avoid "well, technically, this isn't always true". It sounds like the 
students were having a tough enough time of it already :)

Usually one or two have trouble grasping that "int" would be perfectly
adequate in this situation.
The ability to pass around functions at run-time was probably the hardest thing 
to get my head around when I started with Python, after a history of working in 
languages where "the compiler knows about types and functions, and the runtime 
knows about variables and instances".

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Working with recordsets

[[EMAIL PROTECTED]]

Hi.

I have one recorset that I would like to pass to 2 functions, one is
for create an CSV file and the other one is to create a HTML file. The
problem is that the recordset is totally read in the first function,
and then when I pass it to the second funtion the recordset is in the
last record.

I've read docs, but I think that one cursor doesn't have something
like movefirst() method. Anybody have an idea to solve this?

Thank's.

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

Re: Developing Commercial Applications in Python

[Nick Coghlan]

Stephen Waterbury wrote:
A notable example is Verity's search engine -- see
http://python.oreilly.com/news/PythonSS.pdf
Not to mention the kind words of the current reigning king of the search engine 
world. . .

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

python3: 'where' keyword

[Andrey Tatarinov]

Hi.
It would be great to be able to reverse usage/definition parts in 
haskell-way with "where" keyword. Since Python 3 would miss lambda, that 
would be extremly useful for creating readable sources.

Usage could be something like:
>>> res = [ f(i) for i in objects ] where:
>>> def f(x):
>>> #do something
or
>>> print words[3], words[5] where:
>>> words = input.split()
- defining variables in "where" block would restrict their visibility to 
one expression

- it's more easy to read sources when you know which part you can skip, 
compare to

>>> def f(x):
>>> #do something
>>> res = [ f(i) for i in objects ]
in this case you read definition of "f" before you know something about 
it usage.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Pre/Postconditions with decorators

[George Sakkis]

> Hi George,
> it would be nice to see how you have tackled
> the task.
> Maybe we will have a checker
> module in Python one day... ;-)

I posted my module on http://rafb.net/paste/results/voZYTG78.html and its unit 
test on
http://rafb.net/paste/results/MYxMQW95.html. Any feedback will be appreciated.

George


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

why not datetime.strptime() ?

[josh]

Shouldn't datetime have strptime? It already has strftime, and it'd be really
nice to obviate datetime.fromtimestamp(time.mktime(time.strptime(...)))

thanks in advance

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

pygtk swallowing external app

[JiggaHertz]

I am trying to write a gui with pygtk that swallows an external 
application.  I've tried the plug/sockets example in the documentation 
modifying the plug to be an xterm.  However, the xterm isn't swallowed 
by the python script.  I have seen some c code which accomplishes this 
via an X reparent call.  I was wondering how I would implement this with 
pygtk?
--
http://mail.python.org/mailman/listinfo/python-list

Re: HTML purifier using BeautifulSoup?

[Jonathan Clark]

Dan Stromberg wrote:
> Has anyone tried to construct an HTML janitor script using
BeautifulSoup?
>
> My situation:
>
> I'm trying to convert a series of web pages from .html to palmdoc
format,
> using plucker, which is written in python.  The plucker project
suggests
> passing html through "tidy", to get well-formed html for plucker to
work
> with.
>
> However, some of the pages I want to convert are so bad that even
tidy
> pukes on them.
>
> I was thinking that BeautifulSoup might be more tolerant of really
bad
> html...  Which led me to the question this article started out with.
:)
>
> Thanks!

I have used BeautifulSoup for screen scraping, pulling html into
structured form (using XML). Is that similar to a janitor script? I
used it because tidy was puking on some html. BS has been excellent.

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

Re: python3: 'where' keyword

[Steven Bethard]

Andrey Tatarinov wrote:
Hi.
It would be great to be able to reverse usage/definition parts in 
haskell-way with "where" keyword. Since Python 3 would miss lambda, that 
would be extremly useful for creating readable sources.

Usage could be something like:
 >>> res = [ f(i) for i in objects ] where:
 >>> def f(x):
 >>> #do something
or
 >>> print words[3], words[5] where:
 >>> words = input.split()
- defining variables in "where" block would restrict their visibility to 
one expression
How often is this really necessary?  Could you describe some benefits of 
this?  I think the only time I've ever run into scoping problems is with 
lambda, e.g.

[lambda x: f(x) for x, f in lst]
instead of
[lambda x, f=f: for x, f in lst]
Are there other situations where you run into these kinds of problems?
- it's more easy to read sources when you know which part you can skip, 
compare to

 >>> def f(x):
 >>> #do something
 >>> res = [ f(i) for i in objects ]
in this case you read definition of "f" before you know something about 
it usage.
Hmm...  This seems very heavily a matter of personal preference.  I find 
that your where clause makes me skip the 'res' assignment to read what 
the 'res' block contains.  I had to read it twice before I actually 
looked at the list comprehension.  Of course, I'm sure I could be 
retrained to read it the right way, but until I see some real benefit 
from it, I'd rather not have to.

TOOWTDI-ily-yrs,
Steve
--
http://mail.python.org/mailman/listinfo/python-list