Re: list index()

[TheFlyingDutchman]

On Aug 30, 9:06 pm, "Carsten Haese" <[EMAIL PROTECTED]> wrote:
> On Thu, 30 Aug 2007 20:17:00 -0700, zzbbaadd wrote
>
> > Well IN was what I was looking for and would have saved this thread.
> > However I don't believe IN showed up on the doc web page that has
> > list methods, where I found index().
>
> They're not on the exact same page, but index() is in section 3.6.4 of the
> library reference (http://docs.python.org/lib/typesseq-mutable.html), whereas
> "in" is in section 3.6 of the library reference
> (http://docs.python.org/lib/typesseq.html). I'm wondering how you managed to
> find subsection 3.6.4 without finding section 3.6.

www.google.com

search "python list methods"

first search find:

5. Data Structures
The list methods make it very easy to use a list as a stack, where the
last element added  Another useful data type built into Python is
the dictionary. ...
http://docs.python.org/tut/node7.html

"The list data type has some more methods. Here are all of the methods
of list objects:"



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

Re: list index()

[TheFlyingDutchman]

>
> Fair enough, but that's a tutorial. It would be foolish to demand that a
> tutorial be a complete reference for everything that can be done with a list.

I wasn't demanding anything of the page. I was pointing out how I made
the assumption there was no way to find out if a list has a value
other than by using index(). I am not used to having keywords in a
language operate on a data structure, in addition to its methods.

> The page lists all methods of list objects, but there are more things one can
> do with lists that don't look like method calls. For example, it doesn't say
> that you can compare lists. It doesn't say that you can read and write
> elements in the lists. Would you automatically assume that those things aren't
> possible? I hope not. (Of course, those operations are handled by the magical
> methods __eq__, __setitem__, __getitem__ etc, but I think one can forgive the
> tutorial for not mentioning those in the interest of not confusing beginners.)
>
> By your logic, no web page would be allowed to say anything about lists unless
> it says *everything* about lists, and that wouldn't be very useful.

As I just stated, I wasn't making a criticism of the page. But since
you are defending it, let's talk about Python documentation from the
perspective of an experienced programmer who is a new/casual user of
both Python and Java. If I am in the process of writing a little Java
program, java.sun.com provides documentation on its data structures
that show up right at the top of a google search for "Java ArrayList",
"Java Hashtable", etc.

If I am writing a little Python program and want to see what I can do
with a list, I google "python list" I get the tutorial page that has
been mentioned. Then the next query result is a page that is titled
the "Python Language Reference". But in this reference page for
"python str,unicode,list,tuple,buffer,xrange", I see operators that
work on lists and other data structures that I an mot concerned with,
but there is no list of "list methods". But I do see navigational
arrows that I hopefully assume will take me to a page where I can find
all the list methods - but that is not the case. I go from "3.6
Sequence Types -- str, unicode, list, tuple, buffer, xrange" to "3.6.1
String Methods" to "3.6.2 String Formatting Operations" to "3.6.3
XRange Type" to "3.6.4 Mutable Sequence Types". And then I'm done with
3.6 of the Python Language Reference and I never saw a list of list
methods or a page devoted to lists. So I bounce out to the table of
contents assuming that there must be an entry for "list" that will
show all the list methods and operators and give me a summary ala Java
ArrayList. But all I find are entries for UserList and AddressList. :(

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

Re: list index()

[TheFlyingDutchman]

>
> Actually there was. The OP's claim
> | There are a million situations where you can have an item not be in
> | a list and it is not an exception situation.
>
> ...is just plain nonsense. zzbbaadd neither does understand exceptions
> nor what they are used for in Python. An item not being in a list is
> an exception situation /by definition/.

It won't be /by definition/ in my fork of Python 3, which I am pleased
to announce now, is called Python 3.01 while in development, and will
be known as Python 3000 or Python 3K when it gets to a productional
release. So in regard to Python 3000, your statement will be plain
nonsense.



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

Re: Python is overtaking Perl

[TheFlyingDutchman]

> This chart is showing that amount of python programers is smaller every
> year :(

I saw an article maybe a year ago, regarding "best careers" that
completely contradicted previous articles I had seen in years gone by.
It said that the number of people in programming and related jobs
would decline in future decades.


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

parameter list notation

[TheFlyingDutchman]

I am trying to use a database written in Python called buzhug.

In looking at some of the functions I see this prototype:

def create(self,*fields,**kw):

I am not clear on what the * and the ** are for or what they
represent. Or, what are they referred to as so I can do a query for
information on them.

Thanks
TFD

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

Re: parameter list notation

[TheFlyingDutchman]

Well I did a search on "Python variable length arguments" and found a
hit that seems to explain the *fields parameter:

When you declare an argment to start with '*', it takes the argument
list into an array.

def foo(*args):
  print "Number of arguments:", len(args)
  print "Arguments are: ", args


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

Re: parameter list notation

[TheFlyingDutchman]

Steve, Ben, Duncan,

Thanks for the replies.

TFD


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

Re: parameter list notation

[TheFlyingDutchman]

On Sep 4, 1:53 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Mon, 03 Sep 2007 22:10:41 -0700, TheFlyingDutchman wrote:
> > Well I did a search on "Python variable length arguments" and found a
> > hit that seems to explain the *fields parameter:
>
> > When you declare an argment to start with '*', it takes the argument
> > list into an array.
>
> No it doesn't.
>
> >>> def test(*args):
>
> ... import array
> ... assert type(args) is array.array, "Not an array"
> ...>>> test(1, 2, 3)
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", line 3, in test
> AssertionError: Not an array

Oh, I forgot the context of the discussion! As you are well aware, my
Python fork() (which I am now calling PIEthun 3.01 in beta and PIEthun
3000 upon release) has made a few changes. Tuples are known as arrays.
Lists are known as uarrays (for updatable array) and the array module
has been renamed to homo_uarray (homogenous_updatable_array was just
too much typing).

In the future I will be sure to specify the context of my statements -
whether PIEthunic or Pythonic in nature.


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

Re: parameter list notation

[TheFlyingDutchman]

>
> Perhaps you could move further discussions to comp.lang.piethun?
>

Fair enough. Will contain PIEthun discussion to the PIEthun mailing
list and the aforementioned newsgroup once it is established.

It suddenly dawned on me while rereading my defense of my use of the
term "array"  that I wasn't the person who used array.

That came from here and was probably written by someone who has a lot
of experiences in languages other than Python:

http://snippets.dzone.com/posts/show/1713

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

Re: list index()

[TheFlyingDutchman]

>
> I explain it by noting that list.index and dict.get serve totally
> different purposes. The former returns the index given a value; the
> latter returns a value given a key.

And the former raises an exception if the value is not found, while
the latter returns None if the value is not found.

>
> There are many areas of poor symmetry in the language and libraries;
> it isn't particularly clever or difficult to find them if one
> looks. Doing so doesn't appear to illustrate any point I see relevant
> in this thread.

It has been stated in this thread, that in Python, exceptions are used
differently than in other languages. Rather than just use them for
catastrophic errors that can't be dealt with, Python raises exceptions
on routine and survivable situations such as an item not found in a
list. It was mentioned that an exception is more Pythonic than
returning a "not found" value.

Someone pointed out that find() in str was a contradiction to this
since it doesn't throw an exception but returns a "not found" value,
and the response was that it was believed that find() would be removed
from the language (if so, it does not currently show up on the
"removed list" as has_key() and a few others do -
http://docs.python.org/dev/3.0/whatsnew/3.0.html) and was only there
for "historical reasons".

I don't believe the poster was trying to illustrate a point already
mentioned in the thread, but to give a contradiction to statements in
the thread. He was asking the question - why doesn't dict.get() throw
an exception on not found if that is the Pythonic way?


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

Re: Using wild character

[TheFlyingDutchman]

On Sep 5, 10:00 pm, Sreeraj <[EMAIL PROTECTED]> wrote:
> hi,
>
>  I am a beginner in Python. I wish to know how can i filter a list of
> strings using wild characters.ie
> Lets say i have list countries =
> ["india","africa","atlanta","artica","nigeria"]. I need only the list
> of string starting with 'a'.
>
> thank you
>
> Sreeraj

The most thorough answer would no doubt involve regular expressions,
but they can be unpleasant.

To do a "string*" type wildcard filter as in your request:

myList =  ["india","africa","atlanta","artica","nigeria"]

newList = [ item for item in myList if item.startswith("a") ]


To do a "*string" wildcard filter use the endswith() function instead
of startswith() and to do a *string* type wildcard filter use
the find() function > -1.

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

Re: why should I learn python

[TheFlyingDutchman]

On Sep 6, 4:01 pm, windandwaves <[EMAIL PROTECTED]> wrote:
> On Sep 7, 10:44 am, Torsten Bronger <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > Hallöchen!
>
> > Tom Brown writes:
> > > [...] Python has been by far the easiest to develop in.  Some
> > > people might say it is not "real programming" because it is so
> > > easy.
>
> > I can't believe this.  Have you really heard such a statement?
>
> > Tschö,
> > Torsten.
>
> > --
> > Torsten Bronger, aquisgrana, europa vetus
> >   Jabber ID: [EMAIL PROTECTED]
> >   (Seehttp://ime.webhop.orgforICQ, MSN, etc.)
>
> but because I am really not much of a
> programmer, it is often too detailed for me).  I have limited time,
> but it does sound like something to learn, just for fun and for
> practical use.  How would you use it in a web development
> environment?

Python can be used as an apache module called mod_python and also as a
CGI language.

> I mean, in real practical terms.  Could it assist with
> php?

Since you said you are really not much of a programmer I wouldn't
consider learning two languages. I don't believe there is any tie in
between Python and PHP. It could assist in a Web application only in
the sense that you wrote part in PHP and part in Python. For Web
development PHP is, I believe, more prevalent and would be more of a
benefit on a resume. PHP use outside of a Web app is not very common
but is supposed to be possible so if your usage is primarily Web I
would go with PHP.




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

Re: Using wild character

[TheFlyingDutchman]

On Sep 6, 5:53 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
> En Thu, 06 Sep 2007 20:48:31 -0300, Zentrader <[EMAIL PROTECTED]>
> escribi?:
>
> > On Sep 6, 12:47 am, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
>
> >> Maybe better the ``in`` operator for the '*string*' type.  `str.find()`
> >> will go away in the future.
>
> > string.find serves a useful purpose in that it returns the starting
> > location of the string found, or -1 if not found, so if you wanted to
> > slice "abdecf" on"c", string.find will tell you where that is.
>
> PEP3100 says it will be removed, but at the same time says [UNLIKELY]...
> 
>
> partition serves almost the same purpose and its easier to use.
>
> --
> Gabriel Genellina

The Perl community has an expression "There is more than one way to do
it". As in, Perl is good because you have multiple choices (whether
it's a function/module/class/operator) of how to implement a
particular piece of logic.  More choices is often good, but this can
lead to a problem in that you might be presented with more things to
learn and or you come across less common ways of doing something that
you are not familiar with in code you are trying to understand.

Does the Python community have a position regarding duplicate ways in
the language to achieve something in your code?

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

Re: startswith( prefix[, start[, end]]) Query

[TheFlyingDutchman]

> Else, you could as well write your own testing function:
>
> def str_starts_with(astring, *prefixes):
>startswith = astring.startswith
>for prefix in prefixes:
>  if startswith(prefix):
>return true
>return false
>

What is the reason for
  startswith = astring.startswith
  startswith(prefix)

instead of
  astring.startswith(prefix)

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

Re: How to determine the bool between the strings and ints?

[TheFlyingDutchman]

On Sep 7, 8:40 am, "Jorgen Bodde" <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I have a dictionary with settings. The settinfgs can be strings, ints
> or bools. I would like to write this list dynamically to disk in a big
> for loop, unfortunately the bools need to be written as 0 or 1 to the
> config with WriteInt, the integers also with WriteInt and the strings
> with a simple Write.
>
> The list is something like;
>
> options[A] = True
> options[B] = 1
> options[C] = "Hello"
>
> I wanted to use isinstance to determine if it is a bool or an int or a
> string. However I am confused trying it out in the interactive editor;
>
> >>> a = False
> >>> if isinstance(a, bool):
>
> ... print "OK"
> ...
> OK>>> if isinstance(a, int):
>
> ... print "OK"
> ...
> OK
>
>
>
> I don't get it. is the bool derived from 'int' in some way? What is
> the best way to check if the config I want to write is an int or a
> bool ?
>
> Regards,
> - Jorgen

This came up in a discussion within the last two weeks but I cannot
find it in a search of google.

It appear that you can get the exact class (as opposed to "is this
class or a derivative" that isinstance() seems to provide)
 with the  __class__ attribute:


>>> a = True
>>> print a.__class__ == bool
True
>>> print a.__class__ == int
False
>>> b = 1
>>> print b.__class__ == int
True
>>> print b.__class__  == bool
False




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

Re: Python syntax wart

[TheFlyingDutchman]

It may be that a language that doesn't have a statement terminator
(which can be end-of-line) needs a statement continuation symbol.
(Excluding languages like Lisp that have parentheses everywhere).

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

Re: Enum class with ToString functionality

[TheFlyingDutchman]

On Sep 10, 2:28 am, [EMAIL PROTECTED] wrote:
> Hi,
>
> I have the following class -
>
> class TestOutcomes:
> PASSED = 0
> FAILED = 1
> ABORTED = 2
>
> plus the following code -
>
> testResult = TestOutcomes.PASSED
>
> testResultAsString
> if  testResult == TestOutcomes.PASSED:
> testResultAsString = "Passed"
> elif testResult == TestOutcomes.FAILED :
> testResultAsString = "Failed"
> else:
> testResultAsString = "Aborted"
>
> But it would be much nicer if I had a function to covert to string as
> part of the TestOutcomes class. How would I implement this?
>
> Thanks,
>
> Barry

The equivalent to Java's toString() is __str__() in Python:

class TestOutcomes:
PASSED = 0
FAILED = 1
ABORTED = 2

def __init__(self,outcome):
self.outcome = outcome

def __str__(self):
if  self.outcome == TestOutcomes.PASSED:
   return "Passed"
elif self.outcome == TestOutcomes.FAILED :
   return "Failed"
else:
   return "Aborted"

if __name__ == "__main__":
testResult = TestOutcomes(TestOutcomes.ABORTED)
print testResult
testResult = TestOutcomes(TestOutcomes.FAILED)
a = testResult.__str__()
print a

Aborted
Failed


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

Re: Enum class with ToString functionality

[TheFlyingDutchman]

On Sep 10, 2:28 am, [EMAIL PROTECTED] wrote:
> Hi,
>
> I have the following class -
>
> class TestOutcomes:
> PASSED = 0
> FAILED = 1
> ABORTED = 2
>
> plus the following code -
>
> testResult = TestOutcomes.PASSED
>
> testResultAsString
> if  testResult == TestOutcomes.PASSED:
> testResultAsString = "Passed"
> elif testResult == TestOutcomes.FAILED :
> testResultAsString = "Failed"
> else:
> testResultAsString = "Aborted"
>
> But it would be much nicer if I had a function to covert to string as
> part of the TestOutcomes class. How would I implement this?
>
> Thanks,
>
> Barry

class TestOutcomes:
PASSED = 0
FAILED = 1
ABORTED = 2

def ToString(outcome):
if  outcome == TestOutcomes.PASSED:
   return "Passed"
elif outcome == TestOutcomes.FAILED :
   return "Failed"
else:
   return "Aborted"

ToString = staticmethod(ToString)

if __name__ == "__main__":
testResult = TestOutcomes.PASSED
testResultAsString = TestOutcomes.ToString(testResult)
print testResultAsString
print TestOutcomes.ToString(testResult)


Passed
Passed

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

Re: Python syntax wart

[TheFlyingDutchman]

On Sep 9, 11:20 pm, TheFlyingDutchman <[EMAIL PROTECTED]> wrote:
> It may be that a language that doesn't have a statement terminator
> (which can be end-of-line) needs a statement continuation symbol.
> (Excluding languages like Lisp that have parentheses everywhere).

Actually I guess Python does have a statement terminator - end-of-
line.
If you use end-of-line as your statement terminator it is difficult
and maybe impossible
to avoid a line-continuation character in those situations where you
don't want
an end-of-line to terminate your statement.

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

Re: Python syntax wart

[TheFlyingDutchman]

On Sep 10, 4:45 am, Bjoern Schliessmann  wrote:
> TheFlyingDutchman wrote:
> > It may be that a language that doesn't have a statement terminator
> > (which can be end-of-line) needs a statement continuation symbol.
>
> Which language could that be? I can hardly imagine making a complex
> program out of one statement.
>
> Regards,
>
> Björn
>
> --
> BOFH excuse #147:
>
> Party-bug in the Aloha protocol.

Funny how I mentioned end-of-line but didn't include Python as one
those languages that used it.
I should have said "It may be that a language that doesn't have a
statement terminator
symbol, but instead uses end-of-line, can't avoid a statement
continuation symbol.

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

Re: Enum class with ToString functionality

[TheFlyingDutchman]

On Sep 8, 9:52 am, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
> TheFlyingDutchman a écrit :
>
>
>
> > On Sep 10, 2:28 am, [EMAIL PROTECTED] wrote:
>
> >>Hi,
>
> >>I have the following class -
>
> >>class TestOutcomes:
> >>PASSED = 0
> >>FAILED = 1
> >>ABORTED = 2
>
> >>plus the following code -
>
> >>testResult = TestOutcomes.PASSED
>
> >>testResultAsString
> >>if  testResult == TestOutcomes.PASSED:
> >>testResultAsString = "Passed"
> >>elif testResult == TestOutcomes.FAILED :
> >>testResultAsString = "Failed"
> >>else:
> >>testResultAsString = "Aborted"
>
> >>But it would be much nicer if I had a function to covert to string as
> >>part of the TestOutcomes class. How would I implement this?
>
> >>Thanks,
>
> >>Barry
>
> > class TestOutcomes:
> > PASSED = 0
> > FAILED = 1
> > ABORTED = 2
>
> > def ToString(outcome):
> > if  outcome == TestOutcomes.PASSED:
> >return "Passed"
> > elif outcome == TestOutcomes.FAILED :
> >return "Failed"
> > else:
> >return "Aborted"
>
> > ToString = staticmethod(ToString)
>
> > if __name__ == "__main__":
> > testResult = TestOutcomes.PASSED
> > testResultAsString = TestOutcomes.ToString(testResult)
> > print testResultAsString
> > print TestOutcomes.ToString(testResult)
>
> Technically correct, but totally unpythonic.

Speaking of unpythonic, I would call

  ToString = staticmethod(ToString)

A Perlific syntax.

>
> May I suggest some reading 
> ?http://dirtsimple.org/2004/12/python-is-not-java.html

Well the Foo.Foo complaint is bogus:

from Foo import Foo

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

Re: Enum class with ToString functionality

[TheFlyingDutchman]

>
> I'd like to know if the Cheeseshop package 'enum' is useful to
> you. Any constructive feedback would be appreciated.
>
> http://cheeseshop.python.org/pypi/enum/>

Looking at the documentation it looks excellent. But I don't
understand the 0.4.2 version number, particularly when you refer to it
as robust.

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

Re: Enum class with ToString functionality

[TheFlyingDutchman]

On Sep 10, 7:12 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> TheFlyingDutchman <[EMAIL PROTECTED]> writes:
> > > http://cheeseshop.python.org/pypi/enum/>
>
> (Please preserve attribution lines so it's clear who wrote what.)
>
> > Looking at the documentation it looks excellent. But I don't
> > understand the 0.4.2 version number,
>
> Note the tag that says the "Development Status" is "Beta".
>
> > particularly when you refer to it as robust.
>
> I assume you're referring to the short description, "Robust enumerated
> type support in Python".
>
> That refers to the implemented type as robust, not the state of the
> code. That is, the short description should be read as "Support, in
> Python, for robust enumerated types". It's a description of the
> package functionality.
>
> If, of course, the state of the code is not robust, that's a bug that
> needs to be fixed; but that's true for any package.
>
> --
>  \ "Try to become not a man of success, but try rather to become a |
>   `\   man of value." -Albert Einstein |
> _o__)  |
> Ben Finney

What is the difference between this version and the 1.0 version?

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

Re: Enum class with ToString functionality

[TheFlyingDutchman]

On Sep 10, 8:02 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> TheFlyingDutchman <[EMAIL PROTECTED]> writes:
> > On Sep 10, 7:12 pm, Ben Finney <[EMAIL PROTECTED]>
> > wrote:
> > > TheFlyingDutchman <[EMAIL PROTECTED]> writes:
> > > > Looking at the documentation it looks excellent. But I don't
> > > > understand the 0.4.2 version number,
>
> > > Note the tag that says the "Development Status" is "Beta".
>
> > What is the difference between this version and the 1.0 version?
>
> I don't know yet, since my time machine is currently in for repairs.
>
> --
>  \  "If you ever reach total enlightenment while you're drinking a |
>   `\   beer, I bet it makes beer shoot out your nose."  -- Jack Handey |
> _o__)  |
> Ben Finney

When you were developing your Enum module, how did you determine you
were at the 0.4.2 version as opposed to the 0.7.1 version or the 0.9.2
version?

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

Re: Enum class with ToString functionality

[TheFlyingDutchman]

On Sep 10, 7:55 pm, "J. Cliff Dyer" <[EMAIL PROTECTED]> wrote:
> TheFlyingDutchman wrote:
> > On Sep 10, 7:12 pm, Ben Finney <[EMAIL PROTECTED]>
> >  wrote:
> >> TheFlyingDutchman <[EMAIL PROTECTED]> writes:
> >>>> http://cheeseshop.python.org/pypi/enum/>
> >> (Please preserve attribution lines so it's clear who wrote what.)
>
> >>> Looking at the documentation it looks excellent. But I don't
> >>> understand the 0.4.2 version number,
> >> Note the tag that says the "Development Status" is "Beta".
>
> >>> particularly when you refer to it as robust.
> >> I assume you're referring to the short description, "Robust
> >> enumerated type support in Python".
>
> >> That refers to the implemented type as robust, not the state of
> >> the code. That is, the short description should be read as
> >> "Support, in Python, for robust enumerated types". It's a
> >> description of the package functionality.
>
> >> If, of course, the state of the code is not robust, that's a bug
> >> that needs to be fixed; but that's true for any package.
>
> >> -- \ "Try to become not a man of success, but try rather to
> >> become a | `\   man of value."
> >> -Albert Einstein | _o__)
> >> | Ben Finney
>
> > What is the difference between this version and the 1.0 version?
>
> Uh... The 1.0 version is vaporware?
>
> Cheers,
> Cliff

I think not. 42% of it is alive and kicking as we speak.

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

Re: cpython list __str__ method for floats

[TheFlyingDutchman]

On Sep 11, 4:07 am, "[david]" <[EMAIL PROTECTED]> wrote:
> returns poorly formatted values:
>
>  >>>str(13.3)
> '13.3'
>  >>>str([13.3])
> '[13.301]'
>
> [david]

There is some difference in the way repr() and str() convert floats to
strings:

>>> a = 13.3
>>> print str(a)
13.3
>>> print repr(a)
13.301
>>> a
13.301
>>> a.__str__()
'13.3'
>>> a.__repr__()
'13.301'
>>>

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

Python 3K or Python 2.9?

[TheFlyingDutchman]

Python user and advocate Bruce Eckel is disappointed with the
additions (or lack of additions) in Python 3:

http://www.artima.com/weblogs/viewpost.jsp?thread=214112

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

Re: Get the complete command line as-is

[TheFlyingDutchman]

On Sep 11, 8:00 pm, wangzq <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm passing command line parameters to my browser, I need to pass the
> complete command line as-is, for example:
>
> test.py "abc def" xyz
>
> If I use ' '.join(sys.argv[1:]), then the double quotes around "abc
> def" is gone, but I need to pass the complete command line ("abc def"
> xyz) to the browser, how can I do this?
>
> I'm on Windows.
>
> Thanks.

I'm on Solaris and this works for me:

test.py '"abc def" xyz'



print sys.arv[1]

"abc def" xyz

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

Re: Get the complete command line as-is

[TheFlyingDutchman]

On Sep 11, 8:33 pm, TheFlyingDutchman <[EMAIL PROTECTED]> wrote:
> On Sep 11, 8:00 pm, wangzq <[EMAIL PROTECTED]> wrote:
>
> > Hello,
>
> > I'm passing command line parameters to my browser, I need to pass the
> > complete command line as-is, for example:
>
> > test.py "abc def" xyz
>
> > If I use ' '.join(sys.argv[1:]), then the double quotes around "abc
> > def" is gone, but I need to pass the complete command line ("abc def"
> > xyz) to the browser, how can I do this?
>
> > I'm on Windows.
>
> > Thanks.
>
> I'm on Solaris and this works for me:
>
> test.py '"abc def" xyz'
>
> print sys.arv[1]
>
> "abc def" xyz

OK, now I'm on Windows XP and things aren't looking too good.

It seems that \" will retain the quote marks but then the spaces get
gobbled.

But if you replace the spaces with another character:

python.exe test.py  \"abc#def\"#123

then:

import sys
commandLine = "".join(sys.argv[1:])

prints commandLine.replace('#',' ')

gives:

"abc def" 123

Don't know if you can use that technique or not.

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

Re: Get the complete command line as-is

[TheFlyingDutchman]

>
> It seems that \" will retain the quote marks but then the spaces get
> gobbled.
>
> But if you replace the spaces with another character:
>
> python.exe test.py  \"abc#def\"#123
>
> then:
>
> import sys
> commandLine = "".join(sys.argv[1:])
>
> prints commandLine.replace('#',' ')
>
> gives:
>
> "abc def" 123
>
> Don't know if you can use that technique or not.

Came back for a second try and found out that:

python.exe test.py  "\"abc def\" 123"

import sys
commandLine = "".join(sys.argv[1:])

print commandLine

gives:

"abc def" 123

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

Re: Get the complete command line as-is

[TheFlyingDutchman]

>
> python.exe test.py  "\"abc def\" 123"
>
> import sys
> commandLine = "".join(sys.argv[1:])
>
> print commandLine
>
> gives:
>
> "abc def" 123

With the surrounding quotes you actually only need:

commandLine = sys.argv[1]

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

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

On Sep 12, 4:40 am, Bjoern Schliessmann  wrote:
> Ivan Voras wrote:
> > What does "self" have to do with an object model? It's an
> > function/method argument that might as well be hidden in the
> > compiler without ever touching the role it has (if not, why?). I
> > agree that it's needless noise in a language.
>
> If this was needless, why do C++ and Java have the "this" pointer?
>
"this" in C++ and Java is not shown in the parameter list, which was
what he was
complaining about.  He wants

class MyClass:
def SomeFunction(someParameter):
   self.someParameter = someParameter

not

class MyClass:
def SomeFunction(self, someParameter):
   self.someParameter = someParameter


The confusing way about the current Python method when you first
encounter it is
 why is "self" being passed in when you write the function but not
when you call it. If the compiler is smart enough to know that

a = MyClass()
a.SomeFunction(12)

SomeFunction() has a "self" implicitly added to the parameter list, it
seems that it should be smart enough to know that a function defined
in a class has a "self" implicitly added to the parameter list.


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

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

>
> "this" in C++ and Java is not shown in the parameter list, which was
> what he was
> complaining about.  He wants
>
> class MyClass:
> def SomeFunction(someParameter):
>self.someParameter = someParameter
>
> not
>
> class MyClass:
> def SomeFunction(self, someParameter):
>self.someParameter = someParameter
>
> The confusing way about the current Python method when you first
> encounter it is
>  why is "self" being passed in when you write the function but not
> when you call it. If the compiler is smart enough to know that
>
> a = MyClass()
> a.SomeFunction(12)
>
> SomeFunction() has a "self" implicitly added to the parameter list, it
> seems that it should be smart enough to know that a function defined
> in a class has a "self" implicitly added to the parameter list.

In C++ and Java I don't believe "this" is ever referred to as an
implicit function parameter. It is a (sometimes necessary) way to
reference the object inside one if it's methods. If it is in fact a
real parameter in the underlying compiled-code implementation, that
knowledge hurts more than it helps.

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

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

On Sep 12, 3:53 pm, Bjoern Schliessmann  wrote:
> TheFlyingDutchman wrote:
> > In C++ and Java I don't believe "this" is ever referred to as an
> > implicit function parameter.
>
> Oh yes, it is. All methods use it as a base address into instances.
> Implicitly though.

I am not talking about how the implementation of a C++ or Java
compiler uses the this pointer/this reference internally. I am talking
about how an author describes in English the "this" pointer/reference
in their book on programming C++ or Java.

I don't think you will find them saying that under the covers "this"
was passed to the method (if in fact it is). They just say that it
refers to the current object inside that object's method.

Here is a link to a tutorial where Sun is talking about the this
reference:
http://java.sun.com/docs/books/tutorial/java/javaOO/thiskey.html



> > If it is in fact a real parameter in the underlying compiled-code
> > implementation, that knowledge hurts more than it helps.
>
> To which language are you referring here, Python or C++? No matter
> what, I still don't really understand why it hurted.
>
I am referring to C++. If someone is trying to learn the language,
knowledge of the internal implemenation is counter-productive in my
opinion because it distracts from the details they need to learn. If
they are experienced and want to learn about the internals to
potentially help them code in the most blazingingly fast manner they
ideally would just be reminded they are using C++ and not some slower
byte-code executed language where it could possibly matter. ;)

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

Re: Coming from Perl

[TheFlyingDutchman]

On Sep 12, 5:30 pm, Amer Neely <[EMAIL PROTECTED]> wrote:
> I'm a complete newbie with Python, but have several years experience
> with Perl in a web environment.
>
> A question I have, if someone here is familiar with Perl, does Python
> have something like Perl's 'here document'? I've just searched and read
> some postings on generating HTML but they all seem to refer to various
> template utilities. Is this the only way, or am I missing something? I'm
> used to generating X/HTML by hand, which makes the here document in Perl
> ideal for me. Also, many times a client already existing HTML code that
> I can use in a script.
>
> --
> Amer Neely
> w:www.webmechanic.softouch.on.ca/
> Perl | MySQL programming for all data entry forms.
> "Others make web sites. We make web sites work!"

I am not sure if this is what you are looking for, but Python has a
special string with 3 quotes that I believe duplicates part of the
functionality of a here document:

myHmtlHeader = """

My Page

"""

print myHtmlHeader


outputs:



My Page


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

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

On Sep 12, 5:47 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> TheFlyingDutchman <[EMAIL PROTECTED]> writes:
> > I am talking about how an author describes in English the "this"
> > pointer/reference in their book on programming C++ or Java.
>
> > I don't think you will find them saying that under the covers "this"
> > was passed to the method (if in fact it is). They just say that it
> > refers to the current object inside that object's method.
>
> In other words, it's magic, and the behaviour has to be explained so
> the reader knows where the undeclared 'this' comes from.

I would disagree that it _has_ to be explained where it came from. I
think knowing that the compiler is providing it is sufficient. Any
further knowledge of what the compiler is doing under the covers to
provide it is unnecessary. Sun made no mention of where "this" comes
from in that link I provided.

>
> How is that preferable to the magic of "instance is passed as the
> first argument to a method"?

I would mention that an instance is passed as the first parameter
argument of a method if the methods were declared with the extra
argument and called with the extra argument:


a = MyClass()

my_method(a,someParameter)

Then it makes sense to me to talk about it.




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

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

> >>> Foo.bar(foo, "spam")
> >>> foo.bar("spam")

That looks like a case of "There's more than one way to do it". ;)
The first form is definitely consistent with the
method declaration, so there's a lot to be said for using that style
when teaching people to make classes -> send self, receive self.


> The latter two statements are equivalent. The 'instance.method(args)'
> syntax is just sugar for 'Class.method(instance, args)'.

I think I saw where Guido Van Rossum had referred to something as
"syntactic sugar" in some python.org page. I am not familiar with
sugar as related to syntax. Is it being used as a synonym for "easier
way of doing it"?

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

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

Well I'm with Bruce Eckel - there shouldn't be any argument for the
object in the class method parameter list. But since Python 3 was
"code-named" 3000 (implying but not delivering big changes... I don't
think it required big changes) and since it still has an explicit
object parameter it's a given that it's not gonna happen in any
revisions.

Bruce said that no other mainstream OO language is explicitly passing
the object as a parameter to class methods. But Perl does it as well.
I think the label "mainstream OO language" is as valid being applied
to Perl as it is to Python.

What I would like to have seen added to class definitions was the
forced declaration of all object variables in the class outside of
methods. I don't like the fact that they have to be, and can be
created in any method on the fly.

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

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

>
> > Here is a link to a tutorial where Sun is talking about the this
> > reference:
> >http://java.sun.com/docs/books/tutorial/java/javaOO/thiskey.html
>
> That's a tutorial for getting you started, no reference
> documentation or in-depth course.
>
Here's a FAQ item where they refer to it as I think Python should have
done it - a special predefined variable:

http://www.faqs.org/docs/javap/c5/s5.html

"Java provides a special, predefined variable named "this" that you
can use for such purposes. The variable, this, is used in the source
code of an instance method to refer to the object that contains the
method. This intent of the name, this, is to refer to "this object,"
the one right here that this very method is in. If x is an instance
variable in the same object, then this.x can be used as a full name
for that variable. If otherMethod() is an instance method in the same
object, then this.otherMethod() could be used to call that method.
Whenever the computer executes an instance method, it automatically
sets the variable, this, to refer to the object that contains the
method."



"this" is hard to query on but I would be interested in seeing some
site talking about Java where "this" is mentioned as being "passed
in".



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

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

>
> Isn't one of the main ideas behind python that it doesn't force you to
> do (well, declare) anything? And by "ideas" I mean "design decisions".
> Thats exactly what makes python great for prototyping; you just do it
> and see if it works. As soon as you need to declare things you have to
> change stuff in at least 2 places for every change of heart you have.
>
> (Can you tell I'm currently forced to developing in Java? ;) (Which I'm
> currently avoiding to do, by wasting my time on usenet.))
>
But if you are looking at code you didn't write, it's nice to be able
to see all the member variables that a class has listed separate from
method code.

I think static typing helps in trying to deduce what code is doing,
particularly when you are looking at function definitions. You don't
have to work to find out what type of variables it takes.


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

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

>
> (Can you tell I'm currently forced to developing in Java? ;) (Which I'm
> currently avoiding to do, by wasting my time on usenet.))
>

Maybe you can sneak Jython into the mix. Just describe it as "this
Java scripting language".




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

Re: How to Start

[TheFlyingDutchman]

On Sep 13, 2:59 pm, [EMAIL PROTECTED] (Michael R. Copeland) wrote:
>I've decided that Python is a language/environment I'd like to learn
> (I've been a professional programmer for 45+ years), but I really don't
> know where and how to start!  I have a number of books - and am buying
> some more - but because of the bewildering number of after-market
> packages, environments, and add-ons, I am really quite perplexed about
> starting.  8<{{
>Yes, I could fire up the interactive mode and play with some
> statements...but I consider that sort of thing for programming neophytes
> or experimenting with specific issues.  First, I want to develop a
> simple Windows application, and because of the plethora of "stuff" the
> Python world offers, I don't know where to begin.
>For example, what basic, easy-to-use interface might I start with to
> build a simple text file parsing and analysis program?  That is, I'd
> like to start with a simple Windows shell that prompts for a file name,
> processes it, and then displays some result.
>I am certainly impressed with the apparent experience and openness of
> the regular players here, but the discussions here (and in
> c.l.p.announce) truly presume knowledge and experience with Python I
> don't yet have.  Yes, for even a very experienced programmer, entering
> the Python world is very daunting - but I want to get started.
>Please advise.  TIA

I like Wing IDE ( http://www.wingware.com ) . They have a free version
and Personal and Professional versions.

The free version description says:
"Wing IDE 101

Wing IDE 101 is a free basic edition of Wing IDE that was originally
designed with the University of Toronto Computer Science Department
for teaching entry level computer science courses. It is not open
source but is free for use by educators, students, and hobbyists.

Note that Wing IDE 101 omits auto-completion and most other code
intelligence features in the other Wing IDE products. This was by
design, so that students are more conscious of the details of the
language and modules they are learning about."

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

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

> If you look at the thread "parameter list notation" from ten days or so
> ago, TheFlyingDutchman has forked Python and is working on a very special
> new language, PIEthun 3.01B.
> I for one am looking forward to seeing all
> the very special features of PIEthun.

It will be named PIEthun 3000 as it comes out of Beta. But you're not
alone. From the emails I have been receiving there is anticipation and
excitement from Mumbai to Dusseldorf to Caracas.

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

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

>
> 
>
> Hi, I'm new to Python, I don't even fully know the language, never done
> a full project in Python. What's more, probably I'll never will.
> But that's not the point, the point is I want YOU people to modify the
> language you know in and out, the program with which you've done many
> systems, I want you to change it to suit my whims, so that I'll be
> comfortable with the 3 ten liners I'll write.
> TIA
>
> 


Hi, I've used Python and have fallen in love with it. I know exactly
how Guido pronounces his name and since I saw him use the obtuse
phrase syntactic sugar I try and work it into every discussion I have
on Python syntax. I hate it when anyone offers criticism of Guido's
language. I have a picture of Bruce Eckel with a red universal not
sign over it on my wall and I throw my mechanical pencils at it every
night. I am especially upset when someone talks bad about kluges like
@staticmethod or FunctionName = staticmethod(FunctionName). Sure "def
static" or "static def" would be so much cleaner, simpler and clearer
but let's face it my fellow Pythonistas, this language may have
started out based on what was easy for people to learn and use but
we're in Nerdville now and clean and clear have become roadblocks! I
have so much more respect for Perl and the way it developed now!


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

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

> The other half of the confusion is cleared up by considering that
> Python methods are ordinary functions that don't magically "know" in
> which "class" context they are executing: they must be told via the
> first parameter.
>

They can be told all they want by the compiler/runtime - implicitly -
under-the-covers, out-of-sight.

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

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

If you wanna know why the Renault Dauphine requires the driver to pull
down on the rearview mirror in order to shift into reverse you simply
need to open the hood and remove the engine and disassemble the
transmission and you will see that it has no way of distinguishing a
shift into third from a shift into reverse without a rearview mirror
pull. But these days most people just open the glove compartment when
shifting into reverse which works just as well!
 


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

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

On Sep 17, 4:02 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> TheFlyingDutchman wrote:
> >> The other half of the confusion is cleared up by considering that
> >> Python methods are ordinary functions that don't magically "know" in
> >> which "class" context they are executing: they must be told via the
> >> first parameter.
>
> > They can be told all they want by the compiler/runtime - implicitly -
> > under-the-covers, out-of-sight.
>
> I wish you would keep these deep insightful comments to yourself. Your
> knowledge of the interpreter internals appears to be based on
> examination by crystal ball.

I am not talking about the way it does it, but rather, the way it
could do it or... could have done it. That requires no knowledge of
how the interpreter currently does it unless I am proposing something
that no interpreter in the world could ever do.

>
> You conveniently ignore the fact that the situation described by David
> Trudgett (and, by the way, your quoting with no attributions is also
> becoming tiresome very quickly) is a *design choice*, not a mistake.
> It's done precisely to make an explicit reference to the instance
> available to methods.
>


For your own information, supercilious references to the interpreter
internals become tiresome quickly.

I made a complaint about a small design choice. I also made it in the
past tense at least once ("should have done it") and explicitly
expressed that I knew it wasn't going to happen. Python was created
based on a language that was designed to make it easy to use by
beginners. Doing so made it a clean and clear language. My preference
is for everything to be as clean and clear as possible. If I didn't
I'd never have bothered with Python since Perl is much more popular
among programmers I have come across.

Jury-rigging new features is going to make the elite happy but very
likely will be viewed differently by us average programmers.

> change other aspects of the language, such as the ability to graft
> functions into instances and classes as methods.

Those are elite-type features that make code harder to understand by
average programmers and probably the elite as well. To paraphrase
someone "He thought he'd solve the problem by grafting functions into
classes and grafting classes into methods. Then he had two problems".

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

Re: Will Python 3.0 remove the global interpreter lock (GIL)

[TheFlyingDutchman]

On Sep 2, 5:38 pm, "Eduardo O. Padoan" <[EMAIL PROTECTED]>
wrote:
> > No.http://www.artima.com/weblogs/viewpost.jsp?thread=211430
>
> Ops, I meant:http://www.artima.com/forums/threaded.jsp?forum=106&thread=211200
>
> --http://www.advogato.org/person/eopadoan/
> Bookmarks:http://del.icio.us/edcrypt

"No. We're not changing the CPython implementation much. Getting rid
of the GIL would be a massive rewrite of the interpreter because all
the internal data structures (and the reference counting operations)
would have to be made thread-safe. This was tried once before (in the
late '90s by Greg Stein) and the resulting interpreter ran twice as
slow."

How much faster/slower would Greg Stein's code be on today's
processors versus CPython running on the processors of the late
1990's? And if you decide to answer, please add a true/false response
to this statement - "CPython in the late 1990's ran too slow".

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

Re: Will Python 3.0 remove the global interpreter lock (GIL)

[TheFlyingDutchman]

On Sep 19, 8:51 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Tue, 18 Sep 2007 18:09:26 -0700, TheFlyingDutchman wrote:
> > How much faster/slower would Greg Stein's code be on today's processors
> > versus CPython running on the processors of the late 1990's?
>
> I think a better question is, how much faster/slower would Stein's code
> be on today's processors, versus CPython being hand-simulated in a giant
> virtual machine made of clockwork?
>
> --
> Steven.

Steven, You forgot this part:

"And if you decide to answer, please add a true/false response
to this statement - "CPython in the late 1990's ran too slow"'.


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

Google and Python

[TheFlyingDutchman]

Around 2000 I heard that Google was using Python to some extent. Now I
see that Guido Van Rossum works for them as well as Alex Martellis who
has the title "Uber Technical Lead" which seems to imply some fairly
heavy Python usage there. I was wondering what is done at Google with
Python and which Python "environments/applications" (Zope, TurboGears,
mod_python ...) are in use, and what is done with other languages, and
which other languages are they using.

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

Re: Google and Python

[TheFlyingDutchman]

> Have you tried Google "google python".  Turns up a lot of links for me.
>
I had done it on this newsgroup, but not google. I did find a pretty
good link:

http://panela.blog-city.com/python_at_google_greg_stein__sdforum.htm

Which says:
"A few services including code.google.com and google groups.  Most
other front ends are in C++ (google.com) and Java (gmail).  All web
services are built on top of a highly optimizing http server wrapped
with SWIG."

I am not clear on how you would use a language - whether C++, Java or
Python to write the web app with this custom http server. Is this http
server what is referred to as an "application server" or is it the
main web server which is usually Apache at most sites?

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

Re: Google and Python

[TheFlyingDutchman]

On Sep 19, 1:02 pm, Erik Jones <[EMAIL PROTECTED]> wrote:
> is usually Apache at most sites?
>
> No an http server and application server are two different things.  
> An http server services requests of a web server those requests can  
> be for static files or for services of a local application in which  
> case the request if forwarded on to the application.  An application  
> services requests of an application.  They are separate concepts,  
> often chained, although they are sometimes implemented together.  
> What they are saying here is that they have built a highly optimizing  
> custom web server in C++ that services web requests for services of  
> applications written in any of the three listed languages.  So, yes,  
> in this case it is what is often Apache in other installations.
>
OK, thanks. Would you know what technique the custom web server uses
to invoke a C++ app (ditto for Java and Python) CGI is supposed to be
too slow for large sites.


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

Re: Will Python 3.0 remove the global interpreter lock (GIL)

[TheFlyingDutchman]

On Sep 19, 3:41 pm, Paul Boddie <[EMAIL PROTECTED]> wrote:
> On 19 Sep, 03:09, TheFlyingDutchman <[EMAIL PROTECTED]> wrote:
>
>
>
> > How much faster/slower would Greg Stein's code be on today's
> > processors versus CPython running on the processors of the late
> > 1990's? And if you decide to answer, please add a true/false response
> > to this statement - "CPython in the late 1990's ran too slow".
>
> Too slow for what? And what's the fixation with CPython, anyway? Other
> implementations of Python 2.x don't have the GIL. Contrary to popular
> folklore, Jython has been quite a reasonable implementation of Python
> for about half as long as CPython has been around, if you don't mind
> the JVM. I'm sure people have lots of complaints about Jython like
> they do about CPython and the GIL, thinking that complaining about it
> is going to make the situation better, or that they're imparting some
> kind of "wisdom" to which the people who actually wrote the code must
> be oblivious, but nobody is withholding the code from anyone who wants
> to actually improve it.

>
> And there we learn something: that plenty of people are willing to
> prod others into providing them with something that will make their
> lives better, their jobs easier, and their profits greater, but not so
> many are interested in contributing back to the cause and taking on
> very much of the work themselves. Anyway, the response to your
> statement is "false". Now you'll have to provide us with the insight
> we're all missing. Don't disappoint!
>
> Paul

Paul it's a pleasure to see that you are not entirely against
complaints.

The very fastest Intel processor of the last 1990's that I found came
out in October 1999 and had a speed around 783Mhz. Current fastest
processors are something like 3.74 Ghz, with larger caches. Memory is
also faster and larger. It appears that someone running a non-GIL
implementation of CPython today would have significantly faster
performance than a GIL CPython implementation of the late 1990's.
Correct me if I am wrong, but it seems that saying non-GIL CPython is
too slow, while once valid, has become invalid due to the increase in
computing power that has taken place.

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

Re: Will Python 3.0 remove the global interpreter lock (GIL)

[TheFlyingDutchman]

On Sep 19, 8:54 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Wed, 19 Sep 2007 19:14:39 -0700, Paul Rubin wrote:


>
> > etc. is at best an excuse for laziness.
>
> What are you doing about solving the problem? Apart from standing on the
> side-lines calling out "Get yer lazy behinds movin', yer lazy bums!!!" at
> the people who aren't even convinced there is a problem that needs
> solving?

He's trying to convince the developers that there is a problem. That
is not the same as your strawman argument.

>
> > And more and more often, in the
> > application areas where Python is deployed, it's just plain wrong.  Take
> > web servers: a big site like Google has something like a half million of
> > them.  Even the comparatively wimpy site where I work has a couple
> > thousand.  If each server uses 150 watts of power (plus air
> > conditioning), then if making the software 2x faster lets us shut down
> > 1000 of them,
>
> What on earth makes you think that would be anything more than a
> temporary, VERY temporary, shutdown? My prediction is that the last of
> the machines wouldn't have even been unplugged before management decided
> that running twice as fast, or servicing twice as many people at the same
> speed, is more important than saving on the electricity bill, and they'd
> be plugged back in.
>
Plugging back in 1000 servers would be preferable to buying and
plugging in 2000 new servers which is what would occur if the software
in this example had not been sped up 2x and management had still
desired a 2x speed up in system performance as you suggest.

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

Re: Will Python 3.0 remove the global interpreter lock (GIL)

[TheFlyingDutchman]

On Sep 19, 5:08 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> "Terry Reedy" <[EMAIL PROTECTED]> wrote in message

This is a little confusing because google groups does not show your
original post (not uncommon for them to lose a post in a thread - but
somehow still reflect the fact that it exists in the total-posts
number that they display) that you are replying to.


>
> This assumes that comparing versions of 1.5 is still relevant.  As far as I
> know, his patch has not been maintained to apply against current Python.
> This tells me that no one to date really wants to dump the GIL at the cost
> of half Python's speed.  Of course not.  The point of dumping the GIL is to
> use multiprocessors to get more speed!  So with two cores and extra
> overhead, Stein-patched 1.5 would not even break even.
>
> Quad (and more) cores are a different matter.  Hence, I think, the
> resurgence of interest.

I am confused about the benefits/disadvantages of the "GIL removal".
Is it correct that the GIL is preventing CPython from having threads?

Is it correct that the only issue with the GIL is the prevention of
being able to do multi-threading?

If you only planned on writing single-threaded applications would GIL-
removal have no benefit?

Can threading have a performance benefit on a single-core machine
versus  running multiple processes?

> So now this question for you:  "CPython 2.5 runs too slow in 2007: true or
> false?"

I guess I gotta go with Steven D'Aprano - both true and false
depending on your situation.

> If you answer false, then there is no need for GIL removal.

OK, I see that.

> If you answer true, then cutting its speed for 90+% of people is bad.

OK, seems reasonable, assuming that multi-threading cannot be
implemented without a performance hit on single-threaded applications.
Is that a computer science maxim - giving an interpreted language
multi-threading will always negatively impact the performance of
single-threaded applications?

>
> | Most people are not currently bothered by the GIL and would not want its
> | speed halved.
>
> And another question: why should such people spend time they do not have to
> make Python worse for themselves?
>
Saying they don't have time to make a change, any change, is always
valid in my book. I cannot argue against that. Ditto for them saying
they don't want to make a change with no explanation. But it seems if
they make statements about why a change is not good, then it is fair
to make a counter-argument. I do agree with the theme of Steven
D'Aprano's comments in that it should be a cordial counter-argument
and not a demand.


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

Re: Will Python 3.0 remove the global interpreter lock (GIL)

[TheFlyingDutchman]

2

On Sep 19, 5:08 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> "Terry Reedy" <[EMAIL PROTECTED]> wrote in message
>

>
> This assumes that comparing versions of 1.5 is still relevant.  As far as I
> know, his patch has not been maintained to apply against current Python.
> This tells me that no one to date really wants to dump the GIL at the cost
> of half Python's speed.  Of course not.  The point of dumping the GIL is to
> use multiprocessors to get more speed!  So with two cores and extra
> overhead, Stein-patched 1.5 would not even break even.

Is the only point in getting rid of the GIL to allow multi-threaded
applications?

Can't multiple threads also provide a performance boost versus
multiple processes on a single-core machine?

>
> So now this question for you:  "CPython 2.5 runs too slow in 2007: true or
> false?"

Ugh, I guess I have to agree with Steven D'Aprano - it depends.

>
> If you answer false, then there is no need for GIL removal.

OK, I can see that.

> If you answer true, then cutting its speed for 90+% of people is bad.

OK, have to agree. Sounds like it could be a good candidate for a
fork. One question - is it a computer science maxim that an
interpreter that implements multi-threading will always be slower when
running single threaded apps?

>
> And another question: why should such people spend time they do not have to
> make Python worse for themselves?

I can't make an argument for someone doing something for free that
they don't have the time for. Ditto for doing something for free that
they don't want to do. But it does seem that if they give a reason for
why it's the wrong thing to do, it's fair to make a counter-argument.
Although I agree with Steven D'Aprano's theme in that it should be a
cordial rebuttal and not a demand.


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

Re: about __str__

[TheFlyingDutchman]

I read here recently that the __str__ method of a list calls the
__repr__ method of each of its members. So you need to add a __repr__
method to your class:

class CmterIDCmts:
def __init__(self,commiterID,commits):
self.commiterID_=long(commiterID)
self.commits_=long(commits)

def __str__(self):
s=""
s+="<"+str(self.commiterID_)+":"+str(self.commits_)+">"
return s
def __repr__(self):
return self.__str__()


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

Re: newb: BeautifulSoup

[TheFlyingDutchman]

On Sep 20, 8:04 pm, crybaby <[EMAIL PROTECTED]> wrote:
> I need to traverse a html page with big table that has many row and
> columns.  For example, how to go 35th td tag and do regex to retireve
> the content.  After that is done, you move down to 15th td tag from
> 35th tag (35+15) and do regex to retrieve the content?

Make the file an xhtml file (valid xml) if it isn't already and then
you can use software written to process XML files:

http://pyxml.sourceforge.net/topics/


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

Re: An Editor that Skips to the End of a Def

[TheFlyingDutchman]

On Sep 20, 8:47 pm, "W. Watson" <[EMAIL PROTECTED]> wrote:
> How about in the case of MS Win?
>
Try Wing IDE at http://www.wingware.com. It can run and debug programs
and has a free version.

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

Re: Python 3.0 migration plans?

[TheFlyingDutchman]

It seems that Python 3 is more significant for what it removes than
what it adds.

What are the additions that people find the most compelling?

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

Re: Python 3.0 migration plans?

[TheFlyingDutchman]

>
>   - Abstract Base Classes
> http://www.python.org/dev/peps/pep-3119/>
>

I like how someone here characterized decorators - those silly @
things. They remind me of Perl. Not adding keywords for abstract and
static is like Perl not adding a keyword for class. But I know all
such additions are vigorously defended by the most ardent users of
each language.

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

Re: Python 3.0 migration plans?

[TheFlyingDutchman]

On Sep 28, 2:49 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> TheFlyingDutchman wrote:
>
> >> The fact that you compare and criticise the simple annotations like
> >> static or abstract with the much more powerful decorator concept shows
> >> that, despite being the maintainer of a
> >> soon-to-be-ruling-the-python-world Python 3 fork, lack understanding of
> >> even the most basic language features. Which isn't exactly news.[1]
>
> > Don't you mean "lack appreciation for the non-basic language
> > features"? static, class and abstract
> > are basic language features that I appreciate. "decorators" have been
> > in Python for only a small part of its existence, they aren't in the
> > vast majority of languages (if any other language even has them) which
> > means people write all kinds of software without them. Or rather, most
> > of the software ever written didn't use decorators. Doesn't sound
> > basic at all.
>
> People did write all kinds of software in Assembler. And large portions of
> these people complained about every feature that some new language
> introduced.
>
> All serious languages are turing-complete. So can we put away with this
> non-sense argument right away, please?

You said it was a most basic language feature. I still haven't heard
anything that leads me to believe that statement is correct. What
languages implemented decorators as a most basic language feature?
Python didn't have them for over a decade so it doesn't qualify.

>
> >> Maybe you should start using python more and _then_ start discussions
> >> about it's features, when you have good grounds and can provide viable
> >> alternatives? But I guess that's a wish that won't be granted
>
> > static and abstract keywords would seem to be very viable
> > alternatives. Viable enough that several language designers used them.
>
> As I said - you don't get it. The decorators (in conjunction with the
> descriptor protocol - ever heard of that?) are very powerful yet lead as an
> artifact to simple, declarative implementations of features you like,
> namely static and abstract methods.

You said I had to provide a viable alternative. I did that. I haven't
heard of the descriptor protocol.

One of the problems with "getting" decorators is that they are not in
older books at all and newer books like Beginning Python from Novice
to Professional (c) 2005 Magnus Lie Hetland, that I own, devote almost
nothing to them. Out of 640 pages they are only mentioned
in one paragraph that is in a section titled "Static Methods and Class
Methods",(and followed by a class example with @staticmethod and
@classmethod).

So it seems like Magnus Lie Hetland didn't think they were very
important and he had Professional in his book title.

>
> And as you seem being so reluctant to let new features creep into the
> language, the introduction of new keywords you like?

I'm not against additions on principle.

>
> Besides, those 'several language designers' seem to think that the
> introduction of keywords isn't enough, but a general purpose annotation
> scheme seems to be viable - or how do you explain e.g. JDK 1.5 Annotations?

I certainly wouldn't call them a basic language feature. Java 1.0 came
out in January 1996, Java 1.5 in September 2004. It doesn't appear
that the language designer of Java, James Gosling, is still at the
wheel or BDFL. But yes, Java is showing signs of "complexity creep".
You'll be happy to know that I really dislike the C++ template syntax
and Java has decided to add something similar.

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

Re: Python 3.0 migration plans?

[TheFlyingDutchman]

On Sep 28, 10:01 am, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> On Fri, 28 Sep 2007 09:42:49 -0700, TheFlyingDutchman wrote:
> > Which of the common languages have higher order functions and what is
> > the syntax?
>
> C, C++, Pascal, Perl, PHP, Ruby have them.  And of course the functional
> languages, most notably Lisp and Scheme as you asked for common languages.
>
> Don't know if C#'s delegates qualify.
>
> Ciao,
> Marc 'BlackJack' Rintsch

What is the syntax of a higher order function in C, C++ and Pascal?

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

Re: Python 3.0 migration plans?

[TheFlyingDutchman]

>
> The fact that you compare and criticise the simple annotations like
> static or abstract with the much more powerful decorator concept shows
> that, despite being the maintainer of a
> soon-to-be-ruling-the-python-world Python 3 fork, lack understanding of
> even the most basic language features. Which isn't exactly news.[1]

Don't you mean "lack appreciation for the non-basic language
features"? static, class and abstract
are basic language features that I appreciate. "decorators" have been
in Python for only a small part of its existence, they aren't in the
vast majority of languages (if any other language even has them) which
means people write all kinds of software without them. Or rather, most
of the software ever written didn't use decorators. Doesn't sound
basic at all.

>
> Maybe you should start using python more and _then_ start discussions
> about it's features, when you have good grounds and can provide viable
> alternatives? But I guess that's a wish that won't be granted

static and abstract keywords would seem to be very viable
alternatives. Viable enough that several language designers used them.

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

Re: Python 3.0 migration plans?

[TheFlyingDutchman]

On Sep 28, 9:30 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> > You said it was a most basic language feature. I still haven't heard
> > anything that leads me to believe that statement is correct. What
> > languages implemented decorators as a most basic language feature?
>
> I was talking about Python, the programming language that is discussed in
> this NG
>
> > Python didn't have them for over a decade so it doesn't qualify.
>
> Says who? For further comments, see below.

I had the impression you were saying it was a basic language feature
of most languages. In any event Guido Van Rossum didn't include them
for over a decade. If he felt they were a basic language feature it
seems that he would have included them in 1991.

>
>
>
> >> >> Maybe you should start using python more and _then_ start discussions
> >> >> about it's features, when you have good grounds and can provide viable
> >> >> alternatives? But I guess that's a wish that won't be granted
>
> >> > static and abstract keywords would seem to be very viable
> >> > alternatives. Viable enough that several language designers used them.
>
> >> As I said - you don't get it. The decorators (in conjunction with the
> >> descriptor protocol - ever heard of that?) are very powerful yet lead as
> >> an artifact to simple, declarative implementations of features you like,
> >> namely static and abstract methods.
>
> > You said I had to provide a viable alternative. I did that. I haven't
> > heard of the descriptor protocol.
>
> Where did you do provide that alternative?

def static
def abstract

I was not providing an alternative for decorators.


>
> > One of the problems with "getting" decorators is that they are not in
> > older books at all and newer books like Beginning Python from Novice
> > to Professional (c) 2005 Magnus Lie Hetland, that I own, devote almost
> > nothing to them. Out of 640 pages they are only mentioned
> > in one paragraph that is in a section titled "Static Methods and Class
> > Methods",(and followed by a class example with @staticmethod and
> > @classmethod).
>
> > So it seems like Magnus Lie Hetland didn't think they were very
> > important and he had Professional in his book title.
>
> I consider "core features of a language" the features that are part of the
> specification and implementation. Neither do I care if there is anecdotal
> evidence of prior usage in other languages, nor who or who not thinks they
> are important enough to be dealt with in a book.

By that definition isn't anything that is part of a language a core
feature?  Weren't we talking about basic features?

>
> And above all, I don't consider the time things have been around _without_
> any feature as proof of their irrelevance - or do you consider cars being
> not core to western culture because they only have been around about 100
> years, whereas horses have been there for thousands of years? Happy riding,
> cowboy!

A relevant analogy would talk about a feature of cars that was not on
them in the beginning but has been added later and whether it was a
basic (or now, core) feature. Your definition of core feature given
above means that anything on a car when it comes out of the factory is
a core feature.

>
> Python 2.4 has been released in 2003, btw - so decorators are around for 4
> years now.
>
> So unless you come up with a definition of "core feature of a language" that
> someone respectable in the CS-community wrote that features "time being
> around" or "random book authors consider worthy" or "persons lacking the
> motivation to really dig into do finally get it", I consider your
> definition worthless. Agreed?
>

Since you defined a core feature (haven't seen your definition of a
basic feature) as anything in the specification or implementation, I
agree that it makes sense for you to disregard anything that limits
core features to something less than everything.


> >> Besides, those 'several language designers' seem to think that the
> >> introduction of keywords isn't enough, but a general purpose annotation
> >> scheme seems to be viable - or how do you explain e.g. JDK 1.5
> >> Annotations?
>
> > I certainly wouldn't call them a basic language feature. Java 1.0 came
> > out in January 1996, Java 1.5 in September 2004. It doesn't appear
> > that the language designer of Java, James Gosling, is still at the
> > wheel or BDFL. But yes, Java is showing signs of "complexity creep".
> > You'll be happy to know that I really dislike the C++ template syntax
> > and Java has decided to add something similar.
>
> Again, your anecdotal language feature definition is nonsense.
>
> By the way, considering generics and C++-templates as "something similar"
> shows the inclined beholder that there are other languages out there you
> don't really understand.

For me understanding is all I can hope to attain. Really understanding
is something I must yield to the corps d'elite.


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

Re: Python 3.0 migration plans?

[TheFlyingDutchman]

>
> Decorators are syntax sugar for higher order functions. Higher order
> functions are a both a basic and a fundamental language feature, and
> exist in many languages. The fact that you don't know this just
> proves, once again, that you like to talk more than you like to learn.

Which of the common languages have higher order functions and what is
the syntax?

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

Re: Python 3.0 migration plans?

[TheFlyingDutchman]

On Sep 28, 10:57 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> TheFlyingDutchman wrote:
> > On Sep 28, 10:01 am, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> >> On Fri, 28 Sep 2007 09:42:49 -0700, TheFlyingDutchman wrote:
> >>> Which of the common languages have higher order functions and what is
> >>> the syntax?
> >> C, C++, Pascal, Perl, PHP, Ruby have them.  And of course the functional
> >> languages, most notably Lisp and Scheme as you asked for common languages.
>
> >> Don't know if C#'s delegates qualify.
>
> >> Ciao,
> >> Marc 'BlackJack' Rintsch
>
> > What is the syntax of a higher order function in C, C++ and Pascal?
>
> This is like listening to a four-year-old torment its parents with
> incessant questions. Do you *have* to ask every question that pops into
> your mind?
>

In this case I asked it as part of the original question and it was
ignored. I have programmed in C and C++ and a little Pascal many years
ago. I don't remember anything about Higher Order Functions and would
like to see exactly how you do it and to verify the contention.


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

Re: Python 3.0 migration plans?

[TheFlyingDutchman]

On Sep 28, 11:21 am, "Francesco Guerrieri" <[EMAIL PROTECTED]>
wrote:
> On 9/28/07, TheFlyingDutchman <[EMAIL PROTECTED]> wrote:
>
> > On Sep 28, 10:57 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> > > This is like listening to a four-year-old torment its parents with
> > > incessant questions. Do you *have* to ask every question that pops into
> > > your mind?
>
> > In this case I asked it as part of the original question and it was
> > ignored. I have programmed in C and C++ and a little Pascal many years
> > ago. I don't remember anything about Higher Order Functions and would
> > like to see exactly how you do it and to verify the contention.
>
> You could just google for it. Just in case your connection to google
> or other similar search engines has been disabled for some reason,
> here are some links.
>
> Try for instance
>
> http://okmij.org/ftp/c++-digest/Lambda-CPP-more.html#Ex3
>
> or
>
> http://www.cc.gatech.edu/~yannis/fc++/
>
> or
>
> http://www.boost.org/libs/mpl/doc/tutorial/higher-order.html
>
Correct me if I am wrong, but none of those examples showed something
in C++ similar to a decorator in Python - that is, unique syntax in
the language for implementing a Higher Order Function. One thing I
will say about those examples is that they make Python decorators look
sweet!

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

Re: Python 3.0 migration plans?

[TheFlyingDutchman]

On Sep 28, 11:16 am, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Fri, 28 Sep 2007 11:04:39 -0700, TheFlyingDutchman <[EMAIL PROTECTED]> 
> wrote:
> > [snip]
>
> >In this case I asked it as part of the original question and it was
> >ignored. I have programmed in C and C++ and a little Pascal many years
> >ago. I don't remember anything about Higher Order Functions and would
> >like to see exactly how you do it and to verify the contention.
>
> Perhaps you could do a bit of independent research.  Then your messages
> to the group could contain more thoughtful questions and responses.
>
But you miss the fact that I am providing value to the group by
providing unthoughtful questions and unthoughtful responses. By having
most of the pocket protectors being thrown at me, I provide a
diversion that allows others to speak more freely and without fear of
reproach.


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

Re: Python 3.0 migration plans?

[TheFlyingDutchman]

On Sep 28, 11:16 am, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Fri, 28 Sep 2007 11:04:39 -0700, TheFlyingDutchman <[EMAIL PROTECTED]> 
> wrote:
> > [snip]
>
> >In this case I asked it as part of the original question and it was
> >ignored. I have programmed in C and C++ and a little Pascal many years
> >ago. I don't remember anything about Higher Order Functions and would
> >like to see exactly how you do it and to verify the contention.
>
> Perhaps you could do a bit of independent research.  Then your messages
> to the group could contain more thoughtful questions and responses.
>
But you miss the fact that I am providing value to the group by
providing unthoughtful questions and unthoughtful responses. By having
most of the pocket protectors being thrown at me, I provide a
diversion that allows others to speak more freely and without fear of
reproach.


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

Re: Python 3.0 migration plans?

[TheFlyingDutchman]

>
> Or bind resources of these pocket protectors that otherwise would lead to
> answers for people that do seek enlightment...

I don't think it would be correct to characterize my posts as not
seeking enlightenment. I do also happen to voice my opinion which
seems appropriate since this can be characterized as a discussion
group. It theoretically is possible for a discussion group to tolerate
opinions that diverge from the majority.

One issue I have with this group and that I encountered many years ago
in the Perl group is that there is no separate group
comp.lang.python.beginner where you can ask questions without getting
hit with RTFM! and the like.

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

Re: Python 3.0 migration plans?

[TheFlyingDutchman]

On Sep 28, 12:34 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> TheFlyingDutchman wrote:
>
> >> Or bind resources of these pocket protectors that otherwise would lead to
> >> answers for people that do seek enlightment...
>
> > I don't think it would be correct to characterize my posts as not
> > seeking enlightenment. I do also happen to voice my opinion which
> > seems appropriate since this can be characterized as a discussion
> > group. It theoretically is possible for a discussion group to tolerate
> > opinions that diverge from the majority.
>
> I would characterize
>
> """
> I like how someone here characterized decorators - those silly @
> things. They remind me of Perl. Not adding keywords for abstract and
> static is like Perl not adding a keyword for class.
> """
>
> not as seeking enlightenment, but as pure trolling. Disqualifying features
> without actually understanding them as "silly" certainly doesn't lie on one
> of the many path's to enlightenment known man - which to my knowledge
> usually require more humble approaches

Some posts seek enlightenment, some voice opinions. Opinions aren't
always voiced humbly. I don't think you will have to look far for
examples of people other than myself not expressing opinions humbly.

>
> > One issue I have with this group and that I encountered many years ago
> > in the Perl group is that there is no separate group
> > comp.lang.python.beginner where you can ask questions without getting
> > hit with RTFM! and the like.
>
> And I wish people that have no clue about the deeper workings of Python
> wouldn't insist on commenting on these in inappropriate ways as above, but
> instead try and _understand_ them before debunking them or suggesting
> changes.
>

I will grant you that "silly" is too strong a word to use in a group
of ardent users but I think it should be completely valid to gripe
about the syntax at least once.

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

Re: Python 3.0 migration plans?

[TheFlyingDutchman]

On Sep 28, 12:45 pm, George Sakkis <[EMAIL PROTECTED]> wrote:
> On Sep 28, 3:29 pm, TheFlyingDutchman <[EMAIL PROTECTED]> wrote:
>
> > One issue I have with this group and that I encountered many years ago
> > in the Perl group is that there is no separate group
> > comp.lang.python.beginner where you can ask questions without getting
> > hit with RTFM! and the like.
>
> Which shows once again that you're trying to break the world record of
> being wrong in as many sentences as possible:
>
>http://mail.python.org/mailman/listinfo/tutor
>
> You would do yourself (and others) a favor by migrating there for a
> few weeks or months.
>
> George

Being in a land where every nit can be picked, I am surprised that you
offered up a mailing list when I was asking for a newsgroup.

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

Re: Python 3.0 migration plans?

[TheFlyingDutchman]

On Sep 28, 1:09 pm, Steve Holden <[EMAIL PROTECTED]> wrote:

> That's because the tutor list doesn't offer a newsgroup. He was probably
> just trying to get rid of you.
>
> Now at 98.75% ...

Not sure if that's the reading on your trollmeter or on the meter that
measures what percentage of your posts you get huffy.

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

Re: your opinion on book "Foundations of Python Network Programming"?

[TheFlyingDutchman]

On Sep 28, 2:59 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> i'm debating if i should buy this book. it received good reviews at
> Amazon:http://tinyurl.com/24zvrf. but it was published in 2004 and
> i'm afraid quite some materials might be outdated? any input?
>
> thanks,
>
> kelie

I have not read this book but just wanted to say, in case you don't
already know, they have Chapter 13 on FTP available as a free download
at the publisher's web site:

http://www.apress.com/book/view/1590593715


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

global variables

[TheFlyingDutchman]

Does anyone know how the variables label and scale are recognized
without a global statement or parameter, in the function resize() in
this code:



#!/usr/bin/env python

from Tkinter import *

def resize(ev=None):
  label.config(font='Helvetica -%d bold' % \
  scale.get())


top = Tk()
top.geometry('250x150')

label = Label(top, text='Hello World!',
font='Helvetica -12 bold')
label.pack(fill=Y, expand=1)

scale = Scale(top, from_=10, to=40,
 orient=HORIZONTAL, command=resize)
scale.set(12)
scale.pack(fill=X, expand=1)

quit = Button(top, text='QUIT',
command=top.quit, activeforeground='white',
activebackground='red')
quit.pack()

mainloop()

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

Python Windows Installation

[TheFlyingDutchman]

I am trying to install Python 2.5 on Windows XP. It installs into the
root directory on C:\ instead of C:\Python25 which it shows by default
as what it plans to install to. Selecting D:\Python25 on a previous
iteration put the exe in D:\ and did not create a Python25 directory.
On the most recent iteration, when requesting an install to D:
\Python25  it appears to have put files on C:\.  I am installing on
Windows XP Professional. When it asks me for whether I want to install
for all users or just me, I select just me. I do not have admin rights
on the machine.

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

Re: Python Windows Installation

[TheFlyingDutchman]

I manually created C:\Python25 the reran the install program. The
installation program noted that C:\Python25 existed and asked me if I
still wanted to install there. After I said yes it installed to C:\.


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

Re: Python Windows Installation

[TheFlyingDutchman]

With C:\Python25 already existing, I tried to install to C:
\Python25\Python25. It installed to C:\.

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

Re: Python Windows Installation

[TheFlyingDutchman]

On Oct 24, 11:22 pm, Tim Roberts <[EMAIL PROTECTED]> wrote:
> TheFlyingDutchman <[EMAIL PROTECTED]> wrote:
>
> >I am trying to install Python 2.5 on Windows XP. It installs into the
> >root directory on C:\ instead of C:\Python25 which it shows by default
> >as what it plans to install to. Selecting D:\Python25 on a previous
> >iteration put the exe in D:\ and did not create a Python25 directory.
>
> Where did you get the installer?  I've installed Python on Windows many,
> many times, and have never seen this issue.
> --
> Tim Roberts, [EMAIL PROTECTED]
> Providenza & Boekelheide, Inc.

from python.org.   I doubt many people get this or it would be fixed
but it still is shocking how it can prompt me that the installation
directory exists - showing that it fully knows where it is supposed to
install it - and then go ahead and install it to the root directory
and claim success. It also uninstalls Python if you ask it to so any
screwy settings from a previous install should be removed after the
uninstall, but it also fails to install correctly after an uninstall.

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

Re: Python Windows Installation

[TheFlyingDutchman]

I finally gave up trying to install to c:\Python25 and went with the
install to C:\.  However, I tried to install a module called pywin32
(Python for Windows Extensions) and after recognizing that the Python
installation was in C:\ and saying it would install to C:\LIB\SITE-
PACKAGES, it would then blow up. This was consistently repeatable.
Seeing PythonWin mentioned regarding pywin32 reminded me of the
ActiveState distribution of Python as I knew that came with
PythonWin.

After uninstalling the python.org Python from C:\, I was able to
successfuly install the ActiveState Python distribution to C:
\Python25.


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

Re: shouldn't 'string'.find('ugh') return 0, not -1 ?

[TheFlyingDutchman]

On Oct 31, 8:11 am, Carl Banks <[EMAIL PROTECTED]> wrote:

>
> string.find has always been kind of a wart in Python; that's why
> they're getting rid of it.  For testing for the presence of a
> substring, use the in operator:


Per the Python 3000 presentation given by Guido Van Rossum at
PyCon February 2007, the new Bytes type will have a "wart".

"Has some string-like methods, e.g. .find()"


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

Re: Python IDE

[TheFlyingDutchman]

On Nov 3, 6:11 am, Simon Pickles <[EMAIL PROTECTED]> wrote:

> Coming from a Visual Studio background, editing text files and using the
> terminal to execute them offends my sensibilities :)

YOu should take a look at Wing IDE Professional - www.wingware.com


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

Re: Writing a CGI to query DB

[TheFlyingDutchman]

On Nov 9, 8:33 pm, Bighead <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am currently working on a CGI deployed on an Apache server, which,
> given an arbitrary SQL, fetches raw data from a remote DB server and
> return them in a HTML page. This CGI works fine on quick SQLs.
>
> But when I try to run a slow SQL on this CGI, through a Squid Proxy, I
> always get the Error message from Squid: Zero Sized Reply, after 5
> minutes.
>
> The SQL itself is correct, since I have tried it directly on the DB
> server. So what do you think might cause the problem? Thank you.

Slow SQL = query that takes a long time? How long does the query take
if you run it on the same machine as the DB server without a Squid
Proxy?

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

Re: Overloading Methods

[TheFlyingDutchman]

>
> class Foo(object):
> def __init__(self, a, b=10, c=None):

>
> Whereas in Java or C++ this would require several overloads, it can be
> succinctly expressed as a single method in Python.
>

Not that it's important to the discussion, but, while Java does not
have the capability to give default method parameters, C++ does.

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

Re: A java hobbyist programmer learning python

[TheFlyingDutchman]

>
> * No getters and setters. Python takes a very permissive approach to
> class attributes, taking the philosophy "we're all adults here". It's
> easy to change a public attribute to a private attribute with a getter/
> setter if you need to, so there's nothing to be gained by writing getters
> for straight attribute access. It just makes things slow.

If adding a getter/setter made data private, then per a tenet of
Object Oriented Programming, there would be something to be gained
from it. But I don't see getter/setters would do that.

The statically typed object oriented languages, like Java, C++ and C#,
all permit member data and functions to be public - allowing a
programmer to implement a "we're all adults here" programming
philosophy if they so choose. However, they also allow a programmer to
make member data and functions private, thus allowing the
implementation one of the tenets of OOP. I don't use Ruby, a
dynamically typed language like Python, but from a web search it
appears that Ruby does allow at least data to be declared private. But
it appears that a user of a class can get around this private
declaration by writing their own methods and adding them to the class
dynamically.

In his book "Core Python Programming", noted Python expert and PyCon
speaker Wesley J. Chun makes the following statements regarding one of
the main principles of Object Oriented Programming (OOP):

"Encapsulation/Interfaces
Encapsulation describes the concept of data/information hiding and
providing interfaces or accessor functions to the data attributes.
Direct access to data by any client, bypassing the interfaces, goes
against the principles of encapsulation, but the programmer is free to
allow such access. As part of the implementation, the client should
not even know how the data attributes are architected within the
abstraction. In Python, all class attributes are public but names may
be "mangled" to discourage unauthorized access, but otherwise not
prevented. It is up to the designer to provide the appropriate
interfaces to the data so that the client programmer does not have to
resort to manipulating the encapsulated data attributes."
--
http://mail.python.org/mailman/listinfo/python-list

Re: A java hobbyist programmer learning python

[TheFlyingDutchman]

On Jan 23, 8:57 am, Dennis Lee Bieber  wrote:
> On Fri, 23 Jan 2009 01:48:32 -0800 (PST), TheFlyingDutchman
>  declaimed the following in comp.lang.python:
>
> > abstraction. In Python, all class attributes are public but names may
> > be "mangled" to discourage unauthorized access, but otherwise not
> > prevented. It is up to the designer to provide the appropriate
> > interfaces to the data so that the client programmer does not have to
> > resort to manipulating the encapsulated data attributes."
>
>         Double underscore "mangling" was not implemented to "discourage
> unauthorized access". Its primary purpose is to prevent name space
> conflicts when an extended subclass and its parent class use the same
> name for an attribute, but that attribute is not of the same "meaning".
> Using the __ prefix means BOTH attributes are part of the instance, but
> the subclass only see's its variant and should make calls into
> superclass methods to modify the parent variant.
>
>         Python convention is that a single underscore -- which does NOT
> perform name mangling -- is the indicator meant to "discourage
> unauthorized access".
>

Is there a significant performance hit with using the double
underscore for signifying a variable you want to be private? It seems
like it is advantageous that someone trying for direct access has to
use a different notation, which will help to emphasize that it
shouldn't be access directly.

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

Re: A java hobbyist programmer learning python

[TheFlyingDutchman]

>         If you're building an extension tree, you'll either have to supply
> layers of getter/setter methods, or hand-mangle references to attributes
> defined in the superclass.
>
>         Say you start with a "Point2D" class, and make the X, Y coordinates
> double underscore.
>
>         Now extend it to a "Point3D" class via inheritance. The 3D class
> will not be able to access (set) the X, Y values without a setter method
> defined in the parent OR by unmangling the parent names.
>
>         If you'd used the common convention of single underscore as "don't
> touch if you're an outsider", the 3D extension can be considered an
> insider and directly access the X, Y
>
>         Which would you rather read in a 3D point class derived by extending
> a 2D point?
>
>         def move(self, xmod, ymod, zmod):
>                 self._z += zmod
>                 self._y += ymod
>                 self._x += xmod
>
> or
>
>         def move(self, xmod, ymod, zmod):
>                 super(Point3D, self).move(xmod, ymod)
>                 self._z += zmod
>
> or
>
>         def move(self, xmod, ymod, zmod):
>                 self._Point2D__x += xmod
>                 self._Point2D__y += ymod
>                 self.__z += zmod
>
>         Speaking for myself, I'd prefer the first
> --
>         Wulfraed        Dennis Lee Bieber               KD6MOG
>         wlfr...@ix.netcom.com         wulfr...@bestiaria.com
>                 HTTP://wlfraed.home.netcom.com/
>         (Bestiaria Support Staff:               web-a...@bestiaria.com)
>                 HTTP://www.bestiaria.com/

I like the latter two styles, particularly the last one. That way you
can see at a glance that those member variables are defined in the
super class. But then I am a fan of Hungarian notation, which many
programmers can't stand.
--
http://mail.python.org/mailman/listinfo/python-list

Re: A portable LISP interpreter that includes all the major list-processing functions is described. A complete, annotated listing of the program's code, written in PASCAL, is included.

[TheFlyingDutchman]

On Jul 23, 12:06 pm, Emmy Noether  wrote:
> Title   Portable LISP interpreter
> Creator/Author  Cox, L.A. Jr. ; Taylor, W.P.
> Publication Date        1978 May 31
> OSTI Identifier OSTI ID: 7017786
> Report Number(s)        UCRL-52417
> DOE Contract Number     W-7405-ENG-48
> Resource Type   Technical Report
> Research Org    California Univ., Livermore (USA). Lawrence Livermore
> Lab.
> Subject 99 GENERAL AND MISCELLANEOUS//MATHEMATICS, COMPUTING, AND
> INFORMATION SCIENCE; COMPUTER CODES; L CODES; COMPUTERS; PROGRAMMING;
> PROGRAMMING LANGUAGES
> Description/Abstract    A portable LISP interpreter that includes all the
> major list-processing functions is described. A complete, annotated
> listing of the program's code, written in PASCAL, is included.
> Country of Publication  United States
> Language        English
> Format  Medium: X; Size: Pages: 21
> Availability    Dep. NTIS, PC A02/MF A01.
> System Entry Date       2008 Feb 12

Is this available online? If only in hardcopy form, do they lend it
out?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[TheFlyingDutchman]

>
> More specifically, the claim made above:
>
> > in C I can have a function maximum(int a, int b) that will always
> > work. Never blow up, and never give an invalid answer.
>
> is false.  And it is not necessary to invoke the vagaries of run-time
> input to demonstrate that it is false.
>
I don't think you demonstrated it is false. Any values larger than an
int get truncated before they ever get to maximum. The problem does
not lie with the maximum function. It correctly returns the maximum of
whatever two integers it is provided. Calling it with values that are
larger than an int, that get converted to an int _before_ maximum is
called, is an issue outside of maximum.

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

Re: "Strong typing vs. strong testing"

[TheFlyingDutchman]

>
> That argument can be made for dynamic language as well. If you write in
> dynamic language (e.g. python):
>
> def maximum(a, b):
>     return a if a > b else b
>
> The dynamic language's version of maximum() function is 100% correct --
> if you passed an uncomparable object, instead of a number, your call of
> it is incorrect; you just didn't pass the right sort of data. And that's
> your problem as a caller.
>
> In fact, since Python's integer is infinite precision (only bounded by
> available memory); in practice, Python's version of maximum() has less
> chance of producing erroneous result.

"in C I can have a function maximum(int a, int b) that will always
work. Never blow up, and never give an invalid answer. "

Dynamic typed languages like Python fail in this case on "Never blows
up".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[TheFlyingDutchman]

> > Yes.  Nonetheless, the maximum() function does exactly what it is intended
> > to do *with the inputs it receives*.  The failure is outside the function;
> > it did the right thing with the data actually passed to it, the problem
> > was a user misunderstanding as to what data were being passed to it.
>
> > So there's a bug -- there's code which does not do what it was intended
> > to do.  However, that bug is in the caller, not in the maximum()
> > function.
>
> > This is an important distinction -- it means we can write a function
> > which performs that function reliably.  Now we just need to figure out
> > how to call it with valid data... :)
>
> We lost some important context somewhere along the line:
>
> > > > in C I can have a function maximum(int a, int b) that will always
> > > > work. Never blow up, and never give an invalid answer. If someone
> > > > tries to call it incorrectly it is a compile error.
>
> Please take note of the second sentence.
>
> One way or another, this claim is plainly false.  The point I was trying
> to make is not so much that the claim is false (someone else was already
> doing that), but that it can be demonstrated to be false without having
> to rely on any run-time input.
>

The second sentence is not disproved by a cast from one datatype to
another (which changes the value) that happens before maximum() is
called.





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

Re: "Strong typing vs. strong testing"

[TheFlyingDutchman]

On Sep 30, 1:02 am, Paul Rubin  wrote:
> >> > > > in C I can have a function maximum(int a, int b) that will always
> >> > > > work. Never blow up, and never give an invalid answer. If someone
> >> > > > tries to call it incorrectly it is a compile error.
> > The second sentence is not disproved by a cast from one datatype to
> > another (which changes the value) that happens before maximum() is called.
>
>     int maximum(int a, int b);
>
>     int foo() {
>       int (*barf)() = maximum;
>       return barf(3);
>     }
>
> This compiles fine for me.  Where is the cast?  Where is the error message?
> Are you saying barf(3) doesn't call maximum?

With Tiny C on my system, your code does not cause maximum to give an
incorrect value, or to blow up:

int maximum(int a, int b)
{
  printf("entering maximum %d %d\n",a,b);
  if ( a > b )
return a;
  else
return b;
}

int foo()
{
   int (*barf)() = maximum;
   return barf(3);
}

int main (int argc, char *argv[])
{
  printf("maximum is %d\n",foo());
}

- output ---
entering maximum 3 4198400
maximum is 4198400
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[TheFlyingDutchman]

On Sep 30, 1:40 am, RG  wrote:
> In article
> <5bf24e59-1be0-4d31-9fa7-c03a8bf9b...@y12g2000prb.googlegroups.com>,
>
>
>
>
>
>  TheFlyingDutchman  wrote:
> > > > Yes.  Nonetheless, the maximum() function does exactly what it is 
> > > > intended
> > > > to do *with the inputs it receives*.  The failure is outside the 
> > > > function;
> > > > it did the right thing with the data actually passed to it, the problem
> > > > was a user misunderstanding as to what data were being passed to it.
>
> > > > So there's a bug -- there's code which does not do what it was intended
> > > > to do.  However, that bug is in the caller, not in the maximum()
> > > > function.
>
> > > > This is an important distinction -- it means we can write a function
> > > > which performs that function reliably.  Now we just need to figure out
> > > > how to call it with valid data... :)
>
> > > We lost some important context somewhere along the line:
>
> > > > > > in C I can have a function maximum(int a, int b) that will always
> > > > > > work. Never blow up, and never give an invalid answer. If someone
> > > > > > tries to call it incorrectly it is a compile error.
>
> > > Please take note of the second sentence.
>
> > > One way or another, this claim is plainly false.  The point I was trying
> > > to make is not so much that the claim is false (someone else was already
> > > doing that), but that it can be demonstrated to be false without having
> > > to rely on any run-time input.
>
> > The second sentence is not disproved by a cast from one datatype to
> > another (which changes the value) that happens before maximum() is
> > called.
>
> You can't have it both ways.  Either I am calling it incorrectly, in
> which case I should get a compiler error, or I am calling it correctly,
> and I should get the right answer.  That I got neither does in fact
> falsify the claim.  The only way out of this is to say that
> maximum(8589934592, 1) returning 1 is in fact "correct", in which case
> we'll just have to agree to disagree.
>
1) long trying_to_break_maximum = 8589934592;
2) /* compiler adds */
   int created_to_allow_maximum_call = (int) trying_to_break_maximum;
3) maximum(created_to_allow_maximum_call, 1);

I think we have to agree to disagree, because I don't see the lack of
a compiler error at step 2 as a problem with the maximum() function.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[TheFlyingDutchman]

>
> > "in C I can have a function maximum(int a, int b) that will always
> > work. Never blow up, and never give an invalid answer. "
>
> > Dynamic typed languages like Python fail in this case on "Never blows
> > up".
>
> How do you define "Never blows up"?

Never has execution halt.

I think a key reason in the big rise in the popularity of interpreted
languages is that when execution halts, they normally give a call
stack and usually a good reason for why things couldn't continue. As
opposed to compiled languages which present you with a blank screen
and force you to - fire up a debugger, or much much worse, look at a
core dump - to try and discern all the information the interpreter
presents to you immediately.

>
> Personally, I'd consider maximum(8589934592, 1) returning 1 as a blow
> up, and of the worst kind since it passes silently.

If I had to choose between "blow up" or "invalid answer" I would pick
"invalid answer".

In this example RG is passing a long literal greater than INT_MAX to a
function that takes an int and the compiler apparently didn't give a
warning about the change in value as it created the cast to an int,
even with the option -Wall (all warnings). I think it's legitmate to
consider that an option for a warning/error on this condition should
be available. As far the compiler generating code that checks for a
change in value at runtime when a number is cast to a smaller data
type, I think that's also a legitimate request for a C compiler option
(in addition to other runtime check options like array subscript out
of bounds).

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

Re: "Strong typing vs. strong testing"

[TheFlyingDutchman]

>
> > If I had to choose between "blow up" or "invalid answer" I would pick
> > "invalid answer".
>
> there are some application domains where neither option would be
> viewed as a satisfactory error handling strategy. Fly-by-wire, petro-
> chemicals, nuclear power generation. Hell you'd expect better than
> this from your phone!
>

I wasn't speaking generally, just in the case of which of only two
choices RG's code should be referred to - "blowing up" or "giving an
invalid answer".

I think error handling in personal computer and website software has
improved over the years but there is still some room for improvement
as you will still get error messages that don't tell you something you
can relay to tech support more than that an error occurred or that
some operation can't be performed.

But I worked with programmers doing in-house software who were
incredibly turned off by exception handling in C++. I thought that
meant that they preferred to return and check error codes from
functions as they had done in C, and for some of them it did seem to
mean that. But for others it seemed that they didn't want to
anticipate errors at all ("that file is always gonna be there!"). I
read a Java book by Deitel and Deitel and they pointed out what might
have lead to that attitude - the homework and test solutions in
college usually didn't require much if any error handling - the
student could assume files were present, data was all there and in the
format expected, user input was valid and complete, etc.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[TheFlyingDutchman]

> >         in C I can have a function maximum(int a, int b) that will always
> >         work. Never blow up, and never give an invalid answer. If someone
> >         tries to call it incorrectly it is a compile error.
>
> I would agree that the third sentence is arguably wrong, simply
> because there's no such thing (outside #error) of a mandate to stop
> compiling.  However, my understanding was that the dispute was over
> the second sentence, and that's certainly correct.
>
Why do you consider the term "compile error" a "mandate to stop
compiling"? What do you say to refer to the situation when you have a
statement in your program that the compiler finds is an error? And is
it really material whether the compiler flagged an error and stopped,
or flagged an error and looked for additional errors???
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[TheFlyingDutchman]

On Sep 30, 10:37 pm, RG  wrote:
> In article <87tyl63cag@mail.geddis.org>,
>  Don Geddis  wrote:
>
>
>
>
>
> > Keith Thompson  wrote on Thu, 30 Sep 2010:
> > > RG  writes:
> > >> You're missing a lot of context.  I'm not trying to criticize C, just to
> > >> refute a false claim that was made about it.
> > > Can you cite the article that made this false claim, and exactly what
> > > the false claim was?
>
> >http://groups.google.com/group/comp.lang.lisp/msg/431925448da59481
>
> >         Message-ID:
> >         <0497e39d-6bd1-429d-a86f-f4c89babe...@u31g2000pru.googlegroups.com>
> >         From: TheFlyingDutchman 
> >         Newsgroups: comp.lang.lisp
>
> >         [...]
> >         in C I can have a function maximum(int a, int b) that will always
> >         work. Never blow up, and never give an invalid answer. If someone
> >         tries to call it incorrectly it is a compile error.
> >         [...]
>
> > ___­___
> > _
> > Don Geddis                  http://don.geddis.org/             
> > d...@geddis.org
>
> Thanks, Don.
>
> rg-

Thanks from me as well, Don. I was worried that people would start to
believe that the original statement was what you said it was:

"I'm not even saying it's a flaw in the language.  All I'm saying is
that
the original claim -- that any error in a C program will be caught by
the compiler -- is false, and more specifically, that it can be
demonstrated to be false without appeal to unknown run-time input."

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

Re: Land Of Lisp is out

[TheFlyingDutchman]

On Oct 27, 4:55 pm, Lawrence D'Oliveiro  wrote:
> Would it be right to say that the only Lisp still in common use is the Elisp
> built into Emacs?

There is a new version of Lisp called Clojure that runs on the Java
Virtual Machine (JVM) that is on the upswing. Don't know how many
users it has but they had their first conference recently and there
are local meetup groups that have formed for it and some books are
being published about it.

http://clojure-conj.org/

http://pragprog.com/titles/shcloj/programming-clojure

http://www.manning.com/rathore/

http://www.manning.com/fogus/
-- 
http://mail.python.org/mailman/listinfo/python-list