Re: variables exist

[Peter Otten]

Michael J. Fromberger wrote:

> Would the following be a satisfactory implementation?
> 
>   def isset(varname, lloc = locals()):
> return varname in lloc or varname in globals()
> 
> I believe this works as desired:
> 
>   >>> x = 5
>   >>> def f(y):
>   ...   z = 10
>   ...   print isset('z')   ## ==> True
>   ...   print isset('y')   ## ==> True
>   ...   print isset('x')   ## ==> True
>   ...
> 
> Tests:
>   >>> f(1)  ## As shown above

No, try it again in a fresh interpreter:

>>> def isset(name, loc=locals()):
... return name in loc or name in globals()
...
>>> x = 5
>>> def f(y):
... z = 10
... print isset("x"), isset("y"), isset("z")
...
>>> f(42)
True False False
>>>

It may seem from the above that at least the global variable "x" is found
correctly, but beware, the global namespace where isset() is defined is
searched, not the one where it is called. Untested:

def isset(name):
frame = sys._getframe(1)
return name in frame.f_locals or name in frame.f_globals

might work, but is too magic for my taste.

Peter

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

Re: Canceling/interrupting raw_input

[Daniel Cer]

For what it's worth, this looks like a Windows specific problem.
The code below seems to work as expected on a Linux box. That is, 
everything terminates, including the "inputLoop", after sys.exit() is 
called, without the user needing to press 'enter' one last time.

However, if I try to run the code on Windows XP, it exhibits the exact 
same behavior you described.

#!/usr/bin/python
import thread
import time
import sys
def inputLoop():
 while 1:
 input_string = raw_input("Type something: ")
 print "You entered: ", input_string
thread.start_new_thread(inputLoop, () )
time.sleep(15)
sys.exit()
-Dan
J. W. McCall wrote:
I'm working on a MUD server and I have a thread that gets keyboard input 
so that you can enter commands from the command line while it's in its 
main server loop.  Everything works fine except that if a player enters 
the 'shutdown' command, everything shuts down, but the input thread is 
still sitting waiting for enter to be pressed for raw_input.  After 
enter is pressed, it exits back to the command prompt as it should.

I'm wondering if there's a way that I can make the thread stop waiting 
for input.  Even sys.exit() still leaves it waiting.  It's not a big 
deal, but it bugs me.

Any ideas?  Should I be using something other than raw_input?  I'm on 
Windows2000 and running this from the DOS prompt.  I'm using Python 2.4.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Slight discrepancy with filecmp.cmp

[John Machin]

On Sun, 17 Apr 2005 22:06:04 -0600, Ivan Van Laningham
<[EMAIL PROTECTED]> wrote:
[snip]
> So I wrote a set of
>programs to both index the disk versions with the cd versions, and to
>compare, using filecmp.cmp(), the cd and disk version.  Works fine. 
>Turned up several dozen files that had been inadvertantly rotated or
>saved with the wrong quality, various fat-fingered mistakes like that.
>
>However, it didn't flag the files that I know have bitrot.  I seem to
>remember that diff uses a checksum algorithm on binary files, not a
>byte-by-byte comparison.  Am I wrong?  

According to the docs:

"""
cmp( f1, f2[, shallow[, use_statcache]]) 

Compare the files named f1 and f2, returning True if they seem equal,
False otherwise. 
Unless shallow is given and is false, files with identical os.stat()
signatures are taken to be equal
"""

and what is an os.stat() signature, you ask? So did I.

According to the code itself:

def _sig(st):
return (stat.S_IFMT(st.st_mode),
st.st_size,
st.st_mtime)

Looks like it assumes two files are the same if they are of the same
type, same size, and same time-last-modified. Normally I guess that's
good enough, but maybe the phantom bit-toggler is bypassing the file
system somehow. What OS are you running?

You might like to do two things: (1) run your comparison again with
shallow=False (2) submit a patch to the docs.

(-:
You have of course attempted to eliminate other variables by checking
that the bit-rot effect is apparent using different display software,
a different computer, an observer who's not on the same medication as
you, ... haven't you?
:-)


HTH,
John

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

Re: pre-PEP: Suite-Based Keywords

[Shane Hathaway]

Brian Sabbey wrote:
> Maybe using '**' would be better than '...' since it already is used to
> indicate keyword arguments.  Example:
> 
> class C(object):
> x = property(**):
>doc = "I'm the 'x' property."
>def fget(self):
>   return self.__x
>def fset(self, value):
>   self.__x = value
>def fdel(self):
>   del self.__x

Looks good to me.  You should update the pre-PEP and submit it again to
the list.

This syntax might also be a good replacement for event handling when
lambda goes away (as Guido announced in his PyCon 2005 keynote.)

button = Button(self, "Push me")
button.addHandlers(**):
def onmouseover(event):
self.textBox.setText("Are you going to push me?")
def onmouseout(event):
self.textBox.setText("Too shy.  Goodbye.")
def onclick(event):
self.textBox.setText("Ouch!")
oncontextmenu = self.oncontextmenu

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

Re: pre-PEP: Suite-Based Keywords - syntax proposal

[Kay Schluehr]

Steven Bethard wrote:

> So the object of a "where" is then always an ordered dict?

Yes.

> If so, then
> I guess I like this proposal best so far.
>
> However, it does seem to have the problem that you can't have any
> additional local variables so, for example, list comprehensions are
> probably not usable...
>
> Or can you still drop the argument to "where" and just use the names
> directly?  E.g.:
>
> x = property(fget=fget, doc=doc) where:
>  doc = "I'm the 'x' property."
>  def fget(self):
>  return self.__x

I can't see why this shouldn't work?

The specifiers behind "where" are present to determine the matching
behaviour. The order of a dict is caused by different specifiers i.e. a
dict- or tuple-like specifier. If a specifier is not present only names
can be matched regardless of a sequence and this is always possible
because we still have a dict with names as keys.

What should not be possible are statements like this:

 x = property(a, b) where:
  doc = "I'm the 'x' property."
  def fget(self):
  return self.__x

because there is no rule to match doc and fget onto a and b. In this
case we would need specifiers:

 x = property(a, b)
 where **a:
doc = "I'm the 'x' property."
 where **b:
def fget(self):
return self.__x

Ciao,
Kay

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

Re: pre-PEP: Suite-Based Keywords - syntax proposal

[Kay Schluehr]

Bengt Richter wrote:
> On 17 Apr 2005 09:27:34 -0700, "Kay Schluehr" <[EMAIL PROTECTED]>
wrote:
>
> >> Exactly. Except the above example is from the day-old-bread
> >items-tuple-returning version of :: ;-)
> >> And with an ordered dict subtype there is no need for the
generator
> >expression either,
> >> since there is a values method for dicts (which in the subtype
would
> >preserve order). E.g.,
> >>
> >>  x = property(*seq) where:
> >>  seq = (::
> >>  def get_x():
> >>  return self.__x
> >>  def set_x(value):
> >>  self.__x = value
> >>  del_x = None
> >>  doc   = "I'm the 'x' property." ).values())
> >>
> >> Or more directly:
> >>
> >>  x = property(*(::
> >>  def get_x():
> >>  return self.__x
> >>  def set_x(value):
> >>  self.__x = value
> >>  del_x = None
> >>  doc   = "I'm the 'x' property." ).values())
> >
> >Hmmm ... now You eliminate "where" completely in favor for '::'.
This
> >may be reasonable because '::' is stronger and less context
dependent.
> >But on the other hand it may be also reasonable to eliminate '::'
> >towards a stronger "where" ;)
> >
> >
> >x = property(**kw) where kw:
> >doc = "I'm the 'x' property."
> >def fget(self):
> >return self.__x
> >
> >
> >x = property(*args) where args:
> >def fget(self):
> >return self.__x
> >fset = None
> >fdel = None
> >doc = "I'm the 'x' property."
> >
> I like this. But how would you put "where args:" and "where kw:" if
you needed both?
> also, is it looking back to see the '*' or '**' to do (::x=1).values
vs. (::x=1)
> and how about (::x=1).keys() or (::x=1).items() ? And what if you
wanted to pass
> (::x=1) as a dict object without ** expansion into a keyword dict?
>
> Maybe we need asterisks on both ends. e.g.,
>
> foo(dct, values, *args, **kw):
>where **dct:
>   x=1
>where *values:
>   x=2
>where *args:
>   x=3
>where **kw:
>   x=4

Yes... Why not?

>
> But that still doesn't give you, e.g.,
>
>foo(keys) where:
>keys=sorted((::
>from interesting.module import *
>).keys())

This particular statement won't work anyway inside a where-clause
because
"from *" must be called from module level. You would have to import
interesting.module before:

import interesting.module
foo(keys) where:
keys = sorted(interesting.module.__dict__).keys()

But it wasn't ever intended to put arbitrary statements in a kw-suite,
right?

> I like clean sugar, but I still want to be able to
> get at the general primitives to compose them in ways
> that can't be anticipated until a use case comes up.
> And then if the primitives are inaccessible, one is
> out of luck or doomed to workaround hacking ;-)

You can always consider "where" as function of a statement. The only
restriction You have to make is to bind "where" to a function-call i.e.
regard each function as a function object with a where() method.


f(*args,**kw ).where( ,
(|
 |
 )*
)

But that is not a loss of generality because a free (:: x=1 ) can be
mapped onto

  dict(**kw).where(**kw, x=1)

and that is

  dict(**kw) where **kw:
   x=1

I don't see any case where this translation fails. Only if it comes to
functional composition like

  f(g(...(h(:: x=1)...))

it may be awkward to expand this into a nested where clauses. You might
probably define the argument not in a suite ;)

Regards,
Kay

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

Canceling/interrupting raw_input

[J. W. McCall]

I'm working on a MUD server and I have a thread that gets keyboard input 
so that you can enter commands from the command line while it's in its 
main server loop.  Everything works fine except that if a player enters 
the 'shutdown' command, everything shuts down, but the input thread is 
still sitting waiting for enter to be pressed for raw_input.  After 
enter is pressed, it exits back to the command prompt as it should.

I'm wondering if there's a way that I can make the thread stop waiting 
for input.  Even sys.exit() still leaves it waiting.  It's not a big 
deal, but it bugs me.

Any ideas?  Should I be using something other than raw_input?  I'm on 
Windows2000 and running this from the DOS prompt.  I'm using Python 2.4.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Compute pi to base 12 using Python?

[M.E.Farmer]

>>PS. Redirecting with > from a script whose interpreter was started by
>>windows extension association
>>doesn't work on some version of windows. To be safe, invoke the
>>interpreter explicitly, e.g.,
>> python myscript.py [whatever args here] > pi3003.txt

>Thanks very much for this.
>What kind of args could I use here?
Any that your script allows or understands.
an example:
 python c:/Python22/Lib/PySourceColor.py -i- -s -l < c:/MyFile.py >
c:/tmp/myfile.html

A few things that might help you write a well behaved script:
if sys.stdin.isatty():
"direct"
else:
"redirected"
This snippet can determine if you have redirected IO.

I just found this and it looks informative.
http://www.jpsdomain.org/windows/redirection.html

hth,
M.E.Farmer

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

Slight discrepancy with filecmp.cmp

[Ivan Van Laningham]

Hi All--
I noticed recently that a few of the jpgs from my digital cameras have
developed bitrot.  Not a real problem, because the cameras are CD
Mavicas, and I can simply copy the original from the cd.  Except for the
fact that I've got nearly 25,000 images to check.  So I wrote a set of
programs to both index the disk versions with the cd versions, and to
compare, using filecmp.cmp(), the cd and disk version.  Works fine. 
Turned up several dozen files that had been inadvertantly rotated or
saved with the wrong quality, various fat-fingered mistakes like that.

However, it didn't flag the files that I know have bitrot.  I seem to
remember that diff uses a checksum algorithm on binary files, not a
byte-by-byte comparison.  Am I wrong?  If I am, what then is the source
of the problem in my jpg images where it looks like a bit or two has
been shifted or added; suddenly, there's a line going through the
picture above which it's normal, and below it either the color has
changed (usually to pinkish) or the remaining raster lines are all
shifted either right or left?

Any ideas?

Metta,
Ivan
--
Ivan Van Laningham
God N Locomotive Works
http://www.andi-holmes.com/
http://www.foretec.com/python/workshops/1998-11/proceedings.html
Army Signal Corps:  Cu Chi, Class of '70
Author:  Teach Yourself Python in 24 Hours
-- 
http://mail.python.org/mailman/listinfo/python-list

Apache mod_python

[Dan]

I've been writing a server application in Python.  The app listens on
a socket and interfaces to a database.

Now I'd like to write a web application to also access the database.
It seems natural to use Python.  I've installed mod_python (Debian
libapache2-mod-python2.3, mod_python 3.1.3-4).

My question is, how mature/stable is mod_python?  Is it suitable for a
production environment?  The documentation is a bit lacking, and I've
found some errors in the demo example where it looks like the link
should work, but it doesn't. (Could well be something I'm doing.).
I've also noted that there's still work being done on it.

Thanks.

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

Re: Problem with unpack hex to decimal

[Artie Gold]

Jonathan Brady wrote:
<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Hello,
I was looking at this:
http://docs.python.org/lib/module-struct.html
and tried the following

import struct
struct.calcsize('h')
2
struct.calcsize('b')
1
struct.calcsize('bh')
4
I would have expected

struct.calcsize('bh')
3
what am I missing ?

Not sure, however I also find the following confusing:
struct.calcsize('hb')
3
struct.calcsize('hb') == struct.calcsize('bh')
False
I could understand aligning to multiples of 4, but why is 'hb' different 
from 'bh'? 


Evidently, shorts need to be aligned at an even address on your 
platform. Consider the following layout, where `b' represents the signed 
char, `h' represents the bytes occupied by the short and `X' represents 
unused bytes (due to alignment.

'bh', a signed char followed by a short would look like:
bXhh -- or four bytes, but 'hb', a short followed by a signed char would be:
hhb (as `char' and its siblings have no alignment requirements)
HTH,
--ag
--
Artie Gold -- Austin, Texas
http://it-matters.blogspot.com (new post 12/5)
http://www.cafepress.com/goldsays
--
http://mail.python.org/mailman/listinfo/python-list

Re: pre-PEP: Simple Thunks

[Bengt Richter]

On Sun, 17 Apr 2005 15:32:56 -0700, Brian Sabbey <[EMAIL PROTECTED]> wrote:

>Bengt Richter wrote:
>> Hm, one thing my syntax does, I just noticed, is allow you
>> to pass several thunks to a thunk-accepter, if desired, e.g.,
>> (parenthesizing this time, rather than ending (): with
>> dedented comma)
>>
>>each(
>>((i):  # normal thunk
>>print i),
>>((j):  # alternative thunk
>>rejectlist.append(j)),
>>[1,2])
>>
>> 
>>
>
>I see that it might be nice to be able to use multiple thunks, and to be 
>able to specify the positions in the argument list of thunks, but I think 
>allowing a suite inside parentheses is pretty ugly.  One reason is that it 
>is difficult to see where the suite ends and where the argument list 
>begins again.  I'm not sure even what the syntax would be exactly.  I 
>suppose the suite would always have to be inside its own parentheses? 
>Also, you wind up with these closing parentheses far away from their 
>corresponding open parentheses, which is also not pretty.  It's getting 
>too Lisp-like for my tastes.
>
Having had a past love affair (or at least fling) with scheme,
that doesn't bother me so much ;-)

The "where" specifier syntax might help, e.g.,
  
  each(thk1, thk2, [1, 2]) where:
   thk1 = (i):  # normal thunk
  print i
   thk2 = (j):  # alternative thunk
  rejectlist.append(j)

This still uses my (): expression for thunks
but they don't need to be parenthesized, because their suites
terminate with normal dedenting under the where: suite

I.e., the 'p' of 'print i' is the left edge of the (i): suite
and thus the 't' of 'thk2 = ...' ends the (i): suite. The (j): suite
left edge is at the 'r' of 'rejectlist'... so anything to the left
of that (excluding comments) will end the (j): suite, like normal
indentation.

I could have used dedent termination in the previous example too
by moving the commas around to let them trigger dedent level out of
the preceding suite, e.g., with args evaluated in place again:

  each((i): # normal thunk
  print i
  ,(j): # alternative thunk
  rejectlist.append(j)
  ,[1,2])

Of course, if you want lispy, the above simple thunks can be done in a oneliner:

  each(((i):print i), ((j):rejectlist.append(j)), [1,2])

I personally like the power of being able to write that, but given a clean sugar
alternative, I would use it. But if it's an exclusive-or choice, I'll take 
primitives
over sugar, because sugar never covers all the useful combinations of 
primitives that
will turn up later.

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

Re: pre-PEP: Simple Thunks

[Brian Sabbey]

Ron_Adam wrote:
def pickled_file(thunk, name):
f = open(name, 'r')
l = pickle.load(f)
f.close()
thunk(l)
f = open(name, 'w')
pickle.dump(l, f)
f.close()
Now I can re-use pickled_file whenever I have to modify a pickled file:
do data in pickled_file('pickled.txt'):
data.append('more data')
data.append('even more data')
In my opinion, that is easier and faster to write, more readable, and less
bug-prone than any non-thunk alternative.
The above looks like it's missing something to me. How does 'data'
interact with 'thunk(l)'?  What parts are in who's local space?
Your example below explains it well, with 'data' renamed as 'L'.  The 
scope of bindings are the same in both examples, with the exception that 
'data' is in the outermost namespace in the above example, and 'L' is 
local to the function 'data_append' in the below example.

This might be the non-thunk version of the above.
yes
def pickled_file(thunk, name):
f = open(name, 'r')
l = pickle.load(f)
f.close()
thunk(l)
f = open(name, 'w')
pickle.dump(l, f)
f.close()
def data_append(L):
L.append('more data')
L.append('still more data')
pickled_file(data_append, name)
I don't think I would do it this way.  I would put the data
list in a class and add a method to it to update the pickle file. Then
call that from any methods that update the data list.
I also wouldn't do it that way.  I don't see a class as being much better, 
though.  If I understand you correctly, with classes you would have 
something like:

p = Pickled('pickled.txt')
p.load()
p.data.append('more data')
p.data.append('even more data')
p.dump()
This has the same issues as with opening and closing files:  losing the 
'dump', having to always use try/finally if needed, accidentally 
re-binding 'p', significantly more lines.  Moreover, class 'Pickled' won't 
be as readable as the 'pickled_file' function above since 'load' and 
'dump' are separate methods that share data through 'self'.

The motivation for thunks is similar to the motivation for generators-- 
yes, a class could be used instead, but in many cases it's more work than 
should be necessary.

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

Re: pre-PEP: Suite-Based Keywords - syntax proposal

[Steven Bethard]

Kay Schluehr wrote:
Hmmm ... now You eliminate "where" completely in favor for '::'. This
may be reasonable because '::' is stronger and less context dependent.
But on the other hand it may be also reasonable to eliminate '::'
towards a stronger "where" ;)
x = property(**kw) where kw:
doc = "I'm the 'x' property."
def fget(self):
return self.__x
x = property(*args) where args:
def fget(self):
return self.__x
fset = None
fdel = None
doc = "I'm the 'x' property."
[snip]
I think this version is more mainstream syntax ( and without braces and
additional punctuation ) than the unary prefix operator '::' which
drops statements into expressions within expressions.
So the object of a "where" is then always an ordered dict?  If so, then 
I guess I like this proposal best so far.

However, it does seem to have the problem that you can't have any 
additional local variables so, for example, list comprehensions are 
probably not usable...

Or can you still drop the argument to "where" and just use the names 
directly?  E.g.:

x = property(fget=fget, doc=doc) where:
doc = "I'm the 'x' property."
def fget(self):
return self.__x
STeVe
--
http://mail.python.org/mailman/listinfo/python-list

trying to parse a file...

[bruce]

hi,

i'm trying to modify an app (gforge) that uses python to do some file
parsing/processing...

i have the following shell file that uses python. if i understand it
correctly, it's supposed to modify the 'viewcvs.conf' file, and
replace/update the section with 'svn_roots'.

it isn't working correctly... can anybody tell me what i need to do?
basically, i'd like to continually add to the svn_root: block with an
additional line as required. also, can someone tell me what i'd need to do,
if i wanted to remove a line of text from the 'svn_root' block if i had a
given 'test_x:'

thanks

bruce
[EMAIL PROTECTED]

---
viewcvs.conf:
  .
  .
  .
  #
  # This setting specifies each of the Subversion roots (repositories)
  # on your system and assigns names to them. Each root should be given
  # by a "name: path" value. Multiple roots should be separated by
  # commas and can be placed on separate lines.
  #
  #svn_roots = test2: /svn-gforge/uploadsvn
  svn_roots = test5: /gforge-svn/test7/svn,
  test2: /gforge-svn/test7/svn,
  test3: /gforge-svn/test7/svn,

  # The 'root_parents' setting specifies a list of directories in which
  # any number of repositories may reside.  Rather than force you to add
  .
  .
  .
---




[EMAIL PROTECTED] bin]# cat test.sh
---
#! /bin/sh

python <
/var/lib/gforge/etc/viewcvs.py
---



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

Re: python.exe on Mac OS X!?

[Robert Kern]

Rodney Maxwell wrote:
executable produced was 'python.exe'. Can someone tell me whether
this
is a bug, feature, or UserError?

I'm not sure. Why don't you grab the binary?

http://www.python.org/ftp/python/2.4.1/MacPython-OSX-2.4.1-1 .dmg

Because I need to keep multiple versions of Python on this machine, and
as far as I can tell the binary installer overwrites the default
installed version.
I could be wrong.
You are wrong. It installs alongside.
--
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: pre-PEP: Simple Thunks

[Steven Bethard]

Brian Sabbey wrote:
used, but rarely is because doing so would be awkward.  Probably the 
simplest real-world example is opening and closing a file.  Rarely will 
you see code like this:

def with_file(callback, filename):
f = open(filename)
callback(f)
f.close()
def print_file(file):
print file.read()
with_file(print_file, 'file.txt')
For obvious reasons, it usually appears like this:
f = open('file.txt')
print f.read()
f.close()
Normally, though, one wants to do a lot more than just print the file. 
There may be many lines between 'open' and 'close'.  In this case, it is 
easy to introduce a bug, such as returning before calling 'close', or 
re-binding 'f' to a different file (the former bug is avoidable by using 
'try'/'finally', but the latter is not).  It would be nice to be able to 
avoid these types of bugs by abstracting open/close.  Thunks allow you 
to make this abstraction in a way that is more concise and more readable 
than the callback example given above:

do f in with_file('file.txt'):
print f.read()
Thunks are also more useful than callbacks in many cases since they 
allow variables to be rebound:

t = "no file read yet"
do f in with_file('file.txt'):
t = f.read()
Using a callback to do the above example is, in my opinion, more difficult:
def with_file(callback, filename):
f = open(filename)
t = callback(f)
f.close()
return t
def my_read(f):
return f.read()
t = with_file(my_read, 'file.txt')
Definitely put this example into the PEP.  I didn't really understand 
what you were suggesting until I saw this example.  All the other ones 
you gave just confused me more.

When I see 'do', it reminds me of 'do loops'. That is 'Do' involves
some sort of flow control.  I gather you mean it as do items in a
list, but with the capability to substitute the named function.  Is
this correct?
I used 'do' because that's what ruby uses for something similar.  It can 
be used in a flow control-like way, or as an item-in-a-list way.
Please spend some time in the PEP explaining why you chose the keywords 
you chose.  They gave me all the wrong intuitions about what was 
supposed to be going on, and really confused me.  I also got mixed up in 
when you were talking about parameters to the thunk, and when you were 
talking about parameters to the function that is called with the thunk 
as a parameter.

I'd also like to see you start with the full example syntax, e.g.:
do  in  = ():

And then explain what each piece does more carefully.  Something like:
"""
When a do-statement is executed, first  is called with the 
parameters , augmented by the thunk object, e.g.

do func(4, b=2):
...
would call
func(thunk_obj, 4, b=2)
Next, the body of the function is executed.  If the thunk object is 
called, then  will be executed with the names in  
bound to the objects with which the thunk was called, e.g.

def func(thunk):
thunk(1, y=2)
do x, y, z=4 in func():
print x, y, z
would call:
func(thunk_obj)
thunk(1, y=2)
and thus x, y and z would be bound to 1, 2 and 4 and the body of the 
thunk would be executed, printing "1 2 4".

The code in  is then resumed, and the process is repeated 
until  returns.  Note that this means that each additional 
call to the thunk object will cause another execution of , with 
potentially different bindings for the names in .

When the function finally returns, the return value will be bound to 
, e.g.:

def func(thunk):
thunk()
thunk()
return True
do r = func():
print "thunk called"
print r
would print "thunk called" twice as the body of the thunk is executed 
for each call to thunk() in func, and then would print "True" in the 
code following the do-statement.
"""

Not sure if I actually understood everything right, but you definitely 
need a much more throrough walkthrough of what happens with a thunk -- 
it's not clear at all from the current pre-PEP.

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

Re: Finding name of running script

[M.E.Farmer]

runes wrote:
> Thanks!
>
> That's os.path.basename() I guess. It's better, but still complex.

Yea murphy's typo ;)

> I have a
> _nof_ = argv[0].split(sep)[-1]  in my script template and use it
under
> the usage() function to tell what the script does, like:
> "cf.py counts files in directory or directory structure"
>
> If I change the filename, I want it to be automatically reflected
when
> running the script. That's the motivation.

Generally I do it the very same way just spell it different.
os.path.basename(sys.argv[0])

> I have the feeling that I came a cross some very simple way to
extract
> the filename, but I can't find my mental note ;-)
Maybe you found some black magic ;)
M.E.Farmer

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

Re: pre-PEP: Suite-Based Keywords - syntax proposal

[Bengt Richter]

On 17 Apr 2005 09:27:34 -0700, "Kay Schluehr" <[EMAIL PROTECTED]> wrote:

>> Exactly. Except the above example is from the day-old-bread
>items-tuple-returning version of :: ;-)
>> And with an ordered dict subtype there is no need for the generator
>expression either,
>> since there is a values method for dicts (which in the subtype would
>preserve order). E.g.,
>>
>>  x = property(*seq) where:
>>  seq = (::
>>  def get_x():
>>  return self.__x
>>  def set_x(value):
>>  self.__x = value
>>  del_x = None
>>  doc   = "I'm the 'x' property." ).values())
>>
>> Or more directly:
>>
>>  x = property(*(::
>>  def get_x():
>>  return self.__x
>>  def set_x(value):
>>  self.__x = value
>>  del_x = None
>>  doc   = "I'm the 'x' property." ).values())
>
>Hmmm ... now You eliminate "where" completely in favor for '::'. This
>may be reasonable because '::' is stronger and less context dependent.
>But on the other hand it may be also reasonable to eliminate '::'
>towards a stronger "where" ;)
>
>
>x = property(**kw) where kw:
>doc = "I'm the 'x' property."
>def fget(self):
>return self.__x
>
>
>x = property(*args) where args:
>def fget(self):
>return self.__x
>fset = None
>fdel = None
>doc = "I'm the 'x' property."
>
I like this. But how would you put "where args:" and "where kw:" if you needed 
both?
also, is it looking back to see the '*' or '**' to do (::x=1).values vs. (::x=1)
and how about (::x=1).keys() or (::x=1).items() ? And what if you wanted to pass
(::x=1) as a dict object without ** expansion into a keyword dict?

Maybe we need asterisks on both ends. e.g.,

foo(dct, values, *args, **kw):
   where **dct:
  x=1
   where *values:
  x=2
   where *args:
  x=3
   where **kw:
  x=4

But that still doesn't give you, e.g.,

   foo(keys) where:
   keys=sorted((::
   from interesting.module import *
   ).keys())

I like clean sugar, but I still want to be able to
get at the general primitives to compose them in ways
that can't be anticipated until a use case comes up.
And then if the primitives are inaccessible, one is
out of luck or doomed to workaround hacking ;-)

>
>Put definitions into a list:
>
>l = list(*args) where args:
>def fget(self):
>return self.__x
>doc = "I'm the 'x' property."
>
>
>Nest suites:
>
>x = property(*args) where args:
>t = tuple(*t) where t:
>def fget(self):
>return self.__x
>fset = None
>fdel = None
>doc = "I'm the 'x' property."
>
>
>Evaluate conditions:
>
>if f(*args)==1 where args:
>   x = 1
>   y = 2
>
>I think this version is more mainstream syntax ( and without braces and
>additional punctuation ) than the unary prefix operator '::' which
>drops statements into expressions within expressions.
>
I like this mainstream syntax for ordinary use cases, but as mentioned,
I'd still like to have primitives accessible. I don't see why both
couldn't live in harmony ;-)

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

Re: Pattern Matching Given # of Characters and no String Input; use RegularExpressions?

[John Machin]

On 17 Apr 2005 18:12:19 -0700, [EMAIL PROTECTED] (Synonymous)
wrote:

>
>I will look for a Left$(str) function that looks at the first X
>characters for python :)).
>

Wild goose chase alert! AFAIK there isn't one. Python uses slice
notation instead of left/mid/right/substr/whatever functions. I do
suggest that instead of looking for such a beastie, you read this
section of the Python Tutorial: 3.1.2 Strings. 

Then, if you think that that was a good use of your time, you might
like to read the *whole* tutorial :))

HTH,

John

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

Re: ANN: Veusz 0.5 - a scientific plotting package

[Dan Christensen]

Jeremy Sanders <[EMAIL PROTECTED]> writes:

> Veusz 0.5
> -
> Velvet Ember Under Sky Zenith
> -
> http://home.gna.org/veusz/
>
> Veusz is a scientific plotting package written in Python (currently
> 100% Python). It uses PyQt for display and user-interfaces, and
> numarray for handling the numeric data. Veusz is designed to produce
> publication-ready Postscript output.

Just curious how veusz compares to other python plotting libraries,
such as matplotlib...

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

Re: pre-PEP: Simple Thunks

[Ron_Adam]

On Sun, 17 Apr 2005 15:02:12 -0700, Brian Sabbey
<[EMAIL PROTECTED]> wrote:

Brian Sabbey wrote:

> I'm kicking myself for the first example I gave in my original post in 
> this thread because, looking at it again, I see now that it really gives 
> the wrong impression about what I want thunks to be in python.  The 
> 'thunkit' function above shouldn't be in the same namespace as the thunk. 
> It is supposed to be a re-usable function, for example, to acquire and 
> release a resource.  On the other hand, the 'foo' function is supposed to 
> be in the namespace of the surrounding code; it's not re-usable.  So your 
> example above is pretty much the opposite of what I was trying to get 
> across.

This would explain why I'm having trouble seeing it then.


> def pickled_file(thunk, name):
>   f = open(name, 'r')
>   l = pickle.load(f)
>   f.close()
>   thunk(l)
>   f = open(name, 'w')
>   pickle.dump(l, f)
>   f.close()
>
> Now I can re-use pickled_file whenever I have to modify a pickled file:
>
> do data in pickled_file('pickled.txt'):
>   data.append('more data')
>   data.append('even more data')
>
> In my opinion, that is easier and faster to write, more readable, and less 
> bug-prone than any non-thunk alternative.
>

The above looks like it's missing something to me. How does 'data'
interact with 'thunk(l)'?  What parts are in who's local space?  


This might be the non-thunk version of the above. 

def pickled_file(thunk, name):
f = open(name, 'r')
l = pickle.load(f)
f.close()
thunk(l)
f = open(name, 'w')
pickle.dump(l, f)
f.close()

def data_append(L):
L.append('more data')
L.append('still more data')

pickled_file(data_append, name)

I don't think I would do it this way.  I would put the data
list in a class and add a method to it to update the pickle file. Then
call that from any methods that update the data list.


>> def with_file:   # no argument list, local group.
>>  f = open(filename)
>>  t = callback(f)
>>  f.close
>>
>> def my_read(f):
>>  return f.read()
>>
>> callback = my_read
>> filename = 'filename'
>> do with_file
>
> This wouldn't work since with_file wouldn't be re-usable.  It also doesn't 
> get rid of the awkwardness of defining a callback.

As long as the name with_file isn't rebound to something else it could
be used as often as needed.  I admit there are better ways to do it
though.


Cheers,
Ron




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

Re: Finding name of running script

[runes]

Thanks!

That's os.path.basename() I guess. It's better, but still complex.

I have a
_nof_ = argv[0].split(sep)[-1]  in my script template and use it under
the usage() function to tell what the script does, like:

"cf.py counts files in directory or directory structure"

If I change the filename, I want it to be automatically reflected when
running the script. That's the motivation.

I have the feeling that I came a cross some very simple way to extract
the filename, but I can't find my mental note ;-)

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

Re: python.exe on Mac OS X!?

[Rodney Maxwell]

> The default file system on MacOSX is case insensitive.  As a result
the .exe
> extension is required to disambiguate the generated executable from
the 
> Python directory in the source distro. 

OK. I got it.

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

Re: python.exe on Mac OS X!?

[Rodney Maxwell]

>> executable produced was 'python.exe'. Can someone tell me whether
this
>> is a bug, feature, or UserError?

> I'm not sure. Why don't you grab the binary?

> http://www.python.org/ftp/python/2.4.1/MacPython-OSX-2.4.1-1 .dmg

Because I need to keep multiple versions of Python on this machine, and
as far as I can tell the binary installer overwrites the default
installed version.
I could be wrong.

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

Re: Pattern Matching Given # of Characters and no String Input; use RegularExpressions?

[Synonymous]

tiissa <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> tiissa wrote:
> > If you know the number of characters to match can't you just compare 
> > slices?
> If you don't, you can still do it by hand:
> 
> In [7]: def cmp(s1,s2):
>: diff_map=[chr(s1[i]!=s2[i]) for i in range(min(len(s1), 
> len(s2)))]
>: diff_index=''.join(diff_map).find(chr(True))
>: if -1==diff_index:
>: return min(len(s1), len(s2))
>: else:
>: return diff_index
>:
> 
> In [8]: cmp('cccat','cccap')
> Out[8]: 4
> 
> In [9]: cmp('ccc','cccap')
> Out[9]: 3
> 
> In [10]: cmp('cccat','dddfa')
> Out[10]: 0

I will look at that, although if i have 300 images i dont want to type
all the comparisons (In [9]: cmp('ccc','cccap')) by hand, it would
just be easier to sort them then :).

I got it somewhat close to working in visual basic:

If Left$(Cells(iRow, 1).Value, Count) = Left$(Cells(iRow - 1,
1).Value, Count) Then

What it says is when comparing a list, it looks at the 'Count' left
number of characters in the cell and compares it to the row cell
above's 'Count' left number of characters and then does the task (i.e.
makes a directory, moves the files) if they are equal.

I will look for a Left$(str) function that looks at the first X
characters for python :)).

Thank you for your help!

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

Re: python.exe on Mac OS X!?

[Skip Montanaro]

Rodney> I did a source code build of Python 2.4.1 on OS X (10.3.8) and
Rodney> the executable produced was 'python.exe'. Can someone tell me
Rodney> whether this is a bug, feature, or UserError?

The default file system on MacOSX is case insensitive.  As a result the .exe
extension is required to disambiguate the generated executable from the
Python directory in the source distro.

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

Re: Finding name of running script

[M.E.Farmer]

> print locals()['__file__'].split(sep)[-1]
.split(sep)[-1] is pretty dense reading.
try:
print os.basename(locals()['__file__'])

runes wrote:
> Is it a more pythonic way of finding the name of the running script
> than these?
>
> from os import sep
> from sys import argv
>
> print argv[0].split(sep)[-1]
> # or
> print locals()['__file__'].split(sep)[-1]
> # or
> print globals()['__file__'].split(sep)[-1]

M.E.Farmer

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

terminal shutdown

[Dan Richert]

i wrote a script that accesses files at random from the locatedb 
database.  it then prints a random line from the file it's accessed to 
the terminal screen.  this runs continuously and at times makes the 
terminal behave strangely (chaning font colors, output writing over 
itself on the screen, etc) -- i like this strange behavior, but the 
behavior i don't like is when the terminal window closes on its own.  i 
suspect that the script isn't crashing, but that characters are being 
displayed that interrupt terminal somehow.   i'm on mas os x.   any help 
on this would be greatly greatly appreicated.

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

Re: python.exe on Mac OS X!?

[Robert Kern]

Rodney Maxwell wrote:
I did a source code build of Python 2.4.1 on OS X (10.3.8) and the
executable produced was 'python.exe'. Can someone tell me whether this
is a bug, feature, or UserError?
I'm not sure. Why don't you grab the binary?
http://www.python.org/ftp/python/2.4.1/MacPython-OSX-2.4.1-1.dmg
--
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: MS SQL Server/ODBC package for Python

[Peter Herndon]

I switched around the order, both in the actual application and in my
tests as replied to Francois Lepoutre above.  Results were consistent,
after the first run of any given test, which unsurprisingly took a bit
longer.

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

Re: MS SQL Server/ODBC package for Python

[Peter Herndon]

:) Knock away, as my info isn't scientific anyway.  In my case, ASA is
*not* local.  The db is running on a 500MHz x 2 server with 768MB RAM,
over 100BaseT connection.  That same server is also running the MSSQL
instance, and IIS.

Running your benchmark, I ran into a couple of interesting points.
Using mx.ODBC, my times were 0.54 seconds and 6.56 seconds
respectively, while using adodbapi my results are 3.55 seconds and 25.9
seconds respectively.  mx.ODBC is faster with the simple query you
provide.

Next I modified the benchmark to reflect my particular circumstances
more accurately (?Maybe?  Comments invited).  I changed the query to
one of the queries in regular use in my application.  This query
selects 26 columns from 3 joined tables, with a where clause "where
f476 = ?", and I provide the missing value as a tuple in the execute
statement.  Note that, as I mentioned in my reply to M-A, the f476
field is not indexed, and is a long varchar.  Again, the system is
bought, so I have no control over the schema. ;)

The other change I made was to reduce the number of iterations from 100
to 10.  Since there are 128000 records in the main table, the wait for
100 iterations was too long for my patience.  Under these
circumstances, mx.ODBC's numbers are 188.49 seconds and 377.56 seconds
respectively, and adodbapi's times are 111.15 seconds and 223.55
seconds respectively.

My first wall-clock impressions are obvious exaggerations of reality,
for which I duly apologize to all.  However, adodbapi did prove to be
faster in my admittedly very wacky common use case.  Slower to connect,
but faster to run a substantial query.

Comments?  Questions?  Suggestions for improvement?

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

Finding name of running script

[runes]

Is it a more pythonic way of finding the name of the running script
than these?

from os import sep
from sys import argv

print argv[0].split(sep)[-1]
# or
print locals()['__file__'].split(sep)[-1]
# or
print globals()['__file__'].split(sep)[-1]

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

Re: variables exist

[Michael J. Fromberger]

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (fabian) wrote:

> how testing if a variable exists in python as isset in php??
> 

Would the following be a satisfactory implementation?

  def isset(varname, lloc = locals()):
return varname in lloc or varname in globals()

I believe this works as desired:

  >>> x = 5
  >>> def f(y):
  ...   z = 10
  ...   print isset('z')   ## ==> True
  ...   print isset('y')   ## ==> True
  ...   print isset('x')   ## ==> True
  ...

Tests:
  >>> f(1)  ## As shown above
  >>> print isset('z')   ## ==> False
  >>> print isset('y')   ## ==> False
  >>> print isset('x')   ## ==> True
  >>> print isset('varname') ## ==> False
  >>> print isset('lloc')## ==> False
  >>> lloc = "foo!"
  >>> print isset('lloc')## ==> True

Perhaps this is not the most elegant solution, but I believe it handles 
scoping correctly.

-M

-- 
Michael J. Fromberger | Lecturer, Dept. of Computer Science
http://www.dartmouth.edu/~sting/  | Dartmouth College, Hanover, NH, USA
-- 
http://mail.python.org/mailman/listinfo/python-list

python.exe on Mac OS X!?

[Rodney Maxwell]

I did a source code build of Python 2.4.1 on OS X (10.3.8) and the
executable produced was 'python.exe'. Can someone tell me whether this
is a bug, feature, or UserError?

% ./configure

% make

% ./python.exe
Python 2.4.1 (#1, Apr 17 2005, 12:14:12)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
>>>

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

Re: pre-PEP: Simple Thunks

[Brian Sabbey]

Bengt Richter wrote:
Hm, one thing my syntax does, I just noticed, is allow you
to pass several thunks to a thunk-accepter, if desired, e.g.,
(parenthesizing this time, rather than ending (): with
dedented comma)
   each(
   ((i):  # normal thunk
   print i),
   ((j):  # alternative thunk
   rejectlist.append(j)),
   [1,2])

I see that it might be nice to be able to use multiple thunks, and to be 
able to specify the positions in the argument list of thunks, but I think 
allowing a suite inside parentheses is pretty ugly.  One reason is that it 
is difficult to see where the suite ends and where the argument list 
begins again.  I'm not sure even what the syntax would be exactly.  I 
suppose the suite would always have to be inside its own parentheses? 
Also, you wind up with these closing parentheses far away from their 
corresponding open parentheses, which is also not pretty.  It's getting 
too Lisp-like for my tastes.

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

Re: pre-PEP: Suite-Based Keywords

[Brian Sabbey]

Brian Sabbey wrote:
Does anyone know if the 'where' keyword is only for readability (or does it 
disambiguate the syntax in some situations)?  I think I prefer leaving it 
off.
To answer my own question, I see by reading the where threads that using 
the 'where' keyword allows things such as:

# Design by contract (from Nick Coghlan)
@dbc(pre, post)
def foo():
   pass
with:
   def pre():
 pass
   def post():
 pass
--
http://mail.python.org/mailman/listinfo/python-list

Re: pre-PEP: Suite-Based Keywords

[Bengt Richter]

On Sun, 17 Apr 2005 15:25:04 +0200, Reinhold Birkenfeld <[EMAIL PROTECTED]> 
wrote:

>Bengt Richter wrote:
>
>> Stretching for it, using my latest and greatest ;-)
>> 
>> y = f(**::
>>x = 1
>>y = 'y for f'
>> )*g(**::
>>x = 'x for g'
>>y = 'y for g'
>>def foo(): return 'foo for g'
>> )
>> 
>> Note that there is no problem adding other parameters, because :: is 
>> just
>> a unary expression returning dict subtype instance, e.g.,
>> 
>> y = f(11,22,**::
>>x = 1
>>y = 'y for f'
>> )*g(*args_from_somewhere, **::
>>x = 'x for g'
>>y = 'y for g'
>>def foo(): return 'foo for g'
>> )
>
>You know that this is dead ugly?
What aspect in particular? I.e., does this (currently legal) look prettier:

   y = f(11,22, **dict(
  x = 1,
  y = 'y for f'
   ))*g(*args_from_somewhere, **dict(
  x = 'x for g',
  y = 'y for g',
  foo = lambda: return 'foo for g'
   ))

Can you express the same semantics in a prettier way?

To boil it down, doesn't a suite bindings expression like

  d = ::
  x = 1
  y = 'y for f'

(which in this case doesn't even need parens) seem prettier than

  d = dict(
  x = 1,
  y = 'y for f'
  )

to you, especially given that (:: ...) gives you the power
of full suite syntax to create bindings
any way you want[1], not just keyword= ?
(and you can leave out the commas ;-)

[1] I.e., this should work to extend the power of the type expression in a way
that shows what you can't do with dict(...) ;-)

 type('C', (), ::
 def __repr__(self):
 return ''% 
(hex(id(self)&(2L**32-1))
 def cname(self): return type(self).__name__
 classvar = 123
 # ... anything you can do in a class definition body
 )

IMO that's pretty clean.

>
>The real ``problem'' (if you see one) is that the indentation syntax
>doesn't allow for suites in expressions.

I was trying to solve that "problem" with my "suite expressions" ;-)

   ::  # suite bindings expression (as ordered dict)
   def(): # anonymous def
   ():# thunk (anonymous callable suite sharing local 
namespace)

I think suite indentation rules for suite expressions are not that hard, once 
you decide
to deal with it as a separate indentation space from outside the expression. 
That's already
done to allow multiline expressions without indentation interpretation inside 
bracketed expressions.
This is just adding indentation processing within certain types of expressions 
("suite expressions" ;-)

For the most part I like indentation syntax very well, and
I suspect that if there were optional brackets, you would still be indenting
for clarity, so the chances are the bracket version of the above would
mainly add bracket noise to something close to the above.

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

Re: pre-PEP: Simple Thunks

[Brian Sabbey]

Ron_Adam wrote:
On Sat, 16 Apr 2005 17:25:00 -0700, Brian Sabbey
Yes, much of what thunks do can also be done by passing a function
argument.  But thunks are different because they share the surrounding
function's namespace (which inner functions do not), and because they can
be defined in a more readable way.
Generally my reason for using a function is to group and separate code
from the current name space.  I don't see that as a drawback.
I agree that one almost always wants separate namespaces when defining a 
function, but the same is not true when considering only callback 
functions.  Thunks are a type of anonymous callback functions, and so a 
separate namespace usually isn't required or desired.

Are thunks a way to group and reuse expressions in the current scope?
If so, why even use arguments?  Wouldn't it be easier to just declare
what I need right before calling the group?  Maybe just informally
declare the calling procedure in a comment.
def thunkit:  # no argument list defines a local group.
# set thunk,x and y before calling.
before()
result = thunk(x,y)
after()
def foo(x,y):
x, y = y, x
return x,y
thunk = foo
x,y = 1,2
do thunkit
print result
-> (2,1)
Since everything is in local name space, you  really don't need to
pass arguments or return values.
I'm kicking myself for the first example I gave in my original post in 
this thread because, looking at it again, I see now that it really gives 
the wrong impression about what I want thunks to be in python.  The 
'thunkit' function above shouldn't be in the same namespace as the thunk. 
It is supposed to be a re-usable function, for example, to acquire and 
release a resource.  On the other hand, the 'foo' function is supposed to 
be in the namespace of the surrounding code; it's not re-usable.  So your 
example above is pretty much the opposite of what I was trying to get 
across.

The 'do' keyword says to evaluate the group.  Sort of like eval() or
exec would, but in a much more controlled way.  And the group as a
whole can be passed around by not using the 'do'.  But then it starts
to look and act like a class with limits on it.  But maybe a good
replacement for lambas?
I sort of wonder if this is one of those things that looks like it
could be useful at first, but it turns out that using functions and
class's in the proper way, is also the best way. (?)
I don't think so.  My pickled_file example below can't be done as cleanly 
with a class.  If I were to want to ensure the closing of the pickled 
file, the required try/finally could not be encapsulated in a class or 
function.


You're right that, in this case, it would be better to just write
"f(stuff, 27, 28)".  That example was just an attempt at describing the
syntax and semantics rather than to provide any sort of motivation.  If
the thunk contained anything more than a call to 'stuff', though, it would
not be as easy as passing 'stuff' to 'f'.  For example,
do f(27, 28):
print stuff()
would require one to define and pass a callback function to 'f'.  To me,
'do' should be used in any situation in which a callback *could* be used,
but rarely is because doing so would be awkward.  Probably the simplest
real-world example is opening and closing a file.  Rarely will you see
code like this:
def with_file(callback, filename):
f = open(filename)
callback(f)
f.close()
def print_file(file):
print file.read()
with_file(print_file, 'file.txt')
For obvious reasons, it usually appears like this:
f = open('file.txt')
print f.read()
f.close()
Normally, though, one wants to do a lot more than just print the file.
There may be many lines between 'open' and 'close'.  In this case, it is
easy to introduce a bug, such as returning before calling 'close', or
re-binding 'f' to a different file (the former bug is avoidable by using
'try'/'finally', but the latter is not).  It would be nice to be able to
avoid these types of bugs by abstracting open/close.  Thunks allow you to
make this abstraction in a way that is more concise and more readable than
the callback example given above:
How would abstracting open/close help reduce bugs?
I gave two examples of bugs that one can encounter when using open/close. 
Personally, I have run into the first one at least once.

I'm really used to using function calls, so anything that does things
differently tend to be less readable to me. But this is my own
preference.  What is most readable to people tends to be what they use
most. IMHO
do f in with_file('file.txt'):
print f.read()
Thunks are also more useful than callbacks in many cases since they allow
variables to be rebound:
t = "no file read yet"
do f in with_file('file.txt'):
t = f.read()
Using a callback to do the above example is, in my opinion, more
difficult:
def with_file(callback, filename):
f = open(filename)
t = callback(f)
f.close()
return t
def my_read(f):
re

Re: module to parse "pseudo natural" language?

[bytecolor]

Andrew E wrote:
> Hi all
>
> I've written a python program that adds orders into our order routing
> simulation system. It works well, and has a syntax along these lines:
>
>   ./neworder --instrument NOKIA --size 23 --price MARKET --repeats 20
>
> etc
>
> However, I'd like to add a mode that will handle, say:
>
>   ./neworder buy 23 NOKIA at MKT x 20
>
> I could enter several orders either by running multiple times, or use
a
> comma-separated approach, like:
>
>   ./neworder buy 23 NOKIA at MKT on helsinki, sell 20 NOKIA at market
on
> helsinki

You could add a string option instead:
$ neworder -c 'buy 23 NOKIA at MKT on helsinki, sell 20 NOKIA at market
on helsinki'

This would leave your current option parsing in tact. Then just
split on the comma.

Another suggestion would be to drop into an interactive mode if
no arguments are passed:
$ neworder
->? buy 23 NOKIA at MKT on helsinki
->? sell 20 NOKIA at market on helsinki
->? ^d

> The thing about this is that its a "tolerant" parser, so all of these
> should also work:
>
>   # omit words like "at", "on"
>   ./neworder buy 23 NOKIA mkt helsinki
>
>   # take any symbol for helsinki
>   ./neworder buy 23 mkt helsinki
>
>   # figure out that market=helsinki
>   ./neworder buy 23 NOKIA at market price
>
>
> I've started writing a simple state-based parser, usage like:
>
>   class NaturalLanguageInsructionBuilder:
>
> def parse( self, arglist ):
>   """Given a sequence of args, return an Instruction object"""
>   ...
>   return Instruction( instrument, size, price, ... )
>
>
>   class Instruction:
> """encapsulate a single instruction to buy, sell, etc"""
>
> def __init__( self, instrument, size, price, ... ):
>   ...
>
>
> This doesn't work yet, but I know with time I'll get there.
>
> Question is - is there a module out there that will already handle
this
> approach?
>
> Thanks for any suggestions :)
>
> Andrew

If I were in your situation, I'd probably write a BNF for the
tiny-language. This would help wrap my brain around the problem.
The BNF would help show what kind of regular expression you are
looking at creating as well.

--
bytecolor

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

Re: Decorator Syntax For Recursive Properties

[Jeffrey Froman]

Peter Otten wrote:

>> something like this didn't work for me:

> But this will, I suppose:
> 
> @property
> def ancestors(self):
> if self.parent:
> return self.parent.ancestors + [self.parent]
> return []
>  
> A non-recursive variant:
> 
> @property
> def ancestors(self):
> result = []
> node = self.parent
> while node:
> result.append(node)
> node = node.parent
> result.reverse()
> return result

Indeed, both of these patterns suit my needs. Thanks very much for the
eye-opening insights.

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

Re: Problem with unpack hex to decimal

[John Machin]

On Sun, 17 Apr 2005 20:47:20 +0100, "Jonathan Brady"
<[EMAIL PROTECTED]> wrote:

>
><[EMAIL PROTECTED]> wrote in message 
>news:[EMAIL PROTECTED]
>> Hello,
>>
>> I was looking at this:
>> http://docs.python.org/lib/module-struct.html
>> and tried the following
>>
> import struct
> struct.calcsize('h')
>> 2
> struct.calcsize('b')
>> 1
> struct.calcsize('bh')
>> 4
>>
>> I would have expected
>>
> struct.calcsize('bh')
>> 3
>>
>> what am I missing ?


A note for the original poster: "unpack hex to decimal" (the subject
line from your posting) is an interesting concept. Hex[adecimal] and
decimal are ways of representing the *same* number.

Let's take an example of a two-byte piece of data. Suppose the first
byte has all bits set (== 1) and the second byte has all bits clear
(== 0). The first byte's value is hexadecimal FF or decimal 255,
whether or not you unpack it, if you are interpreting it as an
unsigned number ('B' format). Signed ('b' format) gives you
hexadecimal -1 and decimal -1. The second byte's value is 0
hexadecimal and 0 decimal however you interpret it.

Suppose you want to interpret the two bytes as together representing a
16-bit signed number (the 'h' format). If the perp is little-endian,
the result is hex FF and decimal 255; otherwise it's hex -100 and
decimal -256.

>
>Not sure, however I also find the following confusing:
 struct.calcsize('hb')
>3
 struct.calcsize('hb') == struct.calcsize('bh')
>False
>
>I could understand aligning to multiples of 4,

Given we know nothing about the OP's platform or your platform, "4" is
no more understandable than any other number.

> but why is 'hb' different 
>from 'bh'? 

Likely explanation: the C compiler aligns n-byte items on an n-byte
boundary. Thus in 'hb', the h is at offset 0, and the b can start OK
at offset 2, for a total size of 3. With 'bh', the b is at offset 0,
but the h can't (under the compiler's rules) start at 1, it must start
at 2, for a total size of 4.

Typically, you would use "native" byte ordering and alignment (the
default) only where you are accessing data in a C struct that is in
code that is compiled on your platform [1]. When you are picking apart
a file that has been written elsewhere, you will typically need to
read the documentation for the file format and/or use trial & error to
determine which prefix (@, <, >) you should use. If I had to guess for
you, I'd go for "<".

[1] Care may need to be taken if the struct is defined in source
compiled by a compiler *other* than the one used to compile your
Python executable -- there's a slight chance you might need to fiddle
with the "foreign" compiler's alignment options to make it suit.

HTH,

John

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

Re: pre-PEP: Suite-Based Keywords

[Brian Sabbey]

Oren Tirosh wrote:
Take a look at Nick Coglan's "with" proposal:
http://groups.google.co.uk/groups?selm=mailman.403.1105274631.22381.python-list%40python.org
It addresses many of the same issues (e.g. easy definition of
properties). It is more general, though: while your proposal only
applies to keyword arguments in a function call this one can be used
to name any part of a complex expression and define it in a suite.
I think that a good hybrid solution would be to combine the "with"
block with optional use of the ellipsis to mean "all names defined in
the with block".
See also the thread resulting from Andrey Tatarinov's original
proposal (using the keyword "where"):
http://groups.google.co.uk/groups?selm=3480qqF46jprlU1%40individual.net
Thanks for the links.  I wasn't aware of that proposal.
I agree that a hybrid solution is probably the way to go.
Does anyone know if the 'where' keyword is only for readability (or does 
it disambiguate the syntax in some situations)?  I think I prefer leaving 
it off.

Maybe using '**' would be better than '...' since it already is used to 
indicate keyword arguments.  Example:

class C(object):
x = property(**):
   doc = "I'm the 'x' property."
   def fget(self):
  return self.__x
   def fset(self, value):
  self.__x = value
   def fdel(self):
  del self.__x
-Brian
--
http://mail.python.org/mailman/listinfo/python-list

Re: distutils question: different projects under same namespace

[F. Petitjean]

Le 16 Apr 2005 01:20:34 -0700, Qiangning Hong a écrit :
> To avoid namespace confliction with other Python packages, I want all
> my projects to be put into a specific namespace, e.g. 'hongqn' package,
> so that I can use "from hongqn.proj1 import module1", "from
> hongqn.proj2.subpack1 import module2", etc.
That makes sense
> 
> These projects are developed and maintained and distributed seperately,
> so I should not make a whole 'hongqn' package with one setup.py.  I
> must write setup.py scripts for each project.  I meet a problem here.
> 
> For instance, I am writing setup.py script for proj1. I use the
> following parameters when calling distutils.core.setup:
> 
> setup(
> ...
> package_dir = {'hongqn.proj1': 'proj1'},
> packages = ['hongqn.proj1'],
> ...
> )
> 
> "python setup.py install" will create /usr/lib/python2.3/hongqn/proj1
> directory and copy proj1/*.py there.  But this is UNUSABLE!  There is
> NO __init__.py file under /usr/lib/python2.3/hongqn/ so that import
> hongqn.proj1 will fail!
You can detect if there is __init__.py in the hongqn directory.
> 
> I am considering manually create this __init__.py by hacking the
> install_lib command.  But before making my hands dirty,  I want to know
> if there is an "official" solution exists or others have already
> success stories on this matter.
It seems that this problem is tackled in the logilab packages : for
example, you install first the logilab common libraries and then pylint.
So the problem is to define the dependencies of your projects and hence
the order of installation.
> 
> As a note, I wish the solution can handle setup.py bdist and
> bdist_wininst well.
> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pydoc preference for triple double over triple single quotes-- anyreason?

[Brian van den Broek]

Kent Johnson said unto the world upon 2005-04-17 16:17:
Brian van den Broek wrote:
Kent Johnson said unto the world upon 2005-04-16 16:41:
Brian van den Broek wrote:
I've just spent a frustrating bit of time figuring out why pydoc 
didn't extract a description from my module docstrings. Even though 
I had a well formed docstring (one line, followed by a blank line, 
followed by the rest of the docstring), when I ran Module docs, my 
modules showed up as having "no description". ("Module docs" 
referring to the shortcut installed on Windows that launches the 
pydoc server.)

?? It works for me with triple-single quoted strings...from a quick 
look it appears that pydoc uses inspect which looks at the __doc__ 
attribute; do your modules have __doc__ attributes?

Kent, that's odd. My module does have a valid docstring and hence a 
__doc__ attribute (I did explicitly check). help(my_module) works fine 
at the prompt. It is just the results list in the TKinter interface to 
the pydoc server application that doesn't seem to pick up my module's 
description (in the first line of its docstring) when the docstring is 
triple-single quoted.

I'm not sure what you mean by "the results list in the TKinter interface 
to the pydoc server". I ran the server, clicked "open browser" and 
browsed to a module in site-packages; that worked fine for me under 
Win2K and Python 2.4.1.

Kent
By "the TKinter interface to the pydoc server" I mean the window that 
pops up when you select the Module Docs shortcut. It is pictured here 
 , which 
is Fig.1 in an article on pydoc by Cameron Laird 
. By 
"results list" I mean the gray-backround'ed box immediately below the 
"Search for" input box in the illustration.

The puzzle for me was that if I enter my module name in the "Search 
for" box, it shows up in the list of results, as expected. But whether 
the results list entry for my module incorporates the description form 
my module's docstring or instead shows my module as having "(no 
description)" is a function of which style of triple quotes I used. 
(If my module docstring is enclosed by triple double quotes, the 
description is extracted from my module's docstring. If it uses triple 
single quotes instead, for purposes of the results list my module's 
docstring is ignored, and the module is listed as having "(no 
description)".)

At any rate, such was the (minor) irritation which caused me to launch 
the thread. It took me a bit to work out that the quote-style was what 
made the difference, and a preliminary google didn't cast light. 
2/3rd's the point of the post was to make the problem resolvable by 
google.

Thanks for your continued efforts to understand what I'm on about. :-)
Best to all,
Brian vdB
--
http://mail.python.org/mailman/listinfo/python-list

Re: re module methods: flags(), pattern()

[Kay Schluehr]

Xah Lee wrote:
> Python re module has methods flags and pattern. How to use these
> exactly?

>From the Python 2.3 documentation, section 2.4.2

flags

The flags argument used when the RE object was compiled, or 0 if no
flags were provided.


groupindex

A dictionary mapping any symbolic group names defined by (?P) to
group numbers. The dictionary is empty if no symbolic groups were used
in the pattern.

pattern

The pattern string from which the RE object was compiled.


Comments derived from the docs and error messages:

> e.g. i tried
>
> print patternObj.flags()
>
> and the error is some "int object is not callable".

=>  flags is an int object

>
> newpattern=re.compile(ur'\w+',patternObj.flags())
>
> also bad.

=> flags is still an int object


> similar error for patternObj.pattern().

=> pattern is a string

> (and i suppose the same for
> groupindex() )

=> groupindex is a dict

>
> thanks.
>
>  Xah
>  [EMAIL PROTECTED]
> â http://xahlee.org/

The documentation is not that bad that one should not read it at all ;)


If You wrestle with regexps I can recommend an old but still usefull
little wrapper I found eventually on the "Vaults of Parnassus" which is
called reverb.py 

Ciao,
Kay

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

Re: Problem with unpack hex to decimal

[Peter Hansen]

Jonathan Brady wrote:
... I also find the following confusing:
struct.calcsize('hb')
3
struct.calcsize('hb') == struct.calcsize('bh')
False
I could understand aligning to multiples of 4, but why is 'hb' different 
from 'bh'? 
Pad bytes have never been, as far as I know, added
at the end of structs in C, only between fields, when
required.  So the leading "b" gets a following pad
byte, but the trailing one doesn't need padding.
-Peter
--
http://mail.python.org/mailman/listinfo/python-list

Re: sscanf needed

[Lee Harr]

On 2005-04-17, Andrew E <[EMAIL PROTECTED]> wrote:
> Uwe Mayer wrote:
>> Hi,
>> 
>> I've got a ISO 8601 formatted date-time string which I need to read into a
>> datetime object.
>> Is there a shorter way than using regular expressions? Is there a sscanf
>> function as in C?
>
> in addition to the other comments...
>
> I like re, because it gives me the most control. See below.
>
>
> import re
> import datetime
>
> class Converter:
>   
>   def __init__( self ):
>   self.isoPattern = re.compile( "(\d\d\d\d)-(\d\d)-(\d\d)[tT
> ](\d\d):(\d\d):(\d\d)" )
>   
>   def iso2date( self, isoDateString ):
>   match = self.isoPattern.match( isoDateString )
>   if not match: raise ValueError( "Not in ISO format: '%s'" %
> isoDateString )
>   
>   return datetime.datetime(
>   int(match.group(1)),
>   int(match.group(2)),
>   int(match.group(3)),
>   int(match.group(4)),
>   int(match.group(5)),
>   int(match.group(6))
>   )
>
> c = Converter()
>
>
> def demo( iso ):
>   try:
>   date = c.iso2date( iso )
>   print "Input '%s' -> datetime: %s" % ( iso, date )
>   except ValueError, e:
>   print str(e)
>   
> demo( "2005-04-21T12:34:56" )
> demo( "2005-04-21 12:34:57" )
> demo( "2005-04-2 12:34:57" )
>
>


That's nice. We should get some code in to the module
so that it is simple to round-trip the default datetime
timestamps.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pysvn install on freebsd

[Lee Harr]

On 2005-04-17, Timothy Smith <[EMAIL PROTECTED]> wrote:
> has anyone used or installed this on fbsd
> the install for it is totally redundant. i get this error for it
>
> make -f freebsd.mak clean all test
> cd ../Source && make -f pysvn_freebsd_py.mak clean
> make: cannot open pysvn_freebsd_py.mak.
> *** Error code 2
>
> Stop in /usr/home/timothy/pysvn-1.1.2/Extension/Builder.
>


Have you tried
/usr/ports/devel/subversion-python/
?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Accessing multidimensional lists with an index list

[Kent Johnson]

Gabriel Birke wrote:
Given the multidimensional list l:
l = [ {'v1': 1, 'v2': 2},
  [ {'v1':4, 'v2': 7},
{'v1': 9, 'v2': 86},
[ {'v1': 77, 'v2': 88}]
  ]
 ]
I want to access specific items the indices of which are stored in
another list. For now, I created a function to do this:
def getNestedValue(l, indices):
while len(indices) > 0:
i = indices.pop(0)
l = l[i] #In future versions, put error checking here
return l
Is there a more elegant or performant language construct to accomplish
my task?
def getNestedValue(l, indices):
for i in indices:
l = l[i] #In future versions, put error checking here
return l
Kent
--
http://mail.python.org/mailman/listinfo/python-list

Re: pydoc preference for triple double over triple single quotes-- anyreason?

[Kent Johnson]

Brian van den Broek wrote:
Kent Johnson said unto the world upon 2005-04-16 16:41:
Brian van den Broek wrote:
I've just spent a frustrating bit of time figuring out why pydoc 
didn't extract a description from my module docstrings. Even though I 
had a well formed docstring (one line, followed by a blank line, 
followed by the rest of the docstring), when I ran Module docs, my 
modules showed up as having "no description". ("Module docs" 
referring to the shortcut installed on Windows that launches the 
pydoc server.)
?? It works for me with triple-single quoted strings...from a quick 
look it appears that pydoc uses inspect which looks at the __doc__ 
attribute; do your modules have __doc__ attributes?

Kent, that's odd. My module does have a valid docstring and hence a 
__doc__ attribute (I did explicitly check). help(my_module) works fine 
at the prompt. It is just the results list in the TKinter interface to 
the pydoc server application that doesn't seem to pick up my module's 
description (in the first line of its docstring) when the docstring is 
triple-single quoted.
I'm not sure what you mean by "the results list in the TKinter interface to the pydoc server". I ran 
the server, clicked "open browser" and browsed to a module in site-packages; that worked fine for me 
under Win2K and Python 2.4.1.

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

Re: pre-PEP: Simple Thunks

[Ron_Adam]

On 17 Apr 2005 01:46:14 -0700, "Kay Schluehr" <[EMAIL PROTECTED]>
wrote:

>Ron_Adam wrote:
>
>> I sort of wonder if this is one of those things that looks like it
>> could be useful at first, but it turns out that using functions and
>> class's in the proper way, is also the best way. (?)
>
>I think Your block is more low level. 

Yes, that's my thinking too.  I'm sort of looking to see if there is a
basic building blocks here that can be used in different situations
but in very consistent ways.  And questioning the use of it as well.  

>It is like copying and pasting
>code-fragments together but in reversed direction: ...

Yes, in a function call, you send values to a remote code block and
receive back a value.

The reverse is to get a remote code block, then use it.  

In this case the inserted code blocks variables become local, So my
point is you don't need to use arguments to pass values. But you do
need to be very consistent in how you use the code block.  (I'm not
suggesting we do this BTW)

The advantage to argument passing in this case would be that it puts a
control on the block that certain arguments get assigned before it
gets executed.

Is it possible to have a tuple argument translation independently of a
function call?  This would also be a somewhat lower level operation,
but might be useful, for example at a certain point in a program you
want to facilitate that certain values are set, you could use a tuple
argument parser to do so.  It could act the same way as a function
call argument parser but could be used in more places and it would
raise an error as expected.  Basically it would be the same as:

def argset(x,y,z=1):
return x,y,z

But done in a inline way.

a,b,c = (x,y,z=1)   # looks familiar doesn't it.  ;-)

As an inline expression it could use '%' like the string methods,
something like this?

(x,y,z=1)%a,b,c # point x,y,z to a,b,c (?)


And combined with code chunks like this.

def chunk:  # code chunk, ie.. no arguments.
# set (x,y) # informal arguments commented
return x+y  # return a value for inline use 

value = (x,y)%a,b: chunk# use local code chunk as body

I think this might resemble some of the suggested lambda replacements.


The altenative might be just to have functions name space imported as
an option.  

def f(x,y):
return x+y

z = dolocal f(1,2)   #But why would I want to do this?

I think these pre-peps are really about doing more with less typing
and don't really add anything to Python.  I also feel that the
additional abstraction when used only to compress code, will just make
programs harder to understand.

>You have to change all the environments that use the thunk e.g.
>renaming variables. It is the opposite direction of creating
>abstractions i.e. a method to deabstract functions: introduce less
>modularity and more direct dependencies. This is the reason why those
>macros are harmfull and should be abandoned from high level languages (
>using them in C is reasonable because code expansion can be time
>efficient and it is also a way to deal with parametric polymorphism but
>Python won't benefit from either of this issues ).
>
>Ciao,
>Kay

I agree. If a code block of this type is used it should be limited to
within the function it's defined in. The advantage, if it's used in a
bare bones low level way with no argument passing, would be some
performance benefits over function calls in certain situations. That
is, a small reusable code block without the function call overhead.
But only use it in the local name space it's defined in.  Otherwise
use a function or a class.

Cheers,
Ron

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

Re: Decorator Syntax For Recursive Properties

[Peter Otten]

Jeffrey Froman wrote:

> it is the originating node (the node trying to find its ancestors). So
> something like this didn't work for me:
> 
> @property
> def ancestors(self):
> if self.parent is None:
> return [self.name]
> return [self.name] + self.parent.ancestors

But this will, I suppose:

@property
def ancestors(self):
if self.parent:
return self.parent.ancestors + [self.parent]
return []
 
A non-recursive variant:

@property
def ancestors(self):
result = []
node = self.parent
while node:
result.append(node)
node = node.parent
result.reverse()
return result

Peter

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

Accessing multidimensional lists with an index list

[Gabriel Birke]

Given the multidimensional list l:
l = [ {'v1': 1, 'v2': 2},
  [ {'v1':4, 'v2': 7},
{'v1': 9, 'v2': 86},
[ {'v1': 77, 'v2': 88}]
  ]
 ]

I want to access specific items the indices of which are stored in
another list. For now, I created a function to do this:

def getNestedValue(l, indices):
while len(indices) > 0:
i = indices.pop(0)
l = l[i] #In future versions, put error checking here
return l

print getNestedValue(l, [1, 2, 0])
print getNestedValue(l, [1, 1])

Is there a more elegant or performant language construct to accomplish
my task?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problem with unpack hex to decimal

[Jonathan Brady]

<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Hello,
>
> I was looking at this:
> http://docs.python.org/lib/module-struct.html
> and tried the following
>
 import struct
 struct.calcsize('h')
> 2
 struct.calcsize('b')
> 1
 struct.calcsize('bh')
> 4
>
> I would have expected
>
 struct.calcsize('bh')
> 3
>
> what am I missing ?

Not sure, however I also find the following confusing:
>>> struct.calcsize('hb')
3
>>> struct.calcsize('hb') == struct.calcsize('bh')
False

I could understand aligning to multiples of 4, but why is 'hb' different 
from 'bh'? 


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

Re: whitespace , comment stripper, and EOL converter

[M.E.Farmer]

I found the bug and hope I have squashed it.
Single and qouble quoted strings that were assignments and spanned
multilines using \ , were chopped after the first line.
example:
__date__ =  'Apr 16, 2005,' \
'Jan 15 2005,' \
'Oct 24 2004'
became:
__date__ =  'Apr 16, 2005,' \

Not good :(

tokenizer sends this as:
name
operator
string
string
string
newline

I added test for string assignments that end in \.
A flag is set and then all strings till a newline are ignored.
Also rearranged the script a little.
Maybe that will do it ...
Updates available at
> The script is located at:
>  http://bellsouthpwp.net/m/e/mefjr75/python/stripper.py
> 
> M.E.Farmer

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

Re: Problem with unpack hex to decimal

[Fredrik Lundh]

"[EMAIL PROTECTED]" wrote:
I was looking at this:
http://docs.python.org/lib/module-struct.html
and tried the following
import struct
struct.calcsize('h')
2
struct.calcsize('b')
1
struct.calcsize('bh')
4
I would have expected
struct.calcsize('bh')
3
what am I missing ?
the sentence
   "By default, C numbers are represented in the machine's native format
   and byte order, and properly aligned by skipping pad bytes if necessary
   (according to the rules used by the C compiler)."
and the text and table following that sentence.

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

Problem with unpack hex to decimal

[[EMAIL PROTECTED]]

Hello,

I was looking at this:
http://docs.python.org/lib/module-struct.html
and tried the following

>>> import struct
>>> struct.calcsize('h')
2
>>> struct.calcsize('b')
1
>>> struct.calcsize('bh')
4

I would have expected

>>> struct.calcsize('bh')
3

what am I missing ?

Thanks in advance,

Jake.

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

Re: unicode "em space" in regex

["Martin v. LÃwis"]

Xah Lee wrote:
> Thanks. Is it true that any unicode chars can also be used inside regex
> literally?
> 
> e.g.
> re.search(ur'â+',mystring,re.U)
> 
> I tested this case and apparently i can. 

Yes. In fact, when you write u"\u2003" or u"â" doesn't matter
to re.search. Either way you get a Unicode object with U+2003
in it, which is processed by SRE.

> But is it true that any
> unicode char can be embedded in regex literally. (does this apply to
> the esoteric ones such as other non-printing chars and combining
> forms...)

Yes. To SRE, only the Unicode ordinal values matter. To determine
whether something matches, it needs to have the same ordinal value
in the string that you have in the expression. No interpretation
of the character is performed, except for the few characters that
have markup meaning in regular expressions (e.g. $, \, [, etc)

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

Re: Python's use in RAD

[James]

[EMAIL PROTECTED] wrote:
> Active State's Komodo IDE is very nice for python development.  It
> includes integration with pdb (python's debugger).  The pro edition
> also has a GUI designer, however I've never used it.  The personal
> version for non commercial use can be had for $30 (and there's also a
> 30 day trial).  They have windows, linux, and solaris versions.
>
> Ross Cowie wrote:
> > Hi,
> >
> > I am currenly a second year university student and was wondering if
> you
> > could help me ut. As part of a project i have decided to write
about
> python,
> > i am not having very much luck with regards to finding infrmation
on
> pythons
> > use in Rapid Application Development, and was wondering of you
could
> > highlight some of the features that make it suitable for RAD. Like
> the use
> > of dinamic binding.
> >
> > Your healp would be appreciated.
> >
> > Hope to hear from you soon.
> >
> > Ross

I don't think he is asking for tools that he could use for creating GUI
apps. Instead he is asking for the features of Python that would make
it easier to build RAD tools to put in his homework.

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

Re: pydoc preference for triple double over triple single quotes -- anyreason?

[Brian van den Broek]

Kent Johnson said unto the world upon 2005-04-16 16:41:
Brian van den Broek wrote:
Hi all,
I'm posting partly so my problem and solution might be more easily 
found by google, and partly out of mere curiosity.

I've just spent a frustrating bit of time figuring out why pydoc 
didn't extract a description from my module docstrings. Even though I 
had a well formed docstring (one line, followed by a blank line, 
followed by the rest of the docstring), when I ran Module docs, my 
modules showed up as having "no description". ("Module docs" referring 
to the shortcut installed on Windows that launches the pydoc server.)

?? It works for me with triple-single quoted strings...from a quick look 
it appears that pydoc uses inspect which looks at the __doc__ attribute; 
do your modules have __doc__ attributes?

Kent

Thanks for the reply, Kent. (Also to Thomas in another reply addressed 
below.)

Kent, that's odd. My module does have a valid docstring and hence a 
__doc__ attribute (I did explicitly check). help(my_module) works fine 
at the prompt. It is just the results list in the TKinter interface to 
the pydoc server application that doesn't seem to pick up my module's 
description (in the first line of its docstring) when the docstring is 
triple-single quoted.

Either way, it's no big deal; my post was at least as much to have a 
googleable record of the situation as to figure out why. That said, it 
still does puzzle me that the pydoc server treats the two styles of 
triple quoted docstrings differently on my system (Python 2.4.1, 
Windows Me).

Thomas suggested the preference might be related to Emacs 
behaviour--that is something I know little about :-)

He also suggested that it could be that pydoc is following the PEP 257 
 recommendation to use 
triple-double quoting. That might be, but if that's the explanation, 
it just pushes the puzzle up a level for me :-)

Anyway, thanks again to both,
Brian vdB
--
http://mail.python.org/mailman/listinfo/python-list

Re: pre-PEP: Suite-Based Keywords - syntax proposal

[Kay Schluehr]

> Exactly. Except the above example is from the day-old-bread
items-tuple-returning version of :: ;-)
> And with an ordered dict subtype there is no need for the generator
expression either,
> since there is a values method for dicts (which in the subtype would
preserve order). E.g.,
>
>  x = property(*seq) where:
>  seq = (::
>  def get_x():
>  return self.__x
>  def set_x(value):
>  self.__x = value
>  del_x = None
>  doc   = "I'm the 'x' property." ).values())
>
> Or more directly:
>
>  x = property(*(::
>  def get_x():
>  return self.__x
>  def set_x(value):
>  self.__x = value
>  del_x = None
>  doc   = "I'm the 'x' property." ).values())

Hmmm ... now You eliminate "where" completely in favor for '::'. This
may be reasonable because '::' is stronger and less context dependent.
But on the other hand it may be also reasonable to eliminate '::'
towards a stronger "where" ;)


x = property(**kw) where kw:
doc = "I'm the 'x' property."
def fget(self):
return self.__x


x = property(*args) where args:
def fget(self):
return self.__x
fset = None
fdel = None
doc = "I'm the 'x' property."


Put definitions into a list:

l = list(*args) where args:
def fget(self):
return self.__x
doc = "I'm the 'x' property."


Nest suites:

x = property(*args) where args:
t = tuple(*t) where t:
def fget(self):
return self.__x
fset = None
fdel = None
doc = "I'm the 'x' property."


Evaluate conditions:

if f(*args)==1 where args:
   x = 1
   y = 2

I think this version is more mainstream syntax ( and without braces and
additional punctuation ) than the unary prefix operator '::' which
drops statements into expressions within expressions.
   
Regards,
Kay

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

Re: module to parse "pseudo natural" language?

[John Roth]

"Andrew E" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Hi all
I've written a python program that adds orders into our order routing
simulation system. It works well, and has a syntax along these lines:
 ./neworder --instrument NOKIA --size 23 --price MARKET --repeats 20
etc
However, I'd like to add a mode that will handle, say:
 ./neworder buy 23 NOKIA at MKT x 20
I could enter several orders either by running multiple times, or use a
comma-separated approach, like:
 ./neworder buy 23 NOKIA at MKT on helsinki, sell 20 NOKIA at market on
helsinki
The thing about this is that its a "tolerant" parser, so all of these
should also work:
 # omit words like "at", "on"
 ./neworder buy 23 NOKIA mkt helsinki
 # take any symbol for helsinki
 ./neworder buy 23 mkt helsinki
 # figure out that market=helsinki
 ./neworder buy 23 NOKIA at market price
I've started writing a simple state-based parser, usage like:
 class NaturalLanguageInsructionBuilder:
   def parse( self, arglist ):
 """Given a sequence of args, return an Instruction object"""
 ...
 return Instruction( instrument, size, price, ... )
 class Instruction:
   """encapsulate a single instruction to buy, sell, etc"""
   def __init__( self, instrument, size, price, ... ):
 ...
This doesn't work yet, but I know with time I'll get there.
Question is - is there a module out there that will already handle this
approach?
Thanks for any suggestions :)
There's NLTK (on Sourceforge) which has already been  mentioned.
However, it's a teaching tool, not a real production natural language
parser.
I'd suggest you step back from the problem and take a wider
view. Parsing natural language, in all its variations, is an unsolved
research problem that is part of what has given Artificial Intelligence
somewhat of a black eye.
Your problem is, however, much simpler than the general one:
you've got a limited number of commands which pretty much
all follow the VO (verb operands) pattern.
You've also got a lot of words from limited and disjunct
vocabularies that can be used to drive the parse. In your example,
at least one of 'buy' and 'sell' is required to start a clause,
MKT is one of maybe a half dozen
qualifiers that specify other information that must be present,
there are a limited number of exchanges, and the number of
shares seems to be the only number present.
I'd also take a bit of advice from the XP community: don't
write the library first, wait until you've got at least three
working examples so you know the services that the
library really needs to support.
John Roth
Andrew 
--
http://mail.python.org/mailman/listinfo/python-list

Re: re module methods: flags(), pattern()

[Reinhold Birkenfeld]

Xah Lee wrote:
> Python re module has methods flags and pattern. How to use these
> exactly?
> 
> e.g. i tried
> 
> print patternObj.flags()
> 
> and the error is some "int object is not callable".

Where do you read "methods"?

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

How to compile ScientificPython-2.4.9 under XP cygwin environment?

[Zhuanshi He]

Dear All,

I try to compile ScientificPython-2.4.9
(http://starship.python.net/~hinsen/ScientificPython/) under Windows XP
cygwin environment using python 2.3.3 ,and gcc (GCC) 3.3.3 (cygwin
special).

The information shows as fillows:

--
Using netCDF installation in  /usr/local
running build
running build_py
running build_ext
building 'Scientific_netcdf' extension
gcc -shared -Wl,--enable-auto-image-base
build/temp.cygwin-1.5.10-i686-2.3/Src/Scientific_netcdf.o
-L/usr/local/lib -L/usr/lib/python2.3/config -lnetcdf -lpython2.3 -o
build/lib.cygwin-1.5.10-i686-2.3/Scientific/cygwin/Scientific_netcdf.dll

build/temp.cygwin-1.5.10-i686-2.3/Src/Scientific_netcdf.o(.text+0x6eb):
In function `initScientific_netcdf':
/cygdrive/c/pygmt/ScientificPython-2.4.9/Src/Scientific_netcdf.c:2050:
undefined reference to `_ncopts'
build/temp.cygwin-1.5.10-i686-2.3/Src/Scientific_netcdf.o(.text+0x3067):
In function `netcdf_seterror':
/cygdrive/c/pygmt/ScientificPython-2.4.9/Src/Scientific_netcdf.c:46:
undefined reference to `_ncerr'
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1


Does anyone meet same problem?


--
Zhuanshi He / Z. He
Advanced Environmental Monitoring Research Center (ADEMRC)
Gwangju Institute of Science and Technology (GIST)
1 Oryong-dong, Puk-gu, Gwangju 500-712, South Korea
Tel: +82-(0)62-970-3406
Fax: +82-(0)62-970-3404
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: sscanf needed

[Andrew E]

Uwe Mayer wrote:
> Hi,
> 
> I've got a ISO 8601 formatted date-time string which I need to read into a
> datetime object.
> Is there a shorter way than using regular expressions? Is there a sscanf
> function as in C?

in addition to the other comments...

I like re, because it gives me the most control. See below.


import re
import datetime

class Converter:

def __init__( self ):
self.isoPattern = re.compile( "(\d\d\d\d)-(\d\d)-(\d\d)[tT
](\d\d):(\d\d):(\d\d)" )

def iso2date( self, isoDateString ):
match = self.isoPattern.match( isoDateString )
if not match: raise ValueError( "Not in ISO format: '%s'" %
isoDateString )

return datetime.datetime(
int(match.group(1)),
int(match.group(2)),
int(match.group(3)),
int(match.group(4)),
int(match.group(5)),
int(match.group(6))
)

c = Converter()


def demo( iso ):
try:
date = c.iso2date( iso )
print "Input '%s' -> datetime: %s" % ( iso, date )
except ValueError, e:
print str(e)

demo( "2005-04-21T12:34:56" )
demo( "2005-04-21 12:34:57" )
demo( "2005-04-2 12:34:57" )


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

Re: sscanf needed

[Kent Johnson]

Uwe Mayer wrote:
Hi,
I've got a ISO 8601 formatted date-time string which I need to read into a
datetime object.
Something like this (adjust the format to suit):
import datetime, time
dt = datetime.datetime(*time.strptime(data, "%Y-%m-%d %H:%M:%S")[:6])
Kent
--
http://mail.python.org/mailman/listinfo/python-list

How to compile ScientificPython-2.4.9 under XP cygwin environment?

[Zhuanshi He]

I try to compile ScientificPython-2.4.9
(http://starship.python.net/~hinsen/ScientificPython/) under Windows XP
cygwin environment using python 2.3.3 ,and gcc (GCC) 3.3.3 (cygwin
special).

The information shows as follows:

--
Using netCDF installation in  /usr/local
running build
running build_py
running build_ext
building 'Scientific_netcdf' extension
gcc -shared -Wl,--enable-auto-image-base
build/temp.cygwin-1.5.10-i686-2.3/Src/Scientific_netcdf.o
-L/usr/local/lib -L/usr/lib/python2.3/config -lnetcdf -lpython2.3 -o
build/lib.cygwin-1.5.10-i686-2.3/Scientific/cygwin/Scientific_netcdf.dll

build/temp.cygwin-1.5.10-i686-2.3/Src/Scientific_netcdf.o(.text+0x6eb):
In function `initScientific_netcdf':
/cygdrive/c/pygmt/ScientificPython-2.4.9/Src/Scientific_netcdf.c:2050:
undefined reference to `_ncopts'
build/temp.cygwin-1.5.10-i686-2.3/Src/Scientific_netcdf.o(.text+0x3067):
In function `netcdf_seterror':
/cygdrive/c/pygmt/ScientificPython-2.4.9/Src/Scientific_netcdf.c:46:
undefined reference to `_ncerr'
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1


Does anyone meet same problem?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: sscanf needed

[Leif B. Kristensen]

Uwe Mayer skrev:

> Hi,
> 
> I've got a ISO 8601 formatted date-time string which I need to read
> into a datetime object.

Look up time.strptime, it does exactly what you want.
-- 
Leif Biberg Kristensen
http://solumslekt.org/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: sscanf needed

[Fredrik Lundh]

Uwe Mayer wrote:
I've got a ISO 8601 formatted date-time string which I need to read into a
datetime object.

import time
help(time.strptime)
Help on built-in function strptime in module time:
strptime(...)
   strptime(string, format) -> struct_time
   Parse a string to a time tuple according to a format specification.
   See the library reference manual for formatting codes (same as
   strftime()).

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

sscanf needed

[Uwe Mayer]

Hi,

I've got a ISO 8601 formatted date-time string which I need to read into a
datetime object.
Is there a shorter way than using regular expressions? Is there a sscanf
function as in C?

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

Re: Python 2.4 killing commercial Windows Python development ?

[Peter Lee]

 Terry Reedy writes:

>> To put it another way, needing a Python interpreter to run .py files is 
no 
>> different from, for instance, needing a movie player to run .mpg files, 
and 
>> all Windows users are or need to become familiar with that general 
concept.

The problem for windows users isn't that they have to download a movie
player to play .mpg files... it's that they also have to download and
install python/java runtime to "play" the player because it was written
in python/java.  Most won't bother and will download/install native
win32 app instead.

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

re module methods: flags(), pattern()

[Xah Lee]

Python re module has methods flags and pattern. How to use these
exactly?

e.g. i tried

print patternObj.flags()

and the error is some "int object is not callable".

newpattern=re.compile(ur'\w+',patternObj.flags())

also bad.

similar error for patternObj.pattern(). (and i suppose the same for
groupindex() )

thanks.

 Xah
 [EMAIL PROTECTED]
â http://xahlee.org/

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

Re: module to parse "pseudo natural" language?

[F. Petitjean]

Le Sun, 17 Apr 2005 13:38:09 +0200, Andrew E a écrit :
> Hi all
> 
> I've written a python program that adds orders into our order routing
> simulation system. It works well, and has a syntax along these lines:
> 
>   ./neworder --instrument NOKIA --size 23 --price MARKET --repeats 20
> 
> etc
> 
> However, I'd like to add a mode that will handle, say:
> 
>   ./neworder buy 23 NOKIA at MKT x 20
> 
> I could enter several orders either by running multiple times, or use a
> comma-separated approach, like:
> 
>   ./neworder buy 23 NOKIA at MKT on helsinki, sell 20 NOKIA at market on
> helsinki
It would be simpler to have the rule : one line == one order, action,
command wahtever.
> 
> The thing about this is that its a "tolerant" parser, so all of these
> should also work:
> 
>   # omit words like "at", "on"
>   ./neworder buy 23 NOKIA mkt helsinki
> 
>   # take any symbol for helsinki
>   ./neworder buy 23 mkt helsinki
> 
>   # figure out that market=helsinki
>   ./neworder buy 23 NOKIA at market price
You have some variation of the same « buy » order. If you want to detail
the semantics :  you arrive to determine the different parameter of a
BuyCommand : what, where, how (many) ...
  This semantic is expressed differently in english, US-english, french
  ...
  If you base your parser on regex you see that the same BuyOrder is
  represented by a number of variant :
  Please, buy 23 NOKIA at market Helsinki
  Acheter 40 actions Bouygues à la Bouse de Paris

So you have for a given environment (orders management module) a number
of commands expressed in pseudo-natural languages. Each command has a
certain number of attributes
  name, module_name, parameters, variants(list of regexps for instance),
  description, short description, sample sentence  (to be presented
  to the user in an interactive session if requested).
  An important attribute is naturally the action taken when the
  parser/interpreter matches the current line.

So you group the description of the Commands in an easy to parse file
and write an interpreter which on startup read such a file for the
Commands it understands : command to load a module, to list the commands
in the currently loaded module or in the interpreter, command to display
the sample, short or long description (help about cmd  or how to spell
cmd)., command to stop the interpreter (and the program) ...
command to read/include a file containings commands to parse and
execute.
  Python is dynamic, with setattr() you can easily construct a Command
  object from its description.

Here is what could be the description of a command to compute the
equilibrium position in a stability module (using a «here» shell like
syntax ):
command equilibre << eoc
description << eod
La commande « equilibre » permet de lancer le calcul de la position
d'équilibre du flotteur couramment décrit.
position equilibre en partant de pqr 0.0/0.0/1.0 et h=8.500
les mots-clés sont equilibre pqr et h[=]
eod
sample < 
# The regexpes
variants << eov
# the following regexp is with re.I (ignore case flag) :
variant I << eovi
equilibrer?\spqr\s+(?P\d*\.\d*/\d*\.\d*/\d*\.\d*)\s+(?P\d*\.\d*)
eovvi
#  syntax of regexp untested :-)
variant << eovi
equilibrium\spqr\s+(?P\d*\.\d*/\d*\.\d*/\d*\.\d*)\s+(?P\d*\.\d*)
eovvi
eov
eoc

> Thanks for any suggestions :)
> 
> Andrew
-- 
http://mail.python.org/mailman/listinfo/python-list

ANN: Veusz 0.5 - a scientific plotting package

[Jeremy Sanders]

Veusz 0.5
-
Velvet Ember Under Sky Zenith
-
http://home.gna.org/veusz/

Veusz is Copyright (C) 2003-2005 Jeremy Sanders <[EMAIL PROTECTED]>
Licenced under the GPL (version 2 or greater)

Veusz is a scientific plotting package written in Python (currently
100% Python). It uses PyQt for display and user-interfaces, and
numarray for handling the numeric data. Veusz is designed to produce
publication-ready Postscript output.

Veusz provides a GUI, command line and scripting interface (based on
Python) to its plotting facilities. The plots are built using an
object-based system to provide a consistent interface.

Changes from 0.4:
 Installation:
  * distutils used to install the package. RPMS available.
 Plotting:
  * Different error bar styles (diamond, curve...)
  * "Matched" axes, with the same scale on each
  * Data can be linked from external files instead of embedded in
document
  * Filled regions under/over functions or xy plots
  * Improved function clipping near edge of plot
  * Default values can be set for settings, which are remembered
between sessions (e.g. blue points for xy3).
  * Rotated text labels
  * Improved fitting, giving results from chi2, etc..
 UI:
  * Can move around widgets and delete them
  * Exception dump dialog to send bug reports
  * Improved import dialog help
  * Propagate settings between widgets
  * Window positions are saved between sessions 
 Reading data:
  * Better error handling when reading data
 + Numerous bug fixes

Features of package:
 * X-Y plots (with errorbars)
 * Stepped plots (for histograms)
 * Line plots
 * Function plots
 * Fitting functions to data
 * Stacked plots and arrays of plots
 * Plot keys
 * Plot labels
 * LaTeX-like formatting for text
 * EPS output
 * Simple data importing
 * Scripting interface
 * Save/Load plots

To be done:
 * Contour plots
 * Images
 * UI improvements
 * Import filters (for qdp and other plotting packages, fits, csv)
 * Data manipulation
 * Python embedding interface (for embedding Veusz in other programs).
   [some of the external interface is complete]

Requirements:
 Python (probably 2.3 or greater required)
   http://www.python.org/
 Qt (free edition)
   http://www.trolltech.com/products/qt/  
 PyQt (SIP is required to be installed first)
   http://www.riverbankcomputing.co.uk/pyqt/
   http://www.riverbankcomputing.co.uk/sip/
 numarray
   http://www.stsci.edu/resources/software_hardware/numarray
 Microsoft Core Fonts (recommended)
   http://corefonts.sourceforge.net/

For documentation on using Veusz, see the "Documents" directory. The
manual is in pdf, html and text format (generated from docbook).

If you enjoy using Veusz, I would love to hear from you. Please join
the mailing lists at

https://gna.org/mail/?group=veusz

to discuss new features or if you'd like to contribute code. The
newest code can always be found in CVS.

Cheers

Jeremy

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

Re: unicode "em space" in regex

[Fredrik Lundh]

Xah Lee wrote:
"Regular expression pattern strings may not contain null bytes, but can
specify the null byte using the \number notation."
What is meant by null bytes here? Unprintable chars??
no, null bytes.  "\0".  "\x00".  ord(byte) == 0.  chr(0).
and the "\number" is meant to be decimal? 
octal.  this is explained on the "Regular Expression Syntax" page.
and in what encoding?
null byte encoding?  you're confused.

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

Re: unicode "em space" in regex

[Reinhold Birkenfeld]

Xah Lee wrote:

> "Regular expression pattern strings may not contain null bytes, but can
> specify the null byte using the \number notation."
> 
> What is meant by null bytes here? Unprintable chars?? and the "\number"
> is meant to be decimal? and in what encoding?

The null byte is a byte with the integer value 0. Difficult, isn't it.

The \number notation is, as you could read in 
http://docs.python.org/ref/strings.html,
octal.

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

Re: module to parse "pseudo natural" language?

[Diez B. Roggisch]

> 
> Question is - is there a module out there that will already handle this
> approach?

Try the python nltk. I haven't done stuff with it so far, but I'd certainly
give it a try when I need natural language support.


http://nltk.sourceforge.net/

-- 
Regards,

Diez B. Roggisch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [perl-python] Python documentation moronicities (continued)

[Roman Neuhauser]

# [EMAIL PROTECTED] / 2005-04-17 14:59:50 +0200:
> Roman Neuhauser wrote:
> 
> >>Here's a puzzle for you: Where does this list appear? What's missing?
> >>
> >>"..., Mullender, Nagata, Ng, Oner, Oppelstrup, ..."
> >
> >   Sorry, I don't have time for puzzles.
> 
> nor for contributing, it seems.  otherwise, your name would be on that list.

Right. There's a finite number of hours in a day, and I chose
to spend most of it on FreeBSD, and my name is on that operating
system's contributor list. You're welcome to use the results of
the work.

But anyway, I was honestly asked about what I considered suboptimal
in the python documentation, and I honestly answered. Does that
bother you?

-- 
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man.  You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: unicode "em space" in regex

[Xah Lee]

Thanks. Is it true that any unicode chars can also be used inside regex
literally?

e.g.
re.search(ur'â+',mystring,re.U)

I tested this case and apparently i can. But is it true that any
unicode char can be embedded in regex literally. (does this apply to
the esoteric ones such as other non-printing chars and combining
forms...)


Related...:

The official python doc:
 http://python.org/doc/2.4.1/lib/module-re.html
says:

"Regular expression pattern strings may not contain null bytes, but can
specify the null byte using the \number notation."

What is meant by null bytes here? Unprintable chars?? and the "\number"
is meant to be decimal? and in what encoding?

 Xah
 [EMAIL PROTECTED]
â http://xahlee.org/

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

Re: [perl-python] Python documentation moronicities (continued)

[Fredrik Lundh]

Roman Neuhauser wrote:
Here's a puzzle for you: Where does this list appear? What's missing?
"..., Mullender, Nagata, Ng, Oner, Oppelstrup, ..."
   Sorry, I don't have time for puzzles.
nor for contributing, it seems.  otherwise, your name would be on that list.

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

Re: [perl-python] Python documentation moronicities (continued)

[Roman Neuhauser]

# [EMAIL PROTECTED] / 2005-04-13 08:07:06 +1000:
> On Tue, 12 Apr 2005 13:06:36 +0200, Roman Neuhauser
> <[EMAIL PROTECTED]> wrote:
> 
> >Unfortunately, the python community seems to bathe in the
> >misorganized half-documentation, see e. g.
> >http://marc.theaimsgroup.com/?l=python-list&m=111303919606261&w=2
> >especially the reply that (as I read it) suggested reverse
> >engineering as a viable alternative to documentation.
> 
> As I read the reply, it was a smart-arse attempt at humour, a *PUN* on
> the word "list" (mailing list versus Python list). What I would call
> "introspection" (not "reverse engineering") was then suggested.
> 
> Moreover, both of the concepts mentioned in the quoted thread
> (sequence.index() and the "in" operator) are IMESHO adequately
> documented.
> 
> Do you have any examples of what you regard as "misorganized
> half-documentation"?
 
Description of classes:

* What's with "Programmer's Note", is the other paragraph of the
  description aimed at salesmen?

* Why isn't there a link to a description of "new-style classes"
  (presumably to the "New-style Classes" essay since, as
  http://www.python.org/doc/newstyle.html says, NSC aren't
  integrated into the standard documentation.

* Aren't class objects instances of a builtin type? What should
  I read into ""?

distutils:

* sections 10.26 through 10.45 are completely empty

* http://docs.python.org/dist/listing-packages.html:
  "when you say packages = ['foo'] in your setup script" couldn't
  be any more vague I guess. Does the statement belong in the
  global scope?

* http://docs.python.org/dist/listing-packages.html:
  "Then you would put package_dir = {'': 'lib'} in your setup
  script.": does that statement belong in the global scope, or
  is it a keyword argument for setup(), which would mean that the
  listing at http://docs.python.org/dist/module-distutils.core.html
  cannot be trusted as complete?

lists: this is a matter of taste, but I find the split of list
description between http://docs.python.org/lib/typesseq.html and
http://docs.python.org/lib/typesseq-mutable.html (without pointers
from typesseq.html to typesseq-mutable.html where I would expect
them, such as mentioning append()) confusing.

The above applies to other mutable sequential types as well, of
course.

In general, various parts of the documentation often refer the
reader to other parts without using html anchors, what should be
concise, accurate, and complete description is a meandering essay
with vague formulations (see quotes from the distutils manual
above), etc.

There's also this thing with easy access to individual nodes:
I often miss being able to type something like
http://docs.python.org/os.path.expanduser and be redirected to 
http://docs.python.org/lib/module-os.path.html#l2h-1731

Mebbe it's just me, but I've been trying python on and off for
several years now, and it's always been precisely its documentation
that has made me back out. I know I'll get to know the language
quite well some time, but it'll be through scars, and I'll have many
f*cks behind me.

> Here's a puzzle for you: Where does this list appear? What's missing?
> 
> "..., Mullender, Nagata, Ng, Oner, Oppelstrup, ..."

Sorry, I don't have time for puzzles.

-- 
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man.  You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pre-PEP: Suite-Based Keywords

[Reinhold Birkenfeld]

Bengt Richter wrote:

> Stretching for it, using my latest and greatest ;-)
> 
> y = f(**::
>x = 1
>y = 'y for f'
> )*g(**::
>x = 'x for g'
>y = 'y for g'
>def foo(): return 'foo for g'
> )
> 
> Note that there is no problem adding other parameters, because :: is 
> just
> a unary expression returning dict subtype instance, e.g.,
> 
> y = f(11,22,**::
>x = 1
>y = 'y for f'
> )*g(*args_from_somewhere, **::
>x = 'x for g'
>y = 'y for g'
>def foo(): return 'foo for g'
> )

You know that this is dead ugly?

The real ``problem'' (if you see one) is that the indentation syntax
doesn't allow for suites in expressions.

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

Re: Compute pi to base 12 using Python?

[Dick Moores]

Paul Rubin wrote at 02:35 4/17/2005:
Dick Moores <[EMAIL PROTECTED]> writes:
> >C:\cygwin\bin\bc -l > pi12.txt
>
> But how or when do you enter the lines
>
> scale = 3000
> obase = 12
> print 4 * a(1)
You could put them into a file, say pi.bc.  Then run
  bc -l pi.bc
OK, now that I've got Textpad trained to open .bc files, I'm thinking of 
things to store in them. I'm sure I'll want to put in some remarks as 
well. What should I use to mark the remarks. "#", "//", or what?

The bc man page at  is tough. Any 
suggestion for more easily understandable help?

And finally (maybe), is it possible to employ bc within a Python script?
Thanks,
Dick

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

module to parse "pseudo natural" language?

[Andrew E]

Hi all

I've written a python program that adds orders into our order routing
simulation system. It works well, and has a syntax along these lines:

  ./neworder --instrument NOKIA --size 23 --price MARKET --repeats 20

etc

However, I'd like to add a mode that will handle, say:

  ./neworder buy 23 NOKIA at MKT x 20

I could enter several orders either by running multiple times, or use a
comma-separated approach, like:

  ./neworder buy 23 NOKIA at MKT on helsinki, sell 20 NOKIA at market on
helsinki

The thing about this is that its a "tolerant" parser, so all of these
should also work:

  # omit words like "at", "on"
  ./neworder buy 23 NOKIA mkt helsinki

  # take any symbol for helsinki
  ./neworder buy 23 mkt helsinki

  # figure out that market=helsinki
  ./neworder buy 23 NOKIA at market price


I've started writing a simple state-based parser, usage like:

  class NaturalLanguageInsructionBuilder:

def parse( self, arglist ):
  """Given a sequence of args, return an Instruction object"""
  ...
  return Instruction( instrument, size, price, ... )


  class Instruction:
"""encapsulate a single instruction to buy, sell, etc"""

def __init__( self, instrument, size, price, ... ):
  ...


This doesn't work yet, but I know with time I'll get there.

Question is - is there a module out there that will already handle this
approach?

Thanks for any suggestions :)

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

Re: Compute pi to base 12 using Python?

[Dick Moores]

Bengt Richter wrote at 02:26 4/17/2005:
>Could someone remind me how to get the output of bc -l into a text file
>on Windows? (I've tried employing " > pi3003.txt" in various ways) OR,
>how to copy and paste from the command line window, or whatever that
>window is called? (Sorry for the OT question.)
To copy from the command window to the clipboard:
1. Scroll top of desired stuff to make it visible near top
2. Hold down Alt
3. Tap Space Bar
4. Release Alt
5. Tap e
6. Tap k
7. Use mouse or arrow keys to place cursor on top left corner of desired box
8. Hold down Shift
9. Use arrow keys or mouse-with-left-button-pressed to go to bottom 
right character of desired box
9a. If the bottom is out of sight, keep holding  shift down and pretend 
you can cursor down below bottom.
the attempt should make the screen scroll up and select more 
desired material. If you overshoot, don't panic,
just keep holding down shift and use arrows (the are slower) or 
mouse-with-left-button-still-down to move to
desired bottom right corner.
10. Release mouse button if using that
11. Release Shift
12. Press Enter
That should copy to the clipboard and make the selection box revert to 
normal display.

Pasting from clipboard is up to you. Pasting into the command window 
from clipboard
is 2-5 above, and Tap p
Thanks for showing me another way. But Roel Schroeven's
"to copy from the command prompt window: open the system menu
(icon in the top left corner of the window) and choose Edit->Mark. Then
select what you want to copy and press Enter or choose Edit->Copy in the
system menu."
seems to be easier.

PS. Redirecting with > from a script whose interpreter was started by 
windows extension association
doesn't work on some version of windows. To be safe, invoke the 
interpreter explicitly, e.g.,
python myscript.py [whatever args here] > pi3003.txt
Thanks very much for this.
What kind of args could I use here?
Dick
--
http://mail.python.org/mailman/listinfo/python-list

Re: Pattern Matching Given # of Characters and no String Input; useRegularExpressions?

[Kent Johnson]

tiissa wrote:
Synonymous wrote:
Can regular expressions compare file names to one another. It seems RE
can only compare with input i give it, while I want it to compare
amongst itself and give me matches if the first x characters are
similiar.
Do you have to use regular expressions?
If you know the number of characters to match can't you just compare 
slices?

It seems to me you just have to compare each file to the next one (after 
having sorted your list).
itertools.groupby() can do the comparing and grouping:
 >>> import itertools
 >>> def groupbyPrefix(lst, n):
 ...   lst.sort()
 ...   def key(item):
 ... return item[:n]
 ...   return [ list(items) for k, items in itertools.groupby(lst, key=key) ]
 ...
 >>> names = ['cccat', 'cccap', 'cccan', 'cccbt', 'ccddd', 'dddfa', 'dddfg', 
'dddfz']
 >>> groupbyPrefix(names, 3)
[['cccat', 'cccap', 'cccan', 'cccbt'], ['ccddd'], ['dddfa', 'dddfg', 'dddfz']]
 >>> groupbyPrefix(names, 2)
[['cccat', 'cccap', 'cccan', 'cccbt', 'ccddd'], ['dddfa', 'dddfg', 'dddfz']]
Kent
--
http://mail.python.org/mailman/listinfo/python-list

Re: XML parsing per record

[Fredrik Lundh]

William Park wrote:
You may want to try Expat (www.libexpat.org) or Python wrapper to it.
Python comes with a low-level expat wrapper (pyexpat).
however, if you want performance, cElementTree (which also uses expat) is a
lot faster than pyexpat.  (see my other post for links to benchmarks and code).

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

Re: Pattern Matching Given # of Characters and no String Input; use RegularExpressions?

[tiissa]

tiissa wrote:
If you know the number of characters to match can't you just compare 
slices?
If you don't, you can still do it by hand:
In [7]: def cmp(s1,s2):
  : diff_map=[chr(s1[i]!=s2[i]) for i in range(min(len(s1), 
len(s2)))]
  : diff_index=''.join(diff_map).find(chr(True))
  : if -1==diff_index:
  : return min(len(s1), len(s2))
  : else:
  : return diff_index
  :

In [8]: cmp('cccat','cccap')
Out[8]: 4
In [9]: cmp('ccc','cccap')
Out[9]: 3
In [10]: cmp('cccat','dddfa')
Out[10]: 0
--
http://mail.python.org/mailman/listinfo/python-list

Re: Pattern Matching Given # of Characters and no String Input; use RegularExpressions?

[tiissa]

Synonymous wrote:
Can regular expressions compare file names to one another. It seems RE
can only compare with input i give it, while I want it to compare
amongst itself and give me matches if the first x characters are
similiar.
Do you have to use regular expressions?
If you know the number of characters to match can't you just compare slices?
In [1]: f1,f2='cccat','cccap'
In [2]: f1[:3]
Out[2]: 'ccc'
In [3]: f1[:3]==f2[:3]
Out[3]: True
It seems to me you just have to compare each file to the next one (after 
having sorted your list).
--
http://mail.python.org/mailman/listinfo/python-list

Re: whitespace , comment stripper, and EOL converter

[M.E.Farmer]

Google has now 'fixed' there whitespace issue and now has an auto-quote
issue argggh!

The script is located at:
 http://bellsouthpwp.net/m/e/mefjr75/python/stripper.py 

M.E.Farmer

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

Re: Compute pi to base 12 using Python?

[Paul Rubin]

Dick Moores <[EMAIL PROTECTED]> writes:
> >C:\cygwin\bin\bc -l > pi12.txt
> 
> But how or when do you enter the lines
> 
> scale = 3000
> obase = 12
> print 4 * a(1)

You could put them into a file, say pi.bc.  Then run
  bc -l pi.bc
-- 
http://mail.python.org/mailman/listinfo/python-list

Pattern Matching Given # of Characters and no String Input; use RegularExpressions?

[Synonymous]

Hello,

Can regular expressions compare file names to one another. It seems RE
can only compare with input i give it, while I want it to compare
amongst itself and give me matches if the first x characters are
similiar.

For example:

cccat
cccap
cccan
dddfa
dddfg
dddfz

Would result in the 'ddd' and the 'ccc' being grouped together if I
specified it to look for a match of the first 3 characters.

What I am trying to do is build a script that will automatically
create directories based on duplicates like this starting with say 10
characters, and going down to 1.  This way "Vacation1.jpg,
Vacation2.jpg" would be sent to its own directory (if i specifiy the
first 8 characters being similiar) and "Cat1.jpg, Cat2.jpg" would
(with 3) as well.

Thanks for your help and interest!

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

Re: whitespace , comment stripper, and EOL converter

[M.E.Farmer]

MrJean1 wrote:
> There is an issue with both my and your code: it only works if doc
> strings are triple quoted and if there are no other triple quoted
> strings in the Python code.
I had not considered single quoted strings ;)
> A triple quoted string used in an assignment will be removed, for
> example this case
>
>   s  =  '''this string should not be removed'''
>
>
> It is still unclear how to distinguish doc strings from other
strings.
> Also, I have not checked the precise Python syntax, but doc strings
do
> not need to be enclosed by triple quotes.  A single quote may be
> allowed too.
>
> Maybe this rule will work: a doc string is any string preceded by a
> COLON token followed by zero, one or more INDENT or NEWLINE tokens.
> Untested!
Not needed , if you reread my post I explain that I had solved that
issue.
If you use the line argument that tokenizer supplies we can strip
whitespace and 'rRuU' from the start of the line and look for a single
quote or a double quote .
I have tested it and it works.
Reworked the 'pep8' thing and fixed the bug you mentioned here is the
changes.

>
##
> > # Python source stripper
> >
>
##
> >
> > import os
> > import sys
> > import token
> > import keyword
> > import StringIO
> > import tokenize
> > import traceback
> > __credits__ = '''
> > Jürgen Hermann
> > M.E.Farmer
> > Jean Brouwers
> > '''
> > __version__ = '.8'
> > __author__ = 'M.E.Farmer'
> > __date__ =  'Apr 16, 2005,' \
> > 'Jan 15 2005,' \
> > 'Oct 24 2004' \
> >
> >
> >
>
##
> >
> > class Stripper:
> > """Python source stripper
> > """
> > def __init__(self, raw):
> > self.raw = raw
> >
> > def format(self, out=sys.stdout, comments=0, docstrings=0,
> > spaces=1, untabify=1, eol='unix'):
> > """ strip comments,
> > strip docstrings,
> > strip extra whitespace and lines,
> > convert tabs to spaces,
> > convert EOL's in Python code.
> > """
> > # Store line offsets in self.lines
> > self.lines = [0, 0]
> > pos = 0
> > # Strips the first blank line if 1
> > self.lasttoken = 1
> > self.temp = StringIO.StringIO()
> > self.spaces = spaces
> > self.comments = comments
> > self.docstrings = docstrings
> >
> > if untabify:
> >self.raw = self.raw.expandtabs()
> > self.raw = self.raw.rstrip()+' '
> > self.out = out
> >
> > # Have you ever had a multiple line ending script?
> > # They can be nasty so lets get them all the same.
> > self.raw = self.raw.replace('\r\n', '\n')
> > self.raw = self.raw.replace('\r', '\n')
> > self.lineend = '\n'
> >
> > # Gather lines
> > while 1:
> > pos = self.raw.find(self.lineend, pos) + 1
> > if not pos: break
> > self.lines.append(pos)
> >
> > self.lines.append(len(self.raw))
> > self.pos = 0
> >
> > # Wrap text in a filelike object
> > text = StringIO.StringIO(self.raw)
> >
> > # Parse the source.
> > ## Tokenize calls the __call__
> > ## method for each token till done.
> > try:
> > tokenize.tokenize(text.readline, self)
> > except tokenize.TokenError, ex:
> > traceback.print_exc()
> >
> > # Ok now we write it to a file
> > # but we also need to clean the whitespace
> > # between the lines and at the ends.
> > self.temp.seek(0)
> >
> > # All this should be written into the
> > # __call__ method just haven't yet...
> >
> > # Mac CR
> > if eol == 'mac':
> >self.lineend = '\r'
> > # Windows CR LF
> > elif eol == 'win':
> >self.lineend = '\r\n'
> > # Unix LF
> > else:
> >self.lineend = '\n'
> >
> > for line in self.temp.readlines():
> > if spaces == -1:
> > self.out.write(line.rstrip()+self.lineend)
> > else:
> > if not line.isspace():
> > self.lasttoken=0
> > self.out.write(line.rstrip()+self.lineend)
> > else:
> > self.lasttoken+=1
> > if self.lasttoken<=self.spaces and self.spaces:
> > self.out.write(self.lineend)
> >
> > def __call__(self, toktype, toktext,
> >  (srow,scol), (erow,ecol), line):
> > """ Token handler.
> > """
> > # calculate new positions
> > oldpos = self.pos
> > newpos = self.lines[srow] + scol
> > self.pos = newpos + len(toktext)
> >
> ># kill comments
> >  

Re: Compute pi to base 12 using Python?

[Dick Moores]

Roel Schroeven wrote at 01:45 4/17/2005:
Dick Moores wrote:
M.E.Farmer wrote at 23:18 4/14/2005:
> >Using the GNU "bc" utility:
> >
> >   $ bc -l
> >   bc 1.06
> >   Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation,
Inc.
> >   This is free software with ABSOLUTELY NO WARRANTY.
> >   For details type `warranty'.
> >   scale = 3000# number of output places wanted
> >   obase = 12  # output base
> >   print 4 * a(1)  # pi = 4*arctan(1)
Wow! this got me the 3003 (changed from 3000) digits of pi to base 12 
in 60.8 secs. No, I didn't count them yet, nor am I sure they're 
correct. But I'd bet on them..
Could someone remind me how to get the output of bc -l into a text file 
on Windows? (I've tried employing " > pi3003.txt" in various ways) OR, 
how to copy and paste from the command line window, or whatever that 
window is called? (Sorry for the OT question.)
Works for me (using the Cygwin version though) when I do
C:\cygwin\bin\bc -l > pi12.txt
But how or when do you enter the lines
scale = 3000
obase = 12
print 4 * a(1)
Otherwise, to copy from the command prompt window: open the system menu
(icon in the top left corner of the window) and choose Edit->Mark. Then
select what you want to copy and press Enter or choose Edit->Copy in the
system menu.
Thanks! You've just relieved years of frustration.
Dick 

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

Re: Compute pi to base 12 using Python?

[Bengt Richter]

On Sun, 17 Apr 2005 01:00:46 -0700, Dick Moores <[EMAIL PROTECTED]> wrote:

>M.E.Farmer wrote at 23:18 4/14/2005:
>> > >Using the GNU "bc" utility:
>> > >
>> > >   $ bc -l
>> > >   bc 1.06
>> > >   Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation,
>>Inc.
>> > >   This is free software with ABSOLUTELY NO WARRANTY.
>> > >   For details type `warranty'.
>> > >   scale = 3000# number of output places wanted
>> > >   obase = 12  # output base
>> > >   print 4 * a(1)  # pi = 4*arctan(1)
>
>Wow! this got me the 3003 (changed from 3000) digits of pi to base 12 in 
>60.8 secs. No, I didn't count them yet, nor am I sure they're correct. 
>But I'd bet on them..
>
>Could someone remind me how to get the output of bc -l into a text file 
>on Windows? (I've tried employing " > pi3003.txt" in various ways) OR, 
>how to copy and paste from the command line window, or whatever that 
>window is called? (Sorry for the OT question.)
To copy from the command window to the clipboard:

1. Scroll top of desired stuff to make it visible near top
2. Hold down Alt
3. Tap Space Bar
4. Release Alt
5. Tap e
6. Tap k
7. Use mouse or arrow keys to place cursor on top left corner of desired box
8. Hold down Shift
9. Use arrow keys or mouse-with-left-button-pressed to go to bottom right 
character of desired box
9a. If the bottom is out of sight, keep holding  shift down and pretend you can 
cursor down below bottom.
the attempt should make the screen scroll up and select more desired 
material. If you overshoot, don't panic,
just keep holding down shift and use arrows (the are slower) or 
mouse-with-left-button-still-down to move to
desired bottom right corner.
10. Release mouse button if using that
11. Release Shift
12. Press Enter
That should copy to the clipboard and make the selection box revert to normal 
display.

Pasting from clipboard is up to you. Pasting into the command window from 
clipboard
is 2-5 above, and Tap p

HTH

PS. Redirecting with > from a script whose interpreter was started by windows 
extension association
doesn't work on some version of windows. To be safe, invoke the interpreter 
explicitly, e.g.,
python myscript.py [whatever args here] > pi3003.txt

If myscript.py is not in the current directory, use a sufficient path to it. If 
your windows is having
that problem, the same will happen with a perl script or other script when you 
run it as just myscript.ext ...
and depend on windows to start the right interpreter.

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

Re: pre-PEP: Simple Thunks

[Kay Schluehr]

Ron_Adam wrote:

> I sort of wonder if this is one of those things that looks like it
> could be useful at first, but it turns out that using functions and
> class's in the proper way, is also the best way. (?)

I think Your block is more low level. It is like copying and pasting
code-fragments together but in reversed direction: if You copy and
paste a code fragment and wants to change the behaviour You probable
have to change the fragment the same way in every place of occurence.
This is a well known anti-pattern in software construction. If You
change Your thunk somehow e.g. from

def yield_thunk:
yield i

to

def yield_thunk:
yield j

You have to change all the environments that use the thunk e.g.
renaming variables. It is the opposite direction of creating
abstractions i.e. a method to deabstract functions: introduce less
modularity and more direct dependencies. This is the reason why those
macros are harmfull and should be abandoned from high level languages (
using them in C is reasonable because code expansion can be time
efficient and it is also a way to deal with parametric polymorphism but
Python won't benefit from either of this issues ).

Ciao,
Kay

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

Re: Compute pi to base 12 using Python?

[Roel Schroeven]

Dick Moores wrote:
M.E.Farmer wrote at 23:18 4/14/2005:
> >Using the GNU "bc" utility:
> >
> >   $ bc -l
> >   bc 1.06
> >   Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation,
Inc.
> >   This is free software with ABSOLUTELY NO WARRANTY.
> >   For details type `warranty'.
> >   scale = 3000# number of output places wanted
> >   obase = 12  # output base
> >   print 4 * a(1)  # pi = 4*arctan(1)

Wow! this got me the 3003 (changed from 3000) digits of pi to base 12 in 
60.8 secs. No, I didn't count them yet, nor am I sure they're correct. 
But I'd bet on them..

Could someone remind me how to get the output of bc -l into a text file 
on Windows? (I've tried employing " > pi3003.txt" in various ways) OR, 
how to copy and paste from the command line window, or whatever that 
window is called? (Sorry for the OT question.)
Works for me (using the Cygwin version though) when I do
C:\cygwin\bin\bc -l > pi12.txt
Otherwise, to copy from the command prompt window: open the system menu
(icon in the top left corner of the window) and choose Edit->Mark. Then
select what you want to copy and press Enter or choose Edit->Copy in the
system menu.
--
If I have been able to see further, it was only because I stood
on the shoulders of giants.  -- Isaac Newton
Roel Schroeven
--
http://mail.python.org/mailman/listinfo/python-list

Re: new to mac OS10

[Robert Kern]

Maurice LING wrote:
Robert Kern wrote:
3. Apple-installed Python's command line tools are symlinked from 
/usr/bin to /System/Library/Frameworks/Python.framework but the OSX 
installer for Python 2.4.1 places the commandline tools in 
/usr/local/bin and symlinked to /Library/Frameworks/Python.framework. 
So it seems to me that Python 2.4.1 (installed using OSX installer 
for Python 2.4.1) is not a precise replacement of Apple-installed 
Python...

Bingo. It's not intended to be one.
Hi Robert,
Once I've tried to install Python 2.4.1 through the installer Bob 
Ippolito built. I've already for Fink installed Python 2.3.5 in my 
system. So,

/usr/bin/python -> /sw/bin/python
Don't do that. Leave /usr alone! (/usr/local excepted)
Change your PATH environment variable if you want a different Python to 
start up when you type

  $ python
and the newly installed Python 2.4.1 created /usr/local/bin/python -> 
/Library/Frameworks/Python.framework/python

Does /usr/bin/python takes precedence over /usr/local/bin/python?
Somehow it rings an alarm in me...
That depends on your PATH environment variable, and that only affects 
the command line in a terminal shell.

Anything that looks for /usr/bin/python should find the link to the 
system Python. Anything that just asks for "whatever python comes first 
in your PATH" is customizable via the order of directories in your PATH.

--
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: pre-PEP: Suite-Based Keywords - syntax proposal

[Bengt Richter]

On 16 Apr 2005 23:43:03 -0700, "Kay Schluehr" <[EMAIL PROTECTED]> wrote:

>
>Robert Brewer wrote:
>> Bengt Richter wrote:
>> > The '::' unary suite operator should return an ordered dict
>> > subtype representing the bindings
>>
>> Why ordered?
>
>Because You can't otherwise guarantee to feed optional argument
>parameters in a correct way.
>
>Example:
>
>x = property(*seq) where:
>seq = (item[1] for item in ::
>def get_x():
>return self.__x
>def set_x(value):
>self.__x = value
>del_x = None
>doc   = "I'm the 'x' property." )
>
>This statement would not work if the result of '::' ( considered as an
>"ordered dict" ) would return simply a dict because the order of the
>input parameters matters.
>
Exactly. Except the above example is from the day-old-bread 
items-tuple-returning version of :: ;-)
And with an ordered dict subtype there is no need for the generator expression 
either,
since there is a values method for dicts (which in the subtype would preserve 
order). E.g.,

 x = property(*seq) where:
 seq = (::
 def get_x():
 return self.__x
 def set_x(value):
 self.__x = value
 del_x = None
 doc   = "I'm the 'x' property." ).values())

Or more directly:

 x = property(*(::
 def get_x():
 return self.__x
 def set_x(value):
 self.__x = value
 del_x = None
 doc   = "I'm the 'x' property." ).values())

Or eliminating parens by using dedent to end the :: suite:

 x = property(*::
 def get_x():
 return self.__x
 def set_x(value):
 self.__x = value
 del_x = None
 doc   = "I'm the 'x' property."
  .values())

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