Re: Land Of Lisp is out
On Oct 27, 4:55 pm, Lawrence D'Oliveiro l...@geek- central.gen.new_zealand 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
Re: Strong typing vs. strong testing
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
On Sep 30, 10:37 pm, RG rnospa...@flownet.com wrote: In article 87tyl63cag@mail.geddis.org, Don Geddis d...@geddis.org wrote: Keith Thompson ks...@mib.org wrote on Thu, 30 Sep 2010: RG rnospa...@flownet.com 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 zzbba...@aol.com 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: Strong typing vs. strong testing
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
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
On Sep 30, 1:02 am, Paul Rubin no.em...@nospam.invalid 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
On Sep 30, 1:40 am, RG rnospa...@flownet.com wrote: In article 5bf24e59-1be0-4d31-9fa7-c03a8bf9b...@y12g2000prb.googlegroups.com, TheFlyingDutchman zzbba...@aol.com 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
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
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
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: 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.
On Jul 23, 12:06 pm, Emmy Noether emmynoeth...@gmail.com 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: A java hobbyist programmer learning python
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 java hobbyist programmer learning python
On Jan 23, 8:57 am, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: On Fri, 23 Jan 2009 01:48:32 -0800 (PST), TheFlyingDutchman zzbba...@aol.com 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
* 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: Overloading Methods
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: Python IDE
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
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: shouldn't 'string'.find('ugh') return 0, not -1 ?
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 Windows Installation
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: Python Windows Installation
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
Python Windows Installation
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
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
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
global variables
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
Re: Python 3.0 migration plans?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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
Re: Python 3.0 migration plans?
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?
- Abstract Base Classes URL: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: An Editor that Skips to the End of a Def
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: Will Python 3.0 remove the global interpreter lock (GIL)
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__
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
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: Will Python 3.0 remove the global interpreter lock (GIL)
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
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
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
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)
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)
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)
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)
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=106thread=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: Python 3K or Python 2.9?
Ironic 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 /Ironic Zobionic 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! /Zombionic -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
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?
VivaLaFrance 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! /VivaLaFrance -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
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: Python 3K or Python 2.9?
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?
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?
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?
(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
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?
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?
On Sep 12, 4:40 am, Bjoern Schliessmann usenet- [EMAIL PROTECTED] 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?
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?
On Sep 12, 3:53 pm, Bjoern Schliessmann usenet- [EMAIL PROTECTED] 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
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 = head attribute = abc titleMy Page/title /head print myHtmlHeader outputs: head attribute=abc titleMy Page/title /head -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
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?
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: cpython list __str__ method for floats
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?
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
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
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
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
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 syntax wart
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
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
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
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
On Sep 10, 4:45 am, Bjoern Schliessmann usenet- [EMAIL PROTECTED] 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
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
I'd like to know if the Cheeseshop package 'enum' is useful to you. Any constructive feedback would be appreciated. URL: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
On Sep 10, 7:12 pm, Ben Finney [EMAIL PROTECTED] wrote: TheFlyingDutchman [EMAIL PROTECTED] writes: URL: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
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
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: URL: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: startswith( prefix[, start[, end]]) Query
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?
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: Using wild character
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
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
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 onc, string.find will tell you where that is. PEP3100 says it will be removed, but at the same time says [UNLIKELY]... http://www.python.org/dev/peps/pep-3100/#id36 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: list index()
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: parameter list notation
Steve, Ben, Duncan, Thanks for the replies. TFD -- http://mail.python.org/mailman/listinfo/python-list
Re: parameter list notation
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 stdin, line 1, in module File stdin, 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
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()
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
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
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
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: list index()
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()
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
