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

[phil hunt]

On Fri, 7 Oct 2005 01:05:12 -0500, Terry Hancock <[EMAIL PROTECTED]> wrote:
>
>GvR's syntax has the advantage of making grammatical sense in English (i.e.
>reading it as written pretty much makes sense).

I know, let's re-write Python to make it more like COBOL! That's 
bound to be a winner!

-- 
Email: zen19725 at zen dot co dot uk


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

Generating images with text in them

[phil hunt]

I am trying to generate some images (gifs or pngs) with text in 
them. I can use the Python Imaging Library, but it only has access 
to the default, rather crappy, font. 

Ideally I'd like to use one of the nicer fonts that come with my X 
Windows installation. Using Tkinter I can draw these fonts on the 
screen; is there any way to get these fonts into a bitmapped image?
For example, can I draw some text on a canvas and then "grab" that 
canvas as a bitmap into PIL, and then save it as a file?

Alternately, is there a good source of PIL font files (.pil files)
somewhere?

If the writers of the Python Imaging Library are reading this, may I 
suggest that they add more fonts to it. Yes, that would increase 
the size, but these days disk space is cheap and programmer time
expensive.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Generating images with text in them

[phil hunt]

On Thu, 21 Jul 2005 11:23:46 +0100, Daren Russell <[EMAIL PROTECTED]> wrote:
>phil hunt wrote:
>> I am trying to generate some images (gifs or pngs) with text in 
>> them. I can use the Python Imaging Library, but it only has access 
>> to the default, rather crappy, font. 
>> 
>> Ideally I'd like to use one of the nicer fonts that come with my X 
>> Windows installation. Using Tkinter I can draw these fonts on the 
>> screen; is there any way to get these fonts into a bitmapped image?
>> For example, can I draw some text on a canvas and then "grab" that 
>> canvas as a bitmap into PIL, and then save it as a file?
>> 
>> Alternately, is there a good source of PIL font files (.pil files)
>> somewhere?
>> 
>> If the writers of the Python Imaging Library are reading this, may I 
>> suggest that they add more fonts to it. Yes, that would increase 
>> the size, but these days disk space is cheap and programmer time
>> expensive.
>> 
>
>I've just been playing around with this.  You can use truetype fonts with:
>
>font = ImageFont.truetype("/path/to/font.ttf", 12)

Thanks! it's working now!

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Generating images with text in them

[phil hunt]

On Thu, 21 Jul 2005 02:44:03 -0500, Terry Hancock <[EMAIL PROTECTED]> wrote:
>On Wednesday 20 July 2005 11:59 pm, phil hunt wrote:
>> I am trying to generate some images (gifs or pngs) with text in 
>> them. I can use the Python Imaging Library, but it only has access 
>> to the default, rather crappy, font.
>
>On the fly, or just during development?

Just during development.

>In any case, you should be aware of the Skencil vector graphic
>program which is written in Python (with some C extensions),
>and which is also, of course, a python vector-graphics library.

I may look that up, if I don't get joy with PIL or Tkinter.

>Unfortunately, getting it to work in a server environment might
>not be too pretty (requires GTK, etc, even if you don't actually
>use it).  I tried to make a stripped down version that didn't
>require the desktop stuff, but it hasn't worked out so well yet.

I'm runnnig a desktop environment. For example Tkinter works fine.

>> Alternately, is there a good source of PIL font files (.pil files)
>> somewhere?
>
>I believe there is a utility for converting other types of fonts, you
>might have to go through a couple of different conversions from
>the font files you have.

I'm aware there's a utility, and I wish to avoid the hassle of
"go[ing] through a couple of different conversions from the font
files you have"

>> If the writers of the Python Imaging Library are reading this, may I 
>> suggest that they add more fonts to it. Yes, that would increase 
>> the size, but these days disk space is cheap and programmer time
>> expensive.
>
>While bitmap font files are not copyrightable, there are license issues
>with most of the "nicer" fonts you are probably talking about.

Oh? I can understand them being copyrighted; but if they are not 
copywritable, what licnese issues are there? In any case, there 
presumably are not license issues with the fonts that come with a 
standard GNU/Linux distribution such as SuSE 9.1, which is what I am 
using.

> That
>complicates bundling them with the software. The PIL site does
>actually have some additional fonts for download, though, IIRC.

Do yuo have a URL?

-- 
Email: zen19725 at zen dot co dot uk


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

Re: functions without parentheses

[phil hunt]

On Fri, 29 Jul 2005 06:37:52 GMT, Bengt Richter <[EMAIL PROTECTED]> wrote:
>
>I suggested in a previous thread that one could support such a syntax by
>supporting an invisible binary operator between two expressions, 

That's a truely appalling idea.

>so that
>examine "string" translates to examine.__invisbinop__("string") if
>examine as an expression evaluates to an object that has a __invisbinop__ 
>method.
>
>Then you wouldn't define examine as a function, you would define it as an 
>instance
>of a class like
>class Examine(object):
>define __invisbinop__(self, other):
>#...whatever
>examine = Examine()
>and then
>examine "string"

Pass the sick bucket.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: How can I run a program?

[phil hunt]

On 30 Jul 2005 03:33:14 -0700, Lad <[EMAIL PROTECTED]> wrote:
>Hello,
>I am running Python on XP and have a problem with
>a  program  if its name consists '-' for example:
>my-program.py
>When I try to run a program with such name
>I get the error :
>
>Traceback (most recent call last):
>  File "", line 1, in ?
>NameError: name 'my' is not defined
>
>Python thinks that the name of program is my.py only
>but the name is my-program.py
>
>What is a solution?

Have you tried renaming it so it doesn't have a "-" in it?

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Wheel-reinvention with Python

[phil hunt]

On Sat, 30 Jul 2005 08:54:59 +0200, Torsten Bronger <[EMAIL PROTECTED]> wrote:
>Hallöchen!
>
>Calvin Spealman <[EMAIL PROTECTED]> writes:
>
>> The choice is GUI toolkits is largely seperate from
>> Python. Consider that they are just bindings to libraries that are
>> developed completely seperate of the language. GUI is should be
>> seperate from the language, and thus not bound to same
>> expectations and desires as elements of the language itself.
>
>I disagree.  A modern language must provide a convenient and
>well-embedded way to write GUI applications.  This is not a sign of
>decadence, but a very good promotional argument.  Delphi and first
>and foremost VB are extremely popular, and it's sad to see that
>Python could get a lot more of the cake if the efforts for IDEs and
>toolkits were somewhat streamlined.  Besides, all other already good
>aspects of Python wouldn't suffer at all.
>
>Tkinter fits into Python very well and it is very easily (if not
>trivially) accessible for users of our applications.  People
>complain about non-native look-and-feel on Windows, but sorry, I
>simply find it unacceptably ugly on all platforms.  Don't
>misunderstand me: I don't like neat GUI effects just for the sake of
>it but Tkinter makes an outdated impression on the end-user.
>
>I've been having a closer look at wxPython which is not Pythonic at
>all and bad documented.

Tkinter is hardly brilliantly documented, IMO.

> Probably I'll use it nevertheless.  PyGTK
>and PyQt may have their own advantages and disadvantages.
>
>However, in my opinion we don't need yet another binding so thin
>that C or C++ is shining through, but a modern replacement for
>Tkinter with its Pythonic way of thinking.

How about sometihing with the same API as Tkinter (so no need to 
relearn), but which looks prettier? Would that fix your gripes?

-- 
Email: zen19725 at zen dot co dot uk


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

Re: [path-PEP] Path inherits from basestring again

[phil hunt]

On Fri, 29 Jul 2005 14:38:23 +1200, Tony Meyer <[EMAIL PROTECTED]> wrote:
>> def functions_which_modifies_some_file_in_place(path):
>>  output = open(path+'.tmp', 'w')
>>  .
>> 
>> I dont want a seperator inserted between path and the new extension.
>
>Fair enough.  Forget using '+' for join, then (which I was never that keen
>on - TIOWTDI), but I'm still -1 on using '/' for join.

I agree. It's yuck.

What's wrong with simply having each path-element as an argument to 
a function, e.g.

join(foo, bar, baz)

-- 
Email: zen19725 at zen dot co dot uk


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

Re: [path-PEP] Path inherits from basestring again

[phil hunt]

On Fri, 29 Jul 2005 14:48:55 +1200, Tony Meyer <[EMAIL PROTECTED]> wrote:
>
>Would you really choose this:
>
>p = Path() / "build" / "a" / "very" / "very" / "long" / "path"
>
>Over this:
>
>p = Path(os.path.join("build", "a", "very", "very", "long", "path"))

Or have the constructor accept multiple arguments.

>?  A saving of six characters, and the second one is a lot clearer.  If
>there was a os.path.joinPath (or whatever name) function that returned a
>Path object rather than a string, then you'd get:
>
>p = joinPath("build", "a", "very", "very", "long", "path")

Indeed.

I have a little function I've written called normalizePath(). It 
expands users ("~" and "~someuser"), does os.path.join(), then gets 
the absolute path (os.path.abspath()) of the result. The code is
trivial:


def normalizePath(p, *pathParts):
   """ Normalize a file path, by expanding the user name and getting 
   the absolute path..
   @param p [string] = a path to a file or directory
   @param pathParts [list of string] = optional path parts
   @return [string] = the same path, normalized
   """
   p1 = os.path.abspath(os.path.expanduser(p))
   if len(pathParts)>0:
  allPathParts = [ p1 ]
  allPathParts.extend(pathParts)
  p1 = os.path.join(*allPathParts)
   p2 = os.path.abspath(p1)   
   return p2
normalisePath=normalizePath # alternate spelling 
join=normalizePath # it works like os.path.join, but better  


To be honest I don't see the point of having a Path class. That's 
the way Java does it, and I find path handling in Java to be a lot 
more of a hassle than in Python. (Actually, most things are more of 
a hassle in Java, but that's another story).

-- 
Email: zen19725 at zen dot co dot uk


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

Re: [path-PEP] Path inherits from basestring again

[phil hunt]

On Sat, 30 Jul 2005 19:01:49 +0200, Reinhold Birkenfeld <[EMAIL PROTECTED]> 
wrote:
>phil hunt wrote:
>
>> def normalizePath(p, *pathParts):
>>""" Normalize a file path, by expanding the user name and getting 
>>the absolute path..
>>@param p [string] = a path to a file or directory
>>@param pathParts [list of string] = optional path parts
>>@return [string] = the same path, normalized
>>"""
>>p1 = os.path.abspath(os.path.expanduser(p))
>>if len(pathParts)>0:
>>   allPathParts = [ p1 ]
>>   allPathParts.extend(pathParts)
>>   p1 = os.path.join(*allPathParts)
>>p2 = os.path.abspath(p1)   
>>return p2
>> normalisePath=normalizePath # alternate spelling 
>> join=normalizePath # it works like os.path.join, but better  
>> 
>> 
>> To be honest I don't see the point of having a Path class. That's 
>> the way Java does it, and I find path handling in Java to be a lot 
>> more of a hassle than in Python. (Actually, most things are more of 
>> a hassle in Java, but that's another story).
>
>You see, with the Path class the above function could be written as
>
>def normalizePath(p, *pathParts):
>""" Normalize a file path, by expanding the user name and getting
>the absolute path..
>@param p [Path] = a path to a file or directory
>@param pathParts [list of string/Path] = optional path parts
>@return [Path] = the same path, normalized
>"""
>tp = p.expanduser().abspath()
>return tp.joinwith(*pathParts).abspath()
>
>That's clearly an improvement, isn't it?

An improvement to what? To how the class is implemented, or to how 
it is used?

If you mean the former, yes is it, due to the os.path module not 
providing a function that does this. 

If you mean the latter, I disagree, because I would then have to 
call it with something like:

   pn = normalizePath(Path(p), q)

and then I would have the problem that (pn) isn't a string so 
calling a function to write some data into the file at that filename 
would no longer work, i.e. this:

   writeFile(pn, someData)

would become this:

   writeFile(pn.getString(), someData)

I don't see what having a Path type buys me. 

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Wheel-reinvention with Python

[phil hunt]

On Sat, 30 Jul 2005 16:51:13 +0200, Torsten Bronger <[EMAIL PROTECTED]> wrote:
>Hallöchen!
>
>[EMAIL PROTECTED] (phil hunt) writes:
>
>> [...]
>>
>> How about sometihing with the same API as Tkinter (so no need to
>> relearn), but which looks prettier? Would that fix your gripes?
>
>I haven't learned Tkinter.  

You mightn't have, but I suspect more Python programers who've 
written GUI apps have used Tkinter than any of the other APIs.

Not that I'm a particular fan of it, it's just I like 
standardisation, because then you get network effects. 

>So for me, it needn't be like Tkinter.  The three most important
>attributes for me are Pythonic, modern (both nice-looking and
>comprehensive), and non-niche.

What you say Pythonic, what do you mean? And how do you rate 
Tkinter, PyGtk, PyQt/PyKDE, wxWindows for "Pythonicness"? 

-- 
Email: zen19725 at zen dot co dot uk


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

Re: shelve: writing out updates?!

[phil hunt]

On 30 Jul 2005 17:48:39 -0700, Paul Rubin  wrote:
>Shelve uses dbm and pickle to make a persistent object store.  The
>"db" in "dbm" stands for "database" and while I didn't expect full
>ACID capability,

What is ACID?

> I'd have thought there'd be at least some minimum
>gesture towards durability of updates.  But say that s is a shelve
>object.  If I say
>
>   s[whatever] = value
>
>there is no way apparent from the shelve docs to get the update
>flushed out to the disk file until the shelve is actually closed.

Wierd. I'd expect something like an s.flush() function.


-- 
Email: zen19725 at zen dot co dot uk


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

Re: shelve: writing out updates?!

[phil hunt]

On Sat, 30 Jul 2005 17:57:17 -0700, Robert Kern <[EMAIL PROTECTED]> wrote:
>Paul Rubin wrote:
>> Shelve uses dbm and pickle to make a persistent object store.  The
>> "db" in "dbm" stands for "database" and while I didn't expect full
>> ACID capability, I'd have thought there'd be at least some minimum
>> gesture towards durability of updates.  But say that s is a shelve
>> object.  If I say
>> 
>>s[whatever] = value
>> 
>> there is no way apparent from the shelve docs to get the update
>> flushed out to the disk file until the shelve is actually closed.  If
>> I'm using the shelve to store stuff in a long-running server, it could
>> be months before the shelve closes.
>> 
>> Is shelve really missing this capability?  
>
>No. Call the .sync() method. Unfortunately, the shelve module is not 
>well-documented.

Obviously it's good when stuff is well documented. 

I wonder if the barrier to good documentation is set too high?
If i wanted to add some documentation here, I'd have to download the 
current source for the latest Python documentation, download, 
install and learn the code that processes the source documentation, 
write my changes then send the results into the CVS. (I'm assuming 
that's roughly correct -- I haven't actually done it).

The point is, that would be a major effort, too major to merely add 
a few lines detailing the .sync method.

But, what if the Python documentation was on a Wiki? Then it would 
be easy to update! Of course, we would have to guard against false 
or malicious updates, but Wikipedia manage that OK. The 
Documentation Wiki could then be used as a basis for the "official" 
documentation that comes with each new release.

Does this idea make some sense? Or are there hidden pitfalls?

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Wheel-reinvention with Python

[phil hunt]

On 31 Jul 2005 00:23:38 -0700, Paul Rubin <http://[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (phil hunt) writes:
>> What you say Pythonic, what do you mean? And how do you rate 
>> Tkinter, PyGtk, PyQt/PyKDE, wxWindows for "Pythonicness"? 
>
>Tkinter is not very Pythonic because it's sort of a Frankenstein
>hybrid of Python and Tcl, but at least it's there and it more or less
>works.  The others are non-Pythonic because they're not included in
>the standard distro and therefore the Pythonic "use the included
>batteries" tenet says to use Tkinter despite its flaws.

OK, hows this for an idea:

1. create a new API, loosely based on the Tkinter API, but more 
Pythonic

2. implement Tk using this API (probably won't be difficult because 
we can use Tkinter as a base)

3. Implement bindings to Gtk and Qt/KDE using this API.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Wheel-reinvention with Python

[phil hunt]

On Sun, 31 Jul 2005 08:22:23 +0200, Torsten Bronger <[EMAIL PROTECTED]> wrote:
>>
>> What you say Pythonic, what do you mean? And how do you rate 
>> Tkinter, PyGtk, PyQt/PyKDE, wxWindows for "Pythonicness"? 
>
>I don't like to set arguments to -1 or NULL, but to None.  

Fair enough

>I'd like
>to have extensive support for keyword arguments. 

Tkinter has that


-- 
Email: zen19725 at zen dot co dot uk


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

Re: Wheel-reinvention with Python

[phil hunt]

On Sun, 31 Jul 2005 02:23:39 -0700, Robert Kern <[EMAIL PROTECTED]> wrote:
>phil hunt wrote:
>
>> OK, hows this for an idea:
>> 
>> 1. create a new API, loosely based on the Tkinter API, but more 
>> Pythonic
>> 
>> 2. implement Tk using this API (probably won't be difficult because 
>> we can use Tkinter as a base)
>> 
>> 3. Implement bindings to Gtk and Qt/KDE using this API.
>
>Like PyGUI, more or less?
>
>http://www.cosc.canterbury.ac.nz/~greg/python_gui/

Not really, PyGUI attempts to be a thing in itself; what I had in 
mind was more of a slight reworking of Tkinter to make it more 
Pythonic (and at the same time give it better documentation which 
odesn't depend on refering to the Tcl/Tk documentation).

-- 
Email: zen19725 at zen dot co dot uk


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

Re: [path-PEP] Path inherits from basestring again

[phil hunt]

On Sun, 31 Jul 2005 09:48:45 +0200, Reinhold Birkenfeld <[EMAIL PROTECTED]> 
wrote:
>> 
>> An improvement to what? To how the class is implemented, or to how 
>> it is used?
>
>No, the second function is cleaner and more readable than the first,
>IMHO.

True, but the first function, at all of seven lines, is hardly 
complicated. I mean, if anyone couldn't understand it, they'd never 
make a programmer.

>> If you mean the former, yes is it, due to the os.path module not 
>> providing a function that does this. 
>> 
>> If you mean the latter, I disagree, because I would then have to 
>> call it with something like:
>> 
>>pn = normalizePath(Path(p), q)
>
>That's easily helped by s/tp = p/tp = Path(p)/.

I have no idea what that comment means.

>> and then I would have the problem that (pn) isn't a string so 
>> calling a function to write some data into the file at that filename 
>> would no longer work, i.e. this:
>> 
>>writeFile(pn, someData)
>> 
>> would become this:
>> 
>>writeFile(pn.getString(), someData)
>
>Why? A Path is a string.

Aha, having read about path on the web, I know that now.

I also withdraw my objections; it looks like it could well have been 
useful on some of the projects I've worked on.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Wheel-reinvention with Python

[phil hunt]

On Sun, 31 Jul 2005 08:02:43 -0400, Ed Leafe <[EMAIL PROTECTED]> wrote:
>On Sunday 31 July 2005 01:02, phil hunt wrote:
>
>> You mightn't have, but I suspect more Python programers who've
>> written GUI apps have used Tkinter than any of the other APIs.
>>
>> Not that I'm a particular fan of it, it's just I like
>> standardisation, because then you get network effects.
>
> At PyCon DC 2004, Guido was asked about wxPython: "wxPython is the best and 
>most mature cross-platform GUI toolkit, given a number of constraints. The 
>only reason wxPython isn't the standard Python GUI toolkit is that Tkinter 
>was there first."

I was under the impression -- from reading this ng -- that wx was 
buggy on some platforms and less portable than Tkinter. Not true?

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Wheel-reinvention with Python

[phil hunt]

On 31 Jul 2005 10:07:52 -0700, Kay Schluehr <[EMAIL PROTECTED]> wrote:
>
>Ed Leafe wrote:
>> On Sunday 31 July 2005 01:02, phil hunt wrote:
>>
>> > You mightn't have, but I suspect more Python programers who've
>> > written GUI apps have used Tkinter than any of the other APIs.
>> >
>> > Not that I'm a particular fan of it, it's just I like
>> > standardisation, because then you get network effects.
>>
>>  At PyCon DC 2004, Guido was asked about wxPython: "wxPython is the best and
>> most mature cross-platform GUI toolkit, given a number of constraints. The
>> only reason wxPython isn't the standard Python GUI toolkit is that Tkinter
>> was there first."
>
>Maybe. But Guidos intention with Python was to create a secondary
>language originally - an extension language of C - ( unlike Java that
>was concepted as a radically platform independent language and a
>successor of C++ ).

These days you can almost think of C++ as a secondary language to 
Python: code the app in Python and then optimise by recoding the 
bits that need speed in C++.

>Some other people already abandoned Python not for the worst reasons:
>
>http://www.kevin-walzer.com/pivot/entry.php?id=69
>
>My objection with wrappers around wrappers around wrappers is that I
>have no hope ever watching the ground. If some error occurs, which
>layer has to be addressed?

Good point.


-- 
Email: zen19725 at zen dot co dot uk


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

Re: Wheel-reinvention with Python

[phil hunt]

On Sun, 31 Jul 2005 14:52:58 -0400, Mike Meyer <[EMAIL PROTECTED]> wrote:
>Torsten Bronger <[EMAIL PROTECTED]> writes:
>> Hallöchen!
>> Mike Meyer <[EMAIL PROTECTED]> writes:
>>> Torsten Bronger <[EMAIL PROTECTED]> writes:
 Calvin Spealman <[EMAIL PROTECTED]> writes:
> The choice is GUI toolkits is largely seperate from
> Python. Consider that they are just bindings to libraries that
> are developed completely seperate of the language. GUI is should
> be seperate from the language, and thus not bound to same
> expectations and desires as elements of the language itself.
 I disagree.  A modern language must provide a convenient and
 well-embedded way to write GUI applications.
>>> The tools for writing GUI applications belong in a library, not
>>> the langauge.
>> None of us has talked about changing syntax.  However, the standard
>> library is part of the language unless you're really very petty.
>
>Or you use different Python implementations. There are four different
>Python implementations in the world. Not everything in the CPYthon
>standard library runs in all of them. 

I would guess that 90%+ of Python developers develop to CPython.

>To put this differently, it's required if you want to succeed as a
>language for the specific purpose of creating GUI applications. I'd
>agree to that. But there are *lots* of other application areas around,
>so limiting your definition of "success" to that one field is very
>short-sighted.

GUI applications are a large area; and langauge that doesn't do 
them tolerably well is limiting its success.


-- 
Email: zen19725 at zen dot co dot uk


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

Re: Wheel-reinvention with Python

[phil hunt]

On Sun, 31 Jul 2005 12:09:48 -0700, Cliff Wells <[EMAIL PROTECTED]> wrote:
>On Sun, 2005-07-31 at 10:07 -0700, Kay Schluehr wrote:
>
>> Some other people already abandoned Python not for the worst reasons:
>> 
>> http://www.kevin-walzer.com/pivot/entry.php?id=69
>
>Being a developer requires not only a bit of brains, but quite a bit of
>tenacity as well.  Apparently Kevin lacks the second.
>
>> My objection with wrappers around wrappers around wrappers is that I
>> have no hope ever watching the ground. If some error occurs, which
>> layer has to be addressed? Which developing group is reponsible? My own
>> or that of team A, team B, team C ... ? The baroque concept is
>> repulsive to me and only acceptable in case of legacy code that gets
>> wrapped around old one and is dedicated to substitute it continously.
>
>Of course, Tkinter is still a wrapper around a third party library (Tk)
>borrowed from a different language (Tcl) and written again in a third
>language (C), much the same as wxPython.  

In practise any Python GUI is going to contain code from otyher 
languages since if it was coded all the way down in python it would 
be too slow.

-- 
Email: zen19725 at zen dot co dot uk


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

Is this Pythonic?

[phil hunt]

Suppose I'm writing an abstract superclass which will have some 
concrete subclasses. I want to signal in my code that the subclasses 
will implement certan methods. Is this a Pythonic way of doing what 
I have in mind:

class Foo: # abstract superclass
   def bar(self):
  raise Exception, "Implemented by subclass"
   def baz(self):
  raise Exception, "Implemented by subclass"

class Concrete(Foo):
   def bar(self):
  #...actual implemtation...
   def baz(self):
  #...actual implemtation...




-- 
Email: zen19725 at zen dot co dot uk


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

Re: Is this Pythonic?

[phil hunt]

On Mon, 01 Aug 2005 12:52:02 -0400, Peter Hansen <[EMAIL PROTECTED]> wrote:
>phil hunt wrote:
>> Suppose I'm writing an abstract superclass which will have some 
>> concrete subclasses. I want to signal in my code that the subclasses 
>> will implement certan methods. Is this a Pythonic way of doing what 
>> I have in mind:
>> 
>> class Foo: # abstract superclass
>>def bar(self):
>>   raise Exception, "Implemented by subclass"
>>def baz(self):
>>   raise Exception, "Implemented by subclass"
>
>Change those to "raise NotImplementedError('blah')" instead and you'll 
>be taking the more idiomatic approach.

Ta

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Is this Pythonic?

[phil hunt]

On Mon, 01 Aug 2005 22:01:06 +0200, Caleb Hattingh <[EMAIL PROTECTED]> wrote:
>Peter
>
>To my mind, this kind of setup (interface class, or abstact class) is more  
>usually used in static languages to benefit polymorphism - but python is  
>dynamically typed, so in which situations would this setup be useful in a  
>python program?  You see, I expected your post to say that it wouldn't  
>even be necessary, but you didn't :)

I realise it's not necessary. I just thought it would be nice to 
document the interfaces my concrete classes will be using.

>I have spent a little effort training myself not to bother setting up  
>class hierarchies like this in python, due to the fact that I use Delphi a  
>lot at work (I do pretty much the code below to let myself know when an  
>inherited/abstract class method is being called in error).

I started doing OO stuff with Smalltalk, where it isn't necessary, 
then moved to C++, where it is, and liked it.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Is this Pythonic?

[phil hunt]

On Mon, 01 Aug 2005 14:07:46 -0700, Erik Max Francis <[EMAIL PROTECTED]> wrote:
>
>Yes, but raise NotImplementedError instead of Exception.  Another trick 
>you can use is to prevent people from instantiating the abstract class:
>
>   class Foo:
>   def __init__(self):
>   if self.__class__ is Foo:
>   raise NotImplementedError
>   ...
>
>   def bar(self):
>   raise NotImplementedError

That's a clever trick, but it's obvious from the code that the class 
is intended to be abstract, so if people are stupid enough to shoot 
themselves in the foot by creating an instance, I don't feel like 
adding extra code to protect themselves from their stupidity.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: ANN: Kamaelia 0.2.0 released!

[phil hunt]

Kamaelia seems it might be an interesting project. However, I don't 
think the project is well served by this announcement -- which I 
find vague and hard to understand. Which is a shame, because it 
means that other people probably don't understand it very well 
either, which means less people will use it.

In a spirit of constructive criticism I'd like to give some detailed 
comments about this...


On Mon, 01 Aug 2005 19:50:11 +0200, Michael Sparks <[EMAIL PROTECTED]> wrote:
>
>Kamaelia is a collection of Axon components designed for network
>protocol experimentation in a single threaded, select based environment.
>Axon components are python generators are augmented by inbox and outbox
>queues (lists) for communication in a communicating sequential processes
>(CSP) like fashion.

I really have very little idea what this means.

>The architecture is specifically designed to try and simplify the
>process of designing and experimenting with new network protocols in
>real environments. 

The information I can guess out of this is: "Kamaelia is a library 
for creating network protocols that sit on top of tcp and/or udp". 
Given that it's a BBC project, I imagine we're talking about 
protocols for transferring large amount of data, e.g. sound or 
motion pictures.

>More background on the motivations behind Kamaelia
>can be found here: http://kamaelia.sourceforge.net/Challenges/

There's something interesting here:

  In Building Public Value, the BBC has committed to the delivery of 
  BBC content to the British Public over this multitude of systems, 
  in a way that is enjoyable, accessible and **repurposable** by the 
  British Public in the way they choose.

(my emphasis)

This is a laudable aim, but if the BBC want to do this, the first 
step they could make is to open up their content under a Creative 
Commons licence. They could start with their news, current affairs 
and documentaries. They could also do this with music downloads: for 
example a few weeks ago they made available for free download 
all of Beethoven's symphonies, performed by the BBC Orchestra. But the
download only staryed up for a week, and they didn't put the files 
under a CC license, so they could be redistributed. Why not? It 
would have cost them no more to do so than what they did, and 
would've provided better value for downloaders and music lovers.

Of course, the music industry would've complained, but they did
anyway. Frankly, fuck them. Their business model is obsolete, and
they should either get a new one or crawl into a corner and die.

BTW, the html is broken in that it's very poorly written, doedsn't
use CSS, and some of the stuff that is intended to display in a
monospaced font doesn't.  For example, this HTML code from 
:


  def main(self):
  yield 1while
  (self.i):

could be better written as:

  
 def main(self):
yield 1
while (self.i):
  

Much, much simpler, and actually works.

>General feedback is welcome either directly, mailing lists or via the
>project weblog which is here:
>* http://kamaelia.sourceforge.net/cgi-bin/blog/blog.cgi

I guess the main question that needs to be answered is "Why would I, 
as a programmer, use Kamaelia?"


-- 
Email: zen19725 at zen dot co dot uk


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

Re: Wheel-reinvention with Python

[phil hunt]

On Tue, 02 Aug 2005 00:42:53 -0400, Mike Meyer <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (phil hunt) writes:
>> In practise any Python GUI is going to contain code from otyher 
>> languages since if it was coded all the way down in python it would 
>> be too slow.
>
>Not necessarily. My window manger is Python all the way down

Your X server is written in Python? :-)

> - it uses
>the Python Xlib implementation - and is plenty fast.
>
>Of course, it doesn't do a lot of graphics work, even for a window
>manager.

That's what I mean: painting the individual pixels on the screen.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Is this Pythonic?

[phil hunt]

On Tue, 02 Aug 2005 08:31:27 GMT, Michael Hudson <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (phil hunt) writes:
>
>> Suppose I'm writing an abstract superclass which will have some 
>> concrete subclasses. I want to signal in my code that the subclasses 
>> will implement certan methods. Is this a Pythonic way of doing what 
>> I have in mind:
>>
>> class Foo: # abstract superclass
>>def bar(self):
>>   raise Exception, "Implemented by subclass"
>>def baz(self):
>>   raise Exception, "Implemented by subclass"
>>
>> class Concrete(Foo):
>>def bar(self):
>>   #...actual implemtation...
>>def baz(self):
>>   #...actual implemtation...
>
>Well, I guess you know this, but if Foo contains no implementation at
>all, why inherit from it?

(in fact the class I'm using/creating does contain some 
implementation)

>It would (possibly) be more Pythonic to
>define an interface instead,

Does Python have the concept of an interface? When was that added?


-- 
Email: zen19725 at zen dot co dot uk


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

Re: Art of Unit Testing

[phil hunt]

On Tue, 02 Aug 2005 21:11:52 +0200, Christoph Zwerschke <[EMAIL PROTECTED]> 
wrote:
>Thanks for the link, Grig. I wasn't aware of the py lib so far. The 
>possibility to create fixtures at the three different scopes is exactly 
>what I was looking for.
>
>Anyway, I think it would be nice to have that feature in the standard 
>lib unittest as well. It should not be too hard to add setUpOnce and 
>tearDownOnce methods in addition to setUp and tearDown. Actually, I am 
>wondering that there doesn't seem to be any development progress since 
>unittest was included in the standard lib of Python 2.1 in August 2001. 
>I had expected that such an important module would be continually 
>improved and maintained. How come? So few people using unit tests? Or do 
>most people write their own testing code or use py.test?

I can answer this question, at least for myself.

I use regression testing a lot, and have done so since before 
Python's unittest was written.

Originally I just used my own code, which didn't use classes just 
functions that called other functions. later on I decided to have a 
look at unittest. I found two problems with it. 

Firstly it didn't 
stop when it reached an error, it continued doing the rewsr of the 
tests. This wasn't what i wanted: most of the time when a test 
fails, I want to look at what's happening. I don't want unnecessary 
information about other tests, I want to concentrate on that one 
thing.

Also, the log of information sent to stdout about each test was less 
informative than I wanted (and which my old system provided).

So I had a look at unittest to see if I could modify it to fix these 
problems. However, I found the code to be rather complex and hard to 
understand so I decided it would be quicker to write my own testing 
framework. Which I did.


-- 
Email: zen19725 at zen dot co dot uk


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

Re: Art of Unit Testing

[phil hunt]

On Tue, 02 Aug 2005 19:02:09 +0200, Björn Lindström <[EMAIL PROTECTED]> wrote:
>Christoph Zwerschke <[EMAIL PROTECTED]> writes:
>
>> Would it make sense to add "globaleSetup" and "globalTearDown" methods
>> to the TestCase class? I think at least it would not harm
>> anybody. Where should such proposals be submitted?
>
>In general that's not such a good idea. If you build your tests like
>that, it gets hard to know which test really went wrong,

No it isn't, provided you've coded your setup code and tests well.

And if you haven't coded your setup code and tests well, you're 
fucked anyway.

Programming languages and libraries should assume the programmers is 
competent and knows what he's doing. People who disagree should 
stick to Java or Pascal or something.

> and you might
>get the situation where the whole set of tests works, but depend on each
>other in some way. (This can also happen for more obscure reasons, and
>is worth looking out for whichever way you do it.)

Sure. And if the programmer is competent, he'll bear that in mind 
when he's writing the tests.

>So, rebuilding the environment for the each before every single test is
>generally worth the overhead.

Note "generally". Sometimes it isn't.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Art of Unit Testing

[phil hunt]

On Tue, 02 Aug 2005 21:26:28 +0200, Christoph Zwerschke <[EMAIL PROTECTED]> 
wrote:
>Björn Lindström wrote:
>>>Would it make sense to add "globaleSetup" and "globalTearDown" methods
>>>to the TestCase class?
>> In general that's not such a good idea.
>
>I completely agree and I think it makes a lot of sense that unittest 
>calls setUp and tearDown for every single test. However, the fact that 
>this is *generally* the best way doesn't exclude the fact that there are 
>*exceptions* when it makes sense to setUp and tearDown not for every 
>test, e.g. when it is absolutely sure that the fixture cannot be 
>destroyed by the individual tests or when creating the fixture takes too 
>much time. I already gave the example of creating database connections 
>or even creating/importing whole databases. My question was, how do I 
>handle these cases with the standard lib unittest?
>
>According to the "extreme programming" paradigm, testing should be done 
>several times a day. So a requirement for extreme programm is that tests 
>are fast enough. If the testing needs too much time, people are 
>discouraged to test often.

Indeed. Running the tests should ideally take less than a few 
seconds. Any longer, and people won't use them so often.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Art of Unit Testing

[phil hunt]

On Tue, 02 Aug 2005 23:13:08 +0200, rafi <[EMAIL PROTECTED]> wrote:
>
>> According to the "extreme programming" paradigm, testing should be done 
>> several times a day. So a requirement for extreme programm is that tests 
>> are fast enough. If the testing needs too much time, people are 
>> discouraged to test often.
>
>Well as I said above, a unit test is dedicated to a single function or 
>method. So wehn you update a function / method, you should test the 
>whole class or module, but maybe not the whole application

Often this is true. However sometimes the application is complex 
with all sorts of dependencies between different parts of it (I 
know, these should be kept to a minimum), and changes in one thing 
can break stuff in another module. When that happens, you want to 
know about it sooner rather than later.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: ANN: Kamaelia 0.2.0 released!

[phil hunt]

On Tue, 02 Aug 2005 11:05:16 +0100, Michael Sparks <[EMAIL PROTECTED]> wrote:
>Phil Hunt wrote:
>
>> Kamaelia seems it might be an interesting project. However, I don't
>> think the project is well served by this announcement -- which I 
>> find vague and hard to understand. Which is a shame, because it
>> means that other people probably don't understand it very well
>> either, which means less people will use it.
>
>It is a shame, and thanks for mentioning this. Let me have another
>go :-) (ripping to shreds welcome :)
>
>OK, here's a better go. (It's always difficult to think where to pitch
>this sort of thing)
>---START---
>The project aims to make it simple to build networked multimedia
>systems (eg audio, video, interactive systems),

There's plenty of software that facilitates networking, for example 
Python already has software for tcp and http clients/servers, and 
for xmlrpc remote procedure calls.

So what does Kamaelia do that's extra? I imagine it's to to with 
streaming large amounts of data. For example, a streaming video or 
audio player. Or VoIP, perhaps.

> which are naturally
>componentised and naturally concurrent allowing quick and fast reuse in
>the same way as Unix pipelines do. 

OK, so what do the components in the pipelines do? What sort of data 
do they hold? Unix pipelines act on ascii files; I assume you are 
do this on audio and visual data. What langauage will the ele,ments 
in thne pipelines be written it? I assume some will be in C/C++ for 
speed.

>It is designed as a practical toolkit, such that you can build systems
>such as:

When you say "you" who do you mean? Is the audience programmers or 
less technical people? A project that allows non-technical people 
to build complex network applications is an ambitious one, but not 
impossible (I'd find it very impressive and very exciting, 
particularly if it runs on devices such as mobile phones).

>   * Ogg Vorbis streaming server/client systems (via vorbissimple)
>   * Simple network aware games (via pygame)
>   * Quickly build TCP based network servers and clients

What sort of servers and clients? Serving what? Could I use it, for 
example, to build a

>   * Quickly build Multicast based network servers and clients

Serving what? Could I use it, for example, to build an n-player 
encrypted (I mean proper encryption here, the sort GCHQ or the NSA 
can't break) VoIP server to allow people to do conference calls over 
the Internet?

>It runs on Linux, Window, Mac OS X with a subset running on Series 60
>phones.
>
>The basic underlying metaphor of a component us like an office worker
>with inboxes and outboxes, with deliveries occuring between desks,
>offices, and depts. The component can thus do work anyway it likes but
>only communicates with these inboxes and outboxes. Like office workers,
>components run in parallel, and to achieve this are generally
>implemented using python generators, but can also used threads.

That metaphor brings up an image (at least to me) that the sorts of
data that can be communicated are things like documents,
spreadsheets, business graphs, memos. Also the metaphor doesn't 
indicate any sense of real-time-ness; stuff on an in tray isn't 
immediately processed and moved to the out tray.I'm pretty certain 
that's not what you have in mind. 

May I suggest a different metaphor? Consider a hi-fi system where 
you plug cables in to control the dataflow. For example, an 
unamplified audio signal goes into an amp, the amp has various dials 
and buttons on it, and an amplified signal comes out. Note that the 
signal processing is done in real time. 

Is that the sort of thing you are working on?

>The rationale behind the project is to provide a toolkit enabling the
>development of new protocols, including streaming, for large scale
>media delivery.

OK, I get the straming part of it. But what asbout non-streaming 
stuff? What other protocols are necessary?

> The license essentially allows use in proprietary
>systems without change, but all changes to the system itself must be
>shared.

Fair enough.

>---END---
>
>Is that clearer ? 
>
>A short summary of all that could be:
>
>"""Kamaelia is a networking/communications infrastructure for innovative
>multimedia systems. Kamaelia uses a component architecture designed to
>simplify creation and testing of new protocols and large scale media
>delivery systems."""
>
>Hopefully that's clearer than:
>
>>>Kamaelia is a collection of Axon components designed for network
>>>protocol experimentation in a single threaded, select based
>>>environment. Axon components are python generators are augmented by
>>>inbox and outbox queues (lists

Re: Art of Unit Testing

[phil hunt]

On Wed, 03 Aug 2005 09:35:08 +0200, Christoph Zwerschke <[EMAIL PROTECTED]> 
wrote:
>
>> Some (many?) people don't like the unittest module, because it is not very
>> pythonic - nothing to wonder as it has its root in the Java world. That's
>> probably one of the reasons why there are other (more pythonic) unittesting
>> frameworks for Python out there.
>
>So I think it would have been better that "unittest" had been named 
>"PUnit" to make clear that it is a JUnit port and to allow a more 
>pythonic testing framework to be added to the Python's standard lib.

Not a bad idea.


-- 
Email: zen19725 at zen dot co dot uk


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

Re: ANN: Kamaelia 0.2.0 released!

[phil hunt]

On Tue, 2 Aug 2005 12:53:29 +0100, Tim Golden <[EMAIL PROTECTED]> wrote:
>[Michael Sparks]
>| Phil Hunt wrote:
>| 
>| > Kamaelia seems it might be an interesting project. However, I don't
>| > think the project is well served by this announcement -- which I 
>| > find vague and hard to understand. Which is a shame, because it
>| > means that other people probably don't understand it very well
>| > either, which means less people will use it.
>| 
>| It is a shame, and thanks for mentioning this. Let me have another
>| go :-) (ripping to shreds welcome :)
>| 
>| OK, here's a better go. (It's always difficult to think where to pitch
>| this sort of thing)
>
>[... snip ...]
>
>I just wanted to say that I find the ideas behind Kamaelia
>interesting, and I only wish I had an application for it!
>Because I'm not especially into media-streaming, I'm more
>interested in it from the point of view of the generator-based
>architecture.
>
>What prompted me to write now was in appreciation of Michael's
>taking the effort to recast his words into a form which might
>well be understood better by others (including me) when he
>might well have simply huffed a bit and told the other poster 
>to read the words on the site and stop complaining about the HTML!

I'd second that!

I'm not trying to be critical, honestly, I'm trying to understand
something that looks like it could be very cool indeed.

(And on a more general level to improve the average quality of 
documentation for open source projects. Something which is bvery 
often deficient.)

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Art of Unit Testing

[phil hunt]

On Tue, 02 Aug 2005 18:44:01 +0200, Christoph Zwerschke <[EMAIL PROTECTED]> 
wrote:
>In August 2001, there was a thread about the "Art of Unit Testing":
>http://groups.google.com/group/comp.lang.python/browse_frm/thread/aa2bd17e7f995d05/71a29faf0a0485d5
>
>Paul Moore asked the legitimate question why there is no hook for a 
>"global" fixture code that is run only once for the whole TestCase, as 
>opposed to the normal "setUp" and "tearDown" code that is run for every 
>single test in the TestCase. A "global fixture" would be preferable 
>whenever creating the fixture is time consuming, e.g. you have to create 
>a database connection or even a whole database.
>
>What would be the preferred solution for such global fixtures? Simply 
>create the database, run the TestCase, and drop the database?
>
>Would it make sense to add "globaleSetup" and "globalTearDown" methods 
>to the TestCase class? I think at least it would not harm anybody. Where 
>should such proposals be submitted?

I think this cowuld be very useful. As to the name, do other xUnit 
testing frameworks have a common name? If not, may I suggest 
setupAll() and tearDownAll(). 


-- 
Email: zen19725 at zen dot co dot uk


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

Re: Art of Unit Testing

[phil hunt]

On Wed, 03 Aug 2005 10:19:05 +0200, Christoph Zwerschke <[EMAIL PROTECTED]> 
wrote:
>rafi wrote:
>> 'should' may be too strong, 'may' may be better. In the meantime I found:
>> http://python-mock.sourceforge.net/
>
>Thanks for the link. Björn also pointed to http://pmock.sourceforge.net
>
>Using mock objects sounds like a good idea.
>
>A problem with mock objects may be that they make writing tests for the 
>occasional programmer yet another bit more difficult, and that you 
>always have to ensure your mock objects really mock the real objects 
>perfectly, so you have to write another test for that. The behavior and 
>the API of the real objects may change every now and then.
>
>Let me summarize some good answers in this thread:
>
>- unittest is deliberately intended to be a JUnit implementation
>- unittest is for *unit* testing (only) ;-)

I use regression testing (using my "lintest" module, which is 
functionally similar to unittest) on the whole application. I really 
see no reason why the concept should be limited to testing 
individual modules (or roughly similar-sized pieces).

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Art of Unit Testing

[phil hunt]

On Tue, 02 Aug 2005 17:18:51 -0400, Peter Hansen <[EMAIL PROTECTED]> wrote:
>
>If you're going to quote XP rules of thumb, the tests should be 
>independent and very fast, and if you have a setup code that is taking a 
>long time, it's likely a "code smell" of some kind, and you should be 
>fixing the design which prevents you writing these tests with minimal 
>and quick setup.  Are these really like "acceptance" tests?  If they 
>were unit tests, they should take only a few minutes to run, total,

Eek! Seconds, more like.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Art of Unit Testing

[phil hunt]

On Wed, 03 Aug 2005 09:51:49 -0400, Peter Hansen <[EMAIL PROTECTED]> wrote:
>phil hunt wrote:
>> On Tue, 02 Aug 2005 21:26:28 +0200, Christoph Zwerschke <[EMAIL PROTECTED]> 
>> wrote:
>>>According to the "extreme programming" paradigm, testing should be done 
>>>several times a day. So a requirement for extreme programm is that tests 
>>>are fast enough. If the testing needs too much time, people are 
>>>discouraged to test often.
>> 
>> Indeed. Running the tests should ideally take less than a few 
>> seconds. Any longer, and people won't use them so often.
>
>That's probably too general a statement to be very useful, and I don't 
>think it's probably helpful to a newcomer who is seeking guidance.

I did say "ideally"; if the test have to take longer, so be it.

>If one makes the XP-style distinction between "unit" and "acceptance" 
>tests, then the acceptance test *suite* should take no more than some 
>number of minutes.  I believe ten minutes absolute max is a commonly 
>offered rule of thumb, but I've found even eight minutes a little too 
>long.  Five seems to be just fine, and less if of course wonderful.

I think we might be talking at cross purposes here. To me 
"acceptance test suite" means a test suite that has to be passed 
each time before a new version of the software is released to the 
users. I don't see that 10 minutes is a sensible limit here, unless 
you are releasing more often that once a day. (I once had an 
acceptance test suite that ran for 12 hours; I used to run it 
nightly).

>If you're doing 
>test-driven development (TDD), you will want to be able to run unit 
>tests (though maybe not all of them) sometimes a couple of times per 
>minute! 

That's what I often do.

>Still, in a large project (and especially one written in Python, with 
>the overhead of interpreter startup and the cost of executing bytecode) 
>the suite can get fairly long if you have many hundreds of tests.

I'm currently running one with 227 assertions in 38 test functions.
It runs in <1 second on an AMD 3000+.


-- 
Email: zen19725 at zen dot co dot uk


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

Re: ANN: Kamaelia 0.2.0 released!

[phil hunt]

On 03 Aug 2005 17:30:31 +0400, Sergei Organov <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (phil hunt) writes:
>[...]
>> Unix pipelines act on ascii files;
>
>No, they don't.

Nitpicker.

I would have thought it was perfectly obvious, in context, what I 
meant.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: ANN: Kamaelia 0.2.0 released!

[phil hunt]

On Wed, 03 Aug 2005 16:57:34 +0100, Michael Sparks <[EMAIL PROTECTED]> wrote:
>I've reordered the q's slightly to avoid repetition... Also by answering
>this question first, it may put the rest of the answer into context
>better.
>
>phil hunt wrote:
>
>> At what stage of completion is it? 
>
>This is something we deliberately try to reflect in the version number.
>Yes, you can build network servers and new protocols relatively simply
>at the moment. Yes, you can integrate with pygame in a limited useful
>fashion at present. Yes we have audio playback.
>
>However we don't have yet... (some examples)
>   * Decent GUI integration yet. 
>   * /Full/ pygame integration. 
>   * Nice integration with pymedia
>   * Direct support for Dirac.
>Which aside from other things means you can't build (say) a video
>& SMIL playback system trivially, yet.

Isn't SMIL something that's goinhg to go into web browsers? In which 
case, you'd presumably not want to build one yourself, I imagine?

>> There's plenty of software that facilitates networking, for example
>> Python already has software for tcp and http clients/servers, and
>> for xmlrpc remote procedure calls.
>
>There is indeed.
>
>> So what does Kamaelia do that's extra? I imagine it's to to with
>> streaming large amounts of data. For example, a streaming video or
>> audio player. Or VoIP, perhaps.
>
>It's designed to make bolting things together to make these sorts of
>system simpler and easier. 

What you say "bolting things together" do you mean writing Python 
code? Or will there be some other way?

What I have in mind is something like a project I worked on some 
time ago, where a program could be written by drawing boxes on a GUI 
application, and drawing lines (representing data flow) to connect 
the boxes. So one half of a VoIP application might look like:

  +--+ ++ +---+
  | listen   | | convert to | | volume|
  | on udp   |>| audio  |>| control + |
  | port 600 | | stream | | output|
  +--+ ++ +---+

With something like this novel multimedia apps could be prototyped 
quickly (though making them into useful apps would take extra work 
-- in the case of a VoIP application you'd want a phonebook, for 
example).

>At the same time it's designed to encourage
>writing code in a way that makes it simpler. 

Examples would be useful here. Both of what it can do now, and what 
it will be able to do eventually.

>The natural side effect of
>this is the  system might make it easier to take advantage of multiple
>CPU systems as they come online, since it makes a system naturally
>concurrent. As the original announcement said "Kamaelia is designed as
>a testbed". And by testbed I mean testbed as it testing out new ideas,
>see if they work and see if they pan out. (Not as in a testing suite)

So what it will eventually do is not cast in stone?

>Probably the best way of describing the difference is this... After my
>talk about Kamaelia at Europython, I had an long chat with Tommi
>Virtinan about integration between Kamaelia and Twisted. I haven't had
>a chance to follow up with him yet regarding how this would work, though
>I have set a line in the sand aiming to have easy integration between
>Kamaelia and Twisted before Kamaelia hits version 1.0.0. The impression
>I got from Tommi was that he was most interested in the communications
>aspect - the fact we can bolt together systems in a manner directly
>akin to Unix pipelines, though I suspect he found the graphines aspect
>more interesting. 
>
>Or as someone asking a similar question at Open Tech exclaimed after
>I finally managed to explain it better to them "Ooooh - you're trying
>to make concurrency EASY!".
>
>> OK, so what do the components in the pipelines do?  What sort of data
>> do they hold? Unix pipelines act on ascii files; I assume you are
>> do this on audio and visual data. What langauage will the ele,ments
>> in thne pipelines be written it? I assume some will be in C/C++ for
>> speed.
>
>Components are object instances of python classes. The data passed
>between components are object instances. 

What sort of objects? For example, if an application is audio 
straming, what sort of objects will be passed? Will there be onre 
object passed for each 10 ms or so of sound, or will there be a 
continuously-set-up object that passes the data throught it a byte 
at a time?

And if it's written in Python, will it run fast enough?

>Clearly these python classes
>can be written in python, C, C++, pyrex etc. Currently all of Kamael

Re: ANN: Kamaelia 0.2.0 released!

[phil hunt]

On Wed, 03 Aug 2005 16:57:34 +0100, Michael Sparks <[EMAIL PROTECTED]> wrote:
>
>> Is the audience programmers or
>> less technical people? A project that allows non-technical people
>> to build complex network applications is an ambitious one, but not
>> impossible (I'd find it very impressive and very exciting,
>> particularly if it runs on devices such as mobile phones).
>
>It's a little ambitious at this stage, yes.

But it couldbe there eventually?

>>>   * Ogg Vorbis streaming server/client systems (via vorbissimple)
>>>   * Simple network aware games (via pygame)
>>>   * Quickly build TCP based network servers and clients
>> 
>> What sort of servers and clients? 
>
>Whatever you feel like. If you want a server to split and serve audio,
>you could do that.

This is streaming audio, right? For non-streaming I can just use an 
ftp or http server.

>>>   * Quickly build Multicast based network servers and clients
>> Serving what? Could I use it, for example, to build an n-player
>> encrypted  VoIP server to allow people to do conference calls over
>> the Internet?
>
>You could do that probably. (Though we don't have a component
>for audio capture (though a read file adaptor reading from /dev/audio
>might work depending on your platform I suppose) and audio
>encoding at the moment, so those would probably be the core
>components to integrate.

That's a slightly worrying answer for me, worrying because it seems 
I've misunderstood the nature of the project. I assumed that 
components for audio capture, and related activities, would be at 
the heart of the project.

> If you want to use multicast over the wide
>area internet you'd also have to convince all the people using the
>system to use ISPs that support multicast..)

(or just sent the signal out multiple times)

>> (I mean proper encryption here, the sort GCHQ or the NSA can't break)
>
>I'd be impressed if that could be written, using anything really. (Can't
>implies never)

What -- good encryption? That's pretty much a well-known technique
these days (unless the NSA has some *very* advanced hardware in
their basement, which I strongly suspect they don't).

>>>The basic underlying metaphor of a component us like an office worker
>>>with inboxes and outboxes, with deliveries occuring between desks,
>
>> That metaphor brings up an image (at least to me) that the sorts of
>> data that can be communicated are things like documents,
>> spreadsheets, business graphs, memos. 
>
>They could indeed. The underlying framework doesn't differentiate
>between data nor have any realtime aspect embedded in the system
>at present. Just because we're focussing on systems that have a realtime
>element and are multimedia based, this does not mean the system is
>limited to that.

Again, this makes me think I've misunderstood the project.

>> OK, I get the straming part of it. But what asbout non-streaming
>> stuff? What other protocols are necessary?
>
>One example is peer to peer mesh setup. People normally
>think of P2P as a distribution mechanism. However, the underlying
>approach also very good at setting up communications meshes.

When you say a mesh, what do you mean?

>This could be of use in many areas, such as GRID based systems
>for distributed rendering, application layer multicast, and network
>multicast island joining.

Unpack, please.

>Due to the illegal /uses/ of P2P, much work in this area is difficult to
>reuse due to defensive coding.

Oh. Could you give an example?

>We also have to be able to demonstrate system to other people
>inside the BBC in a way non-technical people understand. That means
>showing structures in a friendly dynamic way, showing pictures,
>playing sounds (hence visualisation - looking inside running systems).

Visualisation, if done properly, ought to be useful to technical 
people too.

>That means we need ways of integrating with systems like pygame &
>other toolkits. If however I'm talking outside the BBC I'll try to give
>examples which people might find interesting - such as building a
>presentation tool. The blocks are very much like Lego & K'Nex and
>adding in a new block enables all sorts of new applications.

That's kind of the impression that I've got.

>For example, we could take the text ticker, combine that with a text
>feed and have a personal autocue/teleprompter. Alternatively someone
>could use it to have subtitles (say) at the opera displayed on a Nokia
>770 (maemo) based device. 

That would be useful.

Or you could have subtitles in different languages, and the user 
gets to choose which one to display...

-- 
Email: zen19725 at zen dot co dot uk


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

Re: PEP: Specialization Syntax

[phil hunt]

On 8 Aug 2005 02:26:40 -0700, Kay Schluehr <[EMAIL PROTECTED]> wrote:
>
>I have to admit that i don't actually understand what you want?

Me neither. I don't see the point of this.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Why is this?

[phil hunt]

On Wed, 10 Aug 2005 12:40:54 +0200, Jiri Barton <[EMAIL PROTECTED]> wrote:
>Hi everyone,
>
>I have a problem with initialization.
 a, b = [[]]*2
 a.append(1)
 b
>[1]
>
>Why is this? Why does not this behave like the below:
>
 a, b = [[], []]
 a.append(1)
 b
>[]

In your 1st example a and b point to copies of the same object, in 
the second example the point to two separate objects that happen to 
have the same repr() representation.

Here's another example of the same thing:

>>> c = []
>>> d = [c,c]
>>> e = [[],[]]
>>> d
[[], []]
>>> e
[[], []]

(d) and (e) appear to be the same (i.e. they have the same repr() 
form), but they are not. Consider:

>>> e[1].append("spam")
>>> e
[[], ['spam']]

But:

>>> d[1].append("spam")
>>> d
[['spam'], ['spam']]

The point is that in Python an object's repr() -- which stands for 
"representation" -- doesn't actually tell you how the object is 
represented inside the innards to the Python system.

Incidently I am currently working on a programming language that 
fixes this problem. In my language "Unify", the equivalent of repr 
is called "storage manager format" (or SM-format) because if two 
values have the same SM-format it is guaranteed that the system will 
treat them identiacally. The SM-format can thus be used for 
serialisation, and incidently it is also the same format in which 
literals are written in a program.

In Unify to specify an Array containing two separate empty Arrays 
would look like this:

e := #(() ())

The code to add a value to one sub-array, and print the result is:

e[1] @= 'spam'.  // means same as Python d[1].append("spam")
out << sm(e).// convert to SM-string, output it to stdout

This would print this text:

#(() (spam))

An array containing two copies of the same sub-array might look like 
this:

d := #( () &[0] )

Where "&[0]" means "pointer to the 0th array subscript".


-- 
Email: zen19725 at zen dot co dot uk


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

Re: What is Python?!

[phil hunt]

On Wed, 10 Aug 2005 13:14:26 +0200, Robert Wierschke <[EMAIL PROTECTED]> wrote:
>hi
>
>I'm learning python since 3 days. I' ve some programming experience in 
>BASIC, Pascal, C, C++ and Java. Actually I want to add a scripting 
>language to this repertoire (I have virtually no experience with 
>scripting).
>
>Having read that python is object orientated, I start wondering if 
>python is the right choice and what it is...
>
>   a scripting language or a "normal" language like C++ etc.

Both.

>So please tell me what python is, what are it's strength, what is it 
>good for and when should I use it and not one of the other languages.
>
>other questions:
>What about graphic? Can I create graphical interfaces with python?

There are several GUIs available, for example Tkinter.

>Python is interpreted but is it compiled to something like the java byte 
>code 

Yes. It is compiled to .pyc files which are then interpreted; 
exactly the same idea that java uses.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: "Compile time" checking?

[phil hunt]

On 10 Aug 2005 08:53:15 -0700, Qopit <[EMAIL PROTECTED]> wrote:
>Hi there,
>
>I'm pretty new to Python and am trying to figure out how to get "will
>this code compile?"-like code checking.

Why not just find out, by trying to compile it? :-)


-- 
Email: zen19725 at zen dot co dot uk


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

Re: "Compile time" checking?

[phil hunt]

On 10 Aug 2005 12:01:01 -0700, Qopit <[EMAIL PROTECTED]> wrote:
>> Why not just find out, by trying to compile it? :-)
>
>This will likely certify me as a python newbie, but... how do you mean?
> How do you compile a .py file?

At the command prompt:

$ python yourfile.py

This compiles it, then runs it.

>If you mean to .pyc by doing an import on it,

Indeed so.

> that may work fine for
>the simple example I typed up earlier, but that is easy to bypass by
>slapping the offending line in a function.  The sample below also
>passes PyChecker with not even a warning:
>
>#
>def tester(a,b,c):
>  print "bogus test function",a,b,c
>
>def try1():
>  tester(1,2,3)
>def try2():
>  tester(1,2)#still no error here
>#
>
>Do you mean something different?

I've never used PyChecker myself, so can't comment on it.

I've not personally had problems with the wrong number of argumnets 
to a function call -- they get caught at run-time and are easy 
enough to fix -- but I do sometimes get errors because a varialbe is 
the wrong time, e.g. a string when it should be an int.

One problem I once encountered was wit this and I waasn't picking it 
up because my debugging code looked like this:

   if debug: print "v=%s" % (v,)

Which of course prints the same output whether v is '2' or 2.

For this reason I tend to debug print statements like this now:

   if debug: print "v=%s" % (v,)


-- 
Email: zen19725 at zen dot co dot uk


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

Re: Python supports LSP, does it?

[phil hunt]

On Tue, 09 Aug 2005 18:36:56 -0500, Andy Leszczynski 
 wrote:
>wikipedia 
>(http://en.wikipedia.org/wiki/Python_programming_language#Object-oriented_programming)
> 
>says:
>"""
>Python's support for object oriented programming paradigm is vast. It 
>supports polymorphism [...] fully in the Liskov substitution 
>principle-sense for all objects.
>"""
>
>Just wondering if it is true statement. Is not LSP more a quality of the 
>desing of class hierachy rather then language itslef? Comments?

According to Wikipedia, the Liskov substitution principle is:

  Let q(x) be a property provable about objects x of type T. Then 
  q(y) should be true for objects y of type S where S is a subtype of T

To me, this is nonsense. Under this definition any subtype must 
behave the same as its parent type, becausde if it doesn't there 
will be some q(y) that are different to q(x).

But if it behaves the same, what's the point of having a subtype?

Am I missing something?

-- 
Email: zen19725 at zen dot co dot uk


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

Re: "Compile time" checking?

[phil hunt]

On 10 Aug 2005 18:32:54 -0700, Qopit <[EMAIL PROTECTED]> wrote:
>
>> if debug: print "v=%s" % (v,)
>
>Not that important, but I assume the first one was supposed to be:
>
>  if debug: print "v=", s
>
>right?

No, I'm trying to print (v) not (s).


-- 
Email: zen19725 at zen dot co dot uk


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

Re: "Compile time" checking?

[phil hunt]

On Thu, 11 Aug 2005 02:35:40 GMT, Bengt Richter <[EMAIL PROTECTED]> wrote:
>On Wed, 10 Aug 2005 20:39:03 +0100, [EMAIL PROTECTED] (phil hunt) wrote:
>[...]
>>
>>I've not personally had problems with the wrong number of argumnets 
>>to a function call -- they get caught at run-time and are easy 
>>enough to fix -- but I do sometimes get errors because a varialbe is 
>>the wrong time, e.g. a string when it should be an int.
>>
>>One problem I once encountered was wit this and I waasn't picking it 
>>up because my debugging code looked like this:
>>
>>   if debug: print "v=%s" % (v,)
>>
>>Which of course prints the same output whether v is '2' or 2.
>>
>>For this reason I tend to debug print statements like this now:
>>
>>   if debug: print "v=%s" % (v,)
>
>I usually prefer %r over %s for debug prints
>
>if debug: print "v=%r" % (v,)

Arrghh!! Yes, that's what I meant to write.


-- 
Email: zen19725 at zen dot co dot uk


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

Re: What is Python?!

[phil hunt]

On Thu, 11 Aug 2005 15:51:45 +1200, Evil Bastard <[EMAIL PROTECTED]> wrote:
>
>I guess a language could be called a 'scripting language' if:
> - the source code can be executed directly, and/or
> - source need not be converted to a separate file in a
>   non-human-readable format before it can be executed, and/or
> - a change to the source file automatically causes a change in
>   runtime behaviour
>
>By these, Python is most definitely a scripting language, and joins Perl
>and PHP. Whereas changes to java source files don't change runtime
>behaviour.

It wouldn't be particularly difficult to invoke Java by a shell 
script that checks to see if source has changed and if so 
recompiles it. If such a script became part of standard Java, would 
Java then be a scripting language?

-- 
Email: zen19725 at zen dot co dot uk


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

Re: GUI tookit for science and education

[phil hunt]

On Mon, 15 Aug 2005 04:59:29 +0200, Mateusz £oskot <[EMAIL PROTECTED]> wrote:
>Hi,
>
>I'd like to ask some scientists or students
>which GUI toolkit they would recommend
>to develop scientific prototypes (for education and
>testing some theories).
>I think such toolkit should fill a bit different
>needs and requirements:
>- very simple to learn
>- easy to install
>- beautyfiers and advanced features are not required like OpenGL,
>direct access to Windows GDI subsystem, beauty look and skinning
>- multiplatform required

Tkinter is the default GUI for Python, it runs on lots of platforms 
and often comes already installed (on Linux or Unix distributions).

Is it "very simple to learn"? Well I suppose that depends on what 
you mean by "very simple".

-- 
Email: zen19725 at zen dot co dot uk


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

Re: SOAP and XMLRPC

[phil hunt]

On Mon, 15 Aug 2005 20:04:55 +0200, Magnus Lycka <[EMAIL PROTECTED]> wrote:
>dcrespo wrote:
>> Hi to all...
>> Someone knows if is there possible to have a Python SOAP or XMLRPC
>> server that works with VB? I would like you to include the examples
>> clients and server programs.
>
>If you can write an XML-RPC client in VB, it will work with
>XML-RPC servers written in any language. This is the wrong
>forum to learn how to do that though. May I suggest that you
>google for "visual basic xml-rpc client"

I thought it was the whole point of XMLRPC that the server can be 
written in one language and the client in another. Am I wrong?

-- 
Email: zen19725 at zen dot co dot uk


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

Re: last line chopped from input file

[phil hunt]

On 20 Aug 2005 22:53:42 -0700, Eric Lavigne <[EMAIL PROTECTED]> wrote:
>Here is a shell command (MS-DOS):
>  debug\curve-fit output.txt
>
>And here is a Python script that *should* do the same thing (and almost
>does):
>
>  import os
>
>  inputfilename = 'input.txt'
>  outputfilename = 'output.txt'
>
>  inputfile = open(inputfilename,'r')
>  outputfile = open(outputfilename,'w')
>  inputstream,outputstream = os.popen2("debug\\curve-fit")
>  inputstream.write(inputfile.read())
>  inputfile.close()
>  inputstream.close()
>  outputfile.write(outputstream.read())
>  outputstream.close()
>  outputfile.close()
>
>On a side note, I am very new to Python so I would appreciate any
>comments on style, or suggestions for simpler ways to write something
>like this (seems overkill for matching one line of shell), or more
>portable ways to write it (requires '\\' on windows but '/' on linux).

A shorter python program would be:

   os.command("debug\\curve-fit output.txt")

If you don't like the doubled \\, you could write:

   os.command(r"debug\curve-fit output.txt")

For portability regarding \\ versus /, look at the os.path module.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: global interpreter lock

[phil hunt]

On Thu, 25 Aug 2005 00:56:10 -0400, Mike Meyer <[EMAIL PROTECTED]> wrote:
>> The issue here is whether to confuse reality with what one might
>> wish reality to be.
>
>Let's see. Reality is that writing correct programs is hard. Writing
>correct programs that use concurrency is even harder, because of the
>exponential explosion of the order that operations can happen
>in. Personally, I'm willing to use anything I can find that makes
>those tasks easier.

Indeed so. Use threading (or whatever) when one has to, use an 
asynchronous single-threaded process whenever you can.


-- 
Email: zen19725 at zen dot co dot uk


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

Re: global interpreter lock

[phil hunt]

On 26 Aug 2005 14:35:03 -0700, Paul Rubin <http://[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (phil hunt) writes:
>> >Let's see. Reality is that writing correct programs is hard. Writing
>> >correct programs that use concurrency is even harder, because of the
>> >exponential explosion of the order that operations can happen
>> >in. Personally, I'm willing to use anything I can find that makes
>> >those tasks easier.
>> 
>> Indeed so. Use threading (or whatever) when one has to, use an 
>> asynchronous single-threaded process whenever you can.
>
>This is silly.  You could say the exact same thing about if
>statements.  The number of paths through the program is exponential in
>the number of if statements executed.  So we better get rid of if
>statements.

It's not the number of paths that's important.

What's important is *predictability*, e.g. which instruction will
the computer execute next?

If you only have one thread, you can tell by looking at the code 
what gets executed next. It's very simple.

If you have 2 threads you can easily have a timing-based situation
that occurs rarely but which causes your program to behave wierdly.
This sort of bug is very hard to reproduce and therefore to fix.

>Really, the essence of programming is to find ways of organizing the
>program to stay reliable and maintainable in the face of that
>combinatorial explosion. 

Yes, and introducing code that makes randomly-occurring bugs more
likely makes debugging inherently harder.

> That means facing the problem and finding
>solutions, not running away.

Yes, find solutions. Don't find dangerous dead-ends that look like 
solutions but which will give you lots of trouble.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: global interpreter lock

[phil hunt]

On Sun, 28 Aug 2005 20:34:07 GMT, Bryan Olson <[EMAIL PROTECTED]> wrote:
>phil hunt wrote:
> > Yes, find solutions. Don't find dangerous dead-ends that look like
> > solutions but which will give you lots of trouble.
>
>If concurrency is a dead end, why do the programs that provide
>the most sophisticated services of any in the world rely on it
>so heavily?

Some times concurrency is the best (or only) way to do a job. Other 
times, it's more trouble than its worth. A good programmer will know 
which is which, and will not use an overly complex solution for the 
project he is writing.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: global interpreter lock

[phil hunt]

On Sun, 28 Aug 2005 19:25:55 -0400, Mike Meyer <[EMAIL PROTECTED]> wrote:
>Bryan Olson <[EMAIL PROTECTED]> writes:
>> phil hunt wrote:
>>  > Yes, find solutions. Don't find dangerous dead-ends that look like
>>  > solutions but which will give you lots of trouble.
>> If concurrency is a dead end, why do the programs that provide
>> the most sophisticated services of any in the world rely on it
>> so heavily?
>
>I don't know what Phil is saying, but I'm not calling concurrency a
>dead end. 

In general it isn't. However, in many programs, it might be, in that 
by using it you might end up with a very complex program that fails
unpredictably and if hard to debug: if you get in that situation, 
you may have to start again, in which case your previous work will 
have been a dead end.

(Actually I would suggest that knowing when to throw something away 
and start again is something that differentiates between good and 
bad programmers).

>I'm calling the tools available in most programming
>languages for dealing with it primitive.
>
>We need better tools.

I agree.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Bug in string.find; was: Re: Proposed PEP: New style indexing,was Re: Bug in slice type

[phil hunt]

On Tue, 30 Aug 2005 08:53:27 GMT, Bryan Olson <[EMAIL PROTECTED]> wrote:
> Specifically, to support new-style slicing, a class that
> accepts index or slice arguments to any of:
>
> __getitem__
> __setitem__
> __delitem__
> __getslice__
> __setslice__
> __delslice__
>
> must also consistently implement:
>
> __len__
>
> Sane programmers already follow this rule.


Wouldn't it be more sensible to have an abstract IndexedCollection 
superclass, which imlements all the slicing stuff, then when someone 
writes their own collection class they just have to implement 
__len__ and __getitem__ and slicing works automatically?


-- 
Email: zen19725 at zen dot co dot uk


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

Re: 'isa' keyword

[phil hunt]

On 1 Sep 2005 00:52:54 -0700, talin at acm dot org <[EMAIL PROTECTED]> wrote:
>
>The "isa" operator would of course be overloadable, perhaps by an
>accessor functions called __isa__, which works similarly to
>__contains__. The potential uses for this are not limited to
>isinstance() sugar, however. For example:
>
>if image isa gif:
>elif image isa jpeg:
>elif image isa png:

What's wrong with:

if image.isa(gif):
elif image.isa(jpeg):
elif image.isa(png):

In short, I see no need to add further complexity to Python's 
grammar.

It could be argued of course, that an OOPL should allow methods to 
be sent with a grammar:

   receiver selector argument

(which is almost what Smalltalk does), but you're not arguing for 
that (and I'm not sure it would work with the rest of python's 
grammar).

-- 
Email: zen19725 at zen dot co dot uk


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

Re: 'isa' keyword

[phil hunt]

On Thu, 01 Sep 2005 20:39:14 -0500, Steve Holden <[EMAIL PROTECTED]> wrote:
>phil hunt wrote:
>> It could be argued of course, that an OOPL should allow methods to 
>> be sent with a grammar:
>> 
>>receiver selector argument
>> 
>> (which is almost what Smalltalk does), but you're not arguing for 
>> that (and I'm not sure it would work with the rest of python's 
>> grammar).
>> 
>Even if it did it might mangle operator precedence in the same way 
>SmallTalk did, which I always felt was one of the least attractive 
>features" of the language.

That's certainly a point of view; another is that Smalltalk 
simplified things by making all operators the saem priority. For 
those that don't know smalltalk, in that language:

   a + b * c

means:

   (a + b) * c

>I don't think a change to a message-passing paradigm

I'm not talking about a change in *paradigm* merely a change in 
*syntax*; this:

   receiver selector argument

would mean the same as the current Python:

   receiver.selector(argument)

so it is purely a matter of aesthetics which is preferred. Havcing 
said that, I don't see a big benefit in changing Python's syntax in 
this way.

> would necessarily 
>benefit Python at this stage. Some people are still under the 
>misapprehension that message-passing is a fundamental of object-oriented 
>programming because of Smalltalk, but they are wrong.

I don't see how it can reasonably said that STK has 
"message-passing" but other OOPLs don't. Consider these code 
fragments:

Smalltalk:
   receiver selector: argument

C++ or Java:
   receiver.selector(argument);

Python:
   receiver.selector(argument)

PHP:
   $receiver->selector($argument)

(I'm not sure if the last one is right since I've not done much OO 
stuff in PHP)

These all mean essentially the same thing so how can one be "message 
passing" and the others not?


-- 
Email: zen19725 at zen dot co dot uk


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

Re: 'isa' keyword

[phil hunt]

On Sat, 03 Sep 2005 00:45:19 -0500, Steve Holden <[EMAIL PROTECTED]> wrote:
>> I'm not talking about a change in *paradigm* merely a change in 
>> *syntax*; this:
>> 
>>receiver selector argument
>> 
>> would mean the same as the current Python:
>> 
>>receiver.selector(argument)
>> 
>Aah, I see. I had assumed that "selector" was always going to be an 
>operator. 3 . (+ 4) does indeed seem very "SmallTalkative". I don't 
>think that Python method (or attribute) selection bears any relationship 
>to SmallTalk message-passing, but I hope you will feel free to enlighten me.

Let's consider the Python example first.

You have two classes A and B. Each has a method called 'selector'.

When the line of code above is executed, the Python virtual machine 
decides whether (receiver) is a member of A or B, and then executed 
one of A.selector() or B.selector() depending on which it is. 
Whichever function is executed, it is passed with (reciever) as the 
"self" argument so that the correct data is operated on.

And now let's consider the Smalltalk example. How does it do it? 
Essentially it does *exactly the same thing*.

(Yes, I know there are many differneces in detail between how 
Snalltalk and Python  work, but they are only *details*; the 
fundamental idea governing how these two object-oriented languages 
work is the same).

>>>would necessarily 
>>>benefit Python at this stage. Some people are still under the 
>>>misapprehension that message-passing is a fundamental of object-oriented 
>>>programming because of Smalltalk, but they are wrong.
>> 
>> 
>> I don't see how it can reasonably said that STK has 
>> "message-passing" but other OOPLs don't. Consider these code 
>> fragments:
>> 
>> Smalltalk:
>>receiver selector: argument
>> 
>> C++ or Java:
>>receiver.selector(argument);
>> 
>> Python:
>>receiver.selector(argument)
>> 
>> PHP:
>>$receiver->selector($argument)
>> 
>> (I'm not sure if the last one is right since I've not done much OO 
>> stuff in PHP)
>> 
>> These all mean essentially the same thing so how can one be "message 
>> passing" and the others not?
> 
>Sorry, they don't all mean "essentially the same thing" at all. It seems 
>to me you are looking at SmallTalk in entirely too superficial a light. 

OK, allow me to reprase it. Imagine a language ith the semantics of 
Python but the syntax of C++ or PHP or Smalltalk (or Lisp for that 
matter). It would still basically be Python, wouldn't it?

>  In SmallTalk, control structures aren't syntactic primitives, they are 
>also examples of message-passing, so code blocks are sent as messages to 
>objects. Python eschews such obscurity and (IMHO) gains clarity by so 
>doing. But that is, of course, a matter of opinion.

I agree, that's a major point of departure between Python and 
Smalltalk.

>Also, remember that just because two expressions in different languages 
>"mean the same thing "doesn't mean they are implemented using the same 
>techniques.

Of course not. 

CPython and JPython are different implementations, but they are 
still the same language (mostly).

>I would contend (if backed into a corner) that there is a significant 
>difference between passing the arguments 3 and 4 to a "+" operator 
>(which is what Python and most other languages implementing standard 
>ideas of operator precedence do) and sending the message "+ 4" to the 
>integer 3 (which is effectively what SmallTalk does).

In both python and smalltalk you can override the operator to mean 
what you want, so I disagree that there is any fundamental 
difference. Why do you think there is?

>Of course, I realise that you can argue that the two are equivalent in 
>the sense that they perform the same computation. But SmallTalk's choice 
>led to the loss of operator precedence, which is something that is 
>pretty fundamental to mathematics. 

Surely that's a separate issue, one purely of syntax. Imagine two 
languages:

   (* (+ a b) c)

and:

   (a + b) * c

These both mean the same thing, they just say it differently.

>Also Python allows much more 
>flexibility by hard-wiring operators and allowing alternatives to be 
>considered (if the left operand doesn't have an "__add__" method then 
>try to use the right operand's "__radd__" method). SmallTalk doesn't 
>have any parallel to this that I can think of.

You're right; in Smalltalk you'd have to code that functionality in
the method for the left-hand object.

>Of course it isn't only mathematicians who are taught to us the 
>precedence rules, so I contend that SmallTalk would seem 
>counter-intuitive in a "Programming for Everyone" context as well. 

Probably. 

However consider that a language (e.g. C++) may have lots of 
operators, e.g: & && | || << >> <= >= < > ^ % etc. Is there an 
obvious natural order of precedence for all these? I suspect that 
many C++ programmers couldn't put all its operators in the correect 
order.

>I speak as one who was partly, and in a minor way, responsible for 
>implemen

Re: Create new instance of Python class in C

[phil hunt]

On Fri, 9 Sep 2005 17:19:21 +0200, Sybren Stuvel <[EMAIL PROTECTED]> wrote:
>Hi people,
>
>I'm creating a program that can solve and create Sudoku puzzles. My
>creation function needs to make a lot of copies of a puzzle.

Why do you need to maske lots of copies? And when you say "lots of"
what numbers do you mean? 100? 100?

The reason I ask is I recently wrote a program to solve Sudoku 
puzzles, and IIRC it didn't make copies at all.

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Create new instance of Python class in C

[phil hunt]

On Fri, 9 Sep 2005 18:50:26 +0200, Sybren Stuvel <[EMAIL PROTECTED]> wrote:
>djw enlightened us with:
>> Personally, I would try Psyco first, and consider Pyrex next.
>
>Ok, I'll take a look at those.
>
>> Are you sure your algorithm can't be optimized first, before you
>> start trying to write this in C?
>
>I'm sure there will be optimizations, but profiling showed that the
>copying of the puzzles took the most time. Since the copy.deepcopy()
>function is implemented it Python, I'd thought it would get quite a
>speed boost when done in C instead.

Can you use a different algorithm that doesn't make so many copies?

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Software bugs aren't inevitable

[phil hunt]

On Thu, 15 Sep 2005 21:56:06 +1000, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>
>Are you saying that the recursion done by "serious" languages is a fake?
>That it is actually implemented behind the scenes by iteration?
>
>It seems to me that if recursion and iteration produce "the exact same
>machine code", the argument for preferring recursion over iteration is
>gutted.

It seems to me that if a high level language and assembler produce
"the exact same machine code", the argument for preferring high
level languages is gutted.

Do you see the fallacy in your statement now?

-- 
Email: zen19725 at zen dot co dot uk


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

Re: Software bugs aren't inevitable

[phil hunt]

On Fri, 16 Sep 2005 20:36:02 +1000, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>On Thu, 15 Sep 2005 18:07:28 +0100, phil hunt wrote:
>
>> On Thu, 15 Sep 2005 21:56:06 +1000, Steven D'Aprano <[EMAIL PROTECTED]> 
>> wrote:
>>>
>>>Are you saying that the recursion done by "serious" languages is a fake?
>>>That it is actually implemented behind the scenes by iteration?
>>>
>>>It seems to me that if recursion and iteration produce "the exact same
>>>machine code", the argument for preferring recursion over iteration is
>>>gutted.
>> 
>> It seems to me that if a high level language and assembler produce
>> "the exact same machine code", the argument for preferring high
>> level languages is gutted.
>> 
>> Do you see the fallacy in your statement now?
>
>Ah, yes, you got me on that one.
>
>But there is a difference: writing assembly is *hard*, which is why we
>prefer not to do it. Are you suggesting that functional programming is
>significantly easier to do than declarative?

No. I'm saying that under some circumstances it might be easier to 
write code as a recursive routine than a loop. In those 
circumstances, why should I care if the compiler then re-encodes my 
recursive routine as a loop, so long as the program gives the 
correct answer.

Compilers/interpreters/runtimes are black boxes: we don't (or
shouldn't) care how they do their work as long as they run correctly 
and aren't too heavy on system resources like CPU time and memory.


-- 
Email: zen19725 at zen dot co dot uk


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

Re: Software bugs aren't inevitable

[phil hunt]

On Fri, 16 Sep 2005 20:05:04 -0400, Mike Meyer <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (phil hunt) writes:
>> Compilers/interpreters/runtimes are black boxes: we don't (or
>> shouldn't) care how they do their work as long as they run correctly 
>> and aren't too heavy on system resources like CPU time and memory.
>
>Maybe in academia. Not in the real world. Or maybe you just phrased
>that last clause poorly.

I think perhaps I did.

> In the real world, programs have performance
>constraints.

Yes i know, that's why I said "aren't too heavy on system resources 
like CPU time and memory".

> Some of them are seriously inflexible - in which case we
>call what we're doing "real-time" or "embedded" or words to that
>effect. 

If a program is too slow to respond isn't that about "system time"?

>Others are softer, but in the end they matter *very much*. I
>would have phrased that last clause to make reasonableness a
>requirement, rather than making "not unreasonable" the requirement.
>
>Because of that, you have to care about how your implementation
>works. If you don't know how strings work in Python, you tend to write
>O(n^2) algorithms instead of O(n) ones for fundamental
>operations.

What does "CPU time" mean again?

-- 
Email: zen19725 at zen dot co dot uk


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