Re: Software archeology (was Re: Developing Commercial Applications in Python)

[Stephen Waterbury]

Aahz wrote:
In article <[EMAIL PROTECTED]>,
Stephen Waterbury  <[EMAIL PROTECTED]> wrote:
Aahz wrote:
In article <[EMAIL PROTECTED]>,
Stephen Waterbury  <[EMAIL PROTECTED]> wrote:
Also see Python Success Stories:  http://pythonology.org/success
A notable example is Verity's search engine -- see
http://python.oreilly.com/news/PythonSS.pdf
Actually, your statement is slightly inaccurate.  The Verity search
engine is more than fifteen years old in its core technology; it was
started as a LISP project at IIRC MIT.  (At one point I was much amused
to look at the C source code and find car() and cdr() functions.)  As of
my last information, Python isn't used at all in or with the Verity
search engine.  What you're referring to is the Verity Ultraseek engine,
originally written and owned by Infoseek before getting transferred to
Verity through a series of dot-bomb transactions.  The Ultraseek engine
doesn't use Python, but Python is used to control the engine, and I think
much of the spider is written in Python.
Actually, Aahz didn't add anything useful that wasn't explained better
in the article itself, pointing to which was the purpose of my post,
but he is correct:  Python was *not* used to write the Verity search
engine ... how the hell do these stupid rumors get started anyhow?? ;).
Just read the article, dammit! :)
You're quite correct that I added little useful information, but seeing
as I used to work at Verity, I couldn't resist adding some hopefully
interesting and/or amusing trivia.  Especially the LISP bit.
Well GEEZ, you should've mentioned that you used to work there!
All the trivia *were* amusing ... sorry if I harshed!  :)
Cheers,
Steve
--
http://mail.python.org/mailman/listinfo/python-list

vi and python

[km]

Hi all,

Is there a way to display inbuilt function syntax as the user starts typing a 
function name with 'Vi' editor in console mode? 

tia,
KM
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Raw Sockets vs. What?

[Matt]

Just thought I'd follow up to say that I'm using XML-RPC after all. Not
that I was intimidated when I finally learned that Fredrik had written
the thing. No, it was more the issue that we want to write a php
debugger next and XML-RPC plays well with php, too.
Thanks again,
--Matt

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

How to read/write blobs with mysqldb?

[Christopher J. Bottaro]

First off, writing the blob.  From what I gather on the internet, I'm
suppose to read the entire file into memory (a Python string), then create
a dbiRaw object with that string and use the dbiRaw object in an insert
statement?

That doesn't sound very efficient to me.  What if my computer only has 64 MB
of memory and the data I want to insert is 128 MB?

It seems like there should be a way to read part of the data, insert that
part into the DB, then get the next part, append, etc.

Also, what if you are inserting a huge piece of data, like a GB, and you
want to have a progress bar in your UI?  How would you do that if you
couldn't split up the insert statements?

Thanks for the help.

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

Re: _tkinter problem

[Craig Ringer]

On Sat, 2005-01-08 at 14:30, Jatinder Singh wrote:
> Hi
> I am running a script which is importing tkinter  from 
> "/usr/local/lib/python2.3/lib-tk/Tkinter.py" and generating an error 
> " import _tkinter
> ImportError: No module named _tkinter "
> 
> can anybody tell me what is it? and how to get away with it?

I think your question is the same problem as another recent poster -
that is, you didn't have the Tcl and Tk headers installed when you
installed Python. Please see my answer to "Help uninstalling/installing
Python 2.4" (Yes, I know yours isn't Python 2.4 - it doesn't matter).

--
Craig Ringer

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

Re: python3: 'where' keyword

[michele . simionato]

> But we're talking about the mythical/hypothetical Python 3, so maybe
> there's a chance of fixing the scoping rules, which it seems to me
are
> currently pretty badly broken.

I don't think the current scoping rules will be changed in Python 3.0.
I can't give you the link right now, but there are threads about the
scope rules in
python-dev, with various people protesting and Guido saying that he
wants to 
keep them as they are.

 Michele Simionato

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

Re: switching an instance variable between a property and a normal value

[Nick Coghlan]

Steven Bethard wrote:
where I also accept *args and **kwds when the default value is to be 
called.  It's certainly doable with a flag, but note that I have to 
check the flag every time in both __getitem__ and setdefault.
Alternatively, always use a function for the default value, and set _func to 
lambda: x when working by value :)

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

Re: python3: 'where' keyword

[Nick Coghlan]

Paul Rubin wrote:
the suite has its own scope so any variable created there is local to
the suite plus the following statement.  The scope vanishes after the
statement.
The second part of the idea is to give the statement greater prominence and 
'hide' the uninteresting setup (the contents of the where clause).

Putting the statement of interest after the where suite still gives the benefits 
of avoiding namespace clutter, but doesn't really help readability (it makes it 
worse, if you ask me).

Particularly, what if the next statement is a compound statement?
Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: python3: 'where' keyword

[Nick Coghlan]

Nick Coghlan wrote:
It also allows the necessary but uninteresting setup for an expression 
to be moved "out of the way", bringing the expression that does the real 
work to prominence.
Killer app for this keyword:
class C(object):
  x = property(get, set) where:
def get(self):
  return "Silly property"
def set(self, val):
  self.x = "Told you it was silly"
Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: switching an instance variable between a property and a normal value

[Nick Coghlan]

Steven Bethard wrote:
I'd like to be able to have an instance variable that can sometimes be 
accessed as a property, and sometimes as a regular value, e.g. something 
like:
If you want the behaviour to be switchable per-instance, you have to go the 
route of always running through the property machinery, since property() creates 
a descriptor on the class, not the instance.

On the other hand, if you want to switch the behaviour of every instance, then 
making usevalue and usefunc class methods may give you some mileage.

I'm rather curious about your use case, though. . .
Here's a different way of using the property machinery, too:
Py> class C(object):
...   def __init__(self):
... self._use_val = None
...   def useval(self, x):
... self._val = x
... self._use_val = True
...   def usefunc(self, func, *args, **kwds):
... self._func, self._args, self._kwds = (func, args, kwds)
...   def _get(self):
... use_val = self._use_val
... if use_val is None:
...   raise AttributeError('x')
... if use_val:
...   return self._val
... else:
...   return self._func(*self._args, **self._kwds)
...   x = property(_get)
...
Py> c = C()
Py> c.useval(4)
Py> c.x
4
Py> c.usefunc(list)
Py> c.x
[]
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: python3: 'where' keyword

[Paul Rubin]

Nick Coghlan <[EMAIL PROTECTED]> writes:
> > Usage could be something like:
> >  >>> res = [ f(i) for i in objects ] where:
> >  >>> def f(x):
> >  >>> #do something
> 
> Hmm, this is actually a really interesting idea. Avoiding accidental
> namespace conflicts is certainly one of the advantages of using lambdas.

I like it too.  Seems a little perl-ish, but what the hey.

> In fact, any subexpressions in a complicated expression can be
> extracted and named for clarity without fear of screwing up the
> containing namespace, which would be an enormous boon for software
> maintainers.

Sure, why not:

x = (-b + sqrt(discriminant))/(2*a) where:
  discriminant = b*b - 4*a*c

Maybe you could just have a where: suite that binds variables
within the suite:

where:
   def f(x):
  #do something
res = [ f(i) for i in objects ]

where:
   discriminant = b*b - 4*a*c
x = (-b + sqrt(discriminant))/(2*a) 

Syntax is
   where:
  suite
   statement

the suite has its own scope so any variable created there is local to
the suite plus the following statement.  The scope vanishes after the
statement.
-- 
http://mail.python.org/mailman/listinfo/python-list

_tkinter problem

[Jatinder Singh]

Hi
I am running a script which is 
importing tkinter  from "/usr/local/lib/python2.3/lib-tk/Tkinter.py" 
and generating an error 
" import _tkinter
ImportError: No module named _tkinter 
"
 
can anybody tell me what is it? and how to get away 
with it?
 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: sorting on keys in a list of dicts

[Carl Banks]

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?  I'd
> have expected to just do
>
>  L2 = [(d[key], d) for d in L]
>  L2.sort()
>  L = [d for (v, d) in L2]


Suppose L is a list of objects that can't be compared (for example,
they are dicts that have complex number items) and the keys are not all
distinct.  If sort tries to compare two equal keys, it'll proceed to
compare the objects themselves, which could throw an exception.

Stick the index in there, and that possibility is gone.


-- 
CARL BANKS

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

Re: python3: 'where' keyword

[Nick Coghlan]

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
Hmm, this is actually a really interesting idea. Avoiding accidental namespace 
conflicts is certainly one of the advantages of using lambdas.

This idea has the virtue of being able to do the same thing, but have full 
access to Python's function syntax and assignment statements in the 'expression 
local' suite.

In fact, any subexpressions in a complicated expression can be extracted and 
named for clarity without fear of screwing up the containing namespace, which 
would be an enormous boon for software maintainers.

It also allows the necessary but uninteresting setup for an expression to be 
moved "out of the way", bringing the expression that does the real work to 
prominence.

From the interpreter's point of view, the meaning would probably be something 
like:
namespace = locals()
exec where_suite in globals(), namespace
exec statement in globals(), namespace
res = namespace["res"]
del namespace
Making the 'where' clause part of the grammar for the assignment statement 
should be enough to make the above example parseable, too.

The clause might actually make sense for all of the simple statement forms in 
the grammar which contain an expression:
  expression statement
  assignment statement
  augmented assignment statement
  del statement
  print statement
  return statement
  yield statement
  raise statement
  exec statement

The clause really isn't appropriate for break, continue, import or global 
statements, as they don't contain any expressions :)

For compound statements, a where clause probably isn't appropriate, as it would 
be rather unclear what the where clause applied to.

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

[Carl Banks]

Roy Smith wrote:
> Hmmm.  There's something going on here I don't understand.  The ref
> manual (3.3.5 Emulating container types) says for __getitem__(),
"Note:
> for loops expect that an IndexError will be raised for illegal
indexes
> to allow proper detection of the end of the sequence."  I expected my

> little demo class to therefore break for loops, but they seem to work

> fine:
>
> >>> import awk
> >>> l = awk.awkList ("foo bar baz".split())
> >>> l
> ['foo', 'bar', 'baz']
> >>> for i in l:
> ... print i
> ...
> foo
> bar
> baz
> >>> l[5]
> ''
>
> Given that I've caught the IndexError, I'm not sure how that's
working.


The title of that particular section is "Emulating container types",
which is not what you're doing, so it doesn't apply here.  For built-in
types, iterators are at work.  The list iterator probably doesn't even
call getitem, but accesses the items directly from the C structure.
-- 
CARL BANKS

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

Re: Help uninstalling/installing Python 2.4

[Craig Ringer]

On Sat, 2005-01-08 at 08:08, Baggs wrote:

> Tk calls did not work, the output from Python when running a program 
> stated that I probably did not have TK installed.  I got and installed 
> TK 8.4 and the problem persisted (I know I should have written down the 
> exact error, but I didn't... but the story gets worse!)

You probably didn't have the -devel packages for Tcl and Tk installed,
so Python would've decided you didn't have Tk and not built tkinter
support. Chances are if you install the devel packages and recompile
Python, it'll work fine.

> when I re-installed I still have 
> problems.. everything installs ok, but now I get the following errors 
> with Python...
> 
> bash: /usr/bin/python: No such file or directory

Is that when you run a script, or when you type 'python' in your shell?
If the former, make sure you write your scripts with a #! like this:

#!/usr/bin/env python

not

#!/usr/bin/python

That way, the right python will get run so long as it's on your path -
it doesn't have to be in /usr/bin.

If the error is when typing 'python' on the command line, ensure you
have no aliases for the name 'python' hanging around ('alias python' to
find out). Also check what is actually being run with 'which python' and
see if it's a wrapper script that calls /usr/bin/python.

> when I go to /usr/local/bin and type ./python I get
> 
> Python 2.4 (#6, Jan  7 2005, 18:44:57)
> [GCC 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> Traceback (most recent call last):
>File "/etc/pythonrc.py", line 2, in ?
>  import readline
> ImportError: No module named readline
> 
> I think some paths are screwed up.. can someone take pity on me and give 
> me a hand.

I'd say that'll be the same as with Tkinter - you probably didn't have
the GNU readline development headers installed, so Python disabled
readline support when it was compiled. That's just a guess, but seems
pretty likely.

--
Craig Ringer

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

Here is $50 for signing up free

[me to you]

   Hello,  I'm trying out a new auto poster, and dont know how to use it very
   good, so if this end up in the wrong places, please forgive me,
   and disreguard, sorry for your incovenience, but everyone else, ENJOY!!
KEEP READING TO GET YOUR $50.00 NOW!!!
  This is not spam, it is a legitament way to make money on the net, reading
  e-mail, and other things as well, plus you get $50.00 dollars for signing up.
  This is tottaly free, and requires no credit card on out of pocket money.
  You will get paid for various things on the net, hope you enjoy and find
  some usefull info here that will help you out. Plus you will get fifty 
dollars.
  this is not spam, its usefull news for all newsgroups readers, from me to you,
  hope you can use it for your benifit, please enjoy. If your not sure, get a
  new email address, and then try, you wont get spammed, and all info is
  carefully guarded, and not given out or traded or sold. Enjoy your $50.00,
  I did, so did my friends and family. You'll also be able to do survays if you
  want,  P.S. forgive my spelling.
  
   Just copy and paste into your browser, thanks again.
   
   URL: http://www.CashRead.com/cgi-bin/[EMAIL PROTECTED]
   
   Dont be mean and hatefull, if you dont want to Participate, DON'T.
   If you don't want $50.00, let someone else have it.




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

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

[Roy Smith]

Dan Valentine <[EMAIL PROTECTED]> wrote:

> 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.
> 
> i guess it depends on how faithfully you want to reproduce awk's behavior
> and options.
> 
> as several people have mentioned, strings have the split() method for 
> simple tokenization, but blindly indexing into the resulting sequence 
> can give you an out-of-range exception.  out of range indexes are no
> problem for awk; it would just return an empty string without complaint.

It's pretty easy to create a list type which has awk-ish behavior:

class awkList (list):
def __getitem__ (self, key):
try:
return list.__getitem__ (self, key)
except IndexError:
return ""

l = awkList ("foo bar baz".split())
print "l[0] = ", repr (l[0])
print "l[5] = ", repr (l[5])

---

Roy-Smiths-Computer:play$ ./awk.py
l[0] =  'foo'
l[5] =  ''

Hmmm.  There's something going on here I don't understand.  The ref 
manual (3.3.5 Emulating container types) says for __getitem__(), "Note: 
for loops expect that an IndexError will be raised for illegal indexes 
to allow proper detection of the end of the sequence."  I expected my 
little demo class to therefore break for loops, but they seem to work 
fine:

>>> import awk
>>> l = awk.awkList ("foo bar baz".split())
>>> l
['foo', 'bar', 'baz']
>>> for i in l:
... print i
... 
foo
bar
baz
>>> l[5]
''

Given that I've caught the IndexError, I'm not sure how that's working.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Getting rid of "self."

[Nick Coghlan]

Roy Smith wrote:
It's actually kind of neat, but boy does it play headgames with me when 
I switch back and forth between that and Python.
Switching back and forth betwen C++ and Python plays headgames *anyway* }:>
Cheers,
Nick.
Hardware control with Python is nice. . .
--
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:
Agreed.  I'd started typing before I realized that it'd provide a stable 
sort, which pretty much answered my own question, but decided to send it 
anyhow in case I'd missed anything else... :)
And it turns out we both missed the fact that it avoids comparing the 
dictionaries which could save a *lot* of number crunching (as well as making 
otherwise unsortable lists sortable).

So it's a good thing you did decide to send it :)
Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: What could 'f(this:that=other):' mean?

[Nick Coghlan]

If the caller is meant to supply a namespace, get them to supply a namespace.
def f(ns1, ns2):
  print ns1['a'], ns1['b'], ns2['a'], ns2['b']
f(ns1 = dict(a=1, b=2), ns2 = dict(a=3, b=4))
Hey, where's Steve? Maybe his generic objects should be called namespaces 
instead of bunches. . .

def f(ns1, ns2):
  print ns1.a, ns1.b, ns2.a, ns2.b
f(ns1 = namespace(a=1, b=2), ns2 = namespace(a=3, b=4))
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

[Dan Valentine]

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.

i guess it depends on how faithfully you want to reproduce awk's behavior
and options.

as several people have mentioned, strings have the split() method for 
simple tokenization, but blindly indexing into the resulting sequence 
can give you an out-of-range exception.  out of range indexes are no
problem for awk; it would just return an empty string without complaint.

note that the index bases are slightly different: python sequences
start with index 0, while awk's fields begin with $1.  there IS a $0,
but it means the entire unsplit line.

the split() method accepts a separator argument, which can be used to
replicate awk's -F option / FS variable.

so, if you want to closely approximate awk's behavior without fear of
exceptions, you could try a small function like this:


def awk_it(instring,index,delimiter=" "):
  try:
return [instring,instring.split(delimiter)[index-1]][max(0,min(1,index))]
  except:
return ""


>>> print awk_it("a b c d e",0)
a b c d e

>>> print awk_it("a b c d e",1)
a

>>> print awk_it("a b c d e",5)
e

>>> print awk_it("a b c d e",6)


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

Re: Getting rid of "self."

[Roy Smith]

Jeremy Bowers <[EMAIL PROTECTED]> wrote:
> were I programming in C++ routinely now I'd prefix "this" and 
> dispense with that ugly "m_" garbage. (One of the things I ***hate*** 
> about C++ culture is its acceptance of hideously ugly variable names, 
> but now I'm two parentheticals deep so I probably ought to stop.))

I'm currently working in a C++ system where they have a wrapper class 
that provides some transaction locking functionality for member access.  
The colloquial name for the wrapped "this" pointer is self, i.e. they do 
"self = wrapper (this)" at the beginning of functions that need it.  You 
can then do "member" to get the bare access or "self.member" to get the 
locking functionality.

It's actually kind of neat, but boy does it play headgames with me when 
I switch back and forth between that and Python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Calling Function Without Parentheses!

[Nick Coghlan]

Kamilche wrote:
Uh, you're right! I wouldn't want to bog Python down with even more
checking at run time.  I guess I'm asking for syntax checks that are
typically done only with compiled languages.
In that case, I can suggest having a look at Pychecker, which performs static 
sanity checks on Python code.
http://pychecker.sourceforge.net/

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."

[Jeremy Bowers]

On Fri, 07 Jan 2005 14:39:09 +0100, BJÃrn Lindqvist wrote:
> It works! exec(magic()) does the needed hi = self.hi.

No it doesn't. Try "hi = 'newValue'" and see what happens.

So the next step is to write an "unmagic" function. So now how do you add
instance variables?

There is no way to avoid "self" *and* not pre-declare variables in some
fashion as belonging to the instance (as declarations, as sigils, what
have you). Given that Python is not, will not, and should not do the
latter, I submit that "self" is, at least for you, the lesser of two
evils. (I don't consider it evil at all, so it isn't such for me; were I
programming in C++ routinely now I'd prefix "this" and dispense with that
ugly "m_" garbage. (One of the things I ***hate*** about C++ culture is
its acceptance of hideously ugly variable names, but now I'm two
parentheticals deep so I probably ought to stop.))
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Software archeology (was Re: Developing Commercial Applications in Python)

[Stephen Waterbury]

Aahz wrote:
In article <[EMAIL PROTECTED]>,
Stephen Waterbury  <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] writes:
Can somebody there to point me any good commercial applications
developed using python ?
Also see Python Success Stories:  http://pythonology.org/success
A notable example is Verity's search engine -- see
http://python.oreilly.com/news/PythonSS.pdf
Actually, your statement is slightly inaccurate.  The Verity search
engine is more than fifteen years old in its core technology; it was
started as a LISP project at IIRC MIT.  (At one point I was much amused
to look at the C source code and find car() and cdr() functions.)  As of
my last information, Python isn't used at all in or with the Verity
search engine.  What you're referring to is the Verity Ultraseek engine,
originally written and owned by Infoseek before getting transferred to
Verity through a series of dot-bomb transactions.  The Ultraseek engine
doesn't use Python, but Python is used to control the engine, and I think
much of the spider is written in Python.
Actually, Aahz didn't add anything useful that wasn't explained
better in the article itself, pointing to which was the purpose
of my post, but he is correct:  Python was *not* used to write
the Verity search engine ... how the hell do these stupid rumors
get started anyhow?? ;).  Just read the article, dammit!  :)
Cheers,
Steve
--
http://mail.python.org/mailman/listinfo/python-list

Re: "A Fundamental Turn Toward Concurrency in Software"

[Erik Max Francis]

aurora wrote:
Just gone though an article via Slashdot titled "The Free Lunch Is Over: A  
Fundamental Turn Toward Concurrency in Software"  
[http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues that the  
continous CPU performance gain we've seen is finally over. And that future  
gain would primary be in the area of software concurrency taking advantage  
hyperthreading and multicore architectures.
Well, I think it's reasonable to expect that _eventually_ (whether soon 
or relatively soon or not for a long time) Moore's law will fail, and 
the exponential increase in computing power over time will cease to 
continue.  At that point, it seems reasonable to assume you'll do your 
best to take advantage of this with parallelization -- if your CPU won't 
get faster, just put more and more in the box.  So I've always had it in 
the back of my mind that languages that can easily support massive 
(especially automatic) parallelization will have their day in the sun, 
at least someday.

--
Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
  All the people in my neighborhood turn around and get mad and sing
  -- Public Enemy
--
http://mail.python.org/mailman/listinfo/python-list

Python/Qt Problem

[Michael]

Hi,
I am experiencing something very weird with PyQt. I have created several 
windows based on QWidget using Designer. I can easily hide and show 
these with the hide and show methods. However I have just created a new 
window with Designer and the show method works in my main script but not 
inside the button action method (not using proper temrinology, sorry) of 
another window. Why is that? This works fine for the other windows.

Have I explained my problem properly?
Thanks for any advice,
Michael
--
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[Roy Smith]

In article <[EMAIL PROTECTED]>,
 James Stroud <[EMAIL PROTECTED]> wrote:

> On Friday 07 January 2005 01:24 pm, Paul Rubin wrote:
> > Nick Coghlan <[EMAIL PROTECTED]> writes:
> > > 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.
> >
> > Richard Feynman told a story about being on a review committee for
> > some grade-school science textbooks.  One of these book said something
> > about "counting numbers" and it took him a while to figure out that
> > this was a new term for what he'd been used to calling "integers".
> 
> 
> I think we should not try too hard to make everything "English" like. Its a 
> crappy language anyway (though its the only one I speak good). Matt Neuberg, 
> in _AppleScript: The Definitive Guide_, refers to "the English-likeness 
> monster". His example is that instead of
> 
> x = 4
> 
> you have to say
> 
> copy 4 to x

The syntax was taken directly from HyperCard.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: DOS problem (simple fix??)

[Brian van den Broek]

Gavin Bauer said unto the world upon 2005-01-07 15:47:
My DOS window (running in windows ME) closes the second it finishes
running my programs. As you can imagine, this makes it hard to see the

Thank you, and please make all answers simple enough to be understood
by a highschool student and his father :) .
Hi Gavin,
you received some solutions. I have another, and a warning about Paul's.
The warning:
Paul suggested looking at IDLE. You should; it's a big improvement over 
notepad or the console. But, do you plan to make GUI application with 
Tkinter? If so, they will have troubles under IDLE. IDLE itself is a 
Tkinter application, so if it runs another Tkinter app, the poor beast 
gets confused about which Tkniter commands go where. (If that doesn't 
make sense, then you probably aren't yet at a place where it will 
matter. So, don't worry about it now.)

Another popular alternative is SciTe. If you are doing your code in 
notepad or an interactive window, you really do want to look into an 
alternative!

The other solution:
The exact procedure is Windows version specific, but you can change the 
behaviour of .py files when they are double clicked. Here's what I do on 
my Win version (ME), which, sadly for both of us, we share:

1) Open a file explorer window.
2) Pick Tool->Folder Options from the menu.
3) Select the File Types tab.
4) Select the .py file type in the alphabetical list of file types that 
pops up.
5) Click on the Advanced button.
6) Select the Open action.
7) It will start out with something like:

"C:\Python24\python.exe"
Put a -i immediately thereafter. Mine looks like this
"C:\Python24\python.exe" -i "%1" %*
The -i makes .py files when double-clicked within Windows. The rest has 
to do with sending command line parameters, but I'd muff it if I tried 
to say more ;-)

HTH,
Brian vdB
--
http://mail.python.org/mailman/listinfo/python-list

The limitation of the Photon Hypothesis

[bill]

Please reply to [EMAIL PROTECTED], thank you !

The limitation of the Photon Hypothesis

 

According to the electromagnetic theory of light, its energy is related to the 
amplitude of the electric field of the electromagnetic wave, W=eE^2V(where E is 
the amplitude and V is the volume). It apparently has nothing to do with the 
light's frequency f. 

To explain the photoelectric effect, Einstein put forward the photon 
hypothesis. His paper hypothesized light was made of quantum packets of energy 
called photons. Each photon carried a specific energy related to its frequency 
f, W=hf. This has nothing to do with the amplitude of the electromagnetic wave 
E. 

For the electromagnetic wave that the amplitude E has nothing to do with the 
light's frequency f, if the light's frequency f is high enough, the energy of 
the photon in light is greater than the light's energy, hf>eE^2V. Apparently, 
this is incompatible with the electromagnetic theory of light.

THE UNCERTAINTY PRINCIPLE IS UNTENABLE

 

By re-analysing Heisenberg's Gamma-Ray Microscope experiment and one of the 
thought experiment from which the uncertainty principle is demonstrated, it is 
actually found that the uncertainty principle cannot be demonstrated by them. 
It is therefore found to be untenable.

Key words: 
uncertainty principle; Heisenberg's Gamma-Ray Microscope Experiment; thought 
experiment 

 

The History Of The Uncertainty Principle

If one wants to be clear about what is meant by "position of an object," for 
example of an electron., then one has to specify definite experiments by which 
the "position of an electron" can be measured; otherwise this term has no 
meaning at all. --Heisenberg, in uncertainty paper, 1927

Are the uncertainty relations that Heisenberg discovered in 1927 just the 
result of the equations used, or are they really built into every measurement? 
Heisenberg turned to a thought experiment, since he believed that all concepts 
in science require a definition based on actual, or possible, experimental 
observations.

Heisenberg pictured a microscope that obtains very high resolution by using 
high-energy gamma rays for illumination. No such microscope exists at present, 
but it could be constructed in principle. Heisenberg imagined using this 
microscope to see an electron and to measure its position. He found that the 
electron's position and momentum did indeed obey the uncertainty relation he 
had derived mathematically. Bohr pointed out some flaws in the experiment, but 
once these were corrected the demonstration was fully convincing. 

 

Thought Experiment 1

The corrected version of the thought experiment

Heisenberg's Gamma-Ray Microscope Experiment


A free electron sits directly beneath the center of the microscope's lens 
(please see AIP page http://www.aip.org/history/heisenberg/p08b.htm or diagram 
below) . The circular lens forms a cone of angle 2A from the electron. The 
electron is then illuminated from the left by gamma rays--high-energy light 
which has the shortest wavelength. These yield the highest resolution, for 
according to a principle of wave optics, the microscope can resolve (that is, 
"see" or distinguish) objects to a size of dx, which is related to and to the 
wavelength L of the gamma ray, by the expression: 

dx = L/(2sinA) (1) 

However, in quantum mechanics, where a light wave can act like a particle, a 
gamma ray striking an electron gives it a kick. At the moment the light is 
diffracted by the electron into the microscope lens, the electron is thrust to 
the right. To be observed by the microscope, the gamma ray must be scattered 
into any angle within the cone of angle 2A. In quantum mechanics, the gamma ray 
carries momentum as if it were a particle. The total momentum p is related to 
the wavelength by the formula, 

p = h / L, where h is Planck's constant. (2) 

In the extreme case of diffraction of the gamma ray to the right edge of the 
lens, the total momentum would be the sum of the electron's momentum P'x in the 
x direction and the gamma ray's momentum in the x direction: 

P' x + (h sinA) / L', where L' is the wavelength of the deflected gamma ray. 

In the other extreme, the observed gamma ray recoils backward, just hitting the 
left edge of the lens. In this case, the total momentum in the X direction is: 

P''x - (h sinA) / L''. 

The final x momentum in each case must equal the initial X momentum, since 
momentum is conserved. Therefore, the final X moment are equal to each other: 

P'x + (h sinA) / L' = P''x - (h sinA) / L'' (3) 

If A is small, then the wavelengths are approximately the same, 

L' ~ L" ~ L. So we have 

P''x - P'x = dPx ~ 2h sinA / L (4) 

Since dx = L/(2 sinA), we obtain a reciprocal relationship between the minimum 
uncertainty in the measured position, dx, of the electron along the X axis and 
the uncertainty in its momentum, dPx, in the x direction: 

dPx ~ h / dx or dPx dx ~ h. (5) 

For more than minimum uncertainty, the "greate

Re: Securing a future for anonymous functions in Python

[James Stroud]

On Friday 07 January 2005 01:24 pm, Paul Rubin wrote:
> Nick Coghlan <[EMAIL PROTECTED]> writes:
> > 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.
>
> Richard Feynman told a story about being on a review committee for
> some grade-school science textbooks.  One of these book said something
> about "counting numbers" and it took him a while to figure out that
> this was a new term for what he'd been used to calling "integers".


I think we should not try too hard to make everything "English" like. Its a 
crappy language anyway (though its the only one I speak good). Matt Neuberg, 
in _AppleScript: The Definitive Guide_, refers to "the English-likeness 
monster". His example is that instead of

x = 4

you have to say

copy 4 to x

I think every reader of this list would prefer to look at the former.

The point is that once we learn new symbolics of expression, they are as 
simple to decipher as plain old English if we format properly and
gIvEnThAtwEiNcLuDEsOmEhElPfUlfORmaTtInGInOuRcOdEFroMtImEtOtiME.

So I think that being fearful of new additions to the language (read "more 
ability for expression") is mainly fear of abuse by poor programmers--and 
that is akin to being afraid of the dark.

James



-- 
James Stroud, Ph.D.
UCLA-DOE Institute for Genomics and Proteomics
611 Charles E. Young Dr. S.
MBI 205, UCLA 951570
Los Angeles CA 90095-1570
http://www.jamesstroud.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Robert Kern]

Scott David Daniels wrote:
If you can wait, the plan for MacEnthon (Python 2.4 on Mac) looks great:
Actually, just packages for 2.3 (or 2.3.x for Tiger) as of right now. 
When someone else packages up 2.4 nicely, I'll start making packages for 
that, too.

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.
They probably won't be synchronized too much. My additions to the list 
are primarily for the people I need to support within my organization. 
Or my own personal sense of whimsy.

--
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 Operating System???

[Arich Chanachai]

Paul Rubin wrote:

  Arich Chanachai <[EMAIL PROTECTED]> writes:
  
  

  But I thought Python was an all-purpose language.  After all, OS's
have been written in Lisp before too.

  

Pure Lisp?  Or a Lisp/C/Asm combo?  Lisp has a compiled flavor by the way.

  
  
Compiled flavor?  Lisp has been compiled since the 1950's.  
  

:-)  I was being sarcastic.

  
No, there was no C code on Lisp machines.  There was some low-level
code at the bottom whose capabilities were such that you could
accurately call it asm, but it was Lisp too, just a very restricted
form.
  

Fair enough.  But of course, there is doubt that the OP would require a
compilable version of Python capable of similarly restricted forms, and
as far I know, none such version exists.  ;-)


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

Re: Python Operating System???

[Paul Rubin]

Arich Chanachai <[EMAIL PROTECTED]> writes:
> >But I thought Python was an all-purpose language.  After all, OS's
> >have been written in Lisp before too.
> >
> Pure Lisp?  Or a Lisp/C/Asm combo?  Lisp has a compiled flavor by the way.

Compiled flavor?  Lisp has been compiled since the 1950's.  

No, there was no C code on Lisp machines.  There was some low-level
code at the bottom whose capabilities were such that you could
accurately call it asm, but it was Lisp too, just a very restricted
form.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Operating System???

[Arich Chanachai]

Paul Rubin wrote:
[EMAIL PROTECTED] (Michael Hobbs) writes:
 

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.
   

But I thought Python was an all-purpose language.  After all, OS's
have been written in Lisp before too.
 

Pure Lisp?  Or a Lisp/C/Asm combo?  Lisp has a compiled flavor by the way.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[BJörn Lindqvist]

The more features a language has, the harder it becomes to learn. An
example of that is C++ which has almost everything. Classes, structs,
templates, strange keywords that noone uses like auto, inline const,
passing by reference/value, enum, union, lots of macros, multiple
inheritance, namespaces etc. I'll bet that you could shave off 50% of
C++'s features and it would still be 95% as usable[*].

Judging by the number of PEP proposals and syntax additions that
appear on the mailing list every day Python could some day become as
bloated. We don't want that, do we? So how do we avoid feature bloat?:

1. We stop adding features, either now or at some point in the future.
2. We remove some features.

Either way we have to put a limit on the number of features we want
Python to have. Let's call that number X where X is a number much
smaller than infinity. With a set limit, the discussion becomes "which
features should be selected for use in Python?" instead of "should
this feature be added/removed?" Personally, I don't care either way if
lambda is removed or retained, but I would much rather have the "with"
keyword someone proposed, do-while loops or whatever. I think there
are way too many good features out there just waiting to take lambdas
place.

* - Please don't ask me to make that bet. 

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

Re: EOF for binary?

[flamesrock]

Thanks!

I don't know why, but the most innefficient and unmaintanable means of
doing something usually pops into my head before anything else. I
solved this by going

elif len(header) < 8:
break

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

Re: Notification of PEP Updates

[Bengt Richter]

On Fri, 07 Jan 2005 16:05:31 -0700, Steven Bethard <[EMAIL PROTECTED]> wrote:

>Bengt Richter wrote:
>> On Sat, 08 Jan 2005 03:28:34 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> 
>> 
>>>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.
>> 
>> How does one get to editing one's settings?
>
>
>Go to the bottom of the page
>
>http://mail.python.org/mailman/listinfo/python-checkins
>
>under "Python-checkins Subscribers", fill in your email address and 
>click "Unsubscribe or edit options".  Fill in the "password" field on 
>the next page and click "Log in".  The topic option should be near the 
>bottom of the page.
>
Thanks. It was below the bottom of the screen, and I expected the option
in the context of first subscribing, not coming back in after confirmation. 
D'oh ;-/

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

Re: EOF for binary?

[Roy Smith]

In article <[EMAIL PROTECTED]>,
 "flamesrock" <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> So if I understand correctly, there are NO eof characters in any binary
> file. If so, is there an easier way to check for the end of the file
> than:
> 
> os.path.getsize(infile) <= infile.tell()

How you detect EOF depends on how you're reading the file.  For example, 
read() indicates EOF by returning fewer characters than you asked for 
(possibly zero).

Checking the length of a file is perilous.  Files change size.  File 
sizes don't have much meaning on things like network sockets to begin 
with.
-- 
http://mail.python.org/mailman/listinfo/python-list

Publish your program for free and enjoy worry free earning. 100% !!!! FREE (AND WE MEAN IT - FREE)

[DohnoSoft]

Developers, please read this information.
 
If you have some program or utility that you think may be interesting to 
somebody else, go ahead and submit it to www.dohnosoft.com
This is 100% FREE!!!  and DohnoSoft will take care of all issues related to 
sales, payments and customer support. You will just enjoy worry free earning, 
which will be 89% of each sold program.

NO CREDIT CARDS, BANK INFORMATION OR ANY OTHER PAYMENT INFORMATION IS REQUIRED.

After DohnoSoft sends money with PayPal, you receive an email letting you 
know about your payment. After clicking on the link included in the email, 
you can log in to PayPal or sign up for a new account (100% FREE). The money 
will immediately appear in your account balance.
 
Learn more about it on www.dohnosoft.com
 
Thank you,

Problems? Questions?
 
[EMAIL PROTECTED]

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

Re: Securing a future for anonymous functions in Python

[Steven Bethard]

Alan Gauld wrote:
On Fri, 07 Jan 2005 08:44:57 -0700, Steven Bethard
<[EMAIL PROTECTED]> wrote:
The unfamiliar argument doesn't work for me. After all most
people are unfamiliar with complex numbers (or imaginary) numbers
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.

That's a fair point I suppose but I still don't see much point in
introducing new names and syntaxes when the existing name is a
sensible one, even if unfamiliar to many. After all it works in
Lisp and Haskell - Haskell even uses Lambda as its emblem...
Yeah, I personally expect that if GvR doesn't like lambda now, he won't 
like any of the new syntaxes either.  But I'm in the camp that won't 
miss lambda if it's gone, so I'm not too worried. ;)

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

EOF for binary?

[flamesrock]

Hi,

So if I understand correctly, there are NO eof characters in any binary
file. If so, is there an easier way to check for the end of the file
than:

os.path.getsize(infile) <= infile.tell()

Because that returns the error:
#  File "/usr/lib/python2.3/posixpath.py", line 142, in getsize
#return os.stat(filename).st_size
#TypeError: coercing to Unicode: need string or buffer, file found
for me.


-thanks in advance
flamesrock

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

Re: Returning same type as self for arithmetic in subclasses

[Tim Peters]

[Max M]
> """
> I subclass datetime and timedelta
> 
> >>> dt = myDatetime(1970,1,1)
> >>> type(dt)
> 
> 
> >>> td = myTimedelta(hours=1)
> >>> type(td)
> 
> 
> But when I do arithmetic with these classes, they return datetime and
> timedelta,
...
> >>> new_time = dt + td
> >>> new_time
> datetime.datetime(1970, 1, 1, 1, 0)
> 
> >>> type(new_time)
> 

Yes, and all builtin Python types work that way.  For example,
int.__add__ or float.__add__ applied to a subclass of int or float
will return an int or float; similarly for a subclass of str.  This
was Guido's decision, based on that an implementation of any method in
a base class has no idea what requirements may exist for invoking a
subclass's constructor.  For example, a subclass may restrict the
values of constructor arguments, or require more arguments than a base
class constructor; it may permute the order of positional arguments in
the base class constructor; it may even be "a feature" that a subclass
constructor gives a different meaning to an argument it shares with
the base class constructor.  Since there isn't a way to guess, Python
does a safe thing instead.

> where I want them to return myDatetime and myTimedelta
>
> So I wondered if there was a simlpler way to coerce the result into my
> desired types rather than overwriting the __add__, __sub__ etc. methods?

Generally speaking, no.  But I'm sure someone will torture you with a
framework that purports to make it easy .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Notification of PEP Updates

[Skip Montanaro]

Nick> Let us know if it does anything odd (e.g. sending updates about
Nick> other checkins)

Note that the lone criterion for inclusion is the word "PEP" in the subject
or the first few lines of the message.  You might thus see the occasional
checkin message that mentions "PEP" but isn't directly about a PEP.

Nick> I believe the mail you receive should contain the checkin
Nick> messages, along with a summary of the differences between the old
Nick> version and the new version (handy if you can read a context diff,
Nick> not so handy otherwise).

I believe all the checkin messages come out as unified diffs these days, so
they are a bit easier to read.

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

Re: why not datetime.strptime() ?

[Skip Montanaro]

josh> Shouldn't datetime have strptime?

Sure, but it's not quite as trivial to implement as was strftime() support.
While strftime() is a C library function and thus easily called from within
the datetime C code, strptime() is implemented in Python as part of the time
module for portability (strptime(3) is not universally available).  You'd
need to import the time module, call its strptime() function with the input
string and format, then use the tuple it returns to initialize a new
datetime object.

If someone wants to get their feet wet with extension module programming
this might be a good place to start.  Mostly, I think nobody who has
needed/wanted it so far has the round tuits available to spend on the task.

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

Re: Securing a future for anonymous functions in Python

[Terry Hancock]

On Friday 07 January 2005 06:12 pm, Jeff Shannon wrote:
> Paul Rubin wrote:
> 
> > Richard Feynman told a story about being on a review committee for
> > some grade-school science textbooks.  One of these book said something
> > about "counting numbers" and it took him a while to figure out that
> > this was a new term for what he'd been used to calling "integers".
> 
> With all due respect to Richard Feynman, I'd have thought that 
> "counting numbers" would be non-negative integers, rather than the 
> full set of integers...  which, I suppose, just goes to show how 
> perilous it can be to make up new, "more natural" terms for things. ;)

Speaking of "natural", I think "counting numbers" would indeed be
the "natural numbers" 1,2,3, ...

So, yeah, I agree.  Jargon definitely has its place: I once told a colleague
(in an effort to avoid jargon) that one star was "faster" than another star.

Only after registering his incomprehension, did I really think about the
fact that that had at least 4 or 5 possible meanings (in fact, I meant that
the frequency of its periodic change in radial velocity was higher -- but
I could've meant that it was receeding faster, had a higher amplitude of
radial velocity change, etc.).

I think "lambda" is fine.  Basically if you find you need one, you probably
ought to be using the CS term anyway.  It would make looking up the
theory that much easier, anyway.

Cheers,
Terry



-- 
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com

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

Re: Securing a future for anonymous functions in Python

[Alan Gauld]

On Fri, 07 Jan 2005 08:44:57 -0700, Steven Bethard
<[EMAIL PROTECTED]> wrote:
> > The unfamiliar argument doesn't work for me. After all most
> > people are unfamiliar with complex numbers (or imaginary) numbers
> 
> 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.

That's a fair point I suppose but I still don't see much point in
introducing new names and syntaxes when the existing name is a
sensible one, even if unfamiliar to many. After all it works in
Lisp and Haskell - Haskell even uses Lambda as its emblem...

And besides it may just encoursage some to go and explore Lambda
calculus, it did for me... And my programing improved enormously
as a result. So maybe having the name as a stimulant to research
is a good thing... 

OTOH I do accept the point made by another poster that Pythons
single expression limitations mean that they are a poor imitation
of lambdas in other languages. And provided I get some kind of
anonymous code block to pass around I don't care too much if the
name lambda disappears, provided the concept remains! And the
syntax is reasonably simple to use where lambdas get used now.

(Without lambdas of any kind I might finally make the jump 
to Ruby that I've been toying with for a while but I just hate
those Perl-like @ symbols...)


We often see people stating that programming shouldn't be called
a science because there is no mathematical basis, such claimants
usually haven't seen Predicate or Lambda calculus. I know, I used
to be in that category and while I don't explicitly use either
when programming (or only rarely) awareness of the principles
suddenly made a lot of the "rules of programming" that I'd been
taught make perfect sense (no side-effects, avoid globals, etc)
Its like the fact that I rarely use Maxwell's equations when
designing electronic circuits - but its nice to 
know what the underlying theory is actually based on!


All IMHO of course! :-)

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: OT: spacing of code in Google Groups

[JanC]

Peter Hansen schreef:

> Steve Holden wrote:
>
>> Or even used cut(1) from the command line.
> 
> Or myybe not :-)
> 
> Microsoft Windows XP [Version 5.1.2600]
> (C) Copyright 1985-2001 Microsoft Corp.
> 
> c:\>cut
> 'cut' is not recognized as an internal or external command,
> operable program or batch file.

Microsoft Windows 2000 [versie 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\>cut
cut: u moet een lijst van bytes, tekens, of velden geven
Probeer `cut --help' voor meer informatie.


Seems to work just fine...  :-P

Have a look at: 
They have native win32 builds of many of the GNU commandline utilities...


-- 
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[Jeff Shannon]

Paul Rubin wrote:
Richard Feynman told a story about being on a review committee for
some grade-school science textbooks.  One of these book said something
about "counting numbers" and it took him a while to figure out that
this was a new term for what he'd been used to calling "integers".
With all due respect to Richard Feynman, I'd have thought that 
"counting numbers" would be non-negative integers, rather than the 
full set of integers...  which, I suppose, just goes to show how 
perilous it can be to make up new, "more natural" terms for things. ;)

Jeff Shannon
Technician/Programmer
Credit International
--
http://mail.python.org/mailman/listinfo/python-list

Help uninstalling/installing Python 2.4

[Baggs]

Guys/Gals
I've messed up my Python 2.4 install.  I'm really new to Python (and 
Linux for that matter) and really wanted to try Python out.

I have mandrake 10.1.  The first thing I did was uninstalled via rpm 
Python 2.3 and Tkinter 8.3 (I now realize that was a mistake, since I 
could have both version installed with no problems).  I then downloaded 
Python2.4 ran ./configure make and make install... voila I had Python 
installed...

Tk calls did not work, the output from Python when running a program 
stated that I probably did not have TK installed.  I got and installed 
TK 8.4 and the problem persisted (I know I should have written down the 
exact error, but I didn't... but the story gets worse!)

Here is the really stupid part... I figured if I uninstalled and 
re-installed everything would be ok the bad part is I could not find 
an uninstaller for TK or Python, so I just searched and delted the files 
and directorys from /usr/local when I re-installed I still have 
problems.. everything installs ok, but now I get the following errors 
with Python...

bash: /usr/bin/python: No such file or directory
The interesting thing is the python executable is in /usr/local/bin
when I go to /usr/local/bin and type ./python I get
Python 2.4 (#6, Jan  7 2005, 18:44:57)
[GCC 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Traceback (most recent call last):
  File "/etc/pythonrc.py", line 2, in ?
import readline
ImportError: No module named readline
I think some paths are screwed up.. can someone take pity on me and give 
me a hand.

Thanks
Darrin
PS -- if you want to mail me directly remove the --spamreallysucks-- in 
my email address.

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

Re: AttributeError of a module instance

[holger krekel]

On Mon, Dec 26, 2005 at 17:41 +, Paolino wrote:

> I'd like to catch AttributeError on the module level,so that  I can 
> declare default bindings for useds defore definition.How is this  to be 
> done?Thanks for help.

It cannot be done directly but with a small hack. This is
the idea: 

import sys 

class A: 
def __getattr__(self,name): 
if name[:1] != '_': 
return name
raise AttributeError(name) 

sys.modules['a'] = A()
import a 
print a.helloworld # will print "helloworld"


Note, that subsequently you can "import a" also
from other modules because the import statement
consults sys.modules.   

This is all a bit bothersome and thus it's often 
easier to just do "from somemod import a" directly
and forget about the above magic. 

cheers, 

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

Re: switching an instance variable between a property and a normal value

[Steven Bethard]

Robert Brewer wrote:
Steven Bethard wrote:
I'm playing around with a mapping type that uses setdefault 
as suggested 
in http://www.python.org/moin/Python3_2e0Suggestions.  The 
default value 
for a missing key is either a simple value, or a value 
generated from a 
function.  If it's generated from the function, it should be 
generated 
new each time so that, for example, if the default is an empty list, 
d[1] and d[2] don't access the same list.  This is why 'c.x is c.x' 
should be False if I'm using the function.

The best option I guess is to rewrite this with a 
_getdefault() function instead of a property:

But I was hoping to avoid having two separate attributes (self._value 
and self._func) when only one should have a value at any given time.

It seems to me like you were using the property as a glorified flag.
Just use a flag.
ftypes = ('BuiltinFunctionType', 'BuiltinMethodType',
  'FunctionType', 'GeneratorType', 'LambdaType',
  'MethodType', 'UnboundMethodType',)
class D(dict):
def __init__(self):
self._default = None
self._call_default = False
def __getitem__(self, key):
if not key in self:
if self._call_default:
self[key] = self._default()
else:
self[key] = self._default
return dict.__getitem__(self, key)
def setdefaultvalue(self, value):
self._default = value
self._call_default = isinstance(value, ftypes)
...or:
def setdefaultvalue(self, value, call_callables=True):
self._default = value
self._call_default = callable(value) and call_callables
Well, the right solution using a flag for the particular behavior I was 
looking for would have to look something like:

class D(dict):
def __init__(self):
self._default = None
self._call = False
def __getitem__(self, key):
if not key in self:
if self._call:
func, args, kwds = self._default
self[key] = func(*args, **kwds)
else:
self[key] = self._default
return dict.__getitem__(self, key)
def setdefault(self, value, call=False, *args, **kwds):
if call:
self._default = value, args, kwds
else:
self._default = value
self._call = call
where I also accept *args and **kwds when the default value is to be 
called.  It's certainly doable with a flag, but note that I have to 
check the flag every time in both __getitem__ and setdefault.  It'd 
minimize redundancy a bit if I only had to check it in one place.  Guess 
I could do something like:

class D(dict):
def __init__(self):
self._default = None
self._call_default = False
def __getitem__(self, key):
if not key in self:
self[key] = self._default()
return dict.__getitem__(self, key)
def setdefault(self, value, call=False, *args, **kwds):
if call:
def caller():
return value(*args, **kwds)
else:
def caller():
return value
self._default = caller
Then I only have to test call when setdefault is called.  Not sure I 
like this any better though...

Steve
P.S.  The reason I had two functions, setdefaultvalue and 
setdefaultfunction has to do with argument parsing for 
setdefaultfunction.  Note that

def setdefault(self, value, call=False, *args, **kwds):
...
means that you can't call functions with keyword arguments 'value' or 
'call'.  That means I have to rewrite this function as something like

def setdefault(*args, **kwds):
self = args[0]
value = args[1]
call = ???
...
The problem is, if 'call' is a keyword argument, I don't know whether it 
was intended as one of the function arguments or as an argument to 
setdefault.

If setdefaultvalue and setdefaultfunction are two separate methods, I 
don't run into this problem.
--
http://mail.python.org/mailman/listinfo/python-list

Re: "A Fundamental Turn Toward Concurrency in Software"

[John Roth]

"aurora" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Hello!
Just gone though an article via Slashdot titled "The Free Lunch Is Over: A 
Fundamental Turn Toward Concurrency in Software" 
[http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues that the 
continous CPU performance gain we've seen is finally over. And that future 
gain would primary be in the area of software concurrency taking advantage 
hyperthreading and multicore architectures.

Perhaps something the Python interpreter team can ponder.
Well, yes. However, it's not as bad as it looks. I've spent a good part
of my professional life with multiprocessors (IBM mainframes) and
I have yet to write a multi-thread program for performance reasons.
All of those systems ran multiple programs, not single programs
that had to take advantage of the multiprocessor environment.
Your typical desktop is no different. My current system has 42
processes running, and I'd be willing to bet that the vast majority
of them aren't multi-threaded.
There are a relatively small number of places where multi-threading
is actually useful; many programmers will never run into an application
where they need to use it.
I think it would be a good idea for the Python team to address
decent support for multiprocessors, but I hardly think it is a crisis.
John Roth
--
http://mail.python.org/mailman/listinfo/python-list

Re: Getting rid of "self."

[Sean Ross]

"BJörn Lindqvist" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
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:
[snip ...]
But beyond that, I have no idea and I would be grateful if someone
would like to help me with it.


http://starship.python.net/crew/mwh/hacks/selfless.py


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

Re: Notification of PEP Updates

[Steven Bethard]

Bengt Richter wrote:
On Sat, 08 Jan 2005 03:28:34 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:

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.
How does one get to editing one's settings?

Go to the bottom of the page
http://mail.python.org/mailman/listinfo/python-checkins
under "Python-checkins Subscribers", fill in your email address and 
click "Unsubscribe or edit options".  Fill in the "password" field on 
the next page and click "Log in".  The topic option should be near the 
bottom of the page.

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

Re: Securing a future for anonymous functions in Python

[Bengt Richter]

On 07 Jan 2005 13:24:39 -0800, Paul Rubin  wrote:

>Nick Coghlan <[EMAIL PROTECTED]> writes:
>> 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 ;)
>
>Richard Feynman told a story about being on a review committee for
>some grade-school science textbooks.  One of these book said something
>about "counting numbers" and it took him a while to figure out that
>this was a new term for what he'd been used to calling "integers".
>
>"Integer" is a math term but I think that if we need to use the
>concept of integers with someone unfamiliar with the term, it's best
>to just introduce the term and then use it, rather than make up new
>terminology like "counting numbers" even if those words sound more
>like conversational English.

It's an example of the educational establishment's conspiracy to keep
children from too quickly outshining teachers who feel threatened by raw
intelligence rather than elated at the opportunity to help it form.
Forcing kids to learn a throwaway baby-goo language before they
get the real thing is a kind of abuse IMO.


>
>For the same reason I don't have any problem with "lambda", though
>it's not that big a deal.
>
>I also just can't believe that Pythonistas keep getting into these
>arguments over whether lambda is too confusing, while at the same time
>there's no such discussion over far more abstruse Python features like
>metaclasses.
Some things are considered to be behind the pythonostasis and only for the 
priests? ;-)

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

RE: Exception report library

[Robert Brewer]

Ian Bicking wrote:
> I've been using one of several systems to catch unexpected 
> exceptions and log them (e.g., write to a file, display on
> web page, email me, etc).  But many are built into a
> particular system, or have an interesting but incomplete
> set of features...
> I feel like there must be something out there, since every Python 
> programmer has to deal with this sort of thing to some degree...?

And I replied:
> I feel that way, too, but haven't found it...If we could put our
> many heads together, I think this would be doable for the stdlib.

Ian:
> I'm not optimistic about a good exception handler in the standard 
> library; development slows down a lot at that point, and it's not a 
> reasonable candidate until it is designed and used

Sure; I understand it's a long process, and should start independently.

Me again:
> Here are the pieces of the framework, by the way, which might also
> benefit from some standardization:
> 
>1. Thread-safe application state
>2. Logging (+ exception handling)
>3. Configuration data (reading from various sources)
>4. Registry of Workers for getting things done on a schedule,
> possibly recurring
>5. Registry of startup/shutdown functions
>6. Registry of active user interfaces
> 
> I think the first three are all good candidates for a standard.
> If we had a standard, thread-safe Application object, the rest
> could be registerable plugins for that. You'd basically register 
> callbacks for app.startup and .shutdown methods to iterate over.

Ian:
> Hmm... I'm confused by these bits.  Are you talking about 
> libraries for other parts of a web framework, besides exception
> handling? If so, you might want to look into WSGI...

Those are the bits I pulled out as specifically non-web-specific, which
could be used for any kind of app (and tend to get rewritten for every
framework). If your app is single-process, multi-threaded, it needs a
state manager so two threads don't load or destroy global resources
simultaneously. Most apps need logging and uncaught exception handling
(as you noticed). Etcetera. One way to meet these needs once-and-for-all
would be to have a (eventually standard) library for them, where you
could mix and match the pieces you needed.

So, you could write WSGI consumers of them, but they wouldn't be
WSGI-specific in my mind. If they were, they'd just add to the "several
systems" you were lamenting... ;)


Robert Brewer
MIS
Amor Ministries
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: OT: google groups bug, or worse?

[olsongt]

[EMAIL PROTECTED] wrote:
> I'm concerned that google groups is not correctly reflecting the
> python lists.  A month ago I announced the xsdbXML framework to the
> python list and the python-announce list.  As you can see from the
> links
> below the python announce submission was approved by the moderators
> (thanks!)
> and the python list submission also went out, but the messages cannot
> be found at google groups.
>
>
http://mail.python.org/pipermail/python-list/2004-December/254479.html
>
http://mail.python.org/pipermail/python-announce-list/2004-December/003583.html
>
> Is it a google bug?  Or is it something darker, like an anti-Python
> conspiracy at google?
>
> Inquiring minds want to know.
>
> -- Aaron Watters
>
> ===
> There are 3 kinds of people, those who can count and those who can't.
> -- folklore.

Exact same thing happened to me on Jan 2nd.

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

Re: "A Fundamental Turn Toward Concurrency in Software"

[Steve Horsley]

Jack Diederich wrote:
On Fri, Jan 07, 2005 at 01:35:46PM -0800, aurora wrote:
Hello!
Just gone though an article via Slashdot titled "The Free Lunch Is Over: A  
Fundamental Turn Toward Concurrency in Software"  
[http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues that the  
continous CPU performance gain we've seen is finally over. And that future  
gain would primary be in the area of software concurrency taking advantage  
hyperthreading and multicore architectures.

It got most things right, AMD & Intel are moving towards multiple cores on
a chip so programmers will adapt.  I don't see this as a big deal, the current
trend is rack farms of cheap boxes for heavy computing needs.  Multi-core CPUs
will help those kinds of applications more than single threaded ones.  Existing
threaded apps don't have to worry at all.
But my understanding is that the current Python VM is single-threaded 
internally,
so even if the program creates multiple threads, just one core will be dividing
its time between those "threads".
His picking on Intel to graph CPU speeds was a mistake (I'll be generous and
not say deliberate).  Intel screwed up and pursued a megahertz-at-all-costs
strategy for marketing reasons.  AMD didn't worry about MHz, just about CPUs
that did more work and so AMD is eating Intel's lunch.  Intel has abandoned
their "faster" line of processors and is using their CPUs that are slower in
MHz but get more work done.   So the author's "MHz plateau" graph isn't all
Moore's law breaking down, it is the result of Intel's marketing dept breaking
down.
You may be right, but I agree with the thrust of the article that multicore
looks to be the new in thing at the moment. 

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

Re: Tkinter, Alt, and Windows

[Tim Daneliuk]

Tim Daneliuk wrote:
Arggg.  I have a program that runs comfortably across both Unix 
variants
and Windows ... except  I wish to bind an Alt-ButtonRelease-3 
combination
to popup a menu.  This works flawlessly under Unix, but with windows,
the menu appears briefly and then disappears.  I'm guessing that Alt
under windows generates another event that I am not catching and the
default internal Tk message handler is processing it and causing my
menu to get destroyed.

It seems that any combination involving the Alt key has this issue -
for example Control-Alt-ButtonRelease-3 does the same thing.
Has anyone else run into this behavior and have a fix???
I have a partial workaround but the mechanics still mystify me.
I actually was trying to bind two different popup menus to as follows:
Alt-ButtonRelease-3   Menu1
Alt-Control-ButtonRelease-3   Menu2
This did not work ... so I began to wonder if this was problem
with Tk using greedy matching with event descriptors.  So, I changed
it as follows:
Control-ButtonRelease-3   Menu1
Alt-Control-ButtonRelease-3   Menu2
This now works fine, BUT ONLY if Alt is pressed *before* Control when popping up
Menu2.  IOW Windows is sensitive to the *order* of Alt being applied where
Unix is not.  Very, very strange ...

--

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

RE: switching an instance variable between a property and a normal value

[Robert Brewer]

Steven Bethard wrote:
> I'm playing around with a mapping type that uses setdefault 
> as suggested 
> in http://www.python.org/moin/Python3_2e0Suggestions.  The 
> default value 
> for a missing key is either a simple value, or a value 
> generated from a 
> function.  If it's generated from the function, it should be 
> generated 
> new each time so that, for example, if the default is an empty list, 
> d[1] and d[2] don't access the same list.  This is why 'c.x is c.x' 
> should be False if I'm using the function.
> 
> The best option I guess is to rewrite this with a 
> _getdefault() function instead of a property:
> 
> But I was hoping to avoid having two separate attributes (self._value 
> and self._func) when only one should have a value at any given time.

It seems to me like you were using the property as a glorified flag.
Just use a flag.

ftypes = ('BuiltinFunctionType', 'BuiltinMethodType',
  'FunctionType', 'GeneratorType', 'LambdaType',
  'MethodType', 'UnboundMethodType',)

class D(dict):
def __init__(self):
self._default = None
self._call_default = False
def __getitem__(self, key):
if not key in self:
if self._call_default:
self[key] = self._default()
else:
self[key] = self._default
return dict.__getitem__(self, key)
def setdefaultvalue(self, value):
self._default = value
self._call_default = isinstance(value, ftypes)

...or:

def setdefaultvalue(self, value, call_callables=True):
self._default = value
self._call_default = callable(value) and call_callables


Robert Brewer
MIS
Amor Ministries
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: OT: google groups bug, or worse?

[Bengt Richter]

On 7 Jan 2005 11:59:25 -0800, [EMAIL PROTECTED] wrote:

>I'm concerned that google groups is not correctly reflecting the
>python lists.  A month ago I announced the xsdbXML framework to the
>python list and the python-announce list.  As you can see from the
>links
>below the python announce submission was approved by the moderators
>(thanks!)
>and the python list submission also went out, but the messages cannot
>be found at google groups.
>
>http://mail.python.org/pipermail/python-list/2004-December/254479.html
>http://mail.python.org/pipermail/python-announce-list/2004-December/003583.html
>
>Is it a google bug?  Or is it something darker, like an anti-Python
>conspiracy at google?
>
>Inquiring minds want to know.
>
What did you google with? Is this it?
http://groups-beta.google.com/groups?hl=en&ie=UTF-8&q=%22The+xsdbXML+framework+provides+a+flexible+and+well+defined+infrastructure%22&qt_s=Search+Groups

I.e., searching for one of the first lines in your references

"The xsdbXML framework provides a flexible and well defined infrastructure"

in google groups.

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

Re: Notification of PEP Updates

[Bengt Richter]

On Sat, 08 Jan 2005 03:28:34 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:

>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.
How does one get to editing one's settings?

>
>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).
>
Sounds good.

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

Tkinter, Alt, and Windows

[Tim Daneliuk]

Arggg.  I have a program that runs comfortably across both Unix variants
and Windows ... except  I wish to bind an Alt-ButtonRelease-3 combination
to popup a menu.  This works flawlessly under Unix, but with windows,
the menu appears briefly and then disappears.  I'm guessing that Alt
under windows generates another event that I am not catching and the
default internal Tk message handler is processing it and causing my
menu to get destroyed.
It seems that any combination involving the Alt key has this issue -
for example Control-Alt-ButtonRelease-3 does the same thing.
Has anyone else run into this behavior and have a fix???
TIA,

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

Re: The Industry choice

[Stefan Axelsson]

Bulba! wrote:
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?
Well, to your first question, in a word 'no', it wouldn't count as 
source code. To quote the GPL section 3:

"The source code for a work means the preferred form of the work for 
making modifications to it. For an executable work, complete source code 
means all the source code for all modules it contains, plus any 
associated interface definition files, plus the scripts used to control 
compilation and installation of the executable."

As the preferred form for making changes to Python programs would be 
Python source, that's what counts. This is also what forbids obfuscated 
code. If you were to *write* Python bytecode, as a form of assembly, 
then of course that's another matter.

I've released Python source as GPL and as far as I'm concerned it ought 
to work, even though that's not explicitly covered. As the only way 
you're going to receive my program is by receiving the source then 
you'll end up having it and everything's basically OK. If someone tries 
to make a binary from that and distribute that without also making the 
source available then the GPL obviously comes into effect, and the game 
is up. I haven't sought legal (or FSF) input on this matter though, it's 
just my understanding. You can be fairly confident that the GPL is iron 
clad though, it would have been dragged through every court in the land 
by now if it wasn't.

I've also followed the LGPL/GPL library debate, and while I have 
opinions on that as well, this is getting long in the tooth already.

Stefan,
--
Stefan Axelsson  (email at http://www.cs.chalmers.se/~sax)
--
http://mail.python.org/mailman/listinfo/python-list

Re: switching an instance variable between a property and a normal value

[Steven Bethard]

Robert Brewer wrote:
Steven Bethard wrote:
I'd like to be able to have an instance variable that can 
sometimes be 
accessed as a property, and sometimes as a regular value, 
e.g. something 
like:
...
py> c.x is c.x # I'd like this to be False

You'd like 'c.x is c.x' to be FALSE? You can't be serious. Must be a
typo.
Hmm... maybe I better give the larger context.  The short answer is no, 
I'm serious.

I'm playing around with a mapping type that uses setdefault as suggested 
in http://www.python.org/moin/Python3_2e0Suggestions.  The default value 
for a missing key is either a simple value, or a value generated from a 
function.  If it's generated from the function, it should be generated 
new each time so that, for example, if the default is an empty list, 
d[1] and d[2] don't access the same list.  This is why 'c.x is c.x' 
should be False if I'm using the function.

Some more context:
Before I added the ability to use a function, my code looked something like:
py> class D(dict):
... def __init__(self):
... self._default = None
... def __getitem__(self, key):
... if not key in self:
... self[key] = self._default
... return dict.__getitem__(self, key)
... def setdefaultvalue(self, value):
... self._default = value
...
py> d = D()
py> d[0]
py> d.setdefaultvalue(0)
py> d[1]
0
py> d[2] += 1
py> d
{0: None, 1: 0, 2: 1}
To add the ability to use a function to create the default value, it 
would have been nice to leave basically the same code I already had and 
do something like:

py> class D(dict):
... def __init__(self):
... self._default = None
... def __getitem__(self, key):
... if not key in self:
... self[key] = self._default
... return dict.__getitem__(self, key)
... def setdefaultvalue(self, value):
... self._default = value
... def setdefaultfunction(self, func, *args, **kwds):
... self._func, self._args, self._kwds = func, args, kwds
... self._default = D._defaultfunc
... def _get(self):
... return self._func(*self._args, **self._kwds)
... _defaultfunc = property(_get)
...
Of course, this doesn't work for the reasons that I discussed, but the 
idea would be that D would use a regular attribute when a simple value 
was needed, and a property when a value had to be generated by a 
function each time.

The best option I guess is to rewrite this with a _getdefault() function 
instead of a property:

py> class D(dict):
... _undefined = object()
... def __init__(self):
... self._value = None
... self._func = self._undefined
... def __getitem__(self, key):
... if not key in self:
... self[key] = self.getdefault()
... return dict.__getitem__(self, key)
... def getdefault(self):
... if self._value is not self._undefined:
... return self._value
... if self._func is not self._undefined:
... return self._func(*self._args, **self._kwds)
... def setdefaultvalue(self, value):
... self._value = value
... self._func = self._undefined
... def setdefaultfunction(self, func, *args, **kwds):
... self._func, self._args, self._kwds = func, args, kwds
... self._value = self._undefined
...
But I was hoping to avoid having two separate attributes (self._value 
and self._func) when only one should have a value at any given time.

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

Re: "A Fundamental Turn Toward Concurrency in Software"

[Jack Diederich]

On Fri, Jan 07, 2005 at 01:35:46PM -0800, aurora wrote:
> Hello!
> 
> Just gone though an article via Slashdot titled "The Free Lunch Is Over: A  
> Fundamental Turn Toward Concurrency in Software"  
> [http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues that the  
> continous CPU performance gain we've seen is finally over. And that future  
> gain would primary be in the area of software concurrency taking advantage  
> hyperthreading and multicore architectures.

It got most things right, AMD & Intel are moving towards multiple cores on
a chip so programmers will adapt.  I don't see this as a big deal, the current
trend is rack farms of cheap boxes for heavy computing needs.  Multi-core CPUs
will help those kinds of applications more than single threaded ones.  Existing
threaded apps don't have to worry at all.

His picking on Intel to graph CPU speeds was a mistake (I'll be generous and
not say deliberate).  Intel screwed up and pursued a megahertz-at-all-costs
strategy for marketing reasons.  AMD didn't worry about MHz, just about CPUs
that did more work and so AMD is eating Intel's lunch.  Intel has abandoned
their "faster" line of processors and is using their CPUs that are slower in
MHz but get more work done.   So the author's "MHz plateau" graph isn't all
Moore's law breaking down, it is the result of Intel's marketing dept breaking
down.

-Jack

ps, I started a python corner to my blog, http://jackdied.com/python
Only one substantial post yet, and the RSS feed isn't up, but there ya go.

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

Returning same type as self for arithmetic in subclasses

[Max M]

# -*- coding: latin-1 -*-
"""
I subclass datetime and timedelta
>>> dt = myDatetime(1970,1,1)
>>> type(dt)

>>> td = myTimedelta(hours=1)
>>> type(td)

But when I do arithmetic with these classes, they return datetime and 
timedelta,
where I want them to return myDatetime and myTimedelta

>>> new_time = dt + td
>>> new_time
datetime.datetime(1970, 1, 1, 1, 0)
>>> type(new_time)

So I wondered if there was a simlpler way to coerce the result into my 
desired
types rather than overwriting the __add__, __sub__ etc. methods?

"""
from datetime import datetime, timedelta
class myDatetime(datetime):
pass
class myTimedelta(timedelta):
pass
if __name__ == "__main__":
import os.path, doctest, dtime
# import and test this file
doctest.testmod(dtime)

--
hilsen/regards Max M, Denmark
http://www.mxm.dk/
IT's Mad Science
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python Operating System???

[Bengt Richter]

On Fri, 07 Jan 2005 16:34:48 -, [EMAIL PROTECTED] (Michael Hobbs) wrote:

>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.)
I'd say look at Ada for HLL inspiration, if you want to deal with OS level stuff
in Python.

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

Re: Tkinter: passing parameters to menu commands (looping through a list)

[Philippe C. Martin]

>>l_dec.add_command(label=i, command=lambda x=i: self.__Dec(x))

Woof! I'd better do my homework on lambda !

Thanks,

Philippe



-- 
***
Philippe C. Martin
SnakeCard LLC
www.snakecard.com
***

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

Re: What could 'f(this:that=other):' mean?

[Jonathan Fine]

Jeff Shannon wrote:
Jonathan Fine wrote:

The use of *args and **kwargs allows functions to take a variable number 
of arguments.  The addition of ***nsargs does not add significantly.  
I've posted usage examples elsewhere in this thread.
I think they show that ***nsargs do provide a benefit.
At least in these cases.
How significant is another matter.  And how often do they occur.

Now, though, we've lost the ability to specify *only* the argname and 
not the namespace as well -- that is, you *cannot* call f4 with keywords 
but not namespaces.  From the caller's vantage point, this means that 
they need to know the full namespace spec of the function, which makes 
it no different than simply using longer (but unique) keyword names.
This is a major point.
From the caller's point of view:
  fn_1(x_aa=1, x_bb=2, y_aa=3)
  fn_2(x:aa=1, x:bb=2, y:aa=3)
are very similar.  Replace '_' by ':'.
So you are saying, I think, 'what does this buy the caller'.
Well, by using ':' the namespacing is explicit.
  fn_3(my_path, my_file, any_file)
Is this an example of implicit namespacing? (Rhetorical question.)
Explicit is better than implicit, I'm told (smile).

So, we can see that allowing namespaces and ***nsargs doesn't add any 
utility from the caller's perspective.  How much does the callee gain 
from it?

Well, the following functions would be equivalent:
def g1(arg1, arg2, arg3, arg4):
ns1 = {'arg1':arg1, 'arg2':arg2, 'arg3':arg3, 'arg4':arg4}
return ns1
def g2(ns1:arg1, ns1:arg2, ns1:arg3, ns1:arg4):
return ns1
You might say "Wow, look at all that repetetive typing I'm saving!" But 
that *only* applies if you need to stuff all of your arguments into 
dictionaries.  
This is a key point.  But there's more to it.
Namespace arguments are good if you have to divide the arguments into
two or more dictionaries.  Based on the namespace prefix.
I suspect that this is a rather small subset of 
functions.  In most cases, it will be more convenient to use your 
arguments as local variables than as dictionary entries.
This is a matter of usage.  If the usage is very, very small, then
what's the point.  If the usage is very, very large, then the case
is very strong.
def gcd1(a, b):
while a:
a, b = b%a, a
return b
def gcd2(ns1:a, ns1:b):
while ns1['a']:
ns1['a'], ns1['b'] = ns1['b']%ns1['a'], ns1['a']
return ns1['b']
Speaking of repetetive typing :P
Besides, another function equivalent to the above two would be:
def g3(arg1, arg2, arg3, arg4):
ns1 = locals()
return ns1
which is quite a bit less repetetive typing than the 'namespace' 
version.
These are not good examples for the use of namespacing.
And the results are horrible.
So this is an argument _in favour_ of namespacing.
Namely, that it _passes_ "there should be one (and preferably only one) 
obvious way to do things" test (quoted from your earlier message).


So, you're looking at making the function-calling protocol significantly 
more complex, both for caller and callee, for the rather marginal gain 
of being able to get arguments prepackaged in a dictionary or two, when 
there already exist easy ways of packaging function arguments into a 
dict.  Given the deliberate bias against adding lots of new features to 
Python, one needs a *much* better cost/benefit ratio for a feature to be 
considered worthwhile.
I believe that we _agree_, that it is a matter of cost/benefit ratio.
My opinion is that studying usage examples is a good way of evaluating
this ratio.  Which is why I have posted some favourable usage examples.

I'd note also that the usage you're drawing from, in XML/XSLT, isn't 
really comparable to function parameters.  It's a much closer parallel 
to object attributes.  Python *does* have this concept, but it's spelled 
differently, using a '.' instead of a ':'.  In other words, the XML 
fragment you give,


 would be more appropriate to render in Python as
e = Element()
e.this.that = 'other'
It's quite reasonable to suppose that some object of type Element may 
have a set of font attributes and a set of image attributes, and that 
some of these may have the same name.  Python would use font objects and 
image objects instead of 'namespaces' --

e.font.size = '14pt'
e.image.size = (640, 480)
So while these namespaces are probably a great thing for XML, XSLT, 
they're not very useful in Python.  Which, given the rather different 
goals and design philosophies behind the languages, shouldn't really be 
much of a surprise.
It may be better, in some cases, to write
  fp = FontParams()
  fp.size = 14
  fp.slope = 0.1
  f(this=this, font_params=fp)
But not, I think, if the definition of f is something like:
  def f(this, font_params):
  fpd = font_params.__dict__
  font_function(**fpd)
(Assuming that font_function has got it right.)
Prompted by your post, the idea of writing
  f(this.that='other')
instead of
  f(t

Re: Securing a future for anonymous functions in Python

[Bengt Richter]

On 07 Jan 2005 14:38:01 +0100, Jacek Generowicz <[EMAIL PROTECTED]> 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.
Actually, it may _usually_ be silly, but it could be a way of deferring
a name lookup instead of using the current binding of a name:

 >>> def bar(): return 'this is bar'
 ...
 >>> def foo(f=bar): print f()
 ...
 >>> def bar(): return 'this is updated bar'
 ...
 >>> foo()
 this is bar
 >>> def foo(f=lambda:bar()): print f()
 ...
 >>> foo()
 this is updated bar
 >>> def bar(): return 'this updated bar was picked up by silly lambda'
 ...
 >>> foo()
 this updated bar was picked up by silly lambda

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

Re: Tkinter: passing parameters to menu commands (looping througha list)

[Michael Fuhr]

"Philippe C. Martin" <[EMAIL PROTECTED]> writes:

> l_dec_list = ['ATR','IN']
>
> for i in l_dec_list:
>   l_dec.add_command(label = i, command= lambda: self.__Dec(i))

Give the lambda an argument with a default:

l_dec.add_command(label=i, command=lambda x=i: self.__Dec(x))

-- 
Michael Fuhr
http://www.fuhr.org/~mfuhr/
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Paul Rubin]

[EMAIL PROTECTED] (Roy Smith) writes:
> Something along the lines of:
> 
> words = input.split()
> print words[4], words[5]

That throws an exception if there are fewer than 6 fields, which might
or might not be what you want.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "A Fundamental Turn Toward Concurrency in Software"

[Paul Rubin]

aurora <[EMAIL PROTECTED]> writes:
> Just gone though an article via Slashdot titled "The Free Lunch Is
> Over: A  Fundamental Turn Toward Concurrency in Software"
> [http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues that
> the  continous CPU performance gain we've seen is finally over. And
> that future  gain would primary be in the area of software concurrency
> taking advantage  hyperthreading and multicore architectures.

Well, another gain could be had in making the software less wasteful
of cpu cycles.

I'm a pretty experienced programmer by most people's standards but I
see a lot of systems where I can't for the life of me figure out how
they manage to be so slow.  It might be caused by environmental
pollutants emanating from Redmond.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exception report library

[Ian Bicking]

Robert Brewer wrote:
I've been using one of several systems to catch unexpected exceptions 
and log them (e.g., write to a file, display on web page, email me, 
etc).  But many are built into a particular system, or have an 
interesting but incomplete set of features.  E.g., many web 
frameworks have exception reporters (and the stdlib includes cgitb),
but I want to handle non-web exceptions in the same way as exceptions
from web requests, and that's not generally easy.
...
I feel like there must be something out there, since every Python 
programmer has to deal with this sort of thing to some degree...?

I feel that way, too, but haven't found it. I broke my webapp framework
out of my ORM late last year, and quickly realized how small the core
framework really is (22k, versus 250k for the web bits). Features like
the logging handler could be provided as separate modules, rather than
built into the Application object, and I've been meaning to get around
to that. If we could put our many heads together, I think this would be
doable for the stdlib.
I'm not optimistic about a good exception handler in the standard 
library; development slows down a lot at that point, and it's not a 
reasonable candidate until it is designed and used (in part because of 
that slowdown -- if it's not mature, it is a diservice to the project to 
calcify the interface with such strong backward compatibility 
requirements).  But anyway, hopefully multiple 
people/frameworks/projects could use such a library, done well, as a start.

Here are the pieces of the framework, by the way, which might also
benefit from some standardization (I was thinking about them all at
once):
   1. Thread-safe application state
   2. Logging (+ exception handling)
   3. Configuration data (reading from various sources)
   4. Registry of Workers for getting things done on a schedule,
possibly recurring
   5. Registry of startup/shutdown functions
   6. Registry of active user interfaces
I think the first three are all good candidates for a standard. If we
had a standard, thread-safe Application object, the rest could be
registerable plugins for that. You'd basically register callbacks for
app.startup and .shutdown methods to iterate over.
Hmm... I'm confused by these bits.  Are you talking about libraries for 
other parts of a web framework, besides exception handling?  If so, you 
might want to look into WSGI and then discuss these things on the 
web-sig list (WSGI as a starting point; it doesn't specifically relate 
to many of these ideas, but provides a context in which to develop 
them).  Some of these have been discussed there, like logging, 
configuration, and perhaps aspects of the registration you are thinking 
about.

--
Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.org
--
http://mail.python.org/mailman/listinfo/python-list

Re: Notification of PEP Updates

[Erik Max Francis]

Nick Coghlan wrote:
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.
Maybe someone could roll this into an RSS feed?
--
Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
  There's a reason why we / Keep chasing morning
  -- Sandra St. Victor
--
http://mail.python.org/mailman/listinfo/python-list

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

[Roy Smith]

In article <[EMAIL PROTECTED]>,
Anand S Bisen  <[EMAIL PROTECTED]> 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.

Something along the lines of:

words = input.split()
print words[4], words[5]
-- 
http://mail.python.org/mailman/listinfo/python-list

"A Fundamental Turn Toward Concurrency in Software"

[aurora]

Hello!
Just gone though an article via Slashdot titled "The Free Lunch Is Over: A  
Fundamental Turn Toward Concurrency in Software"  
[http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues that the  
continous CPU performance gain we've seen is finally over. And that future  
gain would primary be in the area of software concurrency taking advantage  
hyperthreading and multicore architectures.

Perhaps something the Python interpreter team can ponder.
--
http://mail.python.org/mailman/listinfo/python-list

RE: Exception report library

[Robert Brewer]

Ian Bicking wrote:
> I've been using one of several systems to catch unexpected exceptions 
> and log them (e.g., write to a file, display on web page, email me, 
> etc).  But many are built into a particular system, or have an 
> interesting but incomplete set of features.  E.g., many web 
> frameworks have exception reporters (and the stdlib includes cgitb),
> but I want to handle non-web exceptions in the same way as exceptions
> from web requests, and that's not generally easy.
...
> I feel like there must be something out there, since every Python 
> programmer has to deal with this sort of thing to some degree...?

I feel that way, too, but haven't found it. I broke my webapp framework
out of my ORM late last year, and quickly realized how small the core
framework really is (22k, versus 250k for the web bits). Features like
the logging handler could be provided as separate modules, rather than
built into the Application object, and I've been meaning to get around
to that. If we could put our many heads together, I think this would be
doable for the stdlib.

Here are the pieces of the framework, by the way, which might also
benefit from some standardization (I was thinking about them all at
once):

   1. Thread-safe application state
   2. Logging (+ exception handling)
   3. Configuration data (reading from various sources)
   4. Registry of Workers for getting things done on a schedule,
possibly recurring
   5. Registry of startup/shutdown functions
   6. Registry of active user interfaces

I think the first three are all good candidates for a standard. If we
had a standard, thread-safe Application object, the rest could be
registerable plugins for that. You'd basically register callbacks for
app.startup and .shutdown methods to iterate over.


Robert Brewer
MIS
Amor Ministries
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: passing parameters to menu commands (looping through a list)

[Philippe C. Martin]

I face a strange behavior when adding menu labels / command parameters
from a list:

*** 
This is the code that works but I wish to avoid - ATR and IN appear in
the menu, and __Dec is called with ATR or IN depending on the choice
***
l_dec.add_command(label = 'ATR', command= lambda: self.__Dec('ATR'))
l_dec.add_command(label = 'IN', command= lambda: self.__Dec('IN'))

*** 
This is the code that does not works but I wish I had - ATR and IN
appear in the menu, but __Dec is always called with the last list item
(IN in this case)

***
l_dec_list = ['ATR','IN']

for i in l_dec_list:
  l_dec.add_command(label = i, command= lambda: self.__Dec(i))



Any clue ?

Regards,

Philippe


-- 
***
Philippe C. Martin
SnakeCard LLC
www.snakecard.com
***

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

Re: args (was Re: Lambda as declarative idiom (was RE: what is lambda used for in real code?))

[Bengt Richter]

On Tue, 04 Jan 2005 14:11:51 -0800, Michael Spencer <[EMAIL PROTECTED]> wrote:
[Hm, this didn't go out for some reason. I'll just send it now.]

>Roman Suzi wrote:
>
>> Maybe this is too outlandish, but I see lambdas as a "quote" mechanism,
>> which presents a possibility to postpone (precisely control, delegate)
>> evaluation. That is, an ovehead for lambda must be much lower but at the
>> same time visible to the programmer:
>> 
>>  d = a + (lambda x, y: x+ y)(3, 4)
>[...]
>
>I believe that this "possibility to postpone" divides into two related but 
>separate concepts: controlling the moment of evaluation, and assembling the 
>arguments required at that moment.  They are both species of 'eval', but 
>managing arguments is more specialized, because it includes possibly renaming 
>parameters, assigning default values, processing positional and keyword 
>arguments, and, perhaps in the future dealing with argument types.
>
I imagine that you should be able to identify bytecode substrings in current 
code
that would have to be part of an implementation of what you are proposing.
But ISTM mabe there's three concepts: 1) defining the formal parameter list,
which is like a template for unpacking and binding an actual arglist produced by
2) the source code for a call of some named function with expression for actual
arguments, and 3) the run time excution of the code compiled from (2).

AFAICS, currently there is no linkage between the called function and the 
calling code
except that the first thing put on the stack is just the result of an 
expression that
_should_ put a reference to a compatible callable on the stack. What follows is 
a sequence
of argument expressions which stack the arg values, and then finally the byte 
code is executed
to make one of several kinds of specialized function calls to use the stack 
contents.
At that point the 'callable' could be None, or another function with the wrong 
signature.

What I see as the deferred-args-evaluation part is the code between pushing the 
callable
reference and making the specialized call. But that can't be what your args 
function is,
since UIAM the 'arguments' to that are not run time calling arguments, but a 
particular
formal parameter signature. That's a guide for unpacking and binding a call's 
arguments
at an associated function's entry, to create a _part_ of the local bindings, 
which has
nothing to do with deferring the evaluation of the call args.


>Meanwhile, GvR wrote (about defining Interfaces in the context of Optional 
>Static Type Checking)
>> Method declarations can be inspected to find out their signature. I propose a
>> __signature__ attribute (also for methods defined in classes!) which might 
>> be an
>> object whose attributes make the signature easily inspectable. This might 
>> take 
>> the form of a list of argument declaration objects giving the name, type and 
>> default
>> (if any) for each argument, and a separate argument for the return type. For 
>> signatures that include *args and/or **kwds, the type of the additional 
>> arguments 
>> should also be given (so you can write for example a varargs method whose 
>> arguments
>> are all strings).
>
>GvR's method.__signature__ object might be related to the args object I 
>proposed 
>  as part of the syntax for anonymous functions without 'lambda'. i.e.,
>
> args(a,*b,**kw) --> an object that specifies but does not evaluate its 
>parameters until it is supplied to a callable, possibly with calling parameters
This is the part I don't understand. To me, that expression doesn't have 
anything to
do with evaluating parameters, it has to do with unpacking a particular call's 
parameters
after they have been evaluated.  If it could "evaluate ist parameters" it would 
have
to have code in it to do that, but the code for evaluation of parameters is 
generated
from the translation of the calling code. And there might be dozens of lines 
calling
the same function. I.e., args(a,*b,**kw) specifies formal parameter names and 
structural
information for dealing with callers' post-evaluation actual args.

The only way it could have the ability to control evaluation of args is if it 
had a reference
to a deferred-arg-eval byte code snippet. IOw, maybe the function should be 
called argsig instead
of args and args could deal with deferred actual arg evaluation. Then the tuple
argsig(x, y), args(1, 2)
could conceptually be like a bound method for deferred evaluation or args _and_ 
binding to
names in some namespace like a function's local namespace, but maybe not 
necessarily. Maybe
it could be applied to other namspaces as well. ... just musing ;-)

>
>This object would contain the default values, and could contain type 
>annotations, explicit, or inferred, as well as more complex assertions used in 
>several contexts.
But it has to be clear that until a particular calling-args list (deferred or 
not) is
selected by being the "current one" of possibly many, the object doesn't have 
a

Re: DOS problem (simple fix??)

[Paul Rubin]

Gavin Bauer <[EMAIL PROTECTED]> writes:
> Thank you, and please make all answers simple enough to be understood
> by a highschool student and his father :) .

You might like to try IDLE, which is included with Python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python3: 'where' keyword

[Paul Rubin]

Donn Cave <[EMAIL PROTECTED]> writes:
> I don't by any means agree that this notation is worth adopting, and
> in general I think this kind of readability issue is more or less a lost 
> cause for a language with Python's scoping rules, but the motive makes
> sense to me.  

But we're talking about the mythical/hypothetical Python 3, so maybe
there's a chance of fixing the scoping rules, which it seems to me are
currently pretty badly broken.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Other notes

[Bengt Richter]

On Fri, 07 Jan 2005 06:04:01 GMT, Andrew Dalke <[EMAIL PROTECTED]> 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.
So what happens if you apply greediness to a grammar that has both . and ..
as legal tokens? That's the point I was trying to make. The current grammar
unfortunately IMHO tries to tokenize floating point numbers, which creates a 
problem
for both numbers and (if you don't isolate it with surrounding spaces) the .. 
token.

There would UIAM be no problem recognizing 1 .. 2 but 1..2 has the problem that
the current tokenizer recognizes 1. as number format. Otherwise the greediness 
would
work to solve the 1..2 "problem."

IMHO it is a mistake to form floating point at the tokenizer level, and a 
similar mistake
follows at the AST level in using platform-specific floating point constants 
(doubles) to
represent what really should preserve full representational accuracy to enable 
translation
to other potential native formats e.g. if cross compiling. Native floating 
point should IMO
not be formed until the platform to which it is supposed to be native is 
identified.

IOW, I think there is a fix: keep tokenizing greedily and tokenize floating 
point as
a sequence of integers and operators, and let  be 
translated by
the compiler to floating point, and  be translated to 
the
appropriate generator expression implementation.


>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".
>
Exactly. Or I am missing something? (which does happen ;-)

>Compare to "a+ =2".  In this case the tokens are "a", "+", "=", "2"
>and the result is a syntax error.
Sure.
>
>>  >>> for t in tokenize.generate_tokens(StringIO.StringIO('a=b+c; a+=2; 
>> x..y').readline):print t
>>  ...
>
>This reinforces what I'm saying, no?  Otherwise I don't understand
>your reason for showing it.
It does reinforce your saying the matching is greedy, yes. But that led me to
think that .. could be recognized without a problem, given a grammar fix.
>
>>  (51, '+=', (1, 8), (1, 10), 'a=b+c; a+=2; x..y')
>
>As I said, the "+=" is found as a single token, and not as two
>tokens merged into __iadd__ by the parser.
No argument.
>
>After some thought I realized that a short explanation may be helpful.
>There are two stages in parsing a data file, at least in the standard
>CS way of viewing things.  First, tokenize the input.  This turns
>characters into words.  Second, parse the words into a structure.
>The result is a parse tree.
>
>Both steps can do a sort of look-ahead.  Tokenizers usually only look
>ahead one character.  These are almost invariably based on regular
>expressions.  There are many different parsing algorithms, with
>different tradeoffs.  Python's is a LL(1) parser.  The (1) means it
>can look ahead one token to resolve ambiguities in a language.
>(The LL is part of a classification scheme which summarizes how
>the algorithm works.)
>
>Consider if 1..3 were to be legal syntax.  Then the tokenizer
>would need to note the ambiguity that the first token could be
>a "1." or a "1".  If "1." then then next token could be a "."
>or a ".3".  In fact, here is the full list of possible choices
>
>  <1.> <.> <3>same as getattr(1., 3)
>  <1> <.> <.> 3   not legal syntax
>  <1.> <.3>   not legal syntax
>  <1> <..> <3>legal with the proposed syntax.
>
Right, but a grammar fix to handle floating point "properly" (IMHO ;-)
would resolve that. Only the last would be legal at the tokenizer stage.

>Some parsers can handle this ambiguity, but Python's
>deliberately does not.  Why?  Because people also find
I'm not sure what you mean. If it has a policy of greedy matching,
that does handle some ambiguities in a particular way.

>it tricky to resolve ambiguity (hence problems with
>precedence rules).  After all, should 1..2 be interpreted
>as 1. . 2 or as 1 .. 2?  What about 1...2?  (Is it 1. .. 2,
 ^^[1]  ^^^[2]
[1] plainly (given my grammar changes ;-)
[2] as plainly not, since <1> would not greedily accept '.' to make <1.>

>1 .. .2 or 1. . .2 ?)
 ^^[3]  ^^^[4]
[3] no, because greed would recognize an ellipsis <...>
[4] ditto. Greedy tokenization would produce <1> <...> <2> for the compiler.

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

Re: Python Operating System???

[Paul Rubin]

[EMAIL PROTECTED] (Michael Hobbs) writes:
> 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.

But I thought Python was an all-purpose language.  After all, OS's
have been written in Lisp before too.
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: switching an instance variable between a property and a normal value

[Robert Brewer]

Steven Bethard wrote:
> I'd like to be able to have an instance variable that can 
> sometimes be 
> accessed as a property, and sometimes as a regular value, 
> e.g. something 
> like:
...
> py> c.x is c.x # I'd like this to be False

You'd like 'c.x is c.x' to be FALSE? You can't be serious. Must be a
typo.

If you want C._x to return something other than the property descriptor,
you can. Grab the sample code for Property from
http://users.rcn.com/python/download/Descriptor.htm#properties and
modify the __get__ method:

def __get__(self, obj, objtype=None):
if obj is None:
return self# Return whatever you like here
if self.fget is None:
raise AttributeError, "unreadable attribute"
return self.fget(obj)

That might be one way to get what you want.


Robert Brewer
MIS
Amor Ministries
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

[Paul Rubin]

Nick Coghlan <[EMAIL PROTECTED]> writes:
> 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 ;)

Richard Feynman told a story about being on a review committee for
some grade-school science textbooks.  One of these book said something
about "counting numbers" and it took him a while to figure out that
this was a new term for what he'd been used to calling "integers".

"Integer" is a math term but I think that if we need to use the
concept of integers with someone unfamiliar with the term, it's best
to just introduce the term and then use it, rather than make up new
terminology like "counting numbers" even if those words sound more
like conversational English.

For the same reason I don't have any problem with "lambda", though
it's not that big a deal.

I also just can't believe that Pythonistas keep getting into these
arguments over whether lambda is too confusing, while at the same time
there's no such discussion over far more abstruse Python features like
metaclasses.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What could 'f(this:that=other):' mean?

[Jonathan Fine]

Jonathan Fine wrote:

I'll post some usage examples later today, I hope.

Well, here are some examples.  A day later, I'm afraid.
** Pipelines and other composites
This is arising for me at work.
I produce Postscript by running TeX on a document.
And then running dvips on the output of TeX.
TeX as a program has parameters (command line options).
As does dvips.
For various reasons I wish to wrap TeX and dvips.
  def tex_fn(filename, input_path=None, eps_path=None):
'''Run tex on filename.
Search for input files on input_path.
Search for EPS files on eps_path. '''
pass
  def dvips_fn(filename, page_size=None, color_profile=None):
'''Run dvips on filename.  etc.'''
pass
In reality, these tex and dvips have many options.
More parameters will be added later.
So now I wish to produce a composite function, that runs
both tex and dvips.  And does other glue things.
  def tex_and_dvips_fn(filename,
tex:input_path=xxx,
dvips:color_profile=yyy):
# glueing stuff
tex_fn(filename, **tex)
# more glueing stuff
dvips_fn(filename, **dvips)
To avoid a name clash, we use 'tex' for the parameter
space, and 'tex_fn' for the function that takes 'tex'
as parameter.
The point is that parameters can be added to tex_fn and
dvips_fn without our having to change tex_and_dvips_fn
**  Wrapping functions
This is the problem that originally motivated my
suggestion.
We have coded a new function.
  def adder(i, j):  return i + j
We wish to test 'adder'.
But unittest is too verbose for us.
We wish to define a decorator (?) test_wrap to
work as follows.
  orig_adder = adder
  adder = test_wrap(adder)
  new_adder = adder
orig_adder(i, j) and new_adder(i, j) to be
effectively identical - same return, same side
effects, raise same exceptions.
So far,
  def test_wrap(fn): return fn
does the job.
But now we want
  new_adder(2, 2, returns=4)
  new_adder(2, '', raises=TypeError)
to be same as
  orig_adder(2, 2)
  orig_adder(2, '')
(which can be achieved by ignoring 'returns' and 'raises'.
The idea here is that we can call
  adder = new(adder)
early on, and not break any working code.
And we also want
  new_adder(2, 2, 5)
  new_adder('', '', raises=TypeError)
to raise something like an AssertionError.
OK - so I have an informal specification of test_wrap.
Its clear, I think, that test_wrap must be something like
  def test_wrap(fn):
def wrapped_fn(*args, **kwargs):
test_args = {}
# transfer entries from one dict to another
for key in ('returns', 'raises'):
if kwargs.has_key(key):
test_args[key] = kwargs[key]
del kwargs[key]
result = fn(args, kwargs)
if test_args.has_key(result):
 assert test_args['result'] = result
(I've not coded testing for 'raises'.)
Now, the more parameters added by the test_wrap function,
the more the chance of a name clash.
So why not reduce the chances by using name spaces.
One possible namespace syntax is:
  new_adder(2, 3, test=dict(returns=5))
Another such syntax is:
  new_adder(2, 3, test:returns=5)
Each has its merits.
The first works with Python 2.4.
The second is, in my opinion, easier on the eye.
Anyway, that's my suggestion.
Jonathan
--
http://mail.python.org/mailman/listinfo/python-list

Re: DOS problem (simple fix??)

[Daniel Bickett]

I tend to run "cmd" and "cd" to the directory of the script, then run
it. This way, the window doesn't close, and I can read any errors that
occur without interruption. Optionally, you can run "cmd" and simply
drag the script you want to run into the window. That pastes its path
(in quotes) into the command line, and you can just hit enter. I
wouldn't recommend this, though, because the cwd wouldn't be that of
the script, and it could cause instability for some apps that use
relative paths.

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

Re: DOS problem (simple fix??)

[beliavsky]

When I have a Python script generating a lot of output, I either open
an output file and then print to it with

fp = open("results.txt","w")
print>>fp,"stuff"

or I redirect output to a file from the command line using ">" (also
works on Unix), for example

python foo.py > results.txt

An alternative is to open a shell buffer within Emacs or XEmacs, two
text editors with Python modes. You can run a Python script from within
the shell buffer, and the results will be printed there. You can move
around the shell buffer as if it were a file.

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

Re: Tkinter: using a Listbox

[Steve]

> #Listbox
> self.listbox = Listbox(self.selectFrame)
> self.listbox.insert(END, "a list entry")
> for item in ["A","B","C"]:
>   self.listbox.insert(END, item)

Don't forget to pack the listbox.

You may find this useful...
http://www.ferg.org/thinking_in_tkinter/index.html

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

Re: Tkinter: passing parameters to menu commands

[Philippe C. Martin]

>>menu.add_cascade(label="File", menu=filemenu)
>>filemenu.add_command(label="New", command=lambda: callback('New'))
>>filemenu.add_command(label="Open...", command=lambda:
callback('Open'))
>>filemenu.add_separator()
>>filemenu.add_command(label="Exit", command=lambda: callback('Exit'))
mainloop()
>>Of course you could do this with named forwarding functions if you
prefer


I'm not sure what 'named forwarding functions' are but I'm actually in a
class and when applying your suggestion in the following manner,
everything works (THANKS!)


def __Dec(self,p_string):
  for i in p_string:
self.__Insert(i)
.
.
.
#menu creation
l_dec.add_command(label = 'ATR', command=lambda: self.__Dec('ATR'))
l_dec.add_command(label = 'IN', command=lambda:self.__Dec('IN'))
.
.
.


Yet I have a question:

If I replace the menu creation code as below, and since __Insert appends
the string p_string into a text widget that is created _after_ the menu
creation; the method __Dec seems to be called at the menu creation and
I get an error in __Insert because the test widget is equal to None.

My reflexes of C programmer tell me that command=self.__Dec just
passes a method pointer (sorry I said it) to add_command - yet it does
not seem to be so.

What is actually going on ?


#menu creation
l_dec.add_command(label = 'ATR', command=self.__Dec('ATR'))
l_dec.add_command(label = 'IN', command=self.__Dec('IN'))





Regards,

Philippe




-- 
***
Philippe C. Martin
SnakeCard LLC
www.snakecard.com
***

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

RE: Display Function Code Body?

[Robert Brewer]

Haibao Tang wrote:
> Hail Python pals! I played with the R (http://r-project.cran.org) last
> night to do some statistics and it has an interactive session too, and
> I found a feature that is quite useful.
> 
> I found by actually typing a function name, the R gives you a 
> code body output.
> 
> > f1 = function(x){x*x}
> > f1
> function(x){x*x}
...
> What I would like to do is to write a function like disp(), 
> when typed, it can give you the code infomation.
> 
> >>> disp(f1)
> 
> def f1(x):
> return x*x
> 

You can do this with lambdas with my LambdaDecompiler inside:
http://www.aminus.org/rbre/dejavu/codewalk.py
If you want to extend it to full functions, be my guest. ;)

There's also a commercial decompiler out there called "decompyle", and
they even have a web service. http://www.crazy-compilers.com/decompyle/


Robert Brewer
MIS
Amor Ministries
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

RE: DOS problem (simple fix??)

[Robert Brewer]

Gavin Bauer wrote:
> My DOS window (running in windows ME) closes the second it finishes
> running my programs. As you can imagine, this makes it hard to see the
> results. I've gotten in the habit of putting raw_input("Press enter to
> exit") at the end of every program, and in addition to being pain in
> the butt, it often fails to work. Being new to programming in general,
> I make more mistakes than most people. My programs often have errors
> before they get to my raw_input command. They then display the error
> and immediately close. It is naturally a lot easier to fix an error
> when you know what the error is. This makes debugging even more
> annoying than it ordinarily would be, if you can imagine that. I've
> heard that it should be a simple preference fix, but I've asked around
> and no one seems to know how.
> 
> Thank you, and please make all answers simple enough to be understood
> by a highschool student and his father :) .

Even after all the IPO hype, the map integration, and the Suggest beta,
Google is STILL your friend:

http://www.google.com/search?q=windows+console+remain+open

In other words, use the /k switch to cmd.exe

Robert Brewer
MIS
Amor Ministries
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: sorting on keys in a list of dicts

[Jeff Shannon]

Nick Coghlan wrote:
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 [...]
Agreed.  I'd started typing before I realized that it'd provide a 
stable sort, which pretty much answered my own question, but decided 
to send it anyhow in case I'd missed anything else... :)

Jeff Shannon
Technician/Programmer
Credit International
--
http://mail.python.org/mailman/listinfo/python-list

Re: The Industry choice

[Scott Robinson]

On Fri, 07 Jan 2005 12:06:42 -0800, Jeff Shannon <[EMAIL PROTECTED]>
wrote:

>Bulba! wrote:
>
>> 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?
>
>Releasing a product in which your code is linked together with GPL'ed 
>code requires that your code also be GPL'ed.  The GPL goes to some 
>lengths to define what exactly "linked together" means.

That looks like a typo.  The LGPL goes to great length to how you can
link to LGPL software without using either the LGPL or GPL.  The GPL
(linked to by fsf.org) merely states:

2.  You may modify your copy or copies of the Program or any
 portion of it, thus forming a work based on the Program, and
copy and distribute such modifications or work under the terms
of Section 1 above, provided that you also meet all of these
conditions:

Note that the conditions are all those of any program released under
the GPL.  Whatever "forming a work based on the Program" means is
whatever you and the copyright owner agree to, or whatever copyright
law considers a derived work in areas you wish to release your code
into.  I would suggest consulting a lawyer before getting close to the
line, but you can expect that any legally enforceable restrictions
claimed by FSF and/or RMS to be legally binding on all software
released under the (L)GPL that the FSF owns the copyright of (they
encourage programmers to sign over copyright to the FSF itself).

>
>Releasing a product in which your code is linked together with LGPL'ed 
>code does *not* require that your code also be (L)GPL'ed.  Changes to 
>the core library must still be released under (L)GPL, but application 
>code which merely *uses* the library does not.  (I've forgotten, now, 
>exactly how LGPL defines this distinction...)
>
>Jeff Shannon
>Technician/Programmer
>Credit International

Scott Robinson

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

Software archeology (was Re: Developing Commercial Applications in Python)

[Aahz]

In article <[EMAIL PROTECTED]>,
Stephen Waterbury  <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] writes:
>>> 
>>>Can somebody there to point me any good commercial applications
>>>developed using python ?
>
>Also see Python Success Stories:  http://pythonology.org/success
>
>A notable example is Verity's search engine -- see
>http://python.oreilly.com/news/PythonSS.pdf

Actually, your statement is slightly inaccurate.  The Verity search
engine is more than fifteen years old in its core technology; it was
started as a LISP project at IIRC MIT.  (At one point I was much amused
to look at the C source code and find car() and cdr() functions.)  As of
my last information, Python isn't used at all in or with the Verity
search engine.  What you're referring to is the Verity Ultraseek engine,
originally written and owned by Infoseek before getting transferred to
Verity through a series of dot-bomb transactions.  The Ultraseek engine
doesn't use Python, but Python is used to control the engine, and I think
much of the spider is written in Python.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing."  --Alan Perlis
-- 
http://mail.python.org/mailman/listinfo/python-list

Tkinter: using a Listbox

[Ebba Cecilia Ovesdotter Alm]

Hello,

I'm learning how to use the Tkinter module. I would like to
use an element similar to a drop-down form,
where the user can select one option out of many. I thought
that a Listbox item could do just this. The following extract
from my code (with the listbox part basically mirroring
http://effbot.org/books/tkinterbook/listbox.htm),
does, however, not create a visable Listbox.  Am I
interpreting the Listbox incorrectly? Ideas or suggestions are
appreciated.

#Frame & label for the listbox
self.selectFrame = Frame(self.root)
self.selectFrame.pack(side=TOP, fill=X, padx=10)
Label(self.selectFrame, text='Primary choice').pack(side=LEFT)
#Listbox
self.listbox = Listbox(self.selectFrame)
self.listbox.insert(END, "a list entry")
for item in ["A","B","C"]:
  self.listbox.insert(END, item)

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