Re: the meaning of r’.......‘

[John Roth]

On Monday, July 23, 2012 1:59:42 AM UTC-6, Chris Angelico wrote:
> On Fri, Jul 20, 2012 at 5:56 PM, levi nie  wrote:
> > the meaning of r’...‘？
> 
> It's a raw string.
> 
> http://docs.python.org/py3k/tutorial/introduction.html#strings
> 
> Chris Angelico

Since this seems to have wandered into the question of unicode support for 
operators and identifiers in Python, I'll add a few general comments. First, 
adding unicode operators has been discussed several times, and the answer has 
always been what several people have stated: lack of support from keyboards and 
fonts. As far as I can tell, the only significant issue that unicode operators 
would solve is set operators. Currently they overload the arithmetic operators, 
so it's not possible to have an object with both arithmetic and set behavior 
supported by operator syntax. I'm not sure how important that is in the real 
world.

Identifiers can have any character that's marked as alphabetic in the unicode 
data base. The doc gives the exact criteria, but it's driven by checking the 
actual data base, or rather Python's copy of it. PEP 8 requires sticking to the 
Ascii character set except for comments, and then only when it's needed for 
properly spelling someone's name. Of course, anyone can do anything they want, 
but Python doesn't have a culture of deliberately trying to write illegible 
code.

And yes, Python did have a problem with the Turkish "i". It got fixed without 
all the sturm and drang that seems to accompany PHP issues.



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

Re: Why doesn't Python remember the initial directory?

[John Roth]

On Sunday, August 19, 2012 7:57:46 PM UTC-6, kj wrote:

> This means that no library code can ever count on, for example,
> 
> being able to reliably find the path to the file that contains the
> 
> definition of __main__. 

If you want to find that, look up __main__ in sys.modules and then look at the 
__file__ attribute. You need to be a bit careful with this; the import 
machinery was rewritten for the upcoming 3.3 release, and there were several 
changes to the module information.

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

Re: Disable use of pyc file with no matching py file

[John Roth]

On Jan 30, 3:43 pm, Terry Reedy  wrote:
> On 1/30/2012 4:30 PM, Roy Smith wrote:
>
> > Every so often (typically when refactoring), I'll remove a .py file
> > and forget to remove the corresponding .pyc file.  If I then import
> > the module, python finds the orphaned .pyc and happily imports it.
> > Usually leading to confusing and hard to debug failures.
>
> > Is there some way to globally tell python, "Never import a .pyc
> > unless the corresponding .py file exits"?
>
> Upgrade to 3.2.
>
> --
> Terry Jan Reedy

Terry,

I've noticed that the tutorial (section 6.1.3) hasn't been updated for
PEP 3147; there's no way of telling that this is the behavior from
reading the tutorial. The development doc for 3.3 hasn't been updated
either.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Disable use of pyc file with no matching py file

[John Roth]

On Jan 31, 4:43 pm, Terry Reedy  wrote:
> On 1/31/2012 3:20 PM, John Roth wrote:
>
> > On Jan 30, 3:43 pm, Terry Reedy  wrote:
> >> On 1/30/2012 4:30 PM, Roy Smith wrote:
>
> >>> Every so often (typically when refactoring), I'll remove a .py file
> >>> and forget to remove the corresponding .pyc file.  If I then import
> >>> the module, python finds the orphaned .pyc and happily imports it.
> >>> Usually leading to confusing and hard to debug failures.
>
> >>> Is there some way to globally tell python, "Never import a .pyc
> >>> unless the corresponding .py file exits"?
>
> >> Upgrade to 3.2.
>
> I tested before writing this. The caveat is that x.pyc in the same
> directly as x.py will not be ignored (for back compatibility). However,
> this only happens intentionally as .pyc files are put in __pycache__/
> with name x..pyc, where  is 'cpython-32' or something
> similar for another version or implementation.
>
> > I've noticed that the tutorial (section 6.1.3) hasn't been updated for
> > PEP 3147; there's no way of telling that this is the behavior from
> > reading the tutorial. The development doc for 3.3 hasn't been updated
> > either.
>
> You are right. An oversight. Thanks for 
> noticing.http://bugs.python.org/issue13915
> Suggested rewrites are welcome.
>
> --
> Terry Jan Reedy

I'll see if I can put a suggestion in the bug report.

One other point: I'm unclear if a compiled module in the source
directory would be named spam.pyc or spam.cpython-32.pyc. I'd think
the latter to allow two versions of a compiled-only distribution.

John Roth

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

Re: Just curious: why is /usr/bin/python not a symlink?

[John Roth]

On Feb 23, 2:11 pm, Terry Reedy  wrote:
> On 2/23/2012 2:34 PM, HoneyMonster wrote:
>
>
>
>
>
>
>
>
>
> > On Thu, 23 Feb 2012 14:24:23 -0500, Jerry Hill wrote:
>
> >> On Thu, Feb 23, 2012 at 2:11 PM, HoneyMonster
> >>   wrote:
> >>> $ cd /usr/bin $ ls -l python*
> >>> -rwxr-xr-x 2 root root 9496 Oct 27 02:42 python lrwxrwxrwx 1 root root
> >>>     6 Oct 29 19:34 python2 ->  python -rwxr-xr-x 2 root root 9496 Oct 27
> >>> 02:42 python2.7 $ diff -s  python python2.7 Files python and python2.7
> >>> are identical $
>
> >>> I'm just curious: Why two identical files rather than a symlink?
>
> >> It's not two files, it's a hardlink.  You can confirm by running ls -li
> >> python* and comparing the inode numbers.
>
> > You are spot on. Thank you, and sorry for my stupidity.
>
> The question 'why a hardlink rather than symlink' is not stupid. It was
> part of the discussion ofhttp://python.org/dev/peps/pep-0394/
> The answer was 'history' and how things were 20 years ago and either the
> pep or the discussion around it says symlinks are fine now and the
> decision is up to distributors.
>
> --
> Terry Jan Reedy

I believe the changes for PEP 394 are using symlinks. The distro
maintainer can, of course, change that.

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

Re: why () is () and [] is [] work in other way?

[John Roth]

On Sunday, April 22, 2012 1:43:36 PM UTC-6, John Nagle wrote:
> On 4/20/2012 9:34 PM, john.tant...@gmail.com wrote:
> > On Friday, April 20, 2012 12:34:46 PM UTC-7, Rotwang wrote:
> >
> >> I believe it says somewhere in the Python docs that it's undefined and
> >> implementation-dependent whether two identical expressions have the same
> >> identity when the result of each is immutable
> 
> Bad design.  Where "is" is ill-defined, it should raise ValueError.
> 
> A worse example, one which is very implementation-dependent:
> 
> http://stackoverflow.com/questions/306313/python-is-operator-behaves-unexpectedly-with-integers
> 
>  >>> a = 256
>  >>> b = 256
>  >>> a is b
> True   # this is an expected result
>  >>> a = 257
>  >>> b = 257
>  >>> a is b
> False
> 
> Operator "is" should be be an error between immutables
> unless one is a built-in constant.  ("True" and "False"
> should be made hard constants, like "None". You can't assign
> to None, but you can assign to True, usually with
> unwanted results.  It's not clear why True and False
> weren't locked down when None was.)
> 
>   John Nagle

Three points. First, since there's no obvious way of telling whether an 
arbitrary user-created object is immutable, trying to make "is" fail in that 
case would be a major change to the language. Given the next point, I expect 
that a request to change Python to do it would be rejected immediately.

Second: the definition of "is" states that it determines whether two objects 
are the same object; this has nothing to do with mutability or immutability. 
It's an implementation detail whether an immutable object is implemented as a 
singleton. Some common cases (None, True, False and the empty tuple) are 
specified to be that in the language definition, but it's not specified for the 
general case.

The id([]) == id([]) thing is a place where cPython's implementation is showing 
through. It won't work that way in any implementation that uses garbage 
collection and object compaction. I think Jython does it that way, I'm not sure 
about either IronPython or PyPy.

Third: True and False are reserved names and cannot be assigned to in the 3.x 
series. They weren't locked down in the 2.x series when they were introduced 
because of backward compatibility.

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

Re: Py3.3 unicode literal and input()

[John Roth]

On Monday, June 18, 2012 9:44:17 AM UTC-6, jmfauth wrote:
> Thinks are very clear to me. I wrote enough interactive
> interpreters with all available toolkits for Windows
> since I know Python (v. 1.5.6).
> 
> I do not see why the semantic may vary differently
> in code source or in an interactive interpreter,
> esp. if Python allow it!
> 
> If you have to know by advance what an end user
> is supposed to type and/or check it ('str' or unicode
> literal) in order to know if the answer has to be
> evaluated or not, then it is better to reintroduce
> input() and raw_input().
> 

The change between Python 2.x and 3.x was made for security reasons. The 
developers felt, correctly in my opinion, that the simpler operation should not 
pose a security risk of a malicious user entering an expression that would 
corrupt the program.

In Python 3.x the equivalent of Python 2.x's input() function is eval(input()). 
It poses the same security risk: acting on unchecked user data.

John Roth


> jmf

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

Re: ActivePython: multiple versions on OSX?

[John Roth]

On Jul 25, 8:18 pm, Ned Deily  wrote:
> In article , Robert 
> wrote:
>
> > Is it possible to install the 2 and 3 series side by side?
>
> Probably.  On Mac OS X, t's certainly possible to install any python.org
> versions side by side, even multiple versions of 2 and 3.  That's one of
> the advantages of the Python framework build layout on OS X, which is
> used by both the python.org installers and, I believe, the ActiveState
> installers.
>
> http://www.python.org/download/
>
> --
>  Ned Deily,
>  n...@acm.org

When you do, you might also want to look at PEP 394:
http://www.python.org/dev/peps/pep-0394/

It can simplify writing scripts which select the version you want.

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

Re: Only Bytecode, No .py Files

[John Roth]

On Jul 27, 1:10 am, Thomas Rachel  wrote:
> Am 26.07.2011 17:19 schrieb Eldon Ziegler:
>
> > Is there a way to have the Python processor look only for bytecode
> > files, not .py files? We are seeing huge numbers of Linux audit messages
> > on production system on which only bytecode files are stored. The audit
> > subsystem is recording each open failure.
>
> Is that really a problem? AFAIK there are many failing open() calls on
> the start of every program.
>
> E.g.
>
> open("/lib/bash/4.1/tls/i686/sse2/libncurses.so.5", O_RDONLY) = -1
> ENOENT (No such file or directory)
> stat64("/lib/bash/4.1/tls/i686/sse2", 0xbfd3a350) = -1 ENOENT (No such
> file or directory)
> open("/lib/bash/4.1/tls/i686/libncurses.so.5", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> stat64("/lib/bash/4.1/tls/i686", 0xbfd3a350) = -1 ENOENT (No such file
> or directory)
> open("/lib/bash/4.1/tls/sse2/libncurses.so.5", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> stat64("/lib/bash/4.1/tls/sse2", 0xbfd3a350) = -1 ENOENT (No such file
> or directory)
> open("/lib/bash/4.1/tls/libncurses.so.5", O_RDONLY) = -1 ENOENT (No such
> file or directory)
> stat64("/lib/bash/4.1/tls", 0xbfd3a350) = -1 ENOENT (No such file or
> directory)
> open("/lib/bash/4.1/i686/sse2/libncurses.so.5", O_RDONLY) = -1 ENOENT
> (No such file or directory)
> stat64("/lib/bash/4.1/i686/sse2", 0xbfd3a350) = -1 ENOENT (No such file
> or directory)
> open("/lib/bash/4.1/i686/libncurses.so.5", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> stat64("/lib/bash/4.1/i686", 0xbfd3a350) = -1 ENOENT (No such file or
> directory)
> open("/lib/bash/4.1/sse2/libncurses.so.5", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> stat64("/lib/bash/4.1/sse2", 0xbfd3a350) = -1 ENOENT (No such file or
> directory)
> open("/lib/bash/4.1/libncurses.so.5", O_RDONLY) = -1 ENOENT (No such
> file or directory)
> stat64("/lib/bash/4.1", 0xbfd3a350)     = -1 ENOENT (No such file or
> directory)
> open("/lib/libncurses.so.5", O_RDONLY)  = 3
>
> is a part of what happens if I start the MySQL client,
>
> Even starting the bash results in
>
> open("/lib/bash/4.1/tls/i686/sse2/libreadline.so.6", O_RDONLY) = -1
> ENOENT (No such file or directory)
> stat64("/lib/bash/4.1/tls/i686/sse2", 0xbfe0c4d0) = -1 ENOENT (No such
> file or directory)
> open("/lib/bash/4.1/tls/i686/libreadline.so.6", O_RDONLY) = -1 ENOENT
> (No such file or directory)
> stat64("/lib/bash/4.1/tls/i686", 0xbfe0c4d0) = -1 ENOENT (No such file
> or directory)
> open("/lib/bash/4.1/tls/sse2/libreadline.so.6", O_RDONLY) = -1 ENOENT
> (No such file or directory)
> stat64("/lib/bash/4.1/tls/sse2", 0xbfe0c4d0) = -1 ENOENT (No such file
> or directory)
> open("/lib/bash/4.1/tls/libreadline.so.6", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> stat64("/lib/bash/4.1/tls", 0xbfe0c4d0) = -1 ENOENT (No such file or
> directory)
> open("/lib/bash/4.1/i686/sse2/libreadline.so.6", O_RDONLY) = -1 ENOENT
> (No such file or directory)
> stat64("/lib/bash/4.1/i686/sse2", 0xbfe0c4d0) = -1 ENOENT (No such file
> or directory)
> open("/lib/bash/4.1/i686/libreadline.so.6", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> stat64("/lib/bash/4.1/i686", 0xbfe0c4d0) = -1 ENOENT (No such file or
> directory)
> open("/lib/bash/4.1/sse2/libreadline.so.6", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> stat64("/lib/bash/4.1/sse2", 0xbfe0c4d0) = -1 ENOENT (No such file or
> directory)
> open("/lib/bash/4.1/libreadline.so.6", O_RDONLY) = -1 ENOENT (No such
> file or directory)
> stat64("/lib/bash/4.1", 0xbfe0c4d0)     = -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.cache", O_RDONLY)      = 3
>
> So can it really be such a huge problem?
>
> Thomas

Two comments. First, your trace isn't showing attempts to open .py
files, it's showing attempts to open the Curses library in the bash
directory. Maybe you also have a problem with the .py files, but it
isn't documented in this trace. It's also not showing the program
that's causing the failing open.

Second, the audit program is an idiot. There are lots of programs
which use the "easier to ask forgiveness" pattern and test for the
existence of optional files by trying to open them. This may be what
Bash is doing.

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

Re: Only Bytecode, No .py Files

[John Roth]

On Jul 27, 8:56 am, Thomas Rachel  wrote:
> Am 27.07.2011 14:18 schrieb John Roth:
>
> > Two comments. First, your trace isn't showing attempts to open .py
> > files, it's showing attempts to open the Curses library in the bash
> > directory.
>
> Of course. My goal was to show that the OP's "problem" is not a python
> one, but occurs all over several programs.
>
>  > Maybe you also have a problem with the .py files,
>
> Why should I?
>
>  > It's also not showing the program that's causing the failing open.
>
> It is irrelevant, IMO.
>
> It just shows that it seems to be common, even for the bin loader, to
> search for libraries to be linked to by trying to open them from several
> places. So every program call must be full of "failures" shown by the
> "audit program".
>
> > Second, the audit program is an idiot. There are lots of programs
> > which use the "easier to ask forgiveness" pattern and test for the
> > existence of optional files by trying to open them. This may be what
> > Bash is doing.
>
> ACK. That is exactly what I wanted to show. (With the difference that
> this is probably nt the bash, but the linux loader trying to link a .so,
> but for the problem, it doesn't make any difference.)
>
> Thomas

Sorry. I thought what you posted was from the OP. I guess I don't
really expect someone to post a completely irrelevant trace in a
thread started by someone who has a problem.

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

Re: Why do class methods always need 'self' as the first parameter?

[John Roth]

On Aug 31, 8:35 am, "T. Goodchild"  wrote:
> I’m new to Python, and I love it.  The philosophy of the language (and
> of the community as a whole) is beautiful to me.
>
> But one of the things that bugs me is the requirement that all class
> methods have 'self' as their first parameter.  On a gut level, to me
> this seems to be at odds with Python’s dedication to simplicity.
>
> For example, consider Python’s indent-sensitive syntax.  Although
> other languages didn’t use indentation to specify scope, programmers
> always used indentation anyways.  Making indentation took a common
> practice, made it a rule, and the result was a significantly improved
> signal-to-noise ratio in the readability of Python code.
>
> So why is 'self' necessary on class methods?  It seems to me that the
> most common practice is that class methods *almost always* operate on
> the instance that called them.  It would make more sense to me if this
> was assumed by default, and for "static" methods (methods that are
> part of a class, but never associated with a specific instance) to be
> labelled instead.
>
> Just curious about the rationale behind this part of the language.

I personally consider this to be a wart. Some time ago I did an
implementation analysis. The gist is that, if self and cls were made
special variables that returned the current instance and class
respectively, then the compiler could determine whether a function was
an instance or class method. If it then marked the code object
appropriately you could get rid of all of the wrappers and the
attendant run-time overhead.

I've never published the analysis because that train has already left
the shed. The earliest it could be considered would be 4.0, which
isn't even on the horizon.

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

Re: Why do class methods always need 'self' as the first parameter?

[John Roth]

On Sep 1, 8:26 am, Ian Kelly  wrote:
> On Thu, Sep 1, 2011 at 6:45 AM, John Roth  wrote:
> > I personally consider this to be a wart. Some time ago I did an
> > implementation analysis. The gist is that, if self and cls were made
> > special variables that returned the current instance and class
> > respectively, then the compiler could determine whether a function was
> > an instance or class method. If it then marked the code object
> > appropriately you could get rid of all of the wrappers and the
> > attendant run-time overhead.
>
> I don't see how you could get rid of the wrappers.  Methods would
> still need to be bound, somehow, so that code like this will work:
>
> methods = {}
> for obj in objs:
>     if obj.is_flagged:
>         methods[obj.user_id] = obj.do_work
>     else:
>         methods[obj.user_id] = obj.do_other_work
> # ...
> methods[some_user_id]()
>
> Without method wrappers, how does the interpreter figure out which
> instance is bound to the method being called?
>
> Cheers,
> Ian

Good question.

Currently the instance wrapper is created during method instantiation,
so the instance is obviously available at that point. There are two
rather obvious ways of remembering it. One is to use the invocation
stack, which has the instance. Another would be for the compiler to
create a local variable for the instance and possibly the class and
fill them in at instantiation time. Both of these require fixing the
names "self" and "cls" so the compiler knows what to do with them. The
first would require giving these two names their own bytecodes, the
second makes them simple local variables the same as the ones in the
method headers. The latter also allows them to be changed by the
method, which is probably not the world's best programming practice
although it's possible now.

John Roth


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

Re: Why do class methods always need 'self' as the first parameter?

[John Roth]

On Sep 2, 2:30 pm, Ian Kelly  wrote:
> On Fri, Sep 2, 2011 at 11:51 AM, John Roth  wrote:
> >> I don't see how you could get rid of the wrappers.  Methods would
> >> still need to be bound, somehow, so that code like this will work:
>
> >> methods = {}
> >> for obj in objs:
> >>     if obj.is_flagged:
> >>         methods[obj.user_id] = obj.do_work
> >>     else:
> >>         methods[obj.user_id] = obj.do_other_work
> >> # ...
> >> methods[some_user_id]()
>
> >> Without method wrappers, how does the interpreter figure out which
> >> instance is bound to the method being called?
>
> >> Cheers,
> >> Ian
>
> > Good question.
>
> > Currently the instance wrapper is created during method instantiation,
> > so the instance is obviously available at that point. There are two
> > rather obvious ways of remembering it. One is to use the invocation
> > stack, which has the instance. Another would be for the compiler to
> > create a local variable for the instance and possibly the class and
> > fill them in at instantiation time. Both of these require fixing the
> > names "self" and "cls" so the compiler knows what to do with them. The
> > first would require giving these two names their own bytecodes, the
> > second makes them simple local variables the same as the ones in the
> > method headers. The latter also allows them to be changed by the
> > method, which is probably not the world's best programming practice
> > although it's possible now.
>
> That's not what I asked.  Both of those options are storing the
> instance within a stack frame, once it's been called.  I'm asking how
> you would remember the instance during the interval from the time when
> the method
> is accessed until when it has been called.
>
> In the code above, the method is accessed just before it is stored in
> the dictionary.  That is when the method wrapper is currently created,
> and the instance is available.  It is not called until much later,
> possibly not even within the same function.  How would you remember
> the instance over that period without wrapping the function?
>
> Cheers,
> Ian

I see what you're saying now - I didn't get your example the first
time. So the optimization of eliminating the instance wrapper is only
possible if it's retrieved via the instance and then called
immediately. That would seem to be a useful optimization if it was
possible - I wonder if PyPy is doing it since they've got that fancy
JIT, and it would seem that an immediate call after retrieving the
method is overwhelmingly more frequent than saving it for later.

I think it's still true that calling the underlying function object
through the instance wrapper requires remaking the parameter list,
which seems to be another piece of unnecessary overhead, unless
there's a fast path through the call machinery that treats the
instance specially.

It does, however, decouple the two issues so I can't claim the
optimization as a benefit. Drat.

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

Re: I found some very odd behaviour in Python's very basic types

[John Roth]

On Mar 9, 10:47 pm, Sunjay Varma  wrote:
> For some reason, sub-classing and overwriting a built-in type does not
> change the behavior of the literal. Logically speaking, overwriting a
> name, such as str, should delete the basic str type, and replace it
> with the new class or object put in its place. For some reason though,
> even though the interpreter says that str == type("hello"),
> overwriting the str name changes nothing in the literal. Is this a
> bug? I'm not sure.
>
> -Sunjay03

This is neither a bug nor a feature, it's simply the way that
Python works. Literals are handled during compilation; the built-in
types are run-time objects.

Python is not a language where a script can change compile-time
behavior. Doing that would make it a very different language, and
would put it into a very different niche in the language ecology.

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

Re: side by side python

[John Roth]

On Mar 21, 6:31 am, Robert  wrote:
> Can I install Python 2.7 and 3.2 (from python.org) side by side on OSX
> without them stepping all over each other?

Also look at PEP 394. It makes some suggestions about installing
symbolic links to each of the versions. If you do it that way, you can
use Python2 for scripts that require 2.7, and Python3 for scripts that
require 3.2, and they'll eventually be portable to other systems.

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

Re: running Python2 Python3 parallel concurrent

[John Roth]

On Mar 30, 7:05 pm, harrismh777  wrote:
> Greetings,
>
>      The purpose of this communique is to document a process for
> installing python2.7.1 in parallel with python3.2 on a concurrent
> desktop with independent idle and python path structure.
>
> ...
>
>      Kind regards,
>
>      m harris
>
>  python2-python3-parallel.txt
> 7KViewDownload

You might want to look at PEP 394, which is tentatively scheduled for
Python 3.3 and the next maintenance release of 2.7. As far as I can
tell, this pretty much solves the problem for Unixoid and MacOS
systems. PEP 397 is a first cut at doing the same thing for Windows.

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

Re: Feature suggestion -- return if true

[John Roth]

On Apr 12, 12:58 am, Paul Rubin  wrote:
> zildjohn01  writes:
> >     _temp = expr
> >     if _temp: return _temp
>
> I'm trying to figure out a context where you'd even want that, and I'm
> thinking that maybe it's some version of a repeat-until loop?  Python
> doesn't have repeat-until and it's been proposed a few times.

I've wanted that a few times, frequently in a situation where I'm
doing validity checking, and I either want to continue after calling a
validity check or return immediately with some kind of error object.
For example:

returnif self.isitaboojum(snark)

This works nicely if the checking routine either returns False or an
error object.

It also works if the method is doing some kind of a ladder evaluation
of several distinct conditions, and it wants to return the first one
it finds.

Also, I wouldn't want a returnif in a loop. Following on with this
idea, loop control would be more of a breakif or continueif statement.

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

Re: vertical ordering of functions

[John Roth]

On May 3, 4:08 pm, Jabba Laci  wrote:
> Hi,
>
> I'm just reading Robert M. Martin's book entitled "Clean Code". In Ch.
> 5 he says that a function that is called should be below a function
> that does the calling. This creates a nice flow down from top to
> bottom.
> However, when I write a Python script I do just the opposite. I start
> with the lines
>
> if __name__ == "__main__":
>     main()
>
> Then I add main() above, which is a control function that contains
> some function calls that decompose the problem into subproblems. Then
> I add these functions above, etc.
>
> Is there a convention for this? Should main() be at the top and called
> function below?
>
> Thanks,
>
> Laszlo

I order classes and methods as I'd expect someone approaching the
program for the first time to want to read it. I think Robert Martin's
recommendation of use before declaration makes it easier to read a
program for the first time. Some compilers require declaration before
use because they need to see the declaration before they see any uses.
Python is in between: you can treat Python as if the order you write
things doesn't matter, but there are cases where it really does
matter. When it does, you have to have the definition before the use.

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

Re: How can engineers not understand source-code control? (was: The Industry choice)

[John Roth]

In article <[EMAIL PROTECTED]>,
Mark Carter  <[EMAIL PROTECTED]> wrote:
.
.
.
Don't start me! Dammit, too late ...
...
Honestly, I thought (real) engineers were supposed to be clever.
You might want to read this:
http://alistair.cockburn.us/crystal/articles/teoseatsoecg/theendofsoftwareengineering.htm
His thesis is very simple: engineering took a wrong turn after
WW II, and the people who coined the term "software engineering"
didn't have a clue.
Of course, he puts it a bit more diplomatically, but he's
got the data to demonstrate that software engineering
is an oxymoron.
John Roth
--
http://mail.python.org/mailman/listinfo/python-list

Optional Static Typing: Part II

[John Roth]

Guido has posted a second blog entry on the optional static typing 
initiative.
I like this a lot better than the first.

http://www.artima.com/weblogs/viewpost.jsp?thread=86641
Now, the base objective seems to be to incorporate PyChecker
functionality into the root. This in turn requires type inference,
which in turn strongly suggests type annotations to help the
inferencer out over rough spots.
I like this approach a lot.
There's also an explicit recognition that there are a lot of
use cases for being able to access type information at
run time.
I also like this. I'm kind of neutral to the idea of using it
for actual type checking: I don't think that it catches that
many errors if the developer is doing a decent job of
testing. However, since it's going to be supplemental to
type inference, it will be a lot less intrusive.
There's a new approach to interfaces that looks
intriguing. One nice part is the ability to include
Design By Contract type preconditions with the
interface. It will be even better if they can be checked
at compile time, or by the PyChecker functionality.
I have to say this turned my attitude around on the
subject: I'm quite in favor of the direction Guido
seems to be going.
John Roth
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[John Roth]

"Paul Rubin" <http://[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
"alex23" <[EMAIL PROTECTED]> writes:

It's called "having an opinion". "Good" documentation does its job, if
noone else thought it was poorly documented then to them it wasn't.
...


In short: grow up and just write the damn documentation.
I've been reading this thread and quietly congratulating myself
on staying out of it, but this statement takes the cake.
I would like to contribute some documentation to Python.
I've got the time, I write quite a bit, etc. I've got fairly
strong opinions about some things that need to be documented,
(such as all the new style class descriptor stuff from 2.2)
and I have relatively little difficulty matching the existing style.
However, I don't
know TEX, Latex, CVS or Sourceforge. (The latter two are
on my "learn sometime soon so I can put PyFIT where it belongs"
list.)
I have no desire to install Perl to run the documentation toolchain.
I also have no particular desire to write up a bunch of final
format stuff and drop it on someone else to put into the latex
format so it can be included.
That means I'm not going to spend literally months learning
all of this stuff so I can then spend the two or three days
(each) it would take to write decent documentation for the
places I think are lacking, and where I have the
competence to write it up.
I'm also not going to spend those same months writing
a current source to XML translator, and then writing
XSLT or more scripts to do the translations to final
format, a strategy which would arguably be much more
beneficial for the Python community as a whole.
The bottom line is that I'm not going to be writing any
extensive pieces of Python documentation. My time
is better spent elsewhere.
John Roth 

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

Re: Python Operating System???

[John Roth]

"David Brown" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Hello. I recently came across a free operating system called Unununium (or
something like that) and it was developed in Python and Assembly.
Now, I have been looking for a way to make an operating system for a long
long time and the only possibilities I could find were C++ and assembly. I
don't mind assembly so much if I don't have to use it very often. But C++ 
is
so complicated and errors are pretty much impossible to find in the code 
for
me.

So, I was wondering if it would be possible to find a bootloader that 
loads
a python file at startup or something...

Is there an example somewhere of a Python OS?
As far as I know, there's no working example. Unununium is still
very early development, and it's going off in a quite interesting
direction that is hardly standard.
Writing an operating system is a lot of work. The approach I'd
take would be to start out with an existing micro-kernel and
enhance it with a kernel level Python system so that you wouldn't
need any C or Asm level code in a typical process.
Then I'd pursue a restricted subset of Python that could be
compiled directly to machine code, and start recoding the
various C and Asm parts in that. See the PyPy project for
the direction they're taking for writing the Python system in
Python.
Have fun with the project!
John Roth

Thanks!

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

Re: Getting rid of "self."

[John Roth]

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

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

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

Re: Getting rid of "self."

[John Roth]

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

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

Re: "A Fundamental Turn Toward Concurrency in Software"

[John Roth]

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

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

Re: "A Fundamental Turn Toward Concurrency in Software"

[John Roth]

"Donn Cave" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Quoth Skip Montanaro <[EMAIL PROTECTED]>:
|
| Jp> How often do you run 4 processes that are all bottlenecked on 
CPU?
|
| In scientific computing I suspect this happens rather frequently.

I think he was trying to say more or less the same thing - responding
to "(IBM mainframes) ... All those systems ran multiple programs ...
My current system has 42 processes running ...", his point was that
however many processes on your desktop, on the rare occasion that
your CPU is pegged, it will be 1 process.  The process structure of
a system workload doesn't make it naturally take advantage of SMP.
So "there will still need to be language innovations" etc. -- to
accommodate scientific computing or whatever.  Your 4 processes are
most likely not a natural architecture for the task at hand, but
rather a complication introduced specifically to exploit SMP.
Exactly. I wasn't addressing some of the known  areas where one
can take advantage of multiple processors, or where one can take
advantage of threading on a single processor to avoid delays.
At this point in time, though, I see multithreading for compute
intensive tasks to be an intermediate step. The final step is to
restructure it so it can take advantage of cluster architectures.
Then you can simply ignore all of the complexity of threads.
That still leaves putting long running tasks (such as printing)
into the background so the UI stays responsive.
Personally I wouldn't care to predict anything here.  For all I know,
someday we may decide that we need cooler and more efficient computers
more than we need faster ones.
Chuckle. I basically think of shared memory multiprocessing
as being perverse: the bottleneck is memory, not compute
speed, so adding more processors accessing the same memory
doesn't strike me as exactly sane. Nor does pushing compute
speed up and up and up when it just stressed the memory
bottleneck.
Donn Cave, [EMAIL PROTECTED] 
--
http://mail.python.org/mailman/listinfo/python-list

Re: "A Fundamental Turn Toward Concurrency in Software"

[John Roth]

"Peter Hansen" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
John Roth wrote:
I have yet to write a multi-thread program for performance reasons.
If we include in the set of things covered by the term
"performance" not only throughput, but also latency, then
I suspect you actually have written some multithreaded programs
for "performance" reasons.
*I* certainly have: that's easily the reason for threading
in 95% of the cases I've dealt with, and I suspect those of
many others.
Actually, I've never written a multi-threaded program for
any reason. There were only two times I had to deal with concurrency:
one was a very nice co-routine implementation (HASP,
the predecessor to the JES2 subsystem on MVS), and
the other was event driven (on an IBM SP). The former
system didn't have a threading library, let alone a lightweight
one, and the event driven design was a lot simpler for the
second application - and I did consider all three options.
John Roth
-Peter 
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python Operating System???

[John Roth]

"Bengt Richter" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
On Sat, 08 Jan 2005 12:47:52 -0500, Peter Hansen <[EMAIL PROTECTED]> 
wrote:

Paul Rubin wrote:
When Unix was first written, people thought implementing an OS in C
was ludicrous.  Everyone knew OS's had to be written in assembler.
Actually, when Unix was first written that belief was entirely
correct, and OSes *did* have to be written in assembler.
That is, pure C did not have the capability to handle all
that was required.  I recall it taking a good decade before it
became *common* to find C compilers with, for example, @interrupt
support to let the compiler generate code that properly saved
all registers and used RTI instead of RTS (or whatever it might
have been called one one's particular flavour of CPU).
Now, once you added a few tiny interrupt handlers, and some context
switching (stack manipulation) routines, pretty much everything else
*could* be done in C, but that doesn't invalidate the point.
I think it's safe to say that none of pure C, pure Lisp, or pure Python
are really capable of being used as the *sole* language to build
an operating system.
It's also safe to say that this is a largely irrelevant point.
It would probably only be of academic interest to try to do
something like that.  Any practical attempt would not think more
than twice of resorting to a little "glue" in assembler or in
the form of "canned" byte sequences built by hand and stuck
into the appropriate places in memory...
Well, usually there's more than one tool in the chain from source
to bootable loader and OS image, even if you are writing in C and 
assembler,
and there's usually more to an OS than the bootable image contains.

So ISTM "writing an OS in " is pretty loose talk ;-)
Most people who work in the field know what it means, though.
One of the touchstones of language design is whether you can
write the compiler and runtime in that language. PyPy is working
on that for Python, Squeak Smalltalk is written in Smalltalk and
then converted to C for compilation of the runtime. Both of them
are completely virtualizable: you can run them (very slowly) under
themselves for testing.
Given that everything in Python is an object, I see no reason
why one couldn't create a set of objects that are appropriate
for an operating system kernel and can also be converted
cleanly to the operating system subset of C, and write a converter
that does it.
That's the easy part. The hard part is writing the operating
system. Look at the (lack of) progress the GNU HURD
project has been making recently.
John Roth

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

Re: Python Operating System???

[John Roth]

"jtauber" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
My experiment, Cleese, was making progress before I got distracted by
other things.
The approach was a micro-kernel in C made up of the CPython bytecode
interpreter with the file-related calls to libc ripped out and some
bare-metal port read/writes and memory operations exposed to Python as
built-in functions.
Everything else could then be written in pure Python. Dave Long was
able to write a VGA driver in Python and an implementation of Sokoban
that used it. You could then boot your machine to Sokoban :-)
I should probably get back to it at some stage.
As my ex-wife was fond of saying, "I wish you'd have
told me it was impossible before I did it."
John Roth
see http://cleese.sourceforge.net/
James Tauber
http://jtauber.com/blog/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Getting rid of "self."

[John Roth]

"Alex Martelli" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
I think it would be cool if you could refer to instance variables
without prefixing with "self." I know noone else thinks like me so
Some do -- Kent Beck's excellent book on TDD-by-example has a specific
grouse against that in the chapter where he develops the unittest module
(in Python).  But that's how comes Kent is a _Smalltalk_ programmer
rather than a _Python_ programmer, see?-)
And of course, the reason it's possible in Smalltalk but not in Python
is that Smalltalk requires the declaration of instance variables. Also
Smalltalk does not have things like module variables and builtins.
The interpreter knows exactly what every name references, which
isn't true in Python.
John Roth

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

Re: Python3: on removing map, reduce, filter

[John Roth]

"Andrey Tatarinov" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Hi.
How does GvR suggestions on removing map(), reduce(), filter() correlate 
with the following that he wrote himself (afaik):

http://www.python.org/doc/essays/list2str.html
This is fairly old. Note that the fastest version
uses the array module, and is quite comprehensible -
if you know the array module and how it works.
It doesn't use the map function.
John Roth
? 
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python & unicode

[John Roth]

It doesn't work because Python scripts
must be in ASCII except for the
contents of string literals. Having a function
name in anything but ASCII isn't
supported.
John Roth
"Michel Claveau - abstraction mÃta-galactique non triviale en fuite 
perpÃtuelle." <[EMAIL PROTECTED]> wrote in 
message news:[EMAIL PROTECTED]
Hi !

If  Python is Ok with Unicode, why the next script not run ?
# -*- coding: utf-8 -*-
def Ñ(toto):
   return(toto*3)
aret = Ñ(4)




@-salutations
--
Michel Claveau

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

Re: why are people still using classic classes?

[John Roth]

"Simon Wittber" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
I've noticed that a few ASPN cookbook recipes, which are recent
additions, use classic classes.
I've also noticed classic classes are used in many places in the
standard library.
I've been using new-style classes since Python 2.2, and am suprised
people are still using the classic classes.
Is there a legitimate use for classic classes that I am not aware of?
Is there a project to specifically migrate standard library classes to
new-style classes?
Part of it is simply that it's a bit easier: you don't have to
inherit from object.
AFAIK, there's no project to migrate the standard library, and I'm
not at all sure that would be a good idea since existing programs
that asssume classic class behavior would be affected when
classes they inherited from suddenly changed.
Classic classes will go away sometime in the future, currently
planned for the semi-mythical 3.0 release.
John Roth
Sw. 
--
http://mail.python.org/mailman/listinfo/python-list

Re: dynamically inserting function into an object

[John Roth]

If what you want is to insert a method into an
instance, look at new.instancemethod.
John Roth
"michael" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Hi,
below is a snipplet that could be seen as a part of a spreadsheet with
getter and setter properties and a way how to dynamically insert
function to be used when setting the value of a "cell" instance
import new
import inspect
class Cell (object):
   def __init__ (self, initialvalue = 0):
   self._func = None
   self.__value = initialvalue
   def setvalue (self, newvalue):
   if self._func:
   self.__value = self._recalculate (newvalue)
   else:
   self.__value = newvalue
   def getvalue (self):
   return self.__value
   def _recalculate (self, value):
   ret_value = self._func (value)
   return ret_value
   def delvalue (self):
   del self.__value
   value = property(getvalue, setvalue, delvalue, "I'm the 'value'
property.")
   def curry(self, func, *args):
   self._func =  new.function(func.func_code, func.func_globals,
argdefs=args)
   func = property(curry, "I'm the 'func' property.")
def func (value, firstcell, secondcell):
   return value + firstcell.value + secondcell.value
cell0 = Cell (10)
cell1 = Cell (20)
curriedcell = Cell (100)
print "uncurried initial %d " % (curriedcell.value)
curriedcell.value = 60
print "uncurried set %d " % (curriedcell.value)
curriedcell.curry (func, cell0, cell1)
curriedcell.value = 62
print "curried set %d " % (curriedcell.value)

Is there a better way to do this or am I totally on the wrong way ?
Regards
Michael 
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 2.3.4 for windows: float("NaN") throws exception

[John Roth]

<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Hi
my python 2.3.4 for windows refuse to execute line float("NaN"). It
says:
float("NaN")
Traceback (most recent call last):
File "", line 1, in ?
ValueError: invalid literal for float(): NaN
The same line works as expected on Linux and Solaris with python 2.3.4.
Could anybody explain what is possibly wrong here? is it bug or
feature?
Andrei
As others have gently tiptoed around, it's basically
the lack of a group of enthusiastic and dedicated
volunteers to make it happen.
Nobody is really happy with the current situation,
but Python is a volunteer effort, and the current
set of volunteers isn't really motivated to put in
a very large amount of work on something that
they think would have relatively little benefit.
In other words, if someone wants to dig in and
do the work, I'm sure the core developers will
look at it favorably - as long as it meets the
usual standards for core development, including
documentation and maintainability.
The bar is lower than it has ever been, by the
way. It used to be: It has to work the same way
on all supported platforms. Now it's just: it has
to work the same on the core platforms, and
if anyone else really wants to work on the others,
more power to them.
John Roth


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

Re: (objects as) mutable dictionary keys

[John Roth]

"Peter Maas" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
I have summarized the discussion about the usability of lists (and
and other mutable types) as dictionary keys and put it into the
Python wiki.URL: http://www.python.org/moin/DictionaryKeys.
This summary might be used as a reference should the 'mutable
dictionary keys' issue come up again in c.l.py.
The last piece has an incorrect conclusion. Lists are not safe
_because_ the cmp function is NOT a compare of id(list), but
is based on list contents, which can change at any time.
It should also be emphasized that the default instance hash
and cmp functions quoted make it impossible for two different
instances to compare equal, thus there is no reason to store them
as dictionary keys: it's simpler to make the value an attribute of
the instance and bypass the additional complexity of the dictionary.
John Roth
--
---
Peter Maas,  M+R Infosysteme,  D-52070 Aachen,  Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
---
--
http://mail.python.org/mailman/listinfo/python-list

Re: PyChecker messages

[John Roth]

"Ben Sizer" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
But you could use a dict of return values, or even just assigning a
different return value in each if clause. The end result is that you
have a single well-defined exit point from the function, which is
generally considered to be preferable.
Preferable, but not any form of an absolute. "Single Exit"
was one of the recommendations from the early structured
program work back in the 70s, and the industry has long
since sent it to the dustbin of history.
The issue is a simple one of clarity, and woodenly applying
the single exit rule where it doesn't belong frequently
winds up creating nested if-elif-else structures and extranious
flag variables.
If an embedded return isn't clear, the method probably
needs to be refactored with "extract method" a few
times until it is clear.
John Roth

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

Re: Assigning to self

[John Roth]

"Frans Englich" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Hello,
[...]
What the code attempts to do is implementing a, to the API user, 
transparent
memory-saver by ensuring that no more than one instance of the class foo
exists for a particular id. E.g, the user can simply "create" an instance 
and
if one not already exists, it is created.
In other words, you're trying to create a singleton. In general,
singletons are frowned on these days for a number of reasons,
not least because of the difficulty of testing them.
First of all; am I approaching the goal with the right solution?
No. In all Python releases since 2.2, the correct way of doing this is to
use the __new__() method. Unfortunately, the only place it is documented
is here:
http://www.python.org/2.2.3/descrintro.html
and here:
http://users.rcn.com/python/download/Descriptor.htm
The first reference contains an example of how to do
a singleton: simply search on the word Singleton.
John Roth
Cheers,
Frans


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

Re: Assigning to self

[John Roth]

"Frans Englich" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
On Monday 17 January 2005 20:03, John Roth wrote:
"Frans Englich" <[EMAIL PROTECTED]> wrote in message

In other words, you're trying to create a singleton. In general,
singletons are frowned on these days for a number of reasons,
not least because of the difficulty of testing them.
Then I have some vague, general questions which perhaps someone can reason
from: what is then the preferred methods for solving problems which 
requires
Singletons? Is it only frowned upon in Python code?
I don't know of any generic methods that will work in all
cases _and_ are easy to apply. There are really two issues:
testing and abuse of the pattern.
There really are some places where you want a single instance
of something that is globally visible. Things that leap immediately
to mind include the connection to a data base and a logger
facility.
However, in a lot of cases, you find singletons used as an
"object oriented" substitute for a global variable, which stinks
just as badly as a global would. Since Python is a multi-paradigm
language, just put in a global at the module level. It's clearer.
Otherwise redesign.
There are several ways of getting around the testing
difficulty. One is the "toolbox" pattern that appears in a
number of places. The idea there is to have a single
object that proxies all of the singletons so that they
can be replace by testing versions at initialization time.
A neater and more modern method is to use an IOC
(Inversion of Control) container, or at least the pattern
involved. All IOC containers I'm aware of support
singletons and make testing them almost trivially
easy.
A third way is to simply take advantage of Python's
dynamic nature and have your tests stuff the testing
instance into the class object before the first call. This
is an ad-hoc variation on the IOC principle.
HTH
John Roth

Cheers,
Frans
--
http://mail.python.org/mailman/listinfo/python-list

Re: Fuzzy matching of postal addresses

[John Roth]

"Andrew McLean" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
I have a problem that is suspect isn't unusual and I'm looking to see if 
there is any code available to help. I've Googled without success.
There isn't any publically availible code that I'm aware of.
Companies that do a good job of address matching regard
that code as a competitive advantage on a par with the
crown jewels.
Basically, I have two databases containing lists of postal addresses and 
need to look for matching addresses in the two databases. More precisely, 
for each address in database A I want to find a single matching address in 
database B.

I'm 90% of the way there, in the sense that I have a simplistic approach 
that matches 90% of the addresses in database A. But the extra cases could 
be a pain to deal with!

From a purely pragmatic viewpoint, is this a one-off, and how many
non-matches do you have to deal with? If the answers are yes,
and not all that many, I'd do the rest by hand.
It's probably not relevant, but I'm using ZODB to store the databases.
I doubt if it's relevant.
The current approach is to loop over addresses in database A. I then 
identify all addresses in database B that share the same postal code 
(typically less than 50). The database has a mapping that lets me do this 
efficiently. Then I look for 'good' matches. If there is exactly one I 
declare a success. This isn't as efficient as it could be, it's O(n^2) for 
each postcode, because I end up comparing all possible pairs. But it's 
fast enough for my application.

The problem is looking for good matches. I currently normalise the 
addresses to ignore some irrelevant issues like case and punctuation, but 
there are other issues.
I used to work on a system that had a reasonably decent address
matching routine. The critical issue is, as you suspected, normalization.
You're not going far enough. You've also got an issue here that doesn't
exist in the States - named buildings.
Here are just some examples where the software didn't declare a match:
1 Brantwood, BEAMINSTER, DORSET, DT8 3SS
THE BEECHES 1, BRANTWOOD, BEAMINSTER, DORSET DT8 3SS
The first line is a street address, the second is a named building and a 
street
without a house number. There's no way of matching this unless you know
that The Beaches doesn't have flat (or room, etc.) numbers and can move the
1 to being the street address. On the other hand, this seems to be a
consistent problem in your data base - in the US, the street address must
be associated with the street name. No comma is allowed between the two.

Flat 2, Bethany House, Broadwindsor Road, BEAMINSTER, DORSET, DT8 3PP
2, BETHANY HOUSE, BEAMINSTER, DORSET DT8 3PP
The first is a flat, house name and street name, the second is a number
and a house name. Assuming that UK postal standards don't allow
more than one named building in a postal code, this is easily matchable
if you do a good job of normalization.
Penthouse,Old Vicarage, 1 Clay Lane, BEAMINSTER, DORSET, DT8 3BU
PENTHOUSE FLAT THE OLD VICARAGE 1, CLAY LANE, BEAMINSTER, DORSET DT8 3BU
The issue here is to use the words "flat" and "the" to split the flat
name and the house name. Then the house number is in the wrong
part - it shoud go with the street name. See the comment above.
St John's Presbytery, Shortmoor, BEAMINSTER, DORSET, DT8 3EL
THE PRESBYTERY, SHORTMOOR, BEAMINSTER, DORSET DT8 3EL
This one may not be resolvable, unless there is only one house name
with "presbytery" in it within the postal code. Notice that "the" should
probably be dropped when normalizing.
The Pinnacles, White Sheet Hill, BEAMINSTER, DORSET, DT8 3SF
PINNACLES, WHITESHEET HILL, BEAMINSTER, DORSET DT8 3SF
Spelling correction needed.
The challenge is to fix some of the false negatives above without 
introducing false positives!

Any pointers gratefully received.
If, on the other hand, this is a repeating problem that's simply going
to be an ongoing headache, I'd look into commercial address correction
software. Here in the US, there are a number of vendors that have
such software to correct addresses to the standards of the USPS.
They also have data bases of all the legitimate addresses in each
postal code. They're adjuncts of mass mailers, and they exist
because the USPS gives a mass mailing discount based on the
number of "good" addresses you give them.
I don't know what the situation is in the UK, but I'd be surprised
if there wasn't some availible address data base, either commercial
or free, possibly as an adjunct of the postal service.
The later, by the way, is probably the first place I'd look. The
postal service has a major interest in having addresses that they
can deliver without a lot of hassle.
Another place is google. The first two pages using "Address
Matching software" gave two UK references, and several
Australian references.
John Roth
--
Andrew McLean 
--
http://mail.python.org/mailman/listinfo/python-list

Re: Fuzzy matching of postal addresses

[John Roth]

"Andrew McLean" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Thanks for all the suggestions. There were some really useful pointers.
A few random points:
1. Spending money is not an option, this is a 'volunteer' project. I'll 
try out some of the ideas over the weekend.

2. Someone commented that the data was suspiciously good quality. The data 
sources are both ones that you might expect to be authoritative. If you 
use as a metric, having a correctly formatted and valid postcode, in one 
database 100% the records do in the other 99.96% do.

3. I've already noticed duplicate addresses in one of the databases.
4. You need to be careful doing an endswith search. It was actually my 
first approach to the house name issue. The problem is you end up matching 
"12 Acacia Avenue, ..." with "2 Acacia Avenue, ...".

I am tempted to try an approach based on splitting the address into a 
sequence of normalised tokens. Then work with a metric based on the 
differences between the sequences. The simple case would look at deleting 
tokens and perhaps concatenating tokens to make a match.
It's been a while since I did this stuff. The trick in dealing
with address normalization is to parse the string backwards,
and try to slot the pieces into the general pattern.
In your case, the postal code,  district (is that what it's called
in the UK?) and city seem to be fine, it's when you get to the
street (with or without house number), building name and flat
or room number that there's a difficulty.
We always had a list of keywords that could be trusted
to be delimiters. In your examples, "the" should be pretty
reliable in indicating a building name. Of course, that might
have some trouble with Tottering on the Brink.
John Roth
--
Andrew McLean 
--
http://mail.python.org/mailman/listinfo/python-list

Re: QOTW from Ryan Tomayko

[John Roth]

"Robert Brewer" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
http://naeblis.cx/rtomayko/2005/01/20/getters-setters-fuxors

"...Many people coming to Python can't believe no one uses IDEs. The
automatic assumption is that Python is for old grey beards who are
comfortable with vi and Emacs and refuse to accept breakthroughs in
programming productivity like IDEs. Then they write a little Python code
and realize that an IDE would just get in their way."
FuManChu
[response]
It's also not true. Lots of people use IDEs - look at the
number of Python IDEs out there, and the number of
attempts (some of them reasonable) to add Python
support to Eclipse.
The thing is, there are relatively fewer programming
tools needed to work with Python than there are
for Java, for example, so the available IDEs are much
simpler.
Line oriented editors are an acquired taste, and they
are one I've never acquired regardless of the environment.
I've used both edit under TSO and vi on a timesharing
arrangement with an AIX system, and both of them suck
compared to the screen editors available.
John Roth 

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

Re: Next step after pychecker

[John Roth]

"Sylvain Thenault" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
On Tue, 01 Feb 2005 05:18:12 +0100, Philippe Fremy wrote:
Did you take a look at the starkiller [1] and pypy projects [2] ?
Has anything happened to Starkiller since PyCon 2004? The
latest mention I can find on Google is a blog entry (by Ted
Leung) on Aug 30 saying he wished someone would give the
author some money to finish it and publish it.
John Roth
--
http://mail.python.org/mailman/listinfo/python-list

Re: Integrated Testing - Peppable?

[John Roth]

<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Hi,
Please excuse the intrusion from an admirer, but not a user, of Python.
I've got an idea that I think could improve the language and might be
relatively simple to implement.  I've developed a prototype with a toy
language here: <https://sourceforge.net/projects/zbt/>, with screenshot
here: <https://sourceforge.net/project/screenshots.php?group_id=130278>
The idea is that if the language had testing built into it, editors
could take advantage of that to highlight, not by syntax, but by
correctness (as defined by the tests).  As a side effect, coverage
coloring is also possible.
So far, I see the need for three keywords: "expect", "returns", and
"archetype".  "expect" and "returns" get used together, as an
expression of what the function should return, given certain inputs.
"archetype" would define edit-type instantiable objects that could be
used in the tests.  The biggest lack at present is support for void
functions.
So...  Should I turn this into a PEP?
I'd say no, for a couple of reasons. One is that there
are Eclipse plugins that do this for JUnit; they don't
require any changes to Java in order to function. They
just require JUnit, which is pretty ubuquitous.
Second, is that the IDEs aren't part of Python proper.
Outside of that, it's might be quite a good idea to
do something similar with unittest, doctest or py.test.
John Roth
Peace,
--Carl
--
http://mail.python.org/mailman/listinfo/python-list

Re: Extreme Python

[John Roth]

Sigh. Another mailing list to
subscribe to. Why do we
need this? Especially why do
we need it at Google?
I'd rather not Balkanize things and
keep the XP and Python issues away
from the two lists involved. If there are
Python specific issues, they're
quite welcome on either this list/newsgroup
or on the regular extremeprogramming
list.
John Roth
PyFIT maintainer.
Extremeprogramming mailing list moderator (1 of 7)
<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Hello all,
I've created a web/email group for topics related to both Extreme
Programming (or other Agile methodologies) and Python. If you're
interested, please visit
http://groups-beta.google.com/group/extreme-python/ and subscribe. Or
just post directly to [EMAIL PROTECTED] Hope to see you
there!
Troy Frever
Extreme Programmer and Coach
Aviarc Corporation
--
http://mail.python.org/mailman/listinfo/python-list

See Pep 294. was: Re: Why is there no instancemethod builtin?

[John Roth]

"Michael Hoffman" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> John Roth wrote:
>
>> you need _both_ isinstance and the types  module to do a correct
>> check for any string type: isinstance(fubar, types.StringTypes).
>> That's because both string and unicode are subtypes of one base.
>
> But basestring, their base class is a built-in.

True, but that wasn't the question.

However, to add a bit of sanity to this thread, please consider
that PEP 294 is still open - it survived the recent spate of PEP
rejections and closings. It suggests extending the types module
to include all types, including those in the new module (which the
OP seems to have overlooked,) and then depreciating the new
module.

John Roth


> -- 
> Michael Hoffman 

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

See Pep 315. was: Re: Loop until condition is true

[John Roth]

See Pep 315, which is still open, and targeted at 2.5.
It survived the recent spate of PEP closings and rejections.

http://www.python.org/peps/pep-0315.html

John Roth

"Remi Villatel" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Hi there,
>
> There is always a "nice" way to do things in Python but this time I can't 
> find one.
>
> What I'm trying to achieve is a conditionnal loop of which the condition 
> test would be done at the end so the loop is executed at least once. It's 
> some way the opposite of "while".
>
> So far, all I got is:
>
> while True:
> some(code)
> if final_condition is True:
> break
> #
> #
>
> What I don't find so "nice" is to have to build an infinite loop only to 
> break it.
>
> Is there a better recipe?
>
> -- 
> ==
> Remi Villatel
> [EMAIL PROTECTED]
> == 

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

Re: Why is there no instancemethod builtin?

[John Roth]

"George Sakkis" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Michele Simionato wrote:
>> I think strings do not have __iter__ on purpose, exactly to distinguish
>> them from other iterables, since sometimes it is nice to consider them
>> atomic, but I am not sure of this. You should ask the developers. Anyway, 
>> the
>> right definition of iterable is (as I was told) "an object X such that
>> iter(X) does not throw an exception".
>
> Hmm.. not a very insightful definition unless someone knows the
> implementation of iter().
>
>> Objects following the __getitem__ protocol - such as strings - are 
>> iterables
>> even if they do not have an __iter__ method.
>
> It would be more uniform if the default 'type' metaclass added an
> __iter__ method to classes that define __getitem__ but not __iter__
> with something like:
>
> from itertools import count
>
> def __iter__(self):
>for i in count():
>try: yield self[i]
>except IndexError: raise StopIteration

Unfortunately it doesn't work: getitem can be defined for
a class that acts like a dictionary: that is, the items are
not integers, let alone integers that extend in a strict
sequence from 0.

John Roth

>
> George
> 

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

Re: Using print with format to stdout generates unwanted space

[John Roth]

Don't use print, write directly to sys.stdout.
Print is not intended for precise output formatting;
it's intended for quick outputs that are useable
most of the time.

John Roth


"Paul Watson" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> #!/usr/bin/env python
>
> #   Using a print statement to stdout results in an
> #   unwanted space character being generated at the
> #   end of each print output.  Same results on
> #   DOS/Windows and AIX.
> #
> #   I need precise control over the bytes that are
> #   produced.  Why is print doing this?
> #
> import sys
>
> #   If this is a DOS/Windows platform, then put stdout
> #   into binary mode so that only the UNIX compatible newline
> #   will be generated.
> #
> try:
>import msvcrt, os
>msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY)
> except:
>print 'This is not an msvcrt platform.'
>pass
>
> #   Using print with newline suppressed generates a space at the
> #   end of each print statement.
> #
> for i in range(3):
>print '%d,60,' % (i),
>for j in range(10):
>print '%d,' % (j),
>print ''
>
> #   Using a list and doing a join does not result in the space
> #   character being generated.
> #
> for i in range(3):
>alist = []
>alist.append('%d,60,' % (i))
>for j in range(10):
>alist.append('%d,' % (j))
>print ''.join(alist)
>
> sys.exit(0)
> 

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

Re: need to strip stuff off email

[John Roth]

"nephish" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> hey there,
> i have a script that retrieves my email, but i need it to
> be able to strip all the stuff off except the body (the message itself)
> so i can later write it to a text file.
>
> anyone know how to accomplish this?
> thanks

See the example at the end of the email package documentation.

John Roth 

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

Re: Does a function like isset() exist in Python?

[John Roth]

I'm not sure what you mean by initialized. If you're asking
if the identifier exists in the namespace, then you can use
hasattr(), or simply try to reference it and catch the exception
if it doesn't exist.

If the identifier exists, it always has a value.

On the other hand, there is a small gotcha on identifiers
in functions/methods where they have to have a value
assigned before you can reference them. If you run into
this at all frequently, you're probably making your methods
too big to be easily understood.

Of course, if you're playing games with the stack and
trying to print out the values of identifiers on the calling
chain on an exception, all bets are off. See the code in
the py.test module (part of the PyPy project) for how
you can do this.

John Roth

"Patrick Fitzsimmons" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Hi,

I'm sure I should know this, but I can't find it in the manual.

Is there a function in Python like the function in PHP isset()?  It
should take a variable name and return True or False depending on
whether the variable is initialized.

Thanks for any help,
Patrick 

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

Re: PEP 304 - is anyone really interested?

[John Roth]

"Patrick Maupin" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Thomas Heller wrote:
>
>> Although I was not interested originally, I think that's
>> a use case I also have.  Optional config files, which
>> should not be compiled to .pyc or .pyo.  Only removing
>> the .py file doesn't have the expected effect
>> if a .pyc and/or .pyo if is left.
>
>
> I also think that if nobody has the same use-case as envisioned by the
> original PEP, we should probably step back and rethink how it should be
> implemented.  The original PEP envisioned the installation of
> third-party .py file libraries without their corresponding .pyc files
> into directories for which the eventual script user had no
> write-access.  As more people become coginzant of the correct way to
> install Python libraries, I think this use-case fades in importance.

See below.

> The key distinction between this older use-case and the currently
> envisioned use-case is that the former assumes third-party code, and
> the latter assumes that the control over .pyc generation is desired by
> the _author_ of some python code, rather than merely the _installer_ of
> some python code.  In this latter case, environment variables are not
> strictly necessary, because the top-level script could do whatever it
> needs to control .pyc generation, from inside Python itself.

Well, after thinking this over, I'm finding a significant problem with
the envisioned mechanism: it specifies a _single_ directory tree that
shadows the source tree. I'd like to suggest a different mechanism,
at least for packages (top level scripts don't generate .pyc files
anyway.) Put a system variable in the __init__.py file. Something
like __obj__ = path would do nicely. Then when Python created
the __init__.pyc file, it would insert a back link __src__ entry.

That way, either the source or the object directory could be
specified in the Pythonpath, the import machinery could then do the
right thing by checking the appropriate directory for the .py and .pyc
files.

I will say that I would personally find it very useful to have the
.py and .pyc (.pyo) files in separate directories for development
work.

>> AFAIK, it is not possible to define empty env vars on Windows.

> You make a good point about null environment variables.  I think the
> original PEP was fairly *nix-centric, both in that aspect, and in the
> aspect of requiring the value of bytecodebase to be the "root" of the
> file system.  This might not have the desired results in all cases on
> Windows.

Actually, the PEP states that if the environment variable does not specify
a directory then it does not generate a .pyc file. Any entry that is not a
directory would do, such as some special characters that are illegal in
file and directory names.

John Roth

>
> Regards,
> Pat
> 

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

Re: Two questions on lambda:

[John Roth]

"Xavier Décoret" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Hi,
>
> I cannot find the way to do generic lambda functions using the lambda 
> syntax in python. I am probably missing a point.

You are. Lambda is restricted to a _single expression_.

Your first example is a statement, not an expression. Your
second example attempts to do an assignment in the body
of a lambda (although that's not what the code actually says)
and assignment is a statement, not an expression.

Lambda is intended for very simple, one line functions. It's
also likely to go away in Python 3.0. Python, for better or
worse, is a multi-paradigm language combining the object
and procedural paradigms. It is not, and it is not intended
to be, a functional style language.

John Roth

>
> For example, the code
>
> # f = lambda : print "hello"
> # f()
>
> does not compile, although:
>
> # def f():
> # print "hello"
> # f()
>
> does compile. Is there a particular syntax for lambda that I am missing or 
> is it simply limited and I cannot do what I want with lambda.
>
> In the same spirit, how can I do to compute intermediary values in the 
> body of a lambda function. Let's say (dummy example):
>
> f = lambda x : y=x*x,y+y
>
>
> In languages like Caml, you can do:
>
> let f = function x -> let y=x*x in y+y;;
>
> Does the lambda : syntax in python allow for the same kind of constructs?
>
> Thanks. 

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

Re: Thoughts on Guido's ITC audio interview

[John Roth]

"Dave Benjamin" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Guido gave a good, long interview, available at IT Conversations, as was
> recently announced by Dr. Dobb's Python-URL! The audio clips are available

[snip]

>  - Java: the usual static vs. dynamic, static analysis vs. unit testing
>arguments. Guido says that there's such a small amount of problems that
>can be caught at compile time, and even the smallest amount of unit
>testing would also catch these problems. "The blindness of that 
> [static]
>position... escapes me."

Three years ago, this was a viable arguement. Two years ago, it was
beginning to show difficulties. Today anyone who makes it can be
accused of having their head in the sand [1].

What's being ignored is that type information is useful for other things
than compile type checking. The major case in point is the way IDEs
such as IntelliJ and Eclipse use type information to do refactoring, code
completion and eventually numerous other things. A Java programmer
using IntelliJ or Eclipse can eliminate the advantage that Python
used to have, and possibly even pull ahead.

The only thing that is even vaguely similar in the Python community
is Bycycle Repair Man, and, to be brutal about it, it sucks in
comparison with what either Eclipse or IntelliJ can do.

I agree with Guido's point later in the interview that type inference
is the way to go, and that it's very difficult to retrofit it to an existing
language. Difficult does not mean impossible though. The place to
start is to go through the standard objects and make sure all return
values make sense.

I'll throw out one very simple example in the string library. The
index() and find() methods, and their variants, suffer from a bad
case of non-obviousness inherited from the C library. A very
simple replacement would fix this.



findall([maxfind,] sub, [start, [end]])

findall returns a list (possibly a tuple) of the beginning index
of each substring which matches sub. If there are no matches,
an empty list is returned. At most maxfind indexes are returned.
start and end have the same meaning as in the existing find and
index methods.



This version works intuitively with if statements (an empty
list is false), goes directly into for statements, can be implemented
as an iterator, and is only less efficient by a constant (creation of
the list) if the maxfind parameter is used. It never throws an
exception (unless the parameter list has the wrong types).
Its an example of a method that can be used cleanly with a
type inferencer, while the index and find methods cannot.

[snip]

John Roth

 [1] I'm well aware that ostritches do not stick their heads in
the sand to avoid looking at distressing things, such as advancing
predators. It is, however, a useful metaphor.

>
> Cheers,
> Dave 

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

Re: Thoughts on Guido's ITC audio interview

[John Roth]

"Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> On Sat, 25 Jun 2005 19:31:20 -0600, John Roth wrote:
>
>>
>> "Dave Benjamin" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> Guido gave a good, long interview, available at IT Conversations, as was
>>> recently announced by Dr. Dobb's Python-URL! The audio clips are 
>>> available
>>
>> [snip]
>>
>>>  - Java: the usual static vs. dynamic, static analysis vs. unit testing
>>>arguments. Guido says that there's such a small amount of problems 
>>> that
>>>can be caught at compile time, and even the smallest amount of unit
>>>testing would also catch these problems. "The blindness of that
>>> [static]
>>>position... escapes me."
>>
>> Three years ago, this was a viable arguement. Two years ago, it was
>> beginning to show difficulties. Today anyone who makes it can be
>> accused of having their head in the sand [1].
>>
>> What's being ignored is that type information is useful for other things
>> than compile type checking. The major case in point is the way IDEs
>> such as IntelliJ and Eclipse use type information to do refactoring, code
>> completion and eventually numerous other things. A Java programmer
>> using IntelliJ or Eclipse can eliminate the advantage that Python
>> used to have, and possibly even pull ahead.
>
> I haven't used IntelliJ or Eclipse, so I guess I'll have to take your word
> for how wonderful they are.

You might want to look at something outside of Python. The world
changes, and if you keep your eyes closed, you might not notice
it changing until it rolls over you.

> [snip]
>> I'll throw out one very simple example in the string library. The
>> index() and find() methods, and their variants, suffer from a bad case
>> of non-obviousness inherited from the C library.
>
> It must be an very bad case of non-obviousness indeed, because it isn't
> obvious to me at all what particular bit of non-obviousness it is that
> you are referring to.

The result of find() cannot be used cleanly in an if statement; you
need to compare it to -1. This is not obvious to a novice, and is
a fertile source of mistakes. It's an irregularity that has to be checked
for.


>
>> A very simple
>> replacement would fix this.
>>
>> 
>>
>> findall([maxfind,] sub, [start, [end]])
>>
>> findall returns a list (possibly a tuple) of the beginning index of each
>> substring which matches sub. If there are no matches, an empty list is
>> returned. At most maxfind indexes are returned. start and end have the
>> same meaning as in the existing find and index methods.
>
> Am I the only one who has reservations about having to build a list of all
> the matches before doing anything with them?

You don't have to build a list of all the matches. First, that's what the
maxfind parameter is all about, second, as I said below, it could be
implemented as an iterator. I'd expect that to happen if it was going
to be used in a for statement.

>
> s = "a" * 1000  # 10 MB of data to search
> L = s.findall("a")  # lots of matches means L is very large
>
> or imagine a more complex case where I have to programmatically change my
> search string as I go. I might not know how many matches I need until I
> have found them and can analyse the text around the match.
>
> Seems to me that rather than having to find all matches regardless of what
> you actually want, it would be better to turn find into a generator. Then
> findall becomes list(find) and you still have the flexibility of finding
> matches one at a time.

See below. I covered it.

>> This version works intuitively with if statements (an empty list is
>> false), goes directly into for statements, can be implemented as an
>> iterator, and is only less efficient by a constant (creation of the
>> list) if the maxfind parameter is used. It never throws an exception
>> (unless the parameter list has the wrong types). Its an example of a
>> method that can be used cleanly with a type inferencer, while the index
>> and find methods cannot.
>
> Er, how does that last one work? How can findall be used cleanly? Why
> can't find?

findall() has a definite type: a list of integers, specifically a list of 
integers
that are legitimate indexes into a specific string. The result of find() 
does
not have this property: it can be an integer that is an index into the 
string,
or it can be a -1. Index can either return an index into the string, or it
can throw an exception. Both of these are complex result types that
hinder further type inference.

John Roth

>
>
> -- 
> Steven.
> 

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

Re: Acceptance test spike example

[John Roth]

"Andrew McDonagh" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Steve Jorgensen wrote:
>> I'm posting this message for 2 reasons.
>>
>> First, I'm still pretty new and shakey to the whole Acceptance Testing 
>> thing,
>> and I'm hoping for some feedback on whether I'm on the right track. 
>> Second,
>> although all the Agile literature talks about the importance of doing
>> Acceptance Testing, there's very little in any of the books or out on the 
>> Web
>> that helps with how to do it.  If I am on the right track, this will be 
>> one
>> more helpful item folks can find on a Google search.
>>
>> The code below is basically a spike I wrote in a few hours last night to 
>> prove
>> to myself and my team that it would be feasible to quickly create a 
>> simple,
>> useful Acceptance Testing harness for our learning project.
>>
>> First, I wrote an example test script I would hope to be able to 
>> execute...
>>
>> ===
>> ?recipeListCount:0
>> !new
>> ?name:"New Recipe"
>> name:"PB&J"
>> ?name:"PB&J"
>> !save
>> !close
>> ?recipeListCount:1
>> !goToListItem 1
>> !openListItem
>> ?name:"PB&J"
>> ===
>>
>
> Snipped.
>
> Its best to aim the Acceptance Test at your Customers level of expertise, 
> not at the developers. As a Customer is the person best placed to tell us 
> What they want. Yes Our team people (Devs or testers) can help write the 
> actual tests, but the Customer should still be able to read them. After 
> all, the tests are Executable Requirements.
>
> There's two flavors of Customer oriented styles I've come across.
>
> The first uses a Domain Specific Language...eg using your values above..
>
> -
> IsTotalNumberOfRecipes 0
>
> ClickNewRecipeButton
> RecipeNameToUse  "PB&J"
> SaveNewRecipe
> CloseDialog
>
> IsTotalNumberOfRecipes 1
>
> IsThereOneRecipeCalled "PB&J"
> -
>
> All commands are the first full word. No need for special tokens to decide 
> what the command is supposed to do, as each Command is the name of a class 
> to use.
>
> You can use reflection to dynamically create the Command instances or the 
> name can be used by a factory as an id.
>
> The Commands themselves know what they are supposed to do, not the Script 
> parsing engine.
>
> The second approach is using FIT/Fitnesse - google these for exact 
> description. They take information in Table form. This allows the customer 
> to use any software to create the test scripts, so long as it can create 
> tables: Word processors, Spread Sheets, etc.

The Python version of FIT (currently at 0.7a2) can be found in the
file section of either the FitNesse Yahoo group or the ExtremeProgramming
Yahoo group. One of these days I'm going to get it on PyPi.

It's full featured, works both in batch and with FitNesse, and
includes most of FitLibrary.

There's a book coming out on FIT (FIT for Developing Software)
by Rick Mugridge and Ward Cunningham. It was supposed to be out
a week ago Friday, but B&N says it was delayed.

John Roth
PyFit

>
> Andrew 

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

Re: Beginner question: Converting Single-Element tuples to list

[John Roth]

"Reinhold Birkenfeld" <[EMAIL PROTECTED]> wrote in 
message news:[EMAIL PROTECTED]
> [EMAIL PROTECTED] wrote:
>> Hi,
>>
>> Thanks for your reply! A new thing learned
>>
>> Allow me to follow that up with another question:
>>
>> Let's say I have a result from a module called pyparsing:
>>
>> Results1 = ['abc', 'def']
>> Results2 = ['abc']
>>
>> They are of the ParseResults type:
>>
>>>>> type(Results1)
>> 
>>>>> type(Results2)
>> 
>>
>> I want to convert them into Python lists. list() will work fine on
>> Results1, but on Results2, it will return:
>>
>> ['a', 'b', 'c']
>>
>> Because 'abc' is a string. But I want it to return ['abc'].
>>
>> In short, my question is: how do I typecast an arbitrary object,
>> whether a list-like object or a string, into a Python list without
>> having Python split my strings into characters?
>
> This seems like a glitch in pyparsing. If a ParseResults class emulates
> a list, it should do so every time, not only if there is more than one
> value in it.

Unfortunately, I've seen that behavior a number of times:
no output is None, one output is the object, more than one
is a list of objects. That forces you to have checks for None
and list types all over the place. Granted, sometimes your
program logic would need checks anyway, but frequently
just returning a possibly empty list would save the caller
a lot of grief.

John Roth
>
> Reinhold 

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

Re: Plain text email?

[John Roth]

"Inkiniteo" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Hi guys. I have a script that sends the info by email, but i'd like to
> avoid the convertion to HTML by the email client or Gmail, because it
> ruins all the formatting i did (with tabs, mostly). Briefing, i wanna
> be able to send SMTP mail  and the receiver only get it in plain text.

As long as your mimetype is text/plain you should have
minimal trouble. There's no way you can control what
the recipient's mail client does, however.

In particular, there are a lot of mail clients out there that
handle tabs poorly. Outlook Express is the poster child
for this: it ignores tabs completely, however it is by no
means the only culprit. It's simply the most widespread one.

In other words, use strings of spaces rather than tabs,
and you'll probably find your messages coming out
looking better.

John Roth
> 

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

Re: Plain text email?

[John Roth]

"Inkiniteo" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
>I see. So... what about sending HTML email? If i send HTML tagged text,
> the client will be able to read it as HTML?
>
> For example, if i send an email with:  
> Yo! will the client read a bold Yo! ?
>
> Because i can replace tabs with tables if this is possible.

To send HTML, you definitely need a mimetype. Otherwise
some clients will autodiagnose as HTML and attempt to render
it, some won't. Strictly speaking, they shouldn't do autodetection.

I also agree with Dan - HTML mail is evil, and I try to avoid it
whenever possible. That's one of the major vectors for worms,
viri and simliar malware.

John Roth
> 

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

Re: Modules for inclusion in standard library?

[John Roth]

"Reinhold Birkenfeld" <[EMAIL PROTECTED]> wrote in 
message news:[EMAIL PROTECTED]
> Hello,
>
> at the moment python-dev is discussing including Jason Orendorff's path 
> module
> into the standard library.
>
> Do you have any other good and valued Python modules that you would think 
> are
> bug-free, mature (that includes a long release distance) and useful enough 
> to
> be granted a place in the stdlib?
>
> For my part, ctypes seems like a suggestion to start with.
>
> Reinhold

I'd go with path. While I'm not at all certain that it's "the" way
to go, it'll at least break the conceptual logjam caused by simply
providing wrappers around the C library functions.

I'd definitely like to see ctypes. I can agree with the segfault
issue, but I think that some design work would eliminate that.

PyChecker, rather obviously. Likewise I'd like to see something
that would do a decent job of coverage analysis. Neither of the
modules out there at the moment is ready for prime time.

I don't have enough experience with interactive mode to have
an opinion on IPython. What I would like to see is a Python
based shell that could compete with either ksh or Monad.

John Roth

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

Re: Dictionary to tuple

[John Roth]

"bruno modulix" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Odd-R. wrote:
>> I have a dictionary, and I want to convert it to a tuple,
>> that is, I want each key - value pair in the dictionary
>> to be a tuple in a tuple.
>>
>> If this is the dictionary {1:'one',2:'two',3:'three'},
>> then I want this to be the resulting tuple:
>> ((1,'one'),(2,'two'),(3,'three')).
>>
>> I have been trying for quite some time now, but I do not
>> get the result as I want it. Can this be done, or is it not
>> possible?
>
> It's of course possible, and even a no-brainer:
>
> dic = {1:'one',2:'two',3:'three'}
> tup = tuple(dic.items())

I think I'll add a little clarification since the OP is really new
to Python. The (dict.items()) part of the expression returns a
list, and if you want to sort it, then you need to sort the list
and then convert it to a tuple.

dic = {1:'one',2:'two',3:'three'}
dic.sort()
tup = tuple(dic)

This points up the fact that the final conversion to a tuple
may not be necessary. Whether or not is is depends on
the circumstances.

>> I must also add that I'm new to Python.
> Welcome on board.
>

John Roth

> -- 
> bruno desthuilliers
> python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
> p in '[EMAIL PROTECTED]'.split('@')])" 

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

Re: map/filter/reduce/lambda opinions and background unscientific mini-survey

[John Roth]

"Tom Anderson" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Comrades,
>
> During our current discussion of the fate of functional constructs in 
> python, someone brought up Guido's bull on the matter:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=98196
>
> He says he's going to dispose of map, filter, reduce and lambda. He's 
> going to give us product, any and all, though, which is nice of him.
>
> What really struck me, though, is the last line of the abstract:
>
> "I expect tons of disagreement in the feedback, all from ex-Lisp-or-Scheme 
> folks. :-)"
>
> I disagree strongly with Guido's proposals, and i am not an 
> ex-Lisp, -Scheme or -any-other-functional-language programmer; my only 
> other real language is Java. I wonder if i'm an outlier.
>
> So, if you're a pythonista who loves map and lambda, and disagrees with 
> Guido, what's your background? Functional or not?

As far as biases  is concerned: my background is assembler.
I've never learned Lisp (although I did learn Forth at one time.)

I think I could note that originally there were five of the things,
including apply, which was cleanly replaced by the * and **
notation in function definitions and calls.

Map, filter and reduce are three things one can do with lists
(or in fact more general sequences).
List comprehensions cleanly replace filter. They don't
quite replace map, and they definitely don't replace reduce.
Claiming that sum etc. do the same job is the whimper of
someone who doesn't want to openly disagree with Guido.

Lambda is a horse of a quite different color. There are times
when an inline definition is the best thing one can have for
notational expressiveness. While lambda has a lot of
problems, Guido seems to be resisting replacing it with
something that can actually do the job.

Having to define an external function or class doesn't
always improve expressiveness. Sometimes it reduces
it. To quote Sean O'Lochlain:  "Sometimes the best
symbol for a sharp knife is a sharp knife." [1]

John Roth

[1] In one of Randall Garrett's Lord Darcy stories.



>
> tom
>
> -- 
> Batman always wins 

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

Re: map/filter/reduce/lambda opinions and background unscientificmini-survey

[John Roth]

"Robert Kern" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

>
> map and filter are being removed *because of* list comprehensions. Did you 
> even read Guido's articles about this issue? Your understanding of why 
> these changes are planned is incorrect; consequently your projection based 
> on that understanding is not on firm footing.

May I most respectfully point out that you've got it backwards.
Part of the justification for list comprehensions was that they could
be used to replace map and filter.

The jihad against the functional constructs has been going on for a
long time, and list comprehensions are only one piece of it.

John Roth

> -- 
> Robert Kern
> [EMAIL PROTECTED]
>
> "In the fields of hell where the grass grows high
>  Are the graves of dreams allowed to die."
>   -- Richard Harter
> 

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

Re: Inheriting from object

[John Roth]

"Bengt Richter" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

> I wonder if the above common use of super could be implemented as a 
> property of object,
> so you'd normally inherit it and be able to write
>self.super.__init__(*args, **kwargs)  # (maybe spell it 
> self.__super__.__init__(...) I suppose)
>
> I.e., self.__super__ would effectively return the equivalent of
>super(type(self), self)

Well, let's look at it. If I implemented a super() method on
object (and I didn't shadow it anywhere) what I'd have when
it was invoked is something like

def super(self):
stuff

>From there one could get the current instance's class, so
we've got all the ingredients of the regular super(class, instance)
built-in function. What it wouldn't have is the ability to invoke it
on an arbitrary class and instance.

The big issue seems to be the direction Guido wants to take
Python - he seems to not want to put methods on the
object type. I have to say that I don't understand his reasoning,
if that is indeed his position.

John Roth

>
> Regards,
> Bengt Richter 

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

Re: Will Guido's "Python Regrets" ever get implemented/fixed?

[John Roth]

"Robert Kern" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> [EMAIL PROTECTED] wrote:
>> Guido gave a nice "Python Regrets" Power Point talk at OSCON few years
>> ago.
>>
>> I was wondering if the plan is to ever implement these ideas.
>>
>> e.g. Guido said he'd prefer 'print' to be a *function* with perhaps a
>> 'println' version IIRC.
>>
>>He also had a ton of stuff he'd rather see become iterators.
>
> As currently being (re)discussed at tedious length in recent threads here, 
> changes would will only be realized in Python 3.0 (aka Python 3000 in 
> facetious reference to when we can expect to see such a beast).

I believe the current plan is to make compatible changes in the
next few releases, and then make the incompatable changes in
Python 3.0 See PEP 3000 for details.

http://www.python.org/peps/pep-3000.html

What this means is that there is a good chance that a print()
built-in function or method on a file object may show up in
a future release, the print statment won't go away until
Python 3.0.

John Roth
>
> -- 
> Robert Kern
> [EMAIL PROTECTED]
>
> "In the fields of hell where the grass grows high
>  Are the graves of dreams allowed to die."
>   -- Richard Harter
> 

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

Re: Will Guido's "Python Regrets" ever get implemented/fixed?

[John Roth]

"Peter Maas" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> George Sakkis schrieb:
>> Given that the latest 2.x python will be 2.9
>
> Why not 2.13 or 2.4711? Version strings are sequences of arbitrary
> integers separated by dots and not decimal numbers, or are they?

Because Guido said (somewhere) that he didn't want to go over
release 2.9.

John Roth
>
> -- 
> ---
> Peter Maas,  M+R Infosysteme,  D-52070 Aachen,  Tel +49-241-93878-0
> E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
> --- 

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

Re: Unicode drives me crazy...

[John Roth]

<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Hi !
>
> I want to get the WMI infos from Windows machines.
> I use Py from HU (iso-8859-2) charset.
>
> Then I wrote some utility for it, because I want to write it to an XML 
> file.
>
> def ToHU(s,NoneStr='-'):
>if s==None: s=NoneStr
>if not (type(s) in [type(''),type(u'')]):
>   s=str(s)
>if type(s)<>type(u''):
>   s=unicode(s)
>s=s.replace(chr(0),' ');
>s=s.encode('iso-8859-2')
>return s
>
> This fn is working, but I have been got an error with this value: 
> 'Kommunik\xe1ci\xf3s port (COM1)'
>
> This routine demonstrates the problem
>
> s='Kommunik\xe1ci\xf3s port (COM1)'
> print s
> print type(s)
> print type(u'aaa')
> s=unicode(s) # error !
>
> This is makes me mad.
> How to I convert every objects to string, and convert (encode) them to 
> iso-8859-2 (if needed) ?
>
> Please help me !

As Tim Golden already explained, you're getting a unicode
object from the WMI interface. The best design help I can
give is to either convert it to iso-8859-2 at the point you
get the object and do your entire program with iso-8859-2
encoded strings, or do your entire program with unicode
objects and encode them as iso-8859-2 strings whenever
you want to write them out. Trying to do your conversion
in the middle will lead to excessive complexity, with the
resulting debugging problems.

If you do  go the unicode route, you must remember that
any method or function that's defined to return a string will
most likely throw an exception. This includes str()! Whether
or not the print statement will work depends on a number
of factors in how your Python installation was set up.

HTH

John Roth


> Thanx for help:
> ft

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

Re: what is __init__.py used for?

[John Roth]

<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
>I am a new learner of Python Programming Language.
> Now. I am reading a book.

...

> ==
>   I was wonderring ... what is the __init__.py used for ?
>   This question may seems to be stupid for an expert.
>   But, if you can give the answer, it will be helpful for me.

__init__.py is used for two things. One is as a flag to
indicate that the python programs in the directory are
part of a module.

The other is as the module itself. Let's take a simple
example. Assume you have a directory named breakfast
which contains modules named spam.py, eggs.py,
toast.py and jam.py, and that the directory containing
breakfast is on the PYTHONPATH.

If it try to import spam.py by writing

import breakfast.spam

it won't work because the breakfast directory
doesn't contain an __init__.py file.

If I then add __init__.py to the breakfast directory,
the import will work, and the result will be *two*
modules loaded. The first module will be bound to
the identifier 'breakfast' in your module. It will be
completely empty except for the identifier 'spam'
which will have the spam module bound to it.

This means that if the spam module contains,
for example, an identifier named "vikings", then I
can refer to it as breakfast.spam.vikings.

The real kicker here is that when I say that the
first module will be completely empty, it's not
quite true. First, it will have some standard
identifiers that all modules have, and second
it will have anything you put into the __init__.py
module file. This last is an advanced feature, and
you're well advised to stay away from it until
you've got a lot more experiance.

HTH

John Roth


>
>  thanks.
> 

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

Re: removing list comprehensions in Python 3.0

[John Roth]

"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> In all probability, both list comprehensions and generator expressions
> will be around in perpetuity.  List comps have been a very successful
> language feature.
>
> The root of this discussion has been the observation that a list
> comprehension can be expressed in terms of list() and a generator
> expression.   However, the former is faster when you actually want a
> list result and many people (including Guido) like the square brackets.
>
> After the advent of generators, it seemed for a while that all
> functions and methods that returned lists would eventually return
> iterators instead.  What we are learning is that there is a place for
> both.  It is darned inconvenient to get an iterator when you really
> need a list, when you want to slice the result, when you want to see a
> few elements through repr(), and when you need to loop over the
> contents more than once.

I was wondering about what seemed like an ill-concieved rush to
make everything an iterator. Iterators are, of course, useful but there
are times when you really did want a list.

John Roth
>
>
> Raymond Hettinger
> 

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

Re: removing list comprehensions in Python 3.0

[John Roth]

"George Sakkis" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

> It's funny how one of the
> arguments for removing lambda -- you can do the same by defining a
> named function -- does not apply for list comprehensions.

Which is a point a number of people have made many times,
with about as much effect as spitting into the wind.

Making a piece of functionality less convenient simply to
satisfy someone's sense of language esthetics doesn't seem
to me, at least, to be a really good idea.

John Roth


>
>
> George
> 

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

Re: Should I use "if" or "try" (as a matter of speed)?

[John Roth]

"Thorsten Kampe" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
>* Steve Juranich (2005-07-09 19:21 +0100)
>> I know that this topic has the potential for blowing up in my face,
>> but I can't help asking.  I've been using Python since 1.5.1, so I'm
>> not what you'd call a "n00b".  I dutifully evangelize on the goodness
>> of Python whenever I talk with fellow developers, but I always hit a
>> snag when it comes to discussing the finer points of the execution
>> model (specifically, exceptions).
>>
>> Without fail, when I start talking with some of the "old-timers"
>> (people who have written code in ADA or Fortran), I hear the same
>> arguments that using "if" is "better" than using "try".  I think that
>> the argument goes something like, "When you set up a 'try' block, you
>> have to set up a lot of extra machinery than is necessary just
>> executing a simple conditional."
>>
>> I was wondering how true this holds for Python, where exceptions are
>> such an integral part of the execution model.  It seems to me, that if
>> I'm executing a loop over a bunch of items, and I expect some
>> condition to hold for a majority of the cases, then a "try" block
>> would be in order, since I could eliminate a bunch of potentially
>> costly comparisons for each item.  But in cases where I'm only trying
>> a single getattr (for example), using "if" might be a cheaper way to
>> go.
>>
>> What do I mean by "cheaper"?  I'm basically talking about the number
>> of instructions that are necessary to set up and execute a try block
>> as opposed to an if block.
>
> "Catch errors rather than avoiding them to avoid cluttering your code
> with special cases. This idiom is called EAFP ('easier to ask
> forgiveness than permission'), as opposed to LBYL ('look before you
> leap')."
>
> http://jaynes.colorado.edu/PythonIdioms.html

It depends on what you're doing, and I don't find a "one size fits all"
approach to be all that useful.

If execution speed is paramount and exceptions are relatively rare,
then the try block is the better approach.

If you simply want to throw an exception, then the clearest way
of writing it that I've ever found is to encapsulate the raise statement
together with the condition test in a subroutine with a name that
describes what's being tested for. Even a name as poor as
"HurlOnFalseCondition(, , , )
can be very enlightening. It gets rid of the in-line if and raise 
statements,
at the cost of an extra method call.

John Roth



In both approaches, you have some
error handling code that is going to clutter up your program flow.


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

Re: Should I use "if" or "try" (as a matter of speed)?

[John Roth]

"Thomas Lotze" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Steven D'Aprano wrote:
>
>
> Basically, I agree with the "make it run, make it right, make it fast"
> attitude. However, FWIW, I sometimes can't resist optimizing routines that
> probably don't strictly need it. Not only does the resulting code run
> faster, but it is usually also shorter and more readable and expressive.
> Plus, I tend to gain further insight into the problem and tools in the
> process. YMMV, of course.

Shorter, more readable and expressive are laudable goals in and
of themselves. Most of the "advice" on optimization assumes that
after optimization, routines will be less readable and expressive,
not more.

In other words, I wouldn't call the activity of making a routine
more readable and expressive of intent "optimization." If it runs
faster, that's a bonus. It frequently will, at least if you don't add
method calls to the process.

John Roth
>
> -- 
> Thomas
> 

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

Re: goto

[John Roth]

"Mage" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Hayri ERDENER wrote:
>
>>hi,
>>what is the equivalent of C languages' goto  statement in python?
>>best regards
>>
>>
> You really shouldn't use goto.

True.

> Fortunately you can't.

Of course you can. Recent versions of Python have the
ability to change where an element on the call stack will
return to.

Don't ask me to debug such a program unless you
really want my unvarnished opinion of such stupidity.

John Roth
>
>   Mage
> 

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

!Re: PEP on path module for standard library

[John Roth]

"Michael Hoffman" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Many of you are familiar with Jason Orendorff's path module 
> <http://www.jorendorff.com/articles/python/path/>, which is frequently 
> recommended here on c.l.p. I submitted an RFE to add it to the Python 
> standard library, and Reinhold Birkenfeld started a discussion on it in 
> python-dev 
> <http://mail.python.org/pipermail/python-dev/2005-June/054438.html>.
>
> The upshot of the discussion was that many python-dev'ers wanted path 
> added to the stdlib, but Guido was not convinced and said it must have a 
> PEP.

Why did Guido want a PEP? Is it because he likes the idea but
feels the feature set needs to be examined a bit more by the wider
community, or is it some other reason?

I'm all in favor of having something that gives an alternative to
the kludge of functions that are "just a thin wrapper on the C
standard library." Considering the known problems with the
C standard library and the fact that it's strictly procedural, that
statement doesn't fill me with confidence. Rather it creates a
mild sense of dread: nobody has thought out how to do those
functions in a useful oo manner.

Path looks useable to me. Do I think it's going to be the
last word? I sincerely hope not! The only way we're going
to find out where it really needs to go from here, though, is
to put it out and find out how the wider community uses
and abuses it.

John Roth

> Thanks in advance,
> -- 
> Michael Hoffman 

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

Re: PEP on path module for standard library

[John Roth]

"Reinhold Birkenfeld" <[EMAIL PROTECTED]> wrote in 
message news:[EMAIL PROTECTED]
> John Roth wrote:
>> "Michael Hoffman" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> Many of you are familiar with Jason Orendorff's path module
>>> <http://www.jorendorff.com/articles/python/path/>, which is frequently
>>> recommended here on c.l.p. I submitted an RFE to add it to the Python
>>> standard library, and Reinhold Birkenfeld started a discussion on it in
>>> python-dev
>>> <http://mail.python.org/pipermail/python-dev/2005-June/054438.html>.
>>>
>>> The upshot of the discussion was that many python-dev'ers wanted path
>>> added to the stdlib, but Guido was not convinced and said it must have a
>>> PEP.
>>
>> Why did Guido want a PEP? Is it because he likes the idea but
>> feels the feature set needs to be examined a bit more by the wider
>> community, or is it some other reason?
>
> He said,
>
> """
> Whoa! Do we really need a completely different mechanism for doing the
> same stuff we can already do? The path module seems mostly useful for
> folks coming from Java who are used to the Java Path class. With the
> massive duplication of functionality we should also consider what to
> recommend for the future: will the old os.path module be deprecated,
> or are we going to maintain both alternatives forever? (And what about
> all the duplication with the os module itself, like the cwd()
> constructor?) Remember TOOWTDI.
> """

Read literally, this says (at least to me) "I don't want to fix it because
I don't think it's broke."

As far as the Java remark is concerned, I suspect that it's because
in Java there is no such thing as a function; everything is either a
method on an object or a static method on a class.

And as far as I'm concerned, it's broke. I could see getting rid of the
bits and  pieces of  procedural code in 3.0, but not sooner.

John Roth
>
> Reinhold 

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

Re: PEP on path module for standard library

[John Roth]

"Duncan Booth" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> George Sakkis wrote:
>
>
> You should need an explicit call to convert a path to a string and that
> forces you when passing the path to something that requires a string to
> think whether you wanted the string relative, absolute, UNC, uri etc.
>
> It may even be that we need a hierarchy of path classes: URLs need similar
> but not identical manipulations to file paths, so if we want to address 
> the
> failings of os.path perhaps we should also look at the failings of 
> urlparse
> at the same time.

You have to start somewhere. One of the lessons that's beginning
to seep into people's minds is that getting something that works
out there is almost always preferable to (over) design by committee.

How to do a comprehensive, covers all the corner cases file
system object (or object hierarchy, etc) has been discussed before,
and nothing has ever come of it. Starting with an object that
actually does something some people want gives the designers a
chance to look at things in the wild.

John Roth 

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

Re: PEP on path module for standard library

[John Roth]

"Duncan Booth" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
>
> John Roth wrote:
>> You have to start somewhere. One of the lessons that's beginning
>> to seep into people's minds is that getting something that works
>> out there is almost always preferable to (over) design by committee.
>
> Dead right, but once it goes into the standard library it has to pretty
> well stop evolving, so it needs to be right, or as close as possible 
> before
> that happens.

It has to stop evolving in incompatible directions, at least. Although
there is a precident with the process functions, classes, module,
whatever it is. It's up to five versions now, isn't it?

AFAICT, from a very broad brush perspective, there is really
only one substantive issue: how to handle multiple path-like
"things". URLs  have been mentioned in this thread, different
file systems and a possible in-memory file system have been
mentioned in other threads.

So whatever gets out there first shouldn't preempt the ability
to eventually fit into a wider structure without substantial
and incompatible modifications.

John Roth
> 

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

Re: PEP on path module for standard library

[John Roth]

"Daniel Dittmar" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Duncan Booth wrote:
>>  I would have expected a path object to be a sequence of path elements 
>> rather than a sequence of characters.
>
> Maybe it's nitpicking, but I don't think that a path object should be a 
> 'sequence of path elements' in an iterator context.
>
> This means that
>
> for element in pathobject:
>
> has no intuitive meaning for me, so it shouldn't be allowed.

However, a path as a sequence of characters has even less
meaning - I can't think of a use, while I have an application
where traversing a path as a sequence of path elements makes
perfect sense: I need to descend the directory structure, directory
by directory, looking for specific files and types.

John Roth
>
> Daniel 

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

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

[John Roth]

"Reinhold Birkenfeld" <[EMAIL PROTECTED]> wrote in 
message news:[EMAIL PROTECTED]

>
> I'll look into it. What about iteration and indexing? Should it support
> "for element in path" or "for char in path" or nothing?

I frankly can't think of a use for iterating over the characters in
the path, but I have a number of programs that check elements,
iterate over them and index them (frequently backwards).

I also like to know the number of elements, which seems to make
sense as len(path). Again, the number of characters in the path seems
to be utterly useless information - at least, I can't imagine a use for
it.

John Roth

>
> Reinhold 

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

Re: why functions in modules need 'global foo' for integer foo but not dictionary foo?

[John Roth]

<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> At top of a module I have an integer like so...
>
> foo = 4
>
> In a function in that module I know I need to do 'global foo' to get at
> the value 4.

Actually, you don't need a "global foo" statement to
_access_ the value. You do need a "global foo" to
_rebind_ the value.

> ...
>
> IIRC, for dictionaries you DO NOT have this issue?
>
> Why this scope problem with integers but not dictionaries?

Telling an object to mutate itself doesn't rebind the object.
so, if you wanted to say:

foo = 5

and have it work at the module level, you'd need a global foo
statement, while

foo["bar"] = "spam"

doesn't. The dictionary "foo" isn't rebound, all that's happening
is that its state is being changed (that is, the key and value is
being added to the dictionary).

HTH

John Roth

>
> Chris
> 

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

Re: Art of Unit Testing

[John Roth]

""Björn Lindström"" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> 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, 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.)
>
> So, rebuilding the environment for the each before every single test is
> generally worth the overhead.

Generally is not always. There are configuration issues that are
best dealt with once at the beginning of the test, and once at
the end, and that have absolutely nothing to do with the order
in which each elementary test runs.

When your customers keep asking for something, and you
keep telling them that they really don't want what they're
asking for, who's lisening, and who's being stubborn?

John Roth
Python Fit.

>
> -- 
> Björn Lindström <[EMAIL PROTECTED]>
> Student of computational linguistics, Uppsala University, Sweden 

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

Re: Art of Unit Testing (Acceptance Tests)

[John Roth]

"Christoph Zwerschke" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Peter Hansen wrote:
>> What's wrong with using Python's existing "global" support, and just 
>> having your test case setUp() call a global setup routine which checks 
>> whether that global setup work has already been done and, if not, does it 
>> once and sets a flag to say that it has now been done?  I've done this 
>> easily in the few cases where I've wanted this behaviour.  It doesn't 
>> seem complex enough to warrant adding to the standard unit test support.
>
> Actually I already thought about doing it that way, but then I thought it 
> is so ugly, there must be a simpler solution ;-)
>
>> 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, and you 
>> should be running them all *many* times a day, not twice.
>
> You're right. I think wanting to have a more global initialization 
> indicates that you are acutally not wanting to do a "unit" test, but a 
> more global test of the overall system, something like an acceptance or 
> integration test, i.e. you are trying to abuse unittest for something it 
> was not intended to be used for.
>
> Maybe since unittest is the only testing framework included with the 
> standard lib, people tend to use it for all testing purposes. If you only 
> have a hammer, everything looks like a nail.

An excellent point, even though it's somewhat blunted by the
inclusion of doctest in the core.

Another point to ponder is that the originators of xUnit, Kent
Beck and Erich Gamma, did not intend it to be used for acceptance
testing. That ecological niche is filled by FIT. The Python port of
Fit can be acquired from the file libraries of the FitNessse or
Extremeprogramming Yahoo mailing lists. I'll get it onto the
CheeseShop (what used to be the Python Package Index) one
of these days Real Soon Now. (Arlo gave me a good shove at
Agile2005 in that direction.)

The FIT developers are working on standardizing the specs,
and expensive setups and teardown are definitely on the agenda.
In fact, that's one of my work items...

Unit testing usually does not require expensive setups and teardowns,
at least if you're not working on real tangled legacy code.
Acceptance testing does.

Meanwhile, there's a book and two web sites: fit.c2.com and
www.fitnesse.org to look at.

John Roth
Python Fit
>
> -- Christoph 

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

Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)

[John Roth]

<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> I've heard 2 people complain that word 'global' is confusing.
>
> Perhaps 'modulescope' or 'module' would be better?
>
> Am I the first peope to have thought of this and suggested it?
>
> Is this a candidate for Python 3000 yet?
>
> Chris

A much better idea would be to fix the underlying
situation that makes the global statement necessary.

I doubt if this is going to happen either, though.

John Roth
> 

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

Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)

[John Roth]

"Mike Meyer" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> "John Roth" <[EMAIL PROTECTED]> writes:
>> <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>> A much better idea would be to fix the underlying
>> situation that makes the global statement necessary.
>
> You can't "fix" this. This code (in some python-like langauge that
> isn't python):
>
> x = 23
>
> def fun():
>x = 25
># Rest of code
>
> has two possible interpretations.
>
> Either the occurrence of x in fun references the global, or it
> references a local that shadows the global. There are reasons for
> wanting both behaviors. So you have to have some way to distinguish
> between the two, and you want it to happen per variable, not per
> function. The method with the fewest keywords is to have one be the
> default, and some keyword that triggers the other.
>
> So the only way to remove the global statement would be to have some
> way to mark the other interpretation, with say a "local"
> decleration. I thik that would be much worse than "global". For one
> thing, most variables would be local whether or not they are
> declared. Second, having an indication that you need to check module
> globals in the function is a better than not having that clue there.

You've got half of the answer. The other half is to have the editor/ide
translate the lexical cues into color coding and hide the lexical cues.

It's not going to happen because the Python community is fat and happy,
and is not seeing the competition moving up on the outside. Characteristics
that make a great language one day make a mediocre one a few years
later, and make a has-been a few years after that.

John Roth

>
> -- 
> Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
> Independent WWW/Perforce/FreeBSD/Unix consultant, email for more 
> information. 

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

Re: Fat and happy Pythonistas (was Re: Replacement for keyword 'global' good idea? ...)

[John Roth]

"Peter Hansen" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> John Roth wrote:
>> It's not going to happen because the Python community is fat and happy,
>> and is not seeing the competition moving up on the outside. 
>> Characteristics
>> that make a great language one day make a mediocre one a few years
>> later, and make a has-been a few years after that.
>
> And here I thought that was the point of Python 3000.  To let the 
> community produce a much improved language while avoiding the problems 
> caused by too much change occurring while people are trying to get useful 
> things done with what the language is _now_.  The competition (and let's 
> see a description of just what that means, too) probably has the dual 
> advantage of newness and a small, hackerish community that is more than 
> happy to see rapid and radical change.  You're right -- as with the 
> stereotypical large/slow vs. small/agile company motif -- that smaller and 
> more agile will pass larger and slow "on the outside", but you're wrong if 
> you think that means the larger-slower entity should drop what it's been 
> doing so well and try to compete entirely on the smaller-faster entity's 
> own ground.

Maybe "fat and happy" wasn't the best choice of words (and maybe
Extreme Programming wasn't Kent Beck's best choice of words either.)

However. I see nothing in the existing Python 3000 PEP that does
anything other than inspire a yawn. Sure, it's a bunch of cleanup, and
some of it is definitely needed. What I don't see is the inspired leap
forward that will once again put Python in the forefront rather than
simply being one choice among many.

What I want to see in Python 3000 is an AST based language
that lets the editors do the pretty printing. Do you want automatic
indenting or would you prefer end statements? It's an editor formatting
option. The AST neither knows or cares. Don't want to see self?
Editor formatting option. The AST knows what scope each
identifier belongs to because it's right there in the text. No need
for rules that you have to learn, sometimes the hard way.

Want to see type inference? I haven't a clue how to do it in a
dynamic language like Python, but an AST based language is a
perfect test bed for experimentation.

What's good about other languages? I see very little here
that is an examination of what Smalltalk, Ruby, Perl, etc.
seem to have gotten right and could be moved into Python
to good effect.

Talk to people who've moved from Python to Ruby, or to
some other language. Ask them why, if Python is so great,
what's even greater in that other language. If you still don't
understand, you might want to read this:

http://martinfowler.com/bliki/CollectionClosureMethod.html

Look at Pep 8. It's a compendium of coding standards
for the standard library. So far, ok. Coding standards
are generally good. But why does Guido like underscores
in method names? I know there was (and the accent is
on the word was) some research, refuted well over a decade
ago, that mixedCase was hard to read. The fact is that
_all_ conventions for separating words are hard to read
until the brain grows new synapses that handle it. Of the
options, no separation is the hardest to handle. There are
reasons why ancient texts, which had neither word
separators nor punctuation, have very contentious translations.

I find the notion that there should be one obviously right way
to do something to be a good design principle, so why isn't
there a single supported GUI library? If I'm over in Java-land,
just about everything comes with a GUI. Python ships with a
lot of little demonstration and utility scripts - none of which has
a GUI.

Part of the tone here is because of the PEP 208 voting
process. From day one, I knew it was going to fail.
Anyone who stood back and looked at the process, rather
than getting into the detail, knew it was going to fail. There
was no way that the Python community was going to come
up with a simple majority in favor of one proposal. None.
And it was obvious from the start.

And the sad fact is that a proposition of the form: "We
want a conditional expression; Guido should pick the
syntax he finds the least obnoxious and get on with it"
would have passed. Overwhelmingly.

I came across a better voting process (Condorcet)
later. Unfortunately it was later or I would have
suggested it.

Why the jihad (and I'm using the word advisedly)
against the map, filter and reduce operators?
It seems to be completely irrational from my
viewpoint. I've seen the arguements, and they
make no sense.

> BTW, I think "large and stable" would have been less offensive than "fat 
> and happy", but perhaps you meant to imply we're both lazy and c

Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope'or 'module' better?)

[John Roth]

"Paolino" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> [EMAIL PROTECTED] wrote:
>> I've heard 2 people complain that word 'global' is confusing.
>>
>> Perhaps 'modulescope' or 'module' would be better?
>>
>> Am I the first peope to have thought of this and suggested it?
>>
>> Is this a candidate for Python 3000 yet?
>>
>> Chris
>
> I don't think the global keyword is useful actually.
>
> What's so special in a module nemespace to be priviledged like that.

> The point IMO is accessing names defined somewhere in the enclosing 
> namespaces.

The issue isn't _accessing_ the module namespace. It's
binding to identifiers in the module  namespace.

The reason is that _assigning_ to an identifier in a
function or method makes that identifier local, so
there needs to be a simply way of saying that you
want to be able to assign to an identifier in the
module namespace. (There's already a more
complicated way: use the global() built-in function.)

John Roth


> Regards Paolino

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

Re: Generalised String Coercion

[John Roth]

"Terry Reedy" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
>> PEP: 349
>> Title: Generalised String Coercion
> ...
>> Rationale
>>Python has had a Unicode string type for some time now but use of
>>it is not yet widespread.  There is a large amount of Python code
>>that assumes that string data is represented as str instances.
>>The long term plan for Python is to phase out the str type and use
>>unicode for all string data.
>
> This PEP strikes me as premature, as putting the toy wagon before the 
> horse, since it is premised on a major change to Python, possibly the most 
> disruptive and controversial ever, being a done deal.  However there is, 
> as far as I could find no PEP on Making Strings be Unicode, let alone a 
> discussed, debated, and finalized PEP on the subject.

PEP 3000, Core Language, Bullet Point 3:

Make all strings be Unicode, and have a separate bytes() type.

John Roth

> Terry J. Reedy


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

Re: Fat and happy Pythonistas (was Re: Replacement for keyword 'global' good idea? ...)

[John Roth]

"Mike Meyer" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> "John Roth" <[EMAIL PROTECTED]> writes:
>> However. I see nothing in the existing Python 3000 PEP that does
>> anything other than inspire a yawn. Sure, it's a bunch of cleanup, and
>> some of it is definitely needed.
>
> Actually, that's pretty much *all* it is. I always figured it was a
> warning about things that were liable to break, rather than a list of
> new features that Python 3000 would incorporate.
>
> For those - well, if a change won't break existing code, why put it
> off until Python 3000? I don't think I've seen *any* new features
> proposed for Python 3000. It's to far in the future, so new features
> are proposed in such a way that don't break current code. Interfaces
> come to mind.
>
>> What I want to see in Python 3000 is an AST based language
>> that lets the editors do the pretty printing. Do you want automatic
>> indenting or would you prefer end statements? It's an editor formatting
>> option. The AST neither knows or cares. Don't want to see self?
>> Editor formatting option. The AST knows what scope each
>> identifier belongs to because it's right there in the text. No need
>> for rules that you have to learn, sometimes the hard way.
>
> I'm not sure what you mean by "AST based language". Google wasn't much
> help, even in finding a definition for AST - it gets swamped by time
> zones and company names. I think you mean abstract syntax tree, but
> I'm not sure how you would go about basing a language on that. Care to
> provide pointers?

You got it.

http://martinfowler.com/articles/languageWorkbench.html

This shows one reason _why_ designing a language with the basic
AST representation as primary may become a big deal. Maybe
not, too.


>
>> Talk to people who've moved from Python to Ruby, or to
>> some other language. Ask them why, if Python is so great,
>> what's even greater in that other language. If you still don't
>> understand, you might want to read this:
>>
>> http://martinfowler.com/bliki/CollectionClosureMethod.html
>
> I read it. I don't see what the big deal is. He praises collections
> and closurs. Python has both. Ok, the closures are sucky, but you can
> fake real one with classes. He likes anonymous blocks. There are a
> couple of proposals floating around to add those to Python.

There have been proposals to add them to Python for as long as
I can remember. They have always been shot down. Vigorously.

The basic issue here is neither the collection methods nor the
closures. It's a compact yet readable syntax that puts them
together. That's what one should get out of the Fowler piece:
how nice it is to be able to do some rather common things
compactly.

All steps in that direction have always been resisted.

> What I do see are a couple of collection methods (find and inject)
> that would maken nice additions to the language. I've already posted a
> suggestion to add them.
>
>> I find the notion that there should be one obviously right way
>> to do something to be a good design principle, so why isn't
>> there a single supported GUI library? If I'm over in Java-land,
>> just about everything comes with a GUI. Python ships with a
>> lot of little demonstration and utility scripts - none of which has
>> a GUI.
>
> The standard library documentation only documents one GUI library. The
> Python distribution includes one *large* example of GUI programming
> with that library - IDLE. I agree that more examples and documentation
> would be usefull, but I'm *not* the person to write them.

And I never suggested you were.

>> Why the jihad (and I'm using the word advisedly)
>> against the map, filter and reduce operators?
>
> I'd say that LCs and GEs make map and filter redundant, thus violating
> the principle of there being one obviously right way to do something
> that you like. Reduce isn't as clear. Maybe we can get it replaced by
> inject.

You've got the horse harnessed backwards. The jihad against
the "functional" operators was being conducted long before
list comprehensions were in sight. The first action on that was
to replace apply() with the * and ** notations in function/method
definitions and calls.

Guido has said (Python  Regrets) that he regrets ever
allowing them into the language. It's a jihad.


>
>> It seems to be completely irrational from my
>> viewpoint. I've seen the arguements, and they
>> make no sense.
>
> They make perfect sense to me. Either you like there's only one way
> (obvious) 

Re: python code with indention

[John Roth]

"Xah Lee" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
is it possible to write python code without any indentation?
Xah
Depends on what you mean by "python code."
If you mean using the full facilities of the language,
then the answer is clearly no - indentation is not
optional.
You can, of course, write a silly little inline script without
any control structures that will all line up at the left
margain. So what?
John Roth
[EMAIL PROTECTED]
http://xahlee.org/PageTwo_dir/more.html
--
http://mail.python.org/mailman/listinfo/python-list

Re: Unittesting for web applications

[John Roth]

I believe there are xUnit clones named
Httpunit and Htmlunit, as well as a number
of variants. See the huge list of xUnit
clones on:
http://www.xprogramming.com/
in the downloads section. I don't think
any of them are Python based, though.
You might also want to look at some of
the Htmlunit integration into FIT and
Fitnesse.
You can frequently get discussions on
the Yahoo TDD list.
John Roth
"Sandip Bhattacharya" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Can someone suggest me some good resources for learning how to use
unittests for web applications? Do we always have to cook up our own
webpage scrapers to test the code?
- Sandip
--
Sandip Bhattacharya*Puroga Technologies   * [EMAIL PROTECTED]
Work: http://www.puroga.com   *Home/Blog: http://www.sandipb.net/blog
PGP/GPG Signature: 51A4 6C57 4BC6 8C82 6A65 AE78 B1A1 2280 A129 0FF3

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

Re: Why doesn't join() call str() on its arguments?

[John Roth]

"Leo Breebaart" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
I've tried Googling for this, but practically all discussions on
str.join() focus on the yuck-ugly-shouldn't-it-be-a-list-method?
issue, which is not my problem/question at all.
What I can't find an explanation for is why str.join() doesn't
automatically call str() on its arguments, so that e.g.
str.join([1,2,4,5]) would yield "1245", and ditto for e.g.
user-defined classes that have a __str__() defined.
All I've been able to find is a 1999 python-dev post by Tim
Peters which would seem to indicate he doesn't understand it
either:
   "string.join(seq) doesn't currently convert seq elements to
string type, and in my vision it would. At least three of us
admit to mapping str across seq anyway before calling
string.join, and I think it would be a nice convenience
[...]"
But now it's 2005, and both string.join() and str.join() still
explicitly expect a sequence of strings rather than a sequence of
stringifiable objects.
I'm not complaining as such -- sep.join(str(i) for i in seq) is
not *that* ugly, but what annoys me is that I don't understand
*why* this was never changed. Presumably there is some
counter-argument involved, some reason why people preferred the
existing semantics after all. But for the life of me I can't
think what that counter-argument might be...
--
Leo Breebaart  <[EMAIL PROTECTED]> 
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why doesn't join() call str() on its arguments?

[John Roth]

"Leo Breebaart" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
I've tried Googling for this, but practically all discussions on
str.join() focus on the yuck-ugly-shouldn't-it-be-a-list-method?
issue, which is not my problem/question at all.
What I can't find an explanation for is why str.join() doesn't
automatically call str() on its arguments, so that e.g.
str.join([1,2,4,5]) would yield "1245", and ditto for e.g.
user-defined classes that have a __str__() defined.
All I've been able to find is a 1999 python-dev post by Tim
Peters which would seem to indicate he doesn't understand it
either:
   "string.join(seq) doesn't currently convert seq elements to
string type, and in my vision it would. At least three of us
admit to mapping str across seq anyway before calling
string.join, and I think it would be a nice convenience
[...]"
But now it's 2005, and both string.join() and str.join() still
explicitly expect a sequence of strings rather than a sequence of
stringifiable objects.
I'm not complaining as such -- sep.join(str(i) for i in seq) is
not *that* ugly, but what annoys me is that I don't understand
*why* this was never changed. Presumably there is some
counter-argument involved, some reason why people preferred the
existing semantics after all. But for the life of me I can't
think what that counter-argument might be...
I was originally going to say performance, but I don't think
that's all that much of an issue.
For me, at least, I've already got a way of taking just about
anything and turning it into a string: the % operator. It's
powerful enough that there have been attempts to make
a less powerful and simpler to understand version.
The limitation here is that you have to know how many
elements you want to join, although even that isn't the
world's hardest issue. Consider:
(untested)
result = ("%s" * len(list)) % list
Not the most obvious code in the world, but it might
work.
And as someone else (you?) pointed out, this will
also work:
(untested)
result = "".join([str(x) for x in list])
and it's got the advantage that it will handle separators
properly.
John Roth
--
Leo Breebaart  <[EMAIL PROTECTED]> 
--
http://mail.python.org/mailman/listinfo/python-list

Re: introspection inquiry

[John Roth]

"Michael Hoffman" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Robin Becker wrote:
self.__class__.__name__
Unless I misunderstood the question, that won't work. That will
give you the name of the class the object is an instance is of.
I think he wants the name of the class the method was defined in.
If that's the case, then the inspect module should give
the tools to do it without a great deal of angst. Unfortunately,
it doesn't give you the class that defined the method, just
the class that invoked it.
John Roth
--
http://mail.python.org/mailman/listinfo/python-list

Re: PyEphem on Win32 -- 2nd try

[John Roth]

A quick look at the site, and following the link to
the XEphem site reveals that the Windows port
of XEphem uses Cygwin. AFAIK, that's not
compatible with the usual CPython implementation.
Again, AFAIK, you'll either have to use a Python
port compiled under Cygwin, or you'll have to
find a Windows port compiled with VS 6 or
higher.
Someone who knows more about those
issues will have to take it from here.
John Roth
<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A second request for help...
Has anyone run the PyEphem ephemeris application under WinXP?
http://rhodesmill.org/brandon/projects/pyephem.html
I have compiled it with Visual Studio 6 and it crashes Python with a
simple
import ephem
ephem.date('1994/7/16')
Identical code works fine under Linux. I suspect that the problem has
to do with a parser built into the c shell for the c code that the
app wraps around.  However, I am not good enough at c to spot the
error.
I am running ActivePython 2.3.5 Build 236 on a WinXP SP2 system with
Visual Studio 6 patched to sp6.
I would appreciate either help from a c guru who knows how to wrap
python around c or a pointer to another list where experts might
reside.
- ---
Cheers, David Flory
-BEGIN PGP SIGNATURE-
Version: PGP 8.1
iQA/AwUBQhy551e2/rcN3lp8EQIu2gCfRyDmSCtiP4uB2qKMtIvjcOOsNUkAn1FD
rir+BKqfDqZ0P+lKcwfgdQPu
=5+at
-END PGP SIGNATURE-
--
http://mail.python.org/mailman/listinfo/python-list

Re: Unit testing - one test class/method, or test class/class

[John Roth]

I tend to write one test class per class, but that's
just the way I got started. My feeling is that the
methods in a test class should tell a story if you
read the names in the order they were written,
so I'd split the tests for a class into several
classes if they had different stories to tell.
John Roth
"Edvard Majakari" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Hi,
I just found py.test[1] and converted a large unit test module to py.test
format (which is actually almost-no-format-at-all, but I won't get there
now). Having 348 test cases in the module and huge test classes, I started
to think about splitting classes. Basically you have at least three 
obvious
choises, if you are going for consistency in your test modules:

Choise a:
Create a single test class for the whole module to be tested, whether it
contains multiple classes or not.
...I dont think this method deserves closer inspection. It's probably 
rather
poor method to begin with. With py.test where no subclassing is required
(like in Python unittest, where you have to subclass unittest.TestCase)
you'd probably be better off with just writing a test method for each 
class
and each class method in the module.

Choise b:
Create a test class for each class in the module, plus one class for any
non-class methods defined in the module.
+ Feels clean, because each test class is mapped to one class in the 
module
+ It is rather easy to find all tests for given class
+ Relatively easy to create class skeleton automatically from test module
 and the other way round

- Test classes get huge easily
- Missing test methods are not very easy to find[2]
- A test method may depend on other tests in the same class
Choise c:
Create a test class for each non-class method and class method in the 
tested
module.

+ Test classes are small, easy to find all tests for given method
+ Helps in test isolation - having separate test class for single method
 makes tested class less dependent of any other methods/classes
+ Relatively easy to create test module from existing class (but then you
 are not doing TDD!) but not vice versa
- Large number of classes results in more overhead; more typing, probably
 requires subclassing because of common test class setup methods etc.
What do you think, any important points I'm missing?
Footnotes:
[1]  In reality, this is a secret plot to advertise py.test, see
http://codespeak.net/py/current/doc/test.html
[2] However, this problem disappears if you start with writing your tests
   first: with TDD, you don't have untested methods, because you start by
   writing the tests first, and end up with a module that passes the tests
--
# Edvard Majakari Software Engineer
# PGP PUBLIC KEY availableSoli Deo Gloria!
One day, when he was naughty, Mr Bunnsy looked over the hedge into Farmer
Fred's field and it was full of fresh green lettuces. Mr Bunnsy, however, 
was
not full of lettuces. This did not seem fair.  --Mr Bunnsy has an 
adventure 
--
http://mail.python.org/mailman/listinfo/python-list

Re: How do I import everything in a subdir?

[John Roth]

"Dfenestr8" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Hi.
I have a program which I want a plugin directory for. I figured the way to
go about that would be to just add a plugin/ dir to sys.path, and import
everything in it. Then my program can just execute the main() method of
each imported plugin.
Is that a good way to go about it?
If so, how do I import everything in the plugins dir? The method raises an
error as you can see.
Read the directory and then use the __import__() method on each
entry that ends in .py, .pyc or .pyo. Filter for duplicates first or you
may be executing a single plugin more than once.
Don't bother with sys.path unless you want your plugins to be
able to import from that directory as well.
John Roth


import sys
import os
sys.path.append("plugins")
ls = os.popen("ls plugins").readlines()
for x in ls:
... plugs.append(x[0:x.rfind(".py")])
for x in plugs:
... import x
...
Traceback (most recent call last):
 File "", line 2, in ?
ImportError: No module named x
--
http://mail.python.org/mailman/listinfo/python-list

Re: Unicode BOM marks

[John Roth]

""Martin v. LÃwis"" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Francis Girard wrote:
Well, no text files can't be concatenated ! Sooner or later, someone will 
use "cat" on the text files your application did generate. That will be a 
lot of fun for the new unicode aware "super-cat".
Well, no. For example, Python source code is not typically concatenated,
nor is source code in any other language. The same holds for XML files:
concatenating two XML documents (using cat) gives an ill-formed document
- whether the files start with an UTF-8 signature or not.
And if you're talking HTML and XML, the situation is even worse, since
the application absolutely needs to be aware of the signature. HTML might
have a  directive close to the front to tell you what the 
encoding
is supposed to be, and then again, it might not. You should be able to 
depend
on the first character being a <, but you might not be able to. FitNesse, 
for
example, sends FIT a file that consists of the HTML between the 
and  tags, and nothing else. This situation makes character set
detection in PyFit, um, interesting. (Fortunately, I have other ways of
dealing with FitNesse, but it's still an issue for batch  use.)

As for the "super-cat": there is actually no problem with putting U+FFFE
in the middle of some document - applications are supposed to filter it
out. The precise processing instructions in the Unicode standard vary
from Unicode version to Unicode version, but essentially, you are
supposed to ignore the BOM if you see it.
It would be useful for "super-cat" to filter all but the first one, however.
John Roth

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

Re: Second argument to super().

[John Roth]

"Tobiah" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
What is the purpose of the second argument to super()?
I've always  found the docs to be fairly confusing.
They didn't give me enough context to tell what
was going on. I also find the terminology confusing:
"type" seems to mean "new style class object", and
"object" seems to mean "instance."
What happens with the second operand is a bit of
sleight of hand. The object returned from super()
gives you access to the methods on the next level up the
mro, however when you use it to invoke a method,
then the 'self' passed to that method is the second
object, not the instance returned from super().
In most cases, this is exactly what you want, since if
the superclass method makes any changes to the
instance, you  want to be able to see them after the
call completes.
What is meant by the returning of an 'unbound' object
when the argument is omitted.
This is basically for calling static methods. Since a static
method is not passed an instance, you need a version of
the object returned from super() that doesn't bind the
method to an instance.
There is also the possibility that you might really want
to call an instance or class method as an unbound method,
explicitly passing it the instance. This is the reason that
the object returned from super() can't make the  distinction
automatically by simply checking for a static method.
Also, when would I pass an object as the second argument,
and when would I pass a type?
You need to pass the class object when you're calling
a class method. While __new__ is technically a static
method, for most practical purposes you can regard
it as a class method.
John Roth
Thanks,
Tobiah 
--
http://mail.python.org/mailman/listinfo/python-list

Re: pre-PEP: Print Without Intervening Space

[John Roth]

I'm against further tinkering with Print on a number
of grounds, not least of which is that it's going
away in Python 3.0. It seems like wasted effort.
I don't see much difficulty with the current behavior:
if you want to get rid of the spaces, there are
alternatives.
I don't buy the novice arguement. If you want,
you can always implement your own print
function with a variable number of arguements
and just about any semantics you want.
John Roth


"Marcin Ciura" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Here is a pre-PEP about print that I wrote recently.
Please let me know what is the community's opinion on it.
Cheers,
  Marcin
PEP: XXX
Title: Print Without Intervening Space
Version: $Revision: 0.0 $
Author: Marcin Ciura 
Status: Draft
Type: Standards Track
Created: 11-Mar-2005
Post-History: 11-Mar-2005
Abstract
This PEP proposes to extend the syntax of the print statement
so that its space-insertion mechanism can be selectively
disabled by using double instead of single commas.
Rationale
The print statement can write several expressions in one line,
but presently always separates them with spaces.  While this
behaviour is often desirable, not uncommon are situations, where
programmers have to use workarounds to achieve a non-spaced
display.  This has been recognized as one of "Python Gotchas"
[1].  Even the simplest workaround results in an unnecessarily
complicated code (for the sake of simplicity let us assume that
fn() returns strings):
result = ''
for x in seq:
result += fn(x)
print result
Not to mention it also has a terrible algorithmic complexity.
None of the more efficient solutions is particularly
straightforward, either:
result = []
for x in seq:
result.append(fn(x))
print ''.join(result)
print ''.join([fn(x) for x in seq])
print ''.join(fn(x) for x in seq)
Moreover, all of them require creating one or two temporary
objects to hold the entire result.  If the programmers use one of
them without qualms, it is only because their mind is warped by
the limitation of print.
Using write() is not especially appealing either, especially if
the print statements are used elsewhere in the code:
import sys
for x in seq:
sys.stdout.write(fn(x))
print # or sys.stdout.write('\n')
The proposed extension to the print statement is to use two
commas to signal that no space should be written after an
expression:
for x in seq:
print fn(x),,
print
To quote "The Zen of Python" [2]: "Beautiful is better than ugly.
Simple is better than complex.  Readability counts."
The proposal applies also to the expressions in the middle of
the print statement.  Thus it provides an alternative to string
concatenation and string interpolation, either with the '%'-based
specifiers, or with the '$'-based ones introduced by PEP 292 [3],
not requiring creating a temporary string object:
print 'The phone number is (',,extension,,')', number,,'.'
Note that I do not claim that the above version is any more
readable than
print 'The phone number is (%s) %s.' % (extension, number)
Specification
It is proposed to allow separating the expressions to be printed
by single or double commas, and to allow single or double commas
at the end of the print statement.  The two commas shall be
consecutive, i.e. there shall be no whitespace between them.
Non-consecutive commas or any sequence of more than two commas
constitute a syntax error.  In the "print chevron" form of the
statement, the name of the file object shall be separated from
the next expression only by a single comma, as it is now.
Formally, the proposed syntax of the extended print statement is
print_stmt: "print"
( [expression (("," | ",,") expression)* ["," | ",,"]]
| ">>" expression [(","
   expression (("," | ",,") expression)* ["," | ",,"]]
Implementing the proposed syntax may require introducing a new
type of token: double comma, or a hack in the parser to recognize
two consecutive commas in the context of the print statement.
Two new byte codes, parallel to PRINT_ITEM and PRINT_ITEM_TO, are
needed to implement the semantics of the proposal.
Discussion
Pros:
- The proposed semantics allows avoiding temporary string objects
  during the execution of the print statement and often makes for
  more readable and explicit source code.
- The proposed syntax is ea

Re: Python-list Digest, Vol 18, Issue 208

[John Roth]

"Charles Hartman" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
I know this isnt that big of a problem,
but i cannot think of one reason why they would not allow numbers 
preceded with a 0 to have a number
higher then a 7 in them...
And it seems very inconsistant to me...

Is there a reason for this?
I *love* questions I can answer! Answer: because that's how you tell 
Python you're entering an octal number. (Parallel to 0x for hexadecimals.) 
So beware of 010, which isn't the number of fingers you presumably have, 
unless you don't count the thumbs.
That's a reason, but I don't consider it a good reason.
I cannot, in fact, think of a single time when I've wanted
to enter an octal number. Hex numbers, yes, but  not
octal.
I personally don't think the frequency of use warrents
the special case syntax and the resultant confusion
with novices.
John Roth
Charles Hartman
--
http://mail.python.org/mailman/listinfo/python-list