Re: DOS or not? [was Re: How to tell Script to use pythonw.exe ?]
On 2013-07-03 13:19:26 +, Steven D'Aprano said: On Wed, 03 Jul 2013 14:00:49 +0100, Tim Golden wrote: Goodness, I doubt if you'll find anyone who can seriously make a case that the Windows command prompt is all it might be. I'm not a Powershell user myself but people speak highly of it. I understand that Powershell is aimed more for batch use rather than interactive use. Not sure what gave that impression. PS comes with handy Unix-like aliases by default. I used it interactively every day for years, and recommend it over either cmd or Cygwin. -- http://mail.python.org/mailman/listinfo/python-list
Re: List question
Zentrader wrote:
On Mar 22, 10:07 am, Arnaud Delobelle [EMAIL PROTECTED] wrote:
On Mar 22, 4:38 pm, Zentrader [EMAIL PROTECTED] wrote:
if ('one', 'two') are in f: ...
are gives me an error in Python 2.5 with a from future import *
statement included. What version and platform are you running. Also,
the docs don't mention it.http://docs.python.org/ref/keywords.html
That's because you have to do:
from bearophile import musings
HTH
--
Arnaud
Thanks. I am admittedly naive and don't have any type of guard up
when on this group for people who think that type of comment makes
them intelligent/funny.
No one meant to laugh at you. Your naivete was not obvious. FWIW, a
sense of humor is a valuable possession in most Python-related
conversations.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Do any of you recommend Python as a first programming language?
jmDesktop wrote: For students 9th - 12th grade, with at least Algebra I. Do you think Python is a good first programming language for someone with zero programming experience? Using Linux and Python for first exposure to programming languages and principles. Linux and Python are a nearly ideal combination for this. Be aware that at some point, you will likely have to dig into C, the primary language used to implement both Linux and Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Do any of you recommend Python as a first programming language?
Larry Bates wrote: jmDesktop wrote: For students 9th - 12th grade, with at least Algebra I. Do you think Python is a good first programming language for someone with zero programming experience? Using Linux and Python for first exposure to programming languages and principles. Thank you. ABSOLUTELY. Get them started with a REAL programming language that will teach them proper fundamentals. I wish Python would have been around 25 years ago when I taught incoming Freshmen at local University. To get students to understand about variable references, etc. What do you mean by variable references, and how are they used in Python? -- http://mail.python.org/mailman/listinfo/python-list
Re: Do any of you recommend Python as a first programming language?
Arnaud Delobelle wrote: Anyway, here the conclusion that I draw: learn lambda-calculus and Turing machines. The rest is syntactic sugar. How is the lambda-calculus fundamentally different from Turing machine-based implementations? I've been learning a fair amount about functional programming recently, mostly because compile-time C++ turns out to be a pure functional programming language. Where should I go for a solid grounding in lambda-calculus? Also, despite reassurances to the contrary, I still get the impression that there is a strong anti-lambda sentiment among the Python in crowd. Is it just a question of the word lambda, as opposed to perceived cleaner syntax? http://www.artima.com/weblogs/viewpost.jsp?thread=98196 http://www.python.org/dev/peps/pep-0290/#replacing-common-uses-of-lambda -- Said the Rabbi Hillel, All the rest is commentary. -- http://mail.python.org/mailman/listinfo/python-list
Re: ftp recursively
Paul Rubin wrote: Jeff Schwab [EMAIL PROTECTED] writes: ftping it as a flat file, and untarring it on the other side. Of course, the motivation wasn't just to get the files from point A to point B using Unix (which I already know how to do), but to take advantage of an opportunity to learn some Python; next time, I'll try the ftpmirror.py script if it's generic enough, or ftplib if there are more specific requirements. I see, that wasn't clear in your original post. You should look at the os.walk function if you want to know how to traverse a directory tree (maybe you are already doing this). I thought os.walk was for locally mounted directories... How is it relevant on remote filesystems? Also, for security reasons, it's getting somewhat uncommon, and is generally not a good idea to run an ftpd these days, even on a LAN. It's more usual these days to transfer all files by rcp or rsync tunnelled through ssh. Don't shoot the messenger, but you're severely confused here. Whether you're using ftp, rcp, or rsync is a completely separate issue to whether you're running over ssl (which I assume you meant by ssh). FTP is a work-horse protocol for transferring files. It's going to be with us for a long, long time. There are various clients and servers built on it, including the traditional ftp command-line tools on Unix and Windows. rcp is a very simple tool for copying files from one (potentially remote) place to another. The point of rcp is that its interface is similar to cp, so the flags are easy to remember. Modern Unix and Linux systems usually include secure versions of both ftp and rcp, called sftp and scp, respectively. The point of rsync is to keep a local directory tree in sync with a remote one, by transferring only change-sets that are conceptually similar to patches. If you're only transferring files once, there's no particular benefit (AFAIK) to using rsync rather than some kind of recursive ftp. -- http://mail.python.org/mailman/listinfo/python-list
Re: Change user on UNIX
Jonathan Gardner wrote: On Mar 20, 4:51 am, Giampaolo Rodola' [EMAIL PROTECTED] wrote: Is there any way to su or login as a different user within a python script? I mainly need to temporarily impersonate another user to execute a command and then come back to the original user. In the unix world, this is highly discouraged. You shouldn't have to change your user. If you want a different user to access files that another user created, that's what groups are for. What's your take on setuid scripts (Python or otherwise)? I more or less agree with your assessment of su, so I would be interested in your opinion of chmod ug+s some_custom_script. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can I run a python program from within emacs?
Grant Edwards wrote: On 2008-03-20, jmDesktop [EMAIL PROTECTED] wrote: Hi, I'm trying to learn Python. I using Aquamac an emac implementation with mac os x. I have a program. If I go to the command prompt and type pythong myprog.py, it works. Can the program be run from within the editor or is that not how development is done? I ask because I was using Visual Studio with C# and, if you're familiar, you just hit run and it works. On Python do I use the editor for editing only and then run the program from the command line? http://www.google.com/search?q=emacs+python Or achieve a similar (more flexible (IMO), but less smoothly integrated) effect with Vim and GNU Screen. Until recently, you had to patch Screen if you wanted vertical splits, but now it's in the main line. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can I run a python program from within emacs?
jmDesktop wrote: On Mar 20, 11:21 am, Grant Edwards [EMAIL PROTECTED] wrote: On 2008-03-20, jmDesktop [EMAIL PROTECTED] wrote: Hi, I'm trying to learn Python. I using Aquamac an emac implementation with mac os x. I have a program. If I go to the command prompt and type pythong myprog.py, it works. Can the program be run from within the editor or is that not how development is done? I ask because I was using Visual Studio with C# and, if you're familiar, you just hit run and it works. On Python do I use the editor for editing only and then run the program from the command line? Sort of. Modern editors generally have support for building and running your program directly from a toolbar button or textual command. I personally use Vim with the toolbar disabled, running in a Terminal, and run the program by first putting Vim in the background (^z). People writing code specific to Mac, but not necessarily all in Python, often use XCode. http://zovirl.com/2006/07/13/xcode-python/ In the Ruby community, Vim is the dominant choice, but a lot of Mac users swear by TextMate. http://macromates.com/ http://www.google.com/search?q=emacs+python Gee. Thanks. I believe Grant was suggesting that Emacs often serves a similar purpose on Unix to what Visual Studio does on Windows, which seemed to be what you were asking. When asking about Mac OS X here, you are likely to get a lot of generic Unix responses. (Would it have been clearer if he had just said emacs?) -- http://mail.python.org/mailman/listinfo/python-list
Re: Can I run a python program from within emacs?
Paulo da Costa wrote: People who say Emacs often mean GNU Emacs. That's funny; to me, Emacs usually means XEmacs. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Can I run a python program from within emacs?
Grant Edwards wrote: On 2008-03-20, Jeff Schwab [EMAIL PROTECTED] wrote: http://www.google.com/search?q=emacs+python Gee. Thanks. I believe Grant was suggesting that Emacs often serves a similar purpose on Unix to what Visual Studio does on Windows, which seemed to be what you were asking. When asking about Mac OS X here, you are likely to get a lot of generic Unix responses. (Would it have been clearer if he had just said emacs?) Don't the normal run/debug python from inside emacs methods work on OS-X? AFAIK, yes; I don't see why it wouldn't. I missed the word emacs in the subject header, and did not recognize an emac in the original post as meaning emacs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Interesting math problem
Marc Christiansen wrote: sturlamolden [EMAIL PROTECTED] wrote: On 18 Mar, 00:58, Jeff Schwab [EMAIL PROTECTED] wrote: def make_slope(distance, parts): if parts == 0: return [] q, r = divmod(distance, parts) if r and parts % r: q += 1 return [q] + make_slope(distance - q, parts - 1) Beautiful. If Python could optimize tail recursion, it would even run fast. This was my first thought, too. But tailcall optimisation wouldn't help here. `make_slope` is not tail recursive, the `+` (aka list.extend) gets executed after the recursion. def make_slope(distance, parts, L=()): if parts == 0: return L q, r = divmod(distance, parts) if r and parts % r: q += 1 return make_slope(distance - q, parts - 1, (q,) + L) -- http://mail.python.org/mailman/listinfo/python-list
Re: PyCon Feedback and Volunteers (Re: Pycon disappointment)
Mike Driscoll wrote: On Mar 18, 1:41 pm, fumanchu [EMAIL PROTECTED] wrote: On Mar 17, 6:25 pm, dundeemt [EMAIL PROTECTED] wrote: I agree - the balance wasn't as good. We can all agree that HowTos and Intros are a necessary part of the conference talks track, but as Robert pointed out some talks should be of a more advanced nature. I enjoy those that stretch my brain. Alex M, Pyke and NetworkIO and Mark Hammond's keynote were among my favorite talks. Raymond Hettinger's talk on collections was not only one of my favorites, it was apparently lots of other people's too--the room was PACKED. I can't recall seeing any other talk that was even close to seating capacity. Robert Brewer [EMAIL PROTECTED] The Using PyGame and PySight to Create an Interactive Halloween Activity (#9) session with Mr. John Harrison was also quite full as was the one for Pyglet. I think the nose presentation had people sitting on the floor. Geeks like games! I know I do! Me too. As I have never attended PyCon, the amount of entertainment already gleaned from this thread has wildly exceeded my expectations. :) Are slides or notes from any of the presentations available online? What was the topic of the well-received presentation from Google? -- http://mail.python.org/mailman/listinfo/python-list
ftp recursively
I need to move a directory tree (~9GB) from one machine to another on the same LAN. What's the best (briefest and most portable) way to do this in Python? I see that urllib has some support for getting files by FTP, but that it has some trouble distinguishing files from directories. http://docs.python.org/lib/module-urllib.html The code handling the FTP protocol cannot differentiate between a file and a directory. I tried it anyway, but got an authentication problem. I don't see a how to log into the FTP server section on docs.python.org. Is there a tutorial I should read? I am particularly looking for a quick, good enough solution that I can use this afternoon. Thanks in advance to any kind-hearted soul who chooses to help me out. -- http://mail.python.org/mailman/listinfo/python-list
Re: ftp recursively
Gabriel Genellina wrote: En Tue, 18 Mar 2008 18:25:28 -0300, Jeff Schwab [EMAIL PROTECTED] escribió: I need to move a directory tree (~9GB) from one machine to another on the same LAN. What's the best (briefest and most portable) way to do this in Python? See Tools/scripts/ftpmirror.py in your Python installation. Thank you, that's perfect. Thanks to Arnaud as well, for the pointer to ftplib, which might useful for other purposes as well. Per the earlier advice of other posters (including one whose message seems mysteriously to have disappeared from c.l.python), I just stuck with the Unix tools I already knew: I ended up tarring the whole 9GB, ftping it as a flat file, and untarring it on the other side. Of course, the motivation wasn't just to get the files from point A to point B using Unix (which I already know how to do), but to take advantage of an opportunity to learn some Python; next time, I'll try the ftpmirror.py script if it's generic enough, or ftplib if there are more specific requirements. -- http://mail.python.org/mailman/listinfo/python-list
Re: String To List
Girish wrote: I have a string a = ['xyz', 'abc'].. I would like to convert it to a list with elements 'xyz' and 'abc'. Is there any simple solution for this?? Do you want: (1) Specifically to vivify lists formatted as in your example? If so, why? (2) To save and restore arbitrary python objects? (3) To define some kind of configuration file format that you can read from Python? -- http://mail.python.org/mailman/listinfo/python-list
Re: python-list Metaquestion
Tom Stambaugh wrote: I continue to receive emails, addressed to [EMAIL PROTECTED], with subject: Re: Your message to Python-list awaits moderator approval, which read: Your mail to 'Python-list' with the subject (no subject) Is being held until the list moderator can review it for approval. The reason it is being held: Message has a suspicious header I'm happy to adjust my headers in whatever way is needed, if I know what the problem is. Is there FAQ somewhere that tells me what I should change? Contact the list administrator and ask whether their spam filters are starting to turn green. http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq03.059.htp -- http://mail.python.org/mailman/listinfo/python-list
Re: Missing PyObject definition
James Whetstone wrote: I'm trying to access a PyObject directly from C++ for the purpose of calling method on a Python object that is an intance of a derived C++ class. My problem is that the compiler is complaining about not PyObject not being defined. Has anyone run into the problem? Where is PyObject defined? Are you using Python's C API? Did you #include Python.h before using PyObject? PyObject is a C-style struct defined in object.h, which is in turn included by Python.h. Does your compiler know where to look for those headers? If you are getting messages of the form error: cannot find Python.h, then add -Iyour_python_root/include/python2.5 (or whatever version) to the CXXFLAGS variable in your makefile, or to your compiler's command line. -- http://mail.python.org/mailman/listinfo/python-list
Re: questions about named pipe objects...
waltbrad wrote: I'm proceeding slowly though the Lutz book Programming Python. I'm in the section on named pipes. The script he uses has two functions: one for the child the other for the parent. You start the parent then the child: python pipefifo.py #starts the parent file /tmp/pipefifo # shows that the file is a named pipe You appear to be using something Unix-like. python pipefifo.py -child # starts a child process and writes to the pipe. This is done between two command windows - the first for the parent and the second for the child. Now, the child's write loop is infinite. So, I used Ctrl-C and stopped the process. But the parent's read loop is also infinite and without and exception, so it keeps reading from the pipe after the child is shutdown even though the lines are empty. So, I had to shut that down also. I then wanted to start the child process first and see what happened when I ran the parent. Well that works but the reads come out in random order. This got me wondering about the pipe file itself. So I tried to open it with leafpad and found that I couldn't. I guess these files can only be opened by processes? Okay. But exactly when does the system brand this file as a named pipe and how? A Unix fifo is only nominally a file. It's really just a convenient way of referring to an in-memory object. mkfifo f some_prog f cat f Is semantically equivalent to: some_prog | cat If you want to peruse the data in your editor, use a regular file, not a fifo. Have the writer (producer, child in your example) open it in append mode. -- http://mail.python.org/mailman/listinfo/python-list
Re: Interesting math problem
BJörn Lindqvist wrote: Here is an interesting math problem: You have a number X 0 and another number Y 0. The goal is to divide X into a list with length Y. Each item in the list is an integer. The sum of all integers is X. Each integer is either A or A + 1, those should be evenly distributed. Example: 17 // 5 = 3 gives the list [3, 3, 4, 3, 4] 16 // 4 = 4 gives the list [4, 4, 4, 4] 113 // 50 = 2 gives the list [2, 3, 2, 3, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3, 3] This algorithm is used a lot in programming. For example, for projecting a line on a pixel display. Your mission, should you choose to accept it, is to improve the code given below which is my best attempt and make it more succinct and easier to read. Preferably by using list comprehensions, map or even reduce def make_slope(distance, parts): step = distance / float(parts) intstep = int(step) floatstep = step - intstep steps = [] acc = 0.0 for i in range(parts): acc += floatstep step = intstep if acc 0.999: step += 1 acc -= 1.0 steps.append(step) return steps # Test code distance = 130 parts = 50 L = make_slope(distance, parts) assert(len(L) == parts) assert(sum(L) == distance) print L def make_slope(distance, parts): if parts == 0: return [] q, r = divmod(distance, parts) if r and parts % r: q += 1 return [q] + make_slope(distance - q, parts - 1) def self_test(distance=130, parts=51): L = make_slope(distance, parts) assert(len(L) == parts) assert(sum(L) == distance) print L if __name__ == '__main__': for distance in range(1, 200): for parts in range(1, 200): self_test(distance, parts) -- http://mail.python.org/mailman/listinfo/python-list
Re: About reading Python code
sturlamolden wrote:
On 17 Mar, 04:54, WaterWalk [EMAIL PROTECTED] wrote:
So I'm curious how to read code effectively. I agree that python code
is clear, but when it becomes long, reading it can still be a hard
work.
First, I recommend that you write readable code! Don't use Python as
if you're entering the obfuscated C contest.
Er, don't use anything other than C if you're entering an obfuscated C
contest, or anything other Perl for an obfuscated Perl contest, etc.
Do use Python if you're entering an obfuscated Python contest. Found
online:
[#[#[#[#[#[#[#[#[# By TaroOgawa #]#]#]#]#]#]#]#]#]
globals()
.update({ __:
lambda x: globals()
.update(( dict([[x]
*2])))}), __(((
Just)))
,__(( another
)),__ (Python
),__( Hacker)
];print (.join(
[(Just),( (another)
),(Python ),Hacker]
));__
Two particularly important points:
* If you find yourself thinking this module is too long, that's
probably what it is. Half a page of code per module is fine. Two pages
of code per module can be too much.
* Comments are always helpful to the reader.
If only 'twere so. *Good* comments are always helpful. Please do not
comment every method with this is a method or the like. One of the
things that often makes newb code stand out is that the programmer
couldn't tell the things that needed to be commented from the places
where comments just got in the way.
Second, I recommend getting a good IDE. E.g. pick one of:
* Microsoft Visual Studio (commercial)
* Eclipse with PyDev and CDT (free)
* SPE (free)
* ActiveState Komodo IDE (commercial)
* Vim on Linux. (No desire here to debate the meaning of IDE, but with
Vim or Emacs on any Unix-like platform, the whole system effectively is
the IDE.)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Interesting math problem
Arnaud Delobelle wrote: On Mar 17, 10:24 pm, BJörn Lindqvist [EMAIL PROTECTED] wrote: Here is an interesting math problem: You have a number X 0 and another number Y 0. The goal is to divide X into a list with length Y. Each item in the list is an integer. The sum of all integers is X. Each integer is either A or A + 1, those should be evenly distributed. Example: 17 // 5 = 3 gives the list [3, 3, 4, 3, 4] 16 // 4 = 4 gives the list [4, 4, 4, 4] 113 // 50 = 2 gives the list [2, 3, 2, 3, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3, 3] This algorithm is used a lot in programming. For example, for projecting a line on a pixel display. Your mission, should you choose to accept it, is to improve the code given below which is my best attempt and make it more succinct and easier to read. Preferably by using list comprehensions, map or even reduce def make_slope(distance, parts): step = distance / float(parts) intstep = int(step) floatstep = step - intstep steps = [] acc = 0.0 for i in range(parts): acc += floatstep step = intstep if acc 0.999: step += 1 acc -= 1.0 steps.append(step) return steps # Test code distance = 130 parts = 50 L = make_slope(distance, parts) assert(len(L) == parts) assert(sum(L) == distance) print L -- mvh Björn OK then, using list comprehensions. It is more succint, is it easier to read? def slope(dist, parts): return [(i+1)*dist/parts - i*dist/parts for i in xrange(parts)] That's awesome, but I sure hope you'd mix in a comment in real code. ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Any fancy grep utility replacements out there?
[EMAIL PROTECTED] wrote: So I need to recursively grep a bunch of gzipped files. This can't be easily done with grep, rgrep or zgrep. (I'm sure given the right pipeline including using the find command it could be donebut seems like a hassle). So I figured I'd find a fancy next generation grep tool. Thirty minutes of searching later I find a bunch in Perl, and even one in Ruby. But I can't find anything that interesting or up to date for Python. Does anyone know of something? I don't know of anything in Python, but it should be straight-forward to write, and I'm betting somebody in this group can do it in one line. (Did you see Arnaud's solution on the Interesting math problem thread?) When you say recursively, do you mean that you want to grep files in nested subdirectories, or do you mean that archive elements should in turn be expanded if they are themselves archives? If you encounter a file that has been compressed twice (gzip|gzip), do you want to uncompress it repeatedly until you get to the original file? For example, given the following setup, what do you expect the output of my_grep to be? ~$ mkdir sample cd sample sample$ for w in hello world; do echo $w |gzip -c $w.gz; done sample$ tar czf helloworld.tgz *.gz sample$ my_grep hello -r . -- http://mail.python.org/mailman/listinfo/python-list
Re: First Program Bug (Newbie)
Benjamin Serrato wrote: P.S. What is the chance I'll get spam for using my real email address? Fendi Chef Bag in Zucca Print - Black Trim Replica AAA, Fake HandBags Cheap Chef Bag in Zucca Print - Black Trim Bags Link : http://www.cnreplicas.com/Fendi_1439.html Chef Bag in Zucca Print - Black Trim Price : $ 170.00 Fendi Hand Bags Link : http://www.cnreplicas.com/Fendi_Replica_Bags.html Replica handbags Home : http://www.cnreplicas.com/ Chef Bag in Zucca Print - Black Trim ,one model of Fendi hand Bags, the most popular designer handbags. You can get top grade Replica Chef Bag in Zucca Print - Black Trim knockoffs at favorable price . Chef Bag in Zucca Print - Black Trim Detailed information : 73f Accessorize in five-star style with this fabulous chef bag from Fendi. The brown and tan signature Fendi print is accented a gathered body adding a sophisticated touch of class. Additional features:Zucca jacquard withblack color patent leather trimBrushed metal hardwareRolled patent handles with ring attachments; 8.75quot; dropPatent band encircles bag with pintucked gathers along seamFrame topZip closure with oversized Fendi-etched metal pullFine textile liningInterior leather-trimmed zip pocket, cellphone pocket, interior multifunctionpocketSerial numberComes with Fendi dust cover and care bookletActual size: 16.5quot; x 5.9quot; x 10.2quot; c34 Buy the cheapest Chef Bag in Zucca Print - Black Trim in toppest Replica . www.cnreplicas.com helps you to save money! The Same Fendi Series : Chef Bag in Zucca Print - Brown Trim Bags : http://www.cnreplicas.com/Fendi_1440.html Crescent Hobo - Black Bags : http://www.cnreplicas.com/Fendi_1441.html Crescent Hobo - Chocolate Bags : http://www.cnreplicas.com/Fendi_1442.html Crescent Hobo - Cream Bags : http://www.cnreplicas.com/Fendi_1443.html Crescent Hobo - Silver Bags : http://www.cnreplicas.com/Fendi_1444.html Crossword Grande Mirrored bag - Gold Bags : http://www.cnreplicas.com/Fendi_1445.html Crossword Grande Mirrored bag - Silver Bags : http://www.cnreplicas.com/Fendi_1446.html Crossword Patent Clutch - Black Bags : http://www.cnreplicas.com/Fendi_1447.html Crossword Patent Clutch - Silver Bags : http://www.cnreplicas.com/Fendi_1448.html Crossword Patent Clutch - White Bags : http://www.cnreplicas.com/Fendi_1449.html Crossword Patent Clutch - Yellow Bags : http://www.cnreplicas.com/Fendi_1450.html Crossword Patent Clutch Multicolored Letters - Black Bags : http://www.cnreplicas.com/Fendi_1451.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Types, Cython, program readability
Ben Finney wrote: sturlamolden [EMAIL PROTECTED] writes: If you don't know how to install a C compiler like Microsoft Visual Studio, you should not be programming computers anyway. Utter elitist nonsense. Programming should be made easier, and I see Python as a very good language for making programming easier. Lowering the barrier for prospective hackers to get into programming is a good thing. The installation of a C compiler is incidental to that, and has no necessary connection with programming. Placing meaningless roadblocks, as you suggest should be done, is anathema to education. Hear, hear! I continue to be shocked when an OS doesn't come with a compiler for the language in which the OS is written. It seems like one of the most basic things that should just be there, along with some kind of command shell (be it CLI or graphical), and ideally a well-defined scripting interface that is easily extensible from the core language. Nowadays, scripts are often intended to work on multiple different platforms; various scripting languages therefore list portability among their most valuable features. One issue from which most of them suffer is that they really are not suitable for systems programming. As scripts evolve into applications, native-language compilers end up being necessary, after all, such that portability of non-trivial programs is severely limited. (It's not really the languages' fault. After all, they were only really meant to enable portable scripting.) Python, I think, helps improve the situation with specific support for applications programming. Unlike Perl or Tcl, Python is not just a scripting language with a set of ad-hoc extensions. There are still issues, and Python probably will never be a general-purpose replacement for system-native language compilers, but it does enable a smooth ramp from just a user, through a user who does some scripting, to application developer. I am of the opinion that the more regular users write and share code, the faster we will see improvement in overall software quality, and the more pleasant the world will be for all of us to live in. See also: http://cm.bell-labs.com/cm/cs/upe/ http://www.linfo.org/unix_philosophy.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Joseph Weizenbaum
Aahz wrote: In article [EMAIL PROTECTED], Tim Roberts [EMAIL PROTECTED] wrote: Jeff Schwab [EMAIL PROTECTED] wrote: Roel Schroeven wrote: [EMAIL PROTECTED] schreef: On Mar 14, 1:47 pm, Reedick, Andrew [EMAIL PROTECTED] wrote: How do you feel about creator of Eliza? What is Eliza? Does that question interest you? Well played, sir. Earlier you said what is Eliza. Do you still feel that way? I am embarrassed to say that this vaguely disrespectful exchange made me laugh out loud. Serious: why do you think this is disrespectful? Not to speak for Tim, but I imagine it could be perceived as disrespectful because Prof. Weizenbaum has only recently passed away. In fact, I think the Prof would be very happy to see people having some fun at the expense of AI, which he saw as a real threat to human freedom. http://www-tech.mit.edu/V128/N12/weizenbaum.html Named for the heroine of My Fair Lady, ELIZA was perhaps the first instance of what today is known as a chatterbot program. Specifically, the ELIZA program simulated a conversation between a patient and a psychotherapist by using a person’s responses to shape the computer’s replies. Weizenbaum was shocked to discover that many users were taking his program seriously and were opening their hearts to it. The experience prompted him to think philosophically about the implications of artificial intelligence, and, later, to become a critic of it. In 1976, he authored Computer Power and Human Reason: From Judgment to Calculation, in which he displayed ambivalence toward computer technology and warned against giving machines the responsibility for making genuinely human choices. Specifically, Weizenbaum argued that it was not just wrong but dangerous and, in some cases, immoral to assume that computers would be able to do anything given enough processing power and clever programming. See also: http://www-ai.ijs.si/eliza-cgi-bin/eliza_script You: What is Eliza? Eliza: Does that question interest you? -- http://mail.python.org/mailman/listinfo/python-list
Re: Need Script For read multiple files(.txt) from a folder
Chris wrote: On Mar 14, 8:36 am, Dennis Lee Bieber [EMAIL PROTECTED] wrote: On Thu, 13 Mar 2008 21:28:18 -0700 (PDT), jai_python [EMAIL PROTECTED] declaimed the following in comp.lang.python: hi frenz I Need a Python Script For read multiple files(.txt) from a folder and write it in a single text file If you are on windows, just open a command prompt and use the standard copy command... C:\Documents and Settings\Dennis Lee Biebercopy /? ... If you want to go that route you could also do: type *.txt output_file.txt On Unix, cygwin, etc: cat dir/*.txt output.txt Or if you need deep copy: cat $(find dir -name '*.txt') output.txt You could write a portable solution in Python (as in Martin Laloux's post), but most modern command-line environments have similar (but not identical) support for globbing and redirecting files. If you're getting the glob pattern from a user, they may expect subtly platform-dependent behaviors, in which case portability might not as important as native feel. -- http://mail.python.org/mailman/listinfo/python-list
Re: Joseph Weizenbaum
Roel Schroeven wrote: [EMAIL PROTECTED] schreef: On Mar 14, 1:47 pm, Reedick, Andrew [EMAIL PROTECTED] wrote: Subject: RIP: Joseph Weizenbaum Creator of Eliza: http://www-tech.mit.edu/V128/N12/weizenbaum.html -- How do you feel about creator of Eliza? What is Eliza? Does that question interest you? Well played, sir. -- Earlier you said what is Eliza. Do you still feel that way? -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there Python equivalent to Perl BEGIN{} block?
Paddy wrote: On Mar 13, 7:03 pm, Jonathan Gardner [EMAIL PROTECTED] wrote: On Mar 12, 6:37 pm, Carl Banks [EMAIL PROTECTED] wrote: Snip And leave out the magical -p and -n. If you want to iterate through a file, for line in sys.stdin:. Or better still: import fileinput for line in fileinput.input(): process(line) I write maybe a dozen one-liners a day. It's not practical to do this with Python, or at least it's not nearly as convenient as Perl. I'm fine with the magic. Abusing the magic is another story; Perl language features are meant to be used in particular contexts, and BEGIN blocks are rarely if ever necessary in Perl modules. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there Python equivalent to Perl BEGIN{} block?
Alex wrote:
The subject says pretty much all, i would very appreciate an answer. I
tried to search the various forums and groups, but didn't find any
specific answer...
I'd like an answer to this, too. In Perl, I mostly used it for
one-liners, when a variable needed to be initialized to some non-default
value; for example, perl -ple 'BEGIN { $sum = 42 } $sum += $_'.
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to port Python code into C++ code automatically?
Bo wrote: I want to port a Python project (about 10,000 line python code) to C+ +. Is there any automatically tool to do this kind of things? e.g., That's not trivial. Python is very heavily oriented toward run-time processing, whereas C++ favors compile-time processing. e.g., SWIG(http://www.swig.org/)? Swig isn't so much a translator as a way of linking C or C++ code to multiple different scripting languages, using shared configuration (.i) files. If you're only connecting two languages (Python and C++), Swig is probably not going to help you much unless you happen to already be a master of Swig-foo. If the Python code works, then it's probably best to keep it in Python. To access it from C++, try Boost.Python. If you really do need to translate the code from Python to C++, try to do it incrementally. If the Python code is so monolithic that you can't find individual pieces to move one-at-a-time, consider refactoring the code in Python so that you'll at least have some modularity to work with. (In the process of refactoring, you may also find that you don't have to move the code out of Python, after all, e.g. because the performance improves along with the design.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Distributed App - C++ with Python for Portability?
Roopan wrote: I assume the C++/Python binding is fairly painless. http://www.boost.org/libs/python/doc/tutorial/doc/html/index.html A. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Regarding coding style
K Viltersten wrote: I've been recommended reading of: http://www.python.org/dev/peps/pep-0008/ and in there i saw two things that i need to get elaborated. 1. When writing English, Strunk and White apply. Where can i download it? Am i actually expected to read the whole book? It's a short book, and worth your time. Searching does turn up free downloads, but I recommend the illustrated version (of which I own a copy). http://www.libraryshop.org/elofstilbywi.html How many people actually do aply it? The problem is how many people don't. 2. You should use two spaces after a sentence-ending period. For heavens sake, why? I've always been obstructed by the double blanks but tolerated them. Now, that i read that it actually is a recommendation, i need to ask about the purpose. (a) It makes the ends of sentences more visually obvious. (b) It makes text easier to parse reliably from scripts. (c) Some text-editors can navigate such sentences out of the box, whereas others cannot. (I recall this limitation with Emacs' text-editing major mode, though it may have been fixed since then; I switched to Vim about five years ago.) -- http://mail.python.org/mailman/listinfo/python-list
OT[1]: Re: SV: Polymorphism using constructors
Dennis Lee Bieber wrote: On Tue, 4 Mar 2008 20:06:38 -0500, Tommy Grav [EMAIL PROTECTED] declaimed the following in comp.lang.python: SV = Svar is the Norwegian word for Reply. Ah, good... In my working life, SV = Space Vehicle, often used to differentiate between the base satellite and PL Payload (the part that earns the money) Which is which? Aren't those both part of the space vehicle? Btw, do you work for government or industry? Do you enjoy working with the space program? I've heard only indirect reviews, and they've been mixed. [1] Av Emne, according to the free online translater. http://www.tranexp.com:2000/Translate/result.shtml -- http://mail.python.org/mailman/listinfo/python-list
Re: OT[1]: Re: SV: Polymorphism using constructors
Dennis Lee Bieber wrote: On Wed, 05 Mar 2008 08:26:04 -0800, Jeff Schwab [EMAIL PROTECTED] declaimed the following in comp.lang.python: Which is which? Aren't those both part of the space vehicle? Btw, do you work for government or industry? Do you enjoy working with the space program? I've heard only indirect reviews, and they've been mixed. Lockheed... I don't really work with the sat's themselves. When it comes to division of responsibility, the payload is the part the customer wants in orbit. The space vehicle is the part that carries it around in that orbit -- the SV has the station-keeping thrusters (I'm presuming a geosynchronous orbit), the power supply and solar panels... The payload may just consist of a wide-band transponder (for direct TV, say) and maybe an independent commanding system (its own receive transmit gear on a different frequency from the satellite control -- though I wouldn't really expect this type of split) Interesting. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: SV: Polymorphism using constructors
What does SV in the subject mean? -- http://mail.python.org/mailman/listinfo/python-list
Re: SV: Polymorphism using constructors
Tommy Grav wrote: On Mar 4, 2008, at 4:53 PM, Jeff Schwab wrote: What does SV in the subject mean? SV = Svar is the Norwegian word for Reply. Thanks. Serves me right for not speaking Norwegian. -- http://mail.python.org/mailman/listinfo/python-list
Re: How about adding rational fraction to Python?
Paul Rubin wrote: I can live with int/int=float but find it sloppy and would be happier if int/int always threw an error (convert explicitly if you want a particular type result). Better yet, how hard would it be to define an otherwise int-like type that did not define a non-flooring division operator? Are there any real use cases for such a type? Maybe a division operator could be defined to perform a run-time check that, for an operation n/d==q, n==q*d; else, throw an exception. Code written to support duck-typed integers should work with such a UDT out of the box. -- http://mail.python.org/mailman/listinfo/python-list
Re: Book Recomendations
Ira Solomon wrote: I am an experienced programmer (40 years) . . . I'm interested in learning Python js wrote: I wonder why nobody mension Python Cookbook yet . . . and Python Standard Library Because cookbooks are not supposed to be language introductions. They are collections of non-obvious techniques, for use by people already familiar with a core language and its standard libraries. Python in particular offers a lot for traditional programmers to wrap their minds around before considering cookbooks; Programming Python, for example, purports to help programmers think Pythonically, and probably belongs chronologically between the introductory books and the cookbooks. Many programmers coming from different languages tend (at first) to write code that makes experienced Pythonistas cringe. Effective use of the language depends on an understanding of its extremely dynamic nature, which can be tough to grasp for those of us coming from compiled language backgrounds. It seems to me, based purely on discussions seen in comp.lang.python, that even folks coming from relatively dynamic languages like Lisp often underestimate the level of run-time indirection provided by Python. One of the neat things about the Nutshell book is that it shows how even the process of resolving object attributes is potentially complicated, and how the new 'type' metaclass helps to at least make the process more consistent than with old-style objects. Experienced programmers first have to learn that an expression like a.x means something very different in Python from what it means elsewhere; then, they can begin leveraging these language features to do the sorts of things illustrated in the cookbooks. -- http://mail.python.org/mailman/listinfo/python-list
Re: First post from a Python newbiw
Christoph Zwerschke wrote: Marc 'BlackJack' Rintsch schrieb: On Sun, 02 Mar 2008 14:15:09 +, Steve Turner wrote: Apart from doing something like a=[0,0,0] b=[0,0,0] c=[0,0,0] d=[a,b,c] is there a better way of creating d?? a = [[0] * 3 for dummy in xrange(3)] Each element of a refers to a distinct array. Why not simply [[0]*3]*3 ? All three elements of the result refer to the same array. -- http://mail.python.org/mailman/listinfo/python-list
Re: How about adding rational fraction to Python?
Paul Rubin wrote:
Jeff Schwab [EMAIL PROTECTED] writes:
Better yet, how hard would it be to define an otherwise int-like type
that did not define a non-flooring division operator? Are there any
real use cases for such a type?
User defined types in python are fairly heavyweight compared with the
built-in types,
Yet they continue to form the basis of almost all non-trivial Python
programs. Anyway, it's a bit soon to be optimizing. :)
and a type like that is just another thing for the
user to have to remember.
How so? A well-written function generally shouldn't depending on the
exact types of its arguments, anyway. If someone has written a function
to find (e.g.) the median of a collection of numbers, their code should
already be prepared to accept values of user-defined numeric types. If
I want to call such a function with my hand-rolled DivisionSafeInteger
type, it should just work, unless specifically documented to work only
with a particular subset of Python data types.
The C library has a bunch of different types like off_t (offset in a
off_t is vendor-specific extension, not part of the standard C library.
In gcc, it's a typedef for __off_t, which is a macro for _G_off_t,
which is in turn a macro for a compiler-specific type called _IO_off_t.
Elsewhere, it may just be a typedef of long int.
file) and size_t, so if you pass an off_t to a function that expects a
size_t as that arg, the compiler notices the error.
On what compiler? I've never seen a C compiler that would mind any kind
of calculation involving two native, unsigned types.
$ cat main.c
#include sys/types.h
int main() { off_t ot = 0; long li = 3L; ot = li; }
$ make
cc -ansi -pedantic -Wall -std=c99main.c -o main
$
But they are
really just integers and they compile with no runtime overhead.
They do indeed have run-time overhead, as opposed to (e.g.) meta-types
whose operations are performed at compile-time. If you mean they have
less overhead than types whose operations perform run-time checks, then
yes, of course that's true. You specifically stated (then snipped) that
you would be happier if int/int always threw an error. The beauty of
a language with such extensive support for user-defined types that can
be used like built-in type is that you are free to define types that
meet your needs. The weight of such hand-rolled solutions may lead to
performance problems at first, but C-linkable extensions go a long way
to help; hence numpy et al.
So, I think Python won't easily support lots of different types of
integers, and we've got what we've got.
My understanding is that Python will easily support lots of different
types of just about anything. That's the point. In theory at least, it
supports programming in a way that lets the translator (compiler +
interpreter) keep track of the exact types being used, so that the
programmer doesn't have to. The fact that the tracking is done
dynamically, rather than statically, is a fundamental design decision
that was made early in the language's development.
There's an interesting talk linked from LTU about future languages:
http://lambda-the-ultimate.org/node/1277
Thanks, but that just seems to have links to the slides. Is there a
written article, or a video of Mr. Sweeney's talk?
--
http://mail.python.org/mailman/listinfo/python-list
Re: First post from a Python newbiw
[EMAIL PROTECTED] wrote: is there a better way of creating d?? a = [[0] * 3 for dummy in xrange(3)] Each element of a refers to a distinct array. Why not simply [[0]*3]*3 ? All three elements of the result refer to the same array. ... whereas you reassign all three elements of [0]* 3. ((0,)*3,)*3 ((0, 0, 0), (0, 0, 0), (0, 0, 0)) You're safe in this one-- changing [0][0] won't change [1][0], 'cuz you can't! A technically correct solution. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Book Recomendations
Ira Solomon wrote: I am an experienced programmer (40 years). I've done Algol (if you've heard of that you must be old too), PL/1, VB,VBA, a little C, and a few other odd languages (e.g. Taskmate). I'm interested in learning Python and have downloaded a slew of books. Too many. I'd like a recommendation as to which books are considered to be the cream of the crop. I know there are tutorials on the web, but, again, I don't know the quality. I would appreciate recommendations on those as well. Python In A Nutshell: http://www.oreilly.com/catalog/pythonian2/ Here's a previous discussion of books for newbies, but I gave my recommendations for other experienced programmers; be forwarned that I'm not quite as experienced as you appear to be. :) http://www.nabble.com/newbie-in-python-td15608979.html#nabble.star15617714-1 -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythons Ladders
Marc 'BlackJack' Rintsch wrote: On Wed, 27 Feb 2008 19:18:27 -0800, Jeff Schwab wrote: Benoit wrote: I've been teaching myself the python language over the past few months using Mark Lutz' Learning Python, 3ed. Python is also the first programming language I've ever taken up. I find the language easy to learn and rather productive in relation to the introductory course on C ++ I'd begun in January for fun @ school (we're practicing dynamic arrays using pointers... kill me now). Get a better teacher, if you can. Please do me a personal favor: Don't hold the crappy course against C++. For the record, you should never have to manage dynamically allocated arrays manually, nor store pointers to them. Try the std::vector template, and post in comp.lang.c++ if have any trouble. Hey a flame bait. I'll bite. Excuse me? Somebody posts about an introductory course on C++ covering dynamic arrays using pointers and literally says kill me now, and I'm the flamer for asking him not to hold the language responsible for the bad course? This a bit of an overreaction unless you know what the course was about. It's supposed to be about C++, according to the OP. If the goal is to learn about the computer and that basically everything is a number in the end, then C is a good choice. More portable than assembler but nearly as close to the metal. And a better choice than C++ would be. To the OP: If you try C++, don't hold that crappy language against C#, D, or Java. ;-) What's the relevance of C#, D, or Java to the OP's post? -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythons Ladders
Marc 'BlackJack' Rintsch wrote: On Thu, 28 Feb 2008 10:34:45 -0800, Jeff Schwab wrote: Hey a flame bait. I'll bite. Excuse me? Somebody posts about an introductory course on C++ covering dynamic arrays using pointers and literally says kill me now, and I'm the flamer for asking him not to hold the language responsible for the bad course? This a bit of an overreaction unless you know what the course was about. It's supposed to be about C++, according to the OP. Yeah, sorry I've read C. Actually it's about a language called C ++ according to the OP. No problem! True that! To the OP: If you try C++, don't hold that crappy language against C#, D, or Java. ;-) What's the relevance of C#, D, or Java to the OP's post? The same as C++ to the OP's post if he would have talked about C. :-) Whew, everybody lives. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythons Ladders
Benoit wrote: Forgive my language concerning C++ as its turned the thread into something I did not intend. I merely wished to point out that Python was easier for me to learn than C++. To Schwab, its likely that Mark Lutz is simply a better instructor than my professor. Sorry for hijacking your thread! In addition to Python Challenge, check out Code Golf: http://codegolf.com/ It's eye-opening to see how concise the solutions can be. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Aahz wrote: In article [EMAIL PROTECTED], Carl Banks [EMAIL PROTECTED] wrote: On Feb 24, 7:03 pm, [EMAIL PROTECTED] (Aahz) wrote: In article [EMAIL PROTECTED], Jeff Schwab [EMAIL PROTECTED] wrote: (3) Garbage collection is at least as desirable a language feature as deterministic destruction. Enh. There probably are some people who claim that, but I can't think of any off-hand. I am most certainly claiming it; in fact I'm claiming that GC far more desirable, because the cost of deterministic destruction is too high. I'm trimming the rest of your post because I don't have time to argue with you, but I want to point out that you're making the same mistake that Jeff is: garbage collection and deterministic destruction are not the only techniques for managing memory and resources. In particular, CPython primarily relies on reference counting That is GC. It's just not mark sweep. , which has similarities with *both* GC and deterministic destruction. Now you know why I said that I don't know anybody who makes Jeff's claim. ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythons Ladders
Benoit wrote: I've been teaching myself the python language over the past few months using Mark Lutz' Learning Python, 3ed. Python is also the first programming language I've ever taken up. I find the language easy to learn and rather productive in relation to the introductory course on C ++ I'd begun in January for fun @ school (we're practicing dynamic arrays using pointers... kill me now). Get a better teacher, if you can. Please do me a personal favor: Don't hold the crappy course against C++. For the record, you should never have to manage dynamically allocated arrays manually, nor store pointers to them. Try the std::vector template, and post in comp.lang.c++ if have any trouble. My problem, however, is that I found myself lacking problems with which to create solutions and so practice what I've learned. I think I'm one of those people who really get into something when the instructions come from without. So I'd like to ask you resident python gurus to help me learn. Give me something to do! Specifically, I'd like to be given tasks that incrementally increase in difficulty, starting from simple file/text manipulation to those harder things like built-in function overloading (you know, where you can make the + operator do something different in relation to a given object). I hope my request doesn't come off as demanding, as perhaps we could archive these tasks for future pedagogy. If something like this already exists though, please point me in the right direction. Otherwise, thanks for any and all assistance. Happy hacking! http://www.pythonchallenge.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: How about adding rational fraction to Python?
J. Cliff Dyer wrote: On Tue, 2008-02-26 at 04:29 -0800, Lie wrote: J Cliff Dyer: I'm in the camp that believes that 3/4 does indeed yield the integer 0, but should be spelled 3//4 when that is the intention. That's creepy for people that are new to programming and doesn't know how CPUs work and are used to general mathematics. That means most people. As programming language are now more accessible to regular people without specialized Computer Science degree, it is a just natural trend that computer arithmetic must be done in an expectable manner as seen by those general population not by people who holds a CS degree. Of course. That's why I think you ought to spell it 3//4. Nobody gets confused when a strange operator that they've never seen before does something unusual. Average Jo off the street looks at python code and sees 3/4, and immediately thinks aha! .75! Show the same person 3//4, and she'll think, A double slash? I'd better check the documentation--or better yet, play with it a little in the interactive interpreter. Or Jo thinks // is a typo, and helpfully fixes it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Nicola Musatti wrote: On Feb 24, 5:25 am, Paul Rubin http://[EMAIL PROTECTED] wrote: Jeff Schwab [EMAIL PROTECTED] writes: there's actually a published book specifically about C++ pitfalls. Mercy, a whole book? http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?EAN=97802... Read the title. This is about C Traps and Pitfalls. Although it shows its age, it's still worth reading. Unfortunately from its price you'd think it was handwritten. That is not a book about C++ pitfalls. That is a book about C pitfalls. They really are two very different languages. Don't get me wrong, C++ has pitfalls of its own -- perhaps the worst of which is writing C and thinking it's C++ in anything other than a superficial sense. But there are vanishingly few cases that could lead to out-of-bounds indexes or dangling pointers anymore. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Jeff Schwab wrote: Nicola Musatti wrote: On Feb 24, 5:25 am, Paul Rubin http://[EMAIL PROTECTED] wrote: Jeff Schwab [EMAIL PROTECTED] writes: there's actually a published book specifically about C++ pitfalls. Mercy, a whole book? http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?EAN=97802... Read the title. This is about C Traps and Pitfalls. Although it shows its age, it's still worth reading. Unfortunately from its price you'd think it was handwritten. That is not a book about C++ pitfalls. That is a book about C pitfalls. Whoops! You already pointed that out. My mistake! As you probably know, Andrew Koenig is reportedly the individual who first proposed argument-dependent lookup, a.k.a Koenig lookup, for C++. -- http://mail.python.org/mailman/listinfo/python-list
Re: Reading a keypress
Dennis Lee Bieber wrote: On Mon, 25 Feb 2008 17:48:21 -0800, Jeff Schwab [EMAIL PROTECTED] declaimed the following in comp.lang.python: What about curses? http://docs.python.org/lib/module-curses.html http://adamv.com/dev/python/curses/ I don't consider needing a 3rd party library for Windows, but not for UNIX/Linux a portable method... The Python module docs claim to support DOS without any kind of extension. I don't know how well (or whether) it works with new versions of Windows. -- http://mail.python.org/mailman/listinfo/python-list
Re: is there enough information?
[EMAIL PROTECTED] wrote: On Feb 26, 10:59 am, Preston Landers [EMAIL PROTECTED] wrote: On Feb 26, 1:45 am, [EMAIL PROTECTED] wrote: Two options occurred to me, which the first showed up in the earlier extremely skeletal and cryptic post: Perhaps you would be more likely to get the kind of help you seem to want if you refrained from posting cryptic and skeletal messages. The fact that many other people have pointed this out to you as of late would tend to suggest you are trolling, i.e. intentionally trying to foster miscommunication and threads that do nothing to advance anyones understanding. And regarding your other recent post about trying to find a solution to the problem of immutable types... Due to the above reasons you are unlikely to influence the design of the core language with half-baked stream of consciousness ramblings. These belong in your LiveJournal, not in c.l.python. If you have a problem you need help with, please read this entire document about 3 times before posting anything else: http://catb.org/~esr/faqs/smart-questions.html Specifically this: http://catb.org/~esr/faqs/smart-questions.html#beprecise and this: http://catb.org/~esr/faqs/smart-questions.html#goal Ugh, very well. You call for an explanation. Back home, the original post would be interesting, so I wrote it. Whatever reactions other people have to them is information that is unavailable to me. I don't know you. I'm rather irked by a proportion of posts, but for my part, it's hard to get me to point a finger. I am not a troll. I want a sustainable, healthy, productive, educational, informative relationship with frequenters of c.l.p, the Python community at large, and anyone who has anything non-negative to contribute. If you are wanting to see how I react to hostility, just ask. I'll fake it for you, but only for a second at a time. Wow. I sure hope I don't come across like castiron does here. Now, what help is it that you believe I seem to want? All I asked for was, ideas. It's a little difficult for me to interpret your code, partly because I am nbt very familiar with Python's support for concurrency. But what are you trying to a achieve? You mentioned: I recently ran into a case (* would that be helpful to describe here?) where thread1 had to do something, thread2 had to do something after that, and thread1 had to wait for that, then do something else, and thread2 again had to wait before starting the first thing again. This is ordinarily called a Producer-Consumer model. It is often implemented using semaphores. Googling python semaphore turns up this documentation: http://www.python.org/doc/lib/semaphore-objects.html That page, in turn, links to an example of the proper use of semaphores in Python. Does that help? -- http://mail.python.org/mailman/listinfo/python-list
Re: How about adding rational fraction to Python?
Grant Edwards wrote: I guess it must depend on where you went to shool. Temple Israel. You? -- http://mail.python.org/mailman/listinfo/python-list
Re: is there enough information?
[EMAIL PROTECTED] wrote: On Feb 26, 11:37 am, Jeff Schwab [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On Feb 26, 10:59 am, Preston Landers [EMAIL PROTECTED] wrote: On Feb 26, 1:45 am, [EMAIL PROTECTED] wrote: Two options occurred to me, which the first showed up in the earlier extremely skeletal and cryptic post: Perhaps you would be more likely to get the kind of help you seem to want if you refrained from posting cryptic and skeletal messages. The fact that many other people have pointed this out to you as of late would tend to suggest you are trolling, i.e. intentionally trying to foster miscommunication and threads that do nothing to advance anyones understanding. And regarding your other recent post about trying to find a solution to the problem of immutable types... Due to the above reasons you are unlikely to influence the design of the core language with half-baked stream of consciousness ramblings. These belong in your LiveJournal, not in c.l.python. If you have a problem you need help with, please read this entire document about 3 times before posting anything else: http://catb.org/~esr/faqs/smart-questions.html Specifically this: http://catb.org/~esr/faqs/smart-questions.html#beprecise and this: http://catb.org/~esr/faqs/smart-questions.html#goal Ugh, very well. You call for an explanation. Back home, the original post would be interesting, so I wrote it. Whatever reactions other people have to them is information that is unavailable to me. I don't know you. I'm rather irked by a proportion of posts, but for my part, it's hard to get me to point a finger. I am not a troll. I want a sustainable, healthy, productive, educational, informative relationship with frequenters of c.l.p, the Python community at large, and anyone who has anything non-negative to contribute. If you are wanting to see how I react to hostility, just ask. I'll fake it for you, but only for a second at a time. Wow. I sure hope I don't come across like castiron does here. Now, what help is it that you believe I seem to want? All I asked for was, ideas. It's a little difficult for me to interpret your code, partly because I am nbt very familiar with Python's support for concurrency. But what are you trying to a achieve? You mentioned: I recently ran into a case (* would that be helpful to describe here?) where thread1 had to do something, thread2 had to do something after that, and thread1 had to wait for that, then do something else, and thread2 again had to wait before starting the first thing again. This is ordinarily called a Producer-Consumer model. It is often implemented using semaphores. Googling python semaphore turns up this documentation: http://www.python.org/doc/lib/semaphore-objects.html That page, in turn, links to an example of the proper use of semaphores in Python. Does that help?- Hide quoted text - - Show quoted text - Hi Jeff. I've enjoyed your recent posts. I'm not quite sure a semaphore is exactly the synchronization object I'm looking for, but I'm a little new to concurrency myself. In the interface I design, only one with-call can get the result at once. It was my understanding that semaphores, and many other synch. objs. returned control at random. I take this to mean that your interface offers a function returns immediately, rather than waiting for the work to complete. Is that correct? In fact, in the background, I'm working on something a little more substantial than this, but it's not done, so the only review of it I can perform is of its interface. The interface is (in my opinion) usually the best place to start the code, anyway. If someone has a yes, but in half the lines, at twice the speed, then tear my posts to shreds. It is not quite clear what your code is intended to do. That doesn't mean there's necessarily anything wrong with it, but it's hard for most Usenetters to take the time to read such long sequences of code. Would it be possible for you to post a complete program, that we can actually run? Wherever your code is not yet ready, just put a line or two of stub code, and add a comment to explain what should be happening. -- http://mail.python.org/mailman/listinfo/python-list
Re: is there enough information?
[EMAIL PROTECTED] wrote: On Feb 26, 12:04 pm, Jeff Schwab [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On Feb 26, 11:37 am, Jeff Schwab [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On Feb 26, 10:59 am, Preston Landers [EMAIL PROTECTED] wrote: On Feb 26, 1:45 am, [EMAIL PROTECTED] wrote: Two options occurred to me, which the first showed up in the earlier extremely skeletal and cryptic post: Perhaps you would be more likely to get the kind of help you seem to want if you refrained from posting cryptic and skeletal messages. The fact that many other people have pointed this out to you as of late would tend to suggest you are trolling, i.e. intentionally trying to foster miscommunication and threads that do nothing to advance anyones understanding. And regarding your other recent post about trying to find a solution to the problem of immutable types... Due to the above reasons you are unlikely to influence the design of the core language with half-baked stream of consciousness ramblings. These belong in your LiveJournal, not in c.l.python. If you have a problem you need help with, please read this entire document about 3 times before posting anything else: http://catb.org/~esr/faqs/smart-questions.html Specifically this: http://catb.org/~esr/faqs/smart-questions.html#beprecise and this: http://catb.org/~esr/faqs/smart-questions.html#goal Ugh, very well. You call for an explanation. Back home, the original post would be interesting, so I wrote it. Whatever reactions other people have to them is information that is unavailable to me. I don't know you. I'm rather irked by a proportion of posts, but for my part, it's hard to get me to point a finger. I am not a troll. I want a sustainable, healthy, productive, educational, informative relationship with frequenters of c.l.p, the Python community at large, and anyone who has anything non-negative to contribute. If you are wanting to see how I react to hostility, just ask. I'll fake it for you, but only for a second at a time. Wow. I sure hope I don't come across like castiron does here. Now, what help is it that you believe I seem to want? All I asked for was, ideas. It's a little difficult for me to interpret your code, partly because I am nbt very familiar with Python's support for concurrency. But what are you trying to a achieve? You mentioned: I recently ran into a case (* would that be helpful to describe here?) where thread1 had to do something, thread2 had to do something after that, and thread1 had to wait for that, then do something else, and thread2 again had to wait before starting the first thing again. This is ordinarily called a Producer-Consumer model. It is often implemented using semaphores. Googling python semaphore turns up this documentation: http://www.python.org/doc/lib/semaphore-objects.html That page, in turn, links to an example of the proper use of semaphores in Python. Does that help?- Hide quoted text - - Show quoted text - Hi Jeff. I've enjoyed your recent posts. I'm not quite sure a semaphore is exactly the synchronization object I'm looking for, but I'm a little new to concurrency myself. In the interface I design, only one with-call can get the result at once. It was my understanding that semaphores, and many other synch. objs. returned control at random. I take this to mean that your interface offers a function returns immediately, rather than waiting for the work to complete. Is that correct? In fact, in the background, I'm working on something a little more substantial than this, but it's not done, so the only review of it I can perform is of its interface. The interface is (in my opinion) usually the best place to start the code, anyway. If someone has a yes, but in half the lines, at twice the speed, then tear my posts to shreds. It is not quite clear what your code is intended to do. That doesn't mean there's necessarily anything wrong with it, but it's hard for most Usenetters to take the time to read such long sequences of code. Would it be possible for you to post a complete program, that we can actually run? Wherever your code is not yet ready, just put a line or two of stub code, and add a comment to explain what should be happening.- Hide quoted text - - Show quoted text - Sure. And honestly, I have no idea what the best way to go about this is, except keep trying. th1 th2 set cmd run cmd get result acknowledge continue continue th2 won't -run cmd- until th1 completes -set cmd-. th1 won't -get result- until th2 completes -run cmd-. and once -acknowledge- completes, both can go about their merry ways. That is exactly the kind of case where semaphores are usually used. Thread1 can fill the semaphore when the command is ready, then Thread2 can empty the semaphore once it has finished running the command. In the example last night, th2 continued to loop
Re: is there enough information?
[EMAIL PROTECTED] wrote: On Feb 26, 12:37 pm, Jeff Schwab [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On Feb 26, 12:04 pm, Jeff Schwab [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On Feb 26, 11:37 am, Jeff Schwab [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On Feb 26, 10:59 am, Preston Landers [EMAIL PROTECTED] wrote: On Feb 26, 1:45 am, [EMAIL PROTECTED] wrote: Two options occurred to me, which the first showed up in the earlier extremely skeletal and cryptic post: Perhaps you would be more likely to get the kind of help you seem to want if you refrained from posting cryptic and skeletal messages. The fact that many other people have pointed this out to you as of late would tend to suggest you are trolling, i.e. intentionally trying to foster miscommunication and threads that do nothing to advance anyones understanding. And regarding your other recent post about trying to find a solution to the problem of immutable types... Due to the above reasons you are unlikely to influence the design of the core language with half-baked stream of consciousness ramblings. These belong in your LiveJournal, not in c.l.python. If you have a problem you need help with, please read this entire document about 3 times before posting anything else: http://catb.org/~esr/faqs/smart-questions.html Specifically this: http://catb.org/~esr/faqs/smart-questions.html#beprecise and this: http://catb.org/~esr/faqs/smart-questions.html#goal Ugh, very well. You call for an explanation. Back home, the original post would be interesting, so I wrote it. Whatever reactions other people have to them is information that is unavailable to me. I don't know you. I'm rather irked by a proportion of posts, but for my part, it's hard to get me to point a finger. I am not a troll. I want a sustainable, healthy, productive, educational, informative relationship with frequenters of c.l.p, the Python community at large, and anyone who has anything non-negative to contribute. If you are wanting to see how I react to hostility, just ask. I'll fake it for you, but only for a second at a time. Wow. I sure hope I don't come across like castiron does here. Now, what help is it that you believe I seem to want? All I asked for was, ideas. It's a little difficult for me to interpret your code, partly because I am nbt very familiar with Python's support for concurrency. But what are you trying to a achieve? You mentioned: I recently ran into a case (* would that be helpful to describe here?) where thread1 had to do something, thread2 had to do something after that, and thread1 had to wait for that, then do something else, and thread2 again had to wait before starting the first thing again. This is ordinarily called a Producer-Consumer model. It is often implemented using semaphores. Googling python semaphore turns up this documentation: http://www.python.org/doc/lib/semaphore-objects.html That page, in turn, links to an example of the proper use of semaphores in Python. Does that help?- Hide quoted text - - Show quoted text - Hi Jeff. I've enjoyed your recent posts. I'm not quite sure a semaphore is exactly the synchronization object I'm looking for, but I'm a little new to concurrency myself. In the interface I design, only one with-call can get the result at once. It was my understanding that semaphores, and many other synch. objs. returned control at random. I take this to mean that your interface offers a function returns immediately, rather than waiting for the work to complete. Is that correct? In fact, in the background, I'm working on something a little more substantial than this, but it's not done, so the only review of it I can perform is of its interface. The interface is (in my opinion) usually the best place to start the code, anyway. If someone has a yes, but in half the lines, at twice the speed, then tear my posts to shreds. It is not quite clear what your code is intended to do. That doesn't mean there's necessarily anything wrong with it, but it's hard for most Usenetters to take the time to read such long sequences of code. Would it be possible for you to post a complete program, that we can actually run? Wherever your code is not yet ready, just put a line or two of stub code, and add a comment to explain what should be happening.- Hide quoted text - - Show quoted text - Sure. And honestly, I have no idea what the best way to go about this is, except keep trying. th1 th2 set cmd run cmd get result acknowledge continue continue th2 won't -run cmd- until th1 completes -set cmd-. th1 won't -get result- until th2 completes -run cmd-. and once -acknowledge- completes, both can go about their merry ways. That is exactly the kind of case where semaphores are usually used. Thread1 can fill the semaphore when the command is ready, then Thread2 can empty the semaphore once it has
Re: How about adding rational fraction to Python?
J. Cliff Dyer wrote: On Tue, 2008-02-26 at 13:51 -0500, D'Arcy J.M. Cain wrote: On Tue, 26 Feb 2008 13:39:38 -0500 J. Cliff Dyer [EMAIL PROTECTED] wrote: a = 2 * 2 b = 20 * 20 type(a) type 'int' type(b) type 'long' A long int is still integral which is the crux of the issue. So do you believe that you should not be able to do natural division without explicitly casting ints as floats, or is your concern just that you want to still be able to to integer division simply? I think the issue is whether this qualifies as natural division in the first place. (For the record, I'm only semi-old-school.) -- http://mail.python.org/mailman/listinfo/python-list
Re: How about adding rational fraction to Python?
Paul Rubin wrote: D'Arcy J.M. Cain [EMAIL PROTECTED] writes: http://en.wikipedia.org/wiki/Natural_number Recheck the context. I was talking about the natural result, not natural numbers. The natural result of doing arithmetic with natural numbers is more natural numbers. Back when I was just a wee little developer, I was taught that division over the natural number was *not* a closed operation. (I still like integer division, and I'm OK with the fact that it truncates.) -- http://mail.python.org/mailman/listinfo/python-list
Re: How about adding rational fraction to Python?
Grant Edwards wrote: On 2008-02-26, Jeff Schwab [EMAIL PROTECTED] wrote: Grant Edwards wrote: I guess it must depend on where you went to shool. Temple Israel. You? Good one. :) I make a lot of typo's on Usenet, so I'm always secretly relieved when other people do, too. (IOW, thanks for being a good sport about it.) -- http://mail.python.org/mailman/listinfo/python-list
Re: is there enough information?
[EMAIL PROTECTED] wrote: On Feb 26, 12:42 pm, Jeff Schwab [EMAIL PROTECTED] wrote: ... th1 th2 set cmd run cmd get result acknowledge continue continue th2 won't -run cmd- until th1 completes -set cmd-. th1 won't -get result- until th2 completes -run cmd-. and once -acknowledge- completes, both can go about their merry ways. That is exactly the kind of case where semaphores are usually used. Thread1 can fill the semaphore when the command is ready, then Thread2 can empty the semaphore once it has finished running the command. I want to awaken -that- -specific- -thread-. Semaphore acquire: The implementation may pick one at random. Lock acquire: which one of the waiting threads proceeds is not defined Event set: All threads waiting for it to become true are awakened Condition notify: This method wakes up one of the threads waiting Condition notifyAll: Wake up all threads waiting on this condition I will contend it's impossible without a specialization. Certainly an array of semaphores could fit the bill; is that what you were suggesting? A collection of semaphores could well be the right solution. Actually, I'm getting the feeling that you want something like a Java Futures: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Future.html Does that sound promising? -- http://mail.python.org/mailman/listinfo/python-list
Re: Adobe CS3
D'Arcy J.M. Cain wrote: On Tue, 26 Feb 2008 12:58:53 -0800 Tobiah [EMAIL PROTECTED] wrote: A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? But then again, when just adding a quip to a long thread in which the readers have already seen the previous comments, top posting can be an advantage to the reader. Unless, of course, you know how to trim quoted text. And unless the reader (like me) tends to scroll immediately to the bottom of the post anyway, without looking for a one-line comment at the top. -- http://mail.python.org/mailman/listinfo/python-list
Re: How about adding rational fraction to Python?
Mark Dickinson wrote: On Feb 26, 9:00 pm, Paul Rubin http://[EMAIL PROTECTED] wrote: Certainly, I'd expect that if x and y are both integers and x is an exact multiple of y, then x/y will be computable and not overflow. But try computing 10**5000 / 10**4000 under future division (that is supposed to give a float). And smaller numbers are problematic too: from __future__ import division 10**50/10**40 100.0 10**60/10**50 99.981 This despite the fact that the quotient *is* exactly representable You know what I find weird about this? The result of truncating division in this case is not just less accurate than it could be; it's actually greater than the result of non-truncating division. (10**60//10**50) (10**60/10**50) True -- http://mail.python.org/mailman/listinfo/python-list
Re: object identity and hashing
[EMAIL PROTECTED] wrote: On Feb 24, 9:28 pm, George Sakkis [EMAIL PROTECTED] wrote: [1]http://www.martinfowler.com/eaaCatalog/identityMap.html [1] illustrates a case in which 'a is a' returns False, and in the other corner of the DeMorgan table, there is 'a is b' returns True for 'a == b' False. What is the 'a is a' == False case? I don't see anything like that illustrated on the Identity Map page. Is it P of EAA? -- http://mail.python.org/mailman/listinfo/python-list
Re: Reading a keypress
Dennis Lee Bieber wrote: On Mon, 25 Feb 2008 10:35:54 -0800 (PST), wyleu [EMAIL PROTECTED] declaimed the following in comp.lang.python: I'm trying to read a single keypress on Linux but expect to have the programme running on Windows platform as well and find the mention in the FAQ: UNIX terminal control stuff snipped. There is NO directly portable way to do low-level I/O with the console. What about curses? http://docs.python.org/lib/module-curses.html http://adamv.com/dev/python/curses/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Matthew Woodcraft wrote: Jeff Schwab [EMAIL PROTECTED] wrote: Matthew Woodcraft wrote: I see. Then, unless you don't care about data loss passing silently, this 'most traditional' way to open a file is unsuitable for files opened for writing. No, why would you think so? If you want something special to happen when the close() fails (as you indeed would if you were writing important data), you have to say somehow that you want your special code called. What syntax would you like to see? Here's what the C++ would look like, supposing you have a type LoggingCloser that calls close and logs any failure: Sure, but this LoggingCloser isn't what you described as the 'most traditional, easiest way to open a file in C++'. It's not there to open the file, it's there to check the error code on close. That's what you said you wanted. The more general point is that, where you want to take action on cleanup and you need to handle errors from this action, it usually isn't enough to have one class per type of resource which knows what clean up action is required (because the required response to the error usually varies). If there is variation, you can either pass some data to the responsible object's constructor, or you can give it policies for what to do in different situations. http://en.wikipedia.org/wiki/Policy-based_design Additionally, in languages where exceptions are the usual way to report errors but exceptions from destructors are not managed pleasantly, the error recovery code can't use the language's normal mechanisms for dealing with the error response. Huh? Why not? -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Larry Bugbee wrote: And the migration to Python is due in large part because of an additional factor of 3-4x in personal productivity (over Java). Improvements in runtime performance wouldn't hurt, but for many applications that's not an issue. (If optional data typing were You mean static data typing, right? Are there any known holes in the dynamic type system that still need to be plugged? (I haven't heard of any.) offered, Python's penetration in the enterprise space would be even higher, and I suspect there would be performance gains as well.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Create multiple directories
Paul Lemelle wrote: I am somewhat new to Python and I am trying to create a program that automatically creates directories from a range of numbers. I researched the os.mkdir os.makedirs methods, but they do not seem to (I don't know) how to include an argumnet to step through my list. I woudl like to do the follwoing: 1) Ask the user how many folders to create 2) take raw_input and then translate it into a while loop that steps through the os.mkdir process. Maybe something like this? import os def mkdirs(n): for i in range(n): os.mkdir(%d % i) if __name__ == '__main__': mkdirs(int(raw_input(How many folders should I create? ))) -- http://mail.python.org/mailman/listinfo/python-list
Re: object identity and hashing
[EMAIL PROTECTED] wrote:
Can someone explain this?
a= {}
Create an empty dict and bind it to the name a.
a[(3,)]= 0
Set the key/value pair (3,):0 to the dict.
(3,) in a
Is (3,) one of the keys in the dict?
True
Yes, it is.
(3,) is (3,)
Create two separate tuples (that happen to be equivalent). Are they the
same object?
False
No, they are not.
Every time you write (3,), you are potentially creating a new object.
These objects have equal values (and hash codes), so they are
interchangeable for purposes of keying a dict.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Bruno Desthuilliers wrote: Jeff Schwab a écrit : Bruno Desthuilliers wrote: Carl Banks a écrit : On Feb 20, 8:58 am, Tim Chase [EMAIL PROTECTED] wrote: You Used Python to Write WHAT? http://www.cio.com/article/185350 Furthermore, the power and expressivity that Python offers means that it may require more skilled developers. [...down to the summary...] Python may not be an appropriate choice if you: [...] * Rely on teams of less-experienced programmers. These developers may benefit from the wider availability of training for languages like Java and are less likely to make mistakes with a compile-time, type-checked language. (snip) C++ is a compile-time, type-checked language, which means it is totally safer for newbies than Python. Yep, your big company is totally safe with newbie C++ programmers. Mouarf ! Brillant demonstration, thanks Carl !-) (and BTW, +1 QOTW) NB: This is not a troll. (Please, nobody try to be cute with a yes it is reply.) NB : standard disclaimer about all the following being MVHO. c.l.python seem to be about the most close-minded of any of the currently popular language-specific news groups. May I suggest you take a tour on c.l.lisp then ?-) It's just taken for granted that Perl and C++, two of my personal favorite things in this world, inherently favor ugly, buggy code. I wouldn't say so. It's a fact that C++ is a really complex language with quite a lot of room for BigMistakes(tm), and that there's something like a 'my-code-is-more-cryptic-than-yours' culture in Perl. You cannot seriously argue on this. I'm not going to argue, because I'm tired of arguing. But I think you're SeriouslyMistaken(tm). Now this has nothing to do with the respective merits of both languages (FWIW, Perl, as a 'Practical Extracting and Reporting Language', beats any other language I know pants down), and I'd be sorry if you were to confuse what is mostly on the friendly jokes side with mere bashing. You may not have noticed, but quite a lot of people here have a working experience with either C++ and/or Perl. Yes. These jokes don't strike me as friendly, though. They strike me as ignorant and hostile. As for my above comment, it doesn't imply anything else than the fact that C++ is way harder to learn than Python (or Ruby etc...), and that bugs in C++ code are likely to have way more nasty results. Both of which I disagree with. I don't see how the same brain can believe it's much harder to do good things, yet much easier to do bad things, in the same language. The joke is not against C++, but about people asserting than static type checking is safer than dynamic type checking without realizing that what is really important is*runtime type checking - something C++ doesn't provide. C++ does provide some run-time type-checking, whereas Python offers virtually no static type-checking. Clearly, C++ does not natively have a run-time environment as powerful as Python's, and that's one of the primary reasons to use Python. If you need a heavyweight runtime environment available from C++, you have to provide one. This is a direct consequence of early design decisions intended to make C++ competitive with C. I have yet to see a runtime-heavy C++ library I really like, whereas Python, Ruby, and Java all have fantastic sets of run-time facilities. NB : As a side note, and while being myself a bit passionated when it comes to languages and my job in general, I would not go as far as labelling any language or technology as one of my favorite things in this world. That's OK. :) I really do feel that way, though. Call me a dork. That is the farthest thing from the truth as I see it. You can (and plenty of people will) write terrible code in any language, including Python. Indeed. Bad coders write bad code, period. And I think we've all been bad coders one day, and that we're all still bad coders sometimes. Aha! Now we're getting somewhere! To use Python effectively, you have to know something about how it works, and the same is true of Perl and C++. And of any other language. Now a decent C++ or Perl programmer can be proficient in Python in a couple weeks and become a master within a year at worst. And it seems that non-professional, occasional programmers (hobbyists, gamers, scientists, and any other kind of power user) are able to get their job done in Python without much pain. They can get their jobs done with C++ without much pain, too, given even a little bit of decent guidance. It's true that you *can* shoot yourself in the foot with C++, but you kind of have to work at it. (One good way is to write C code, and think it's C++.) But a newbie who's learning from a decent source (avoid the C++ for Morons style books) is likely (I contend) to be writing semi-useful programs about as fast as with Python, and to be writing heavy-duty work
Re: Article of interest: Python pros/cons for the enterprise
George Sakkis wrote: On Feb 22, 2:15 pm, Jeff Schwab [EMAIL PROTECTED] wrote: Nicola Musatti wrote: The real sad thing is that nobody is likely to convince Guido to turn CPython into C++Python ;-) How difficult would that be? Could it be done in stages? I would be willing to spend some time on that kind of project. Yeah right.. what we need is yet another implementation of Python. At least Jython/IronPython/Pypy (and Pyrex, Cython, Shedskin, etc.) had a better motivation than my language is better than yours. I am sure your time, skills and experience would be much appreciated in more useful projects. Neither C++ nor C is my language, nor yours. I love all my children the same. :) That said, your point is well taken. What I would like is not so much a new Python implementation, as a vehicle to help demonstrate a few things to other Python users. Recently, I've had a few replies in tones that imply I'm on the brink of entering several kill-files, mostly because I express disagreement with a few closely held beliefs of some other c.l.p posters. For example, the following are widely held opinions with which I disagree: (1) Python is a gotcha-free language. (2) C++ is basically the same language as C, but more complicated. (3) Garbage collection is at least as desirable a language feature as deterministic destruction. (4) Static typing is inferior to dynamic typing. One of the things that's supposed to be great about Python is the user community, and in many ways, that community is wonderful; for example, both new and experienced users can quickly get a variety of solutions to any given coding issue, just by asking for help. In other ways, though, the Python community is just blindingly ignorant, arrogant, and argumentative. I expect my use of Python to increase in the coming years, so I want the best possible relationship with other regular users, especially on Usenet. To do that, I think it would be helpful to have an informed discussion. Instead, I mostly just the same old justifications for baseless bigotry: I worked with crappy [Perl or C++] code for ten years, so when I tell you [Perl or C++] encourages crappy code, I know what I'm talking about. These beliefs are accepted by just about everybody. You don't *really* think all these bright people are wrong, do you? C++ is not newbie-friendly; if you need proof, just look at all these really low-level ways you can screw yourself. When I see this silliness again and again, it really breaks my heart, because the culture of the software development industry has a strong effect on the quality of my own life. I care about clean air, because I breath it; clean water, because I drink it; and I am starting to become really concerned about the clarity of mind of the Python community, because I hope to rely on it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Ryan Ginstrom wrote: On Behalf Of Jeff Schwab When I see this silliness again and again, it really breaks my heart If you allow your heart to be broken by others' opinions, you're setting yourself up for a lot of disappointment IMHO. It's not so much their opinions, as the fact that their opinions strongly influence their work. But you're probably right, anyway. I personally used C++ for about 90% of my code for 10 years. During that time, I was chugging the C++ Kool-Aid so hard I almost peed myself. I still think that C++ is a beautiful language, but I have also come to think that starting a program with C++ is a premature optimization. I'm not much of a Kool Aid drinker. :) I just tend to find, when I develop anything non-trivial in a language other than C++, that I wish I had used C++, because it would have allowed me to enforce design semantics more efficiently. Optimization has nothing to do with it; I'm a firm believer in profiling before you optimize. I think that very few Python programmers today started with Python. Most of them came to Python for a reason. For several reasons, even! -- http://mail.python.org/mailman/listinfo/python-list
Re: Return value of an assignment statement?
[EMAIL PROTECTED] wrote:
What you can't do (that I really miss) is have a tree of assign-and-test
expressions:
import re
pat = re.compile('some pattern')
if m = pat.match(some_string):
do_something(m)
else if m = pat.match(other_string):
do_other_thing(m)
else:
do_default_thing()
What you want is:
for astring, afunc in ((some_string, do_something), (other_string,
do_other_thing)):
m = pat.match(astring)
if m:
afunc(m)
break
else:
do_default_thing()
That looks like the first realistic alternative I've seen. I find the
flow a little hard to follow, but I think that's mostly just because I'm
not accustomed to the syntax.
Your approach fits in my head a little more comfortably if none of the
lines are longer than eighty columns, if the for-loop isn't given an
else-clause (which still looks to my untrained eye like it should match
the preceding if), and if the break-statement is replaced with a
return-statement:
actions = (
('some_string', do_something),
('other_string', do_other_thing))
def find_action(pattern):
for string, action in actions:
m = pattern.match(string)
if m:
return action
return do_default_thing
find_action(re.compile('some pattern'))()
--
http://mail.python.org/mailman/listinfo/python-list
Re: Return value of an assignment statement?
Jeff Schwab wrote:
mrstephengross wrote:
Hi all. In C, an assignment statement returns the value assigned. For
instance:
int x
int y = (x = 3)
In the above example, (x=3) returns 3, which is assigned to y.
In python, as far as I can tell, assignment statements don't return
anything:
y = (x = 3)
The above example generates a SyntaxError.
Is this correct? I just want to make sure I've understood the
semantics.
Yes, but there is valid syntax for the common case you mentioned:
y = x = 3
What you can't do (that I really miss) is have a tree of assign-and-test
expressions:
import re
pat = re.compile('some pattern')
if m = pat.match(some_string):
do_something(m)
else if m = pat.match(other_string):
do_other_thing(m)
else:
do_default_thing()
This is apparently section 1.9 of the Python Cookbook:
http://www.oreilly.com/catalog/pythoncook2/toc.html
Martelli suggests something similar to the thigamabob technique I use
(he calls it DataHolder). It's really more like the xmatch posted by
Paul Rubin.
Martelli also says, though, that if you need this, you're not thinking
Pythonically. I don't know what the Pythonic alternative is. The
iterating-over-pairs approach suggested by Bruno is the only alternative
I've seen.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Paul Rubin wrote:
Jeff Schwab [EMAIL PROTECTED] writes:
The most traditional, easiest way to open a file in C++ is to use an
fstream object, so the file is guaranteed to be closed when the
fstream goes out of scope.
Python has this too, except it's using a special type of scope
created by the with statement.
Yes, this seems to be the Python way: For each popular feature of some
other language, create a less flexible Python feature that achieves the
same effect in the most common cases (e.g. lambda to imitate function
literals, or recursive assignment to allow x = y = z).
CPython offers a similar feature, since
you can create a temporary object whose reference count will become
zero at the end of the statement where it is defined:
$ echo world hello
$ python
file('hello').read()
'world\n'
CPython does not guarantee that the reference count will become zero
at the end of the statement. It only happens to work that way in your
example, because the file.read operation doesn't make any new
references to the file object anywhere.
It doesn't happen to work that way in the example; it works that way
by design. I see what you're saying, though, and it is a good point.
Given a statements of the form:
some_class().method()
The method body could create an external reference to the instance of
some_class, such that the instance would not be reclaimed at the end of
the statement.
Other code might well do
something different, especially in a complex multi-statement scope.
Your scheme's
It's not my scheme. I got it from Martelli.
determinism relies on the programmer accurately keeping
track of reference counts in their head, which is precisely what
automatic resource management is supposed to avoid.
This is a special case of the reference count being 1, then immediately
dropping to zero. It is simple and convenient. The approach is, as you
rightly point out, not extensible to more complicated situations in
Python, because the reference counting ceases to be trivial.
The point is that once you tie object lifetimes to scope, rather than
unpredictable garbage collection, you can predict with perfect ease and
comfort exactly where the objects are created and destroyed. If you can
then request that arbitrary actions be taken automatically when those
events happen, you can pair up resource acquisitions and releases very
easily. Each resource has an owner object whose constructor acquires,
and whose destructor releases. The resources are released in the
reverse order, which is almost always exactly what you want.
Suppose you are using objects that have to be closed when you have
finished with them. You would associate this concept with a type:
class Closer:
def __init__(self, closable):
self.closable = closable)
def __del__(self):
self.closable.close()
The C++-style paradigm would then let you do this:
def my_func(a, b, c):
a_closer = Closer(a)
b_closer = Closer(b)
c_closer = Closer(c)
# ... arbitrary code ...
If an exception gets thrown, the objects get closed. If you return
normally, the objects get closed. This is what with is supposed to
replace, except that it only seems to cover the trivial case of a
single, all-in-one cleanup func. That's only a direct replacement for a
single constructor/destructor pair, unless you're willing to have an
additional, nested with-statement for each resource.
Now suppose there is an object type whose instances need to be
released rather than closed; i.e., they have a release() method, but
no close() method. No problem: You have the Closer class get its
action indirectly from a mapping of types to close-actions. Whenever
you have a type whose instances require some kind of cleanup action, you
add an entry to the mapping.
class Closer:
actions = TypeActionMap()
# ...
def __del__(self):
actions[type(self.closable)](self.closable)
The mapping is not quite as simple as a dict, because of inheritance.
This is what function overloads and C++ template specializations are
meant to achieve. Similar functionality could be implemented in Python
via pure Python mapping types, represented above by TypeActionMap.
If you want
reliable destruction it's better to set it up explicitly, using
with.
That's true of the current language. I don't have enough experience
with with yet to know whether it's a realistic solution to the issue.
IMO, they are at least preferable to Java-style finally-clauses, but
probably not a replacement for C++-style RAII.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Return value of an assignment statement?
Arnaud Delobelle wrote:
On Feb 23, 3:44 pm, Jeff Schwab [EMAIL PROTECTED] wrote:
actions = (
('some_string', do_something),
('other_string', do_other_thing))
def find_action(pattern):
for string, action in actions:
m = pattern.match(string)
if m:
return action
return do_default_thing
find_action(re.compile('some pattern'))()
You don't need to pass the pattern, just pass the match function:
def find_action(match, actions=actions, default_action=None):
for string, action in actions:
if match(string):
return action
return default_action
find_action(re.compile('some pattern').match)()
That's cool. :)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Carl Banks wrote: On Feb 23, 6:40 am, Jeff Schwab [EMAIL PROTECTED] wrote: Recently, I've had a few replies in tones that imply I'm on the brink of entering several kill-files, mostly because I express disagreement with a few closely held beliefs of some other c.l.p posters. A bit of advice: Python and C++ have almost no common ground in terms of what the priorties of the language are. Producing software of measurable quality. Increasing developer productivity. Providing in-language support for formal design and development processes. I think the languages approach the same high-level goals, just from very different angles. So, if you're a big proponent of the language features of C++, you really ought to expect lots of disagreement over just about anything you opine. P.S. I've had much sharper disagreements with some Pythonistas over aspects of Python. None of them are in my killfile. Good to know. :) One of the things that's supposed to be great about Python is the user community, and in many ways, that community is wonderful; for example, both new and experienced users can quickly get a variety of solutions to any given coding issue, just by asking for help. They say that about every small language community. I'm not sure Python qualifies as a small community anymore. Language-based communities that continue to support free thought and open conversation over time are much more rare. The worst case scenario is (apologies in advance) the Lisp-style consensus: This language is just the best tool for every job, period. In other ways, though, the Python community is just blindingly ignorant, arrogant, and argumentative. You're not exactly riding the humble bus there yourself, chief. Saying things like (in so many words), I'm just here because C++ doesn't have good runtime libraries, doesn't come off too well. That's not how I feel, and I never meant to imply anything like it. Things I like about Python: - No separate compilation step during development - Emphasis on design-for-test - Extensibility from other languages - Clean syntax - Portability - Mainstream use and support - Excellent documentation - Large standard library - Progress by design, rather than ad hoc improvements - Design decisions value useful over neat-o - Support for data-as-code (or code-as-data) and I am starting to become really concerned about the clarity of mind of the Python community, because I hope to rely on it. I think your expectations for the Python community are unreasonable. Maybe. My advice to you, if you want a good relationship with the Python community, would be to keep the comparisons with C++ out of it as much as possible. Understand that a lot--a lot--of people are going to say bad things about C++ and various features that C++ implements. If you try to defend C++ every time that happens, you won't last long here. Thanks. I do value my sanity, and would like to preserve what's left of it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Matthew Woodcraft wrote: Jeff Schwab [EMAIL PROTECTED] wrote: The most traditional, easiest way to open a file in C++ is to use an fstream object, so the file is guaranteed to be closed when the fstream goes out of scope. Out of interest, what is the usual way to manage errors that the operating system reports when it closes the file? By default, the fstream object just sets its failbit, which you can check manually by calling my_stream.fail(). If you want anything particular to take place on failure to close a stream, you either have to call close manually, or you need a dedicated object whose destructor will deal with it. Alternatively, you can tell the fstream ahead of time that you want exceptions thrown if particular actions fail. There's a convention that destructors don't ever throw exceptions, though, so it would be unusual to request an exception when close() fails. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Terry Reedy wrote: Jeff Schwab [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [snip discussion of 'with' statements] | Yes, this seems to be the Python way: For each popular feature of some | other language, create a less flexible Python feature that achieves the | same effect in the most common cases (e.g. lambda to imitate function | literals, or recursive assignment to allow x = y = z). This is a rather acute observation. Another example is generators versus full coroutines (or continuations). Guido is content to capture 80% of the practical use cases of a feature. He never intended Python to be a 100% replace-everything language. I think the idea is to balance power on one hand, against complexity and potential confusion on the other. One great thing about C is that a programmer can realistically hope to know the entire language definition; maybe Guido would like the same to be true of Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Paul Rubin wrote:
Terry Reedy [EMAIL PROTECTED] writes:
| Yes, this seems to be the Python way: For each popular feature of some
| other language, create a less flexible Python feature that achieves the
| same effect in the most common cases (e.g. lambda to imitate function
| literals, or recursive assignment to allow x = y = z).
This is a rather acute observation. Another example is generators versus
full coroutines (or continuations). Guido is content to capture 80% of the
practical use cases of a feature. He never intended Python to be a 100%
replace-everything language.
I don't understand the lambda example due to not being sure what Jeff
means by function literals. But in other languages, lambda is the
basic primitive, and def or equivalent is syntax sugar.
Sorry, I didn't know what else to call them except lambdas. I meant
the bare code blocks you can use in Perl, or what Java tries to achieve
via anonymous inner classes. So to use the Perl example: If you want
to sort a list using some arbitrary snippet of code as the comparison
function, you can write:
sort { code to compare $a and $b } @elements
This isn't really native in C++ either:
http://www.boost.org/doc/html/lambda.html
What language do you have in mind, in which lambda is more basic than
named definitions? Are you coming from a functional language background?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Matthew Woodcraft wrote:
Jeff Schwab [EMAIL PROTECTED] wrote:
Matthew Woodcraft wrote:
Jeff Schwab [EMAIL PROTECTED] wrote:
The most traditional, easiest way to open a file in C++ is to use an
fstream object, so the file is guaranteed to be closed when the fstream
goes out of scope.
Out of interest, what is the usual way to manage errors that the
operating system reports when it closes the file?
By default, the fstream object just sets its failbit, which you can
check manually by calling my_stream.fail(). If you want anything
particular to take place on failure to close a stream, you either have
to call close manually, or you need a dedicated object whose destructor
will deal with it.
Alternatively, you can tell the fstream ahead of time that you want
exceptions thrown if particular actions fail. There's a convention that
destructors don't ever throw exceptions, though, so it would be unusual
to request an exception when close() fails.
I see. Then, unless you don't care about data loss passing silently,
this 'most traditional' way to open a file is unsuitable for files
opened for writing.
No, why would you think so? If you want something special to happen
when the close() fails (as you indeed would if you were writing
important data), you have to say somehow that you want your special code
called. What syntax would you like to see? Here's what the C++ would
look like, supposing you have a type LoggingCloser that calls close and
logs any failure:
void f(std::string file_name) {
std::ofstream out(file_name.c_str()); // [1]
LoggingCloser closer(out);
// ... your work code here ...
}
The closer's destructor is guaranteed to be called before the file
stream's. That gives it a chance to call close manually, and keeps the
error-handling code separate from the rest of the program logic.
Compare the following Python equivalent, assuming we've replaced Logging
Closer's constructor and destructor with __enter__ and __exit__ definitions:
def f(file_name):
with file(file_name, 'w') as out:
with LoggingCloser(out) as closer:
// ... your work code here ...
In this case, the Python with-statement is not too bad, because you only
have two constructor/destructor pairs. For each new pair, though, it
seems like you need an extra level of nesting (and therefore
indentation). Of course, it may just be that I don't yet know how to
use the with-statement effectively.
[1] That c_str() kludge is usually the primary complaint about using
ofstream. It has been fixed in the new draft standard, which will
become official in 2009.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Paul Rubin wrote:
Jeff Schwab [EMAIL PROTECTED] writes:
So to use the Perl example: If you want to sort a list using some
arbitrary snippet of code as the comparison function, you can write:
sort { code to compare $a and $b } @elements
Yes, you can do that in Python, using a lambda expression, a named
function, or whatever.
You can indeed. I think you can also use this to do the other stuff you
would expect, e.g. return locally defined code snippets to define closures:
def mkadder(n):
return lambda x: x + n
I have gotten the impression that this was somehow inferior in Python
though, at least in terms of performance. Every time somebody uses
lambda here, they seem to get a bunch why are you using lambda?
responses. If I am grossly mistake, please just enlighten me.
What language do you have in mind, in which lambda is more basic than
named definitions? Are you coming from a functional language
background?
All languages that I know of with lambda, treat it as more basic than
named definitions, e.g. the Lisp family (not sure if those count as
functional languages) in addition to functional languages like Haskell.
I note from your other posts that you seem to have a strong Lisp bent.
Lisp programmer and Smalltalk programmers stand out in the crowd. I
first noted this when somebody found a while-loop offensive, on the
grounds that recursion was somehow a more natural way to implement
looping. It can take a while to convince somebody like that they
different idioms work best in different languages.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Paul Rubin wrote: Jeff Schwab [EMAIL PROTECTED] writes: One great thing about C is that a programmer can realistically hope to know the entire language definition; maybe Guido would like the same to be true of Python. C is horrendously complicated, with zillions of obscure traps. C++ is even worse; Who feeds you this stuff? there's actually a published book specifically about C++ pitfalls. Mercy, a whole book? My current favorite book of language-specific pitfalls: http://www.javapuzzlers.com/ Wait a few years. A Python Puzzlers book will surely be on the shelves eventually. Here are some of the top results when Googling python pitfalls: http://zephyrfalcon.org/labs/python_pitfalls.html http://evanjones.ca/python-pitfall-scope.html Maybe C++ needs better pub. The guy who wrote the first of those articles says elswhere on his web site: My Python pitfalls article seems to be a popular read. It's written from a somewhat negative viewpoint: things that can go wrong. (Of course, that's useful; you're never going to do these things wrong again. Right? ;-) To counter-balance this, I think there should an article with a more positive viewpoint as well. So I was wondering, if I could collect 10 anti-pitfalls; parts of the Python language that are especially clever, elegant and intuitive. Good luck with that. Once language Y comes along, there will be a million reasons people believe that language X was downright unusable. Python is underspecified but freer of weird hazards in practice. C and C++ should practically be outlawed at this point. On what grounds? I don't approve of the programming language you're using. Cease and desist. Nyah! -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Paul Rubin wrote: Jeff Schwab [EMAIL PROTECTED] writes: there's actually a published book specifically about C++ pitfalls. Mercy, a whole book? http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?EAN=9780201179286 C and C++ should practically be outlawed at this point. On what grounds? I don't approve of the programming language you're using. Cease and desist. Nyah! Well, outlawed of course is a figure of speech; however use of those languages should be a red flag in a design review, and a factor in determining product liability if a program misbehaves. Your product gets the benefit of the doubt if it was written in Python, but not if written in C? What if the Python interpreter screws up? Think of all the buffer overflow exploits against Microsoft Windows programs that couldn't have happened if Microsoft had used safer languages. There was clearly a failure to use best engineering practices. In the first place, you're not distinguishing C from C++. I know you think they're the same. They're not. Python's array bounds checking is done in C, as is the case for traditional OS kernels. C++, like Python, offers you container types that smell like arrays, but do safety checking under the hood; the C++ bounds checks, unlike the Python checks, are done in-language. If C++ were marketed like Java, people might advertise that the C++ standard containers are pure C++, or that C++ is written in C++. Secondly, you're going to have a hard time writing an operating system kernel without fixed-size buffers. You have to read data in chunks of some size. It's fine to say that buffer access should be checked to make sure indexes should be in range, but somebody actually has to write the code to do the checking, and then programmers have to use it. Buffer overflows are the result of developers deliberately choosing not to use bounds-checking. In Python, somebody could still define a monolithic array, use different parts of it to represent different things, and then oops lose track of their index, thereby overwriting one part of the array with data that should have stayed in the other part. If you're thinking Yeah, they *could*, but only a dodo would do that, and it's not Python's fault that the programmer did something bone-headed, then you're beginning to get the picture. If you somehow wrote an OS kernel in Python, and the above-mentioned bone-headedness took place, then there would be no lower level to save your OS from having a dangerous security hole. Even if the hardware supported checked access for large quantities of arbitrarily sized arrays, somebody would have to enable that access. Even then you're trusting the hardware developers to check for invalid indexes (bus errors and seg faults). Should we outlaw computer hardware, too? Thirdly, you mentioned a failure to use best engineering practices. If you mean there was a failure to design and implement a bug-free operating system, then by Jiminy, you're right. Best practices, though, is usually just what managers say when they mean what everybody else is doing. The idea is that if you're a manager who sticks to best practices, then if everything goes to hell, the problem can't be linked specifically to you. Server-side Python is now, at this very moment, becoming acceptable as best practice. It's no better or worse for this; it's just that a lot more uninspired, uncreative programmers are about to start using it. Do not underestimate their ability to make any programming language look bad. If you make it fool-proof, they'll build a better fool. The only way to keep them from writing code that will blow up at run-time is to impose formal verification of their program, every time they change it; that's what the C++ static type system lets you do, in a limited and easily subverted way. Even if you could somehow remove every feature open to potential abuse, and thereby dodo-proof the language, the result would be a slow, weak, ugly language that non-dodos would not want to use. But hey, at least it would still be best practice. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Carl Banks wrote: On Feb 22, 12:23 am, Jeff Schwab [EMAIL PROTECTED] wrote: Carl Banks wrote: On Feb 21, 7:17 pm, Jeff Schwab [EMAIL PROTECTED] wrote: Carl Banks wrote: On Feb 21, 1:22 pm, Nicola Musatti [EMAIL PROTECTED] wrote: There are other downsides to garbage collection, as the fact that it makes it harder to implement the Resource Acquisition Is Initialization idiom, due to the lack of deterministic destruction. That's not a downside: it's at least a wash. In C++ you manage memory and the language manages resourcewithout bringing anything of particular value to the table.s. In Python you manage resources and the language manages memory. RAII is merely one way of minimizing complexity. Garbage collection is another way. If you've already got a generic, language-supported way to manage resources (like RAII with deterministic destruction), then why bother with garbage collection? Because now you have to manage memory? Did you read my post? You have to manage one thing or the other. Yes, I read your post. You seem to be saying there's some kind of trade-off between automatic management of dynamically allocated memory, and automated management of other kinds of resources. I don't understand why you believe that, so I asked. If you have proper RAII and deterministic destruction, the management is of resources is consistent, and mostly automated. If you have garbage collection, the management of memory is consistent, and mostly automated. Managing memory is just not that difficult, Managing resources is just not that difficult, especially if the vast majority of objects are allocated on the stack or in static memory. Especially if the there are fewer resources to manage than there would have been heap objects A special language feature for managing dynamically allocated memory robs the programmer of a reliable way to clean up resources automatically, A special language feature more managing dynamically allocated robs the programmer of a reliable way to free memory automatically, without bringing anything of particular value to the table. without bringing anything of particular value to the table. It cuts both ways, chief. You like managing your own memory, be my guest. But please don't imply that you're putting forth less effort because of it. You're just putting forth different effort. I disagree with you completely. Your points don't make any sense to me at all. I believe I am putting forth less effort by having a generic resource-management infrastructure, rather than a memory-specific language feature -- that's not just an implication, it's my honest belief. But I guess we'll agree to disagree. -- http://mail.python.org/mailman/listinfo/python-list
Re: Return value of an assignment statement?
George Sakkis wrote: On Feb 22, 12:26 am, Jeff Schwab [EMAIL PROTECTED] wrote: On the other hand, a = b does always the same thing; unlike C++, '=' is not an operator and therefore it cannot be overriden by the class of 'a'. Not an operator? Then what is it? In this context, it's just the token used for the assignment statement. In short, if 'a' is an identifier, the statement means bind the name 'a' to the object 'b' (in the local or global namespace). It doesn't say anything about memory allocation, initialization or copying. The only case where assigning an identifier affects memory is the following [1]: The name is rebound if it was already bound. This may cause the reference count for the object previously bound to the name to reach zero, causing the object to be deallocated and its destructor (if it has one) to be called. [1] http://docs.python.org/ref/assignment.html OK, thanks for trying to make it clear. I'm about through with this discussion, but FWIW, this is a real gotcha for me and many others. This is a case where Python does not do what many programmers expect, and it at least takes some getting used-to. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Nicola Musatti wrote: The real sad thing is that nobody is likely to convince Guido to turn CPython into C++Python ;-) How difficult would that be? Could it be done in stages? I would be willing to spend some time on that kind of project. Since I know almost nothing about Python internals, though, I'd appreciate it if a C++-fluent Python expert could give an estimate in person-months. Also, what would be the general break-down? Maybe: (1) Prepare a build environment appropriate for Python, supporting code in both C and C++. Include unit-test targets, and a mechanism for module developers to add unit tests to those targets. (2) Get all the headers C++-clean. (3) Begin translating one module at a time. Different people could work on different modules, and add their test-cases to the global target. One potential problem would be linkage. Would Python-internal C++ modules still have to provide C-linkable APIs, so that they could be invoked from other parts of Python? A breakdown of module dependencies would help address this issue, so that it would be clear which parts of the code-base would be directly affected by translating a given module to C++. At the external API level, would it still be important to support C-style linkage, even if the implementation code isn't written in C? I don't know whether it's realistic for people embedding Python in non-C++ applications to have to work directly with C++ APIs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent of system()?
Max wrote: Is there a Python equivalent of C++'s system()? More or less. You probably want subprocess.Popen: import subprocess subprocess.Popen(echo hello, shell=True) hello subprocess.Popen object at 0x2ab8f3665d10 http://docs.python.org/lib/node533.html#CHILD_LINKS -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Bruno Desthuilliers wrote: Carl Banks a écrit : On Feb 20, 8:58 am, Tim Chase [EMAIL PROTECTED] wrote: You Used Python to Write WHAT? http://www.cio.com/article/185350 Furthermore, the power and expressivity that Python offers means that it may require more skilled developers. [...down to the summary...] Python may not be an appropriate choice if you: [...] * Rely on teams of less-experienced programmers. These developers may benefit from the wider availability of training for languages like Java and are less likely to make mistakes with a compile-time, type-checked language. (snip) C++ is a compile-time, type-checked language, which means it is totally safer for newbies than Python. Yep, your big company is totally safe with newbie C++ programmers. Mouarf ! Brillant demonstration, thanks Carl !-) (and BTW, +1 QOTW) NB: This is not a troll. (Please, nobody try to be cute with a yes it is reply.) c.l.python seem to be about the most close-minded of any of the currently popular language-specific news groups. It's just taken for granted that Perl and C++, two of my personal favorite things in this world, inherently favor ugly, buggy code. That is the farthest thing from the truth as I see it. You can (and plenty of people will) write terrible code in any language, including Python. To use Python effectively, you have to know something about how it works, and the same is true of Perl and C++. But a newbie who's learning from a decent source (avoid the C++ for Morons style books) is likely (I contend) to be writing semi-useful programs about as fast as with Python, and to be writing heavy-duty work-horse programs far sooner. Perl is, and always has been, a language for getting your job done; when everything else failed, Perl and C++ got me through some of the toughest tasks of my life. Translating file formats, automating system-level tasks... And now that the C++ standard library is getting regular expressions, I can replace plenty of glued-together scripts with single-language, cohesive applications. I like Python, and I think it's got a brilliant future ahead of it. It is rapidly becoming the dynamic language of choice, especially for C++ projects. I am glad that Python can be extended straightforwardly in any C-linkable language. But this bashing of other powerful languages on the basis that they're hard to read and hard to use correctly is, frankly, nonsense. -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie in python
[EMAIL PROTECTED] wrote: I'm very interesed to learn python and really willing to do so,but unfortunately dont know where to start, or what programs need to install to start. There are several good replies already on this thread, but in case any experienced programmers searching the Google archives are looking for the fastest way to learn Python, I highly recommend Python in a Nutshell by Alex Martelli (O'Reilly). Good tutorial, high information density, avoids hand-waving, solid reference. Do *not* bother with Programming Python until you have some experience with the core language. I don't know why O'Reilly called it that, except to mislead people into thinking it was similar to the highly successful Programming Perl; if so, I fell for it, and so did plenty of other people (so there's probably a copy in your coworker's office already). Programming Python is (despite its size) the moral equivalent of the O'Reilly Cookbooks for other languages. It's not necessarily a bad book, but the only language/library tutorial it gives is meant to be a review, not an introduction. -- http://mail.python.org/mailman/listinfo/python-list
Re: Return value of an assignment statement?
mrstephengross wrote:
Hi all. In C, an assignment statement returns the value assigned. For
instance:
int x
int y = (x = 3)
In the above example, (x=3) returns 3, which is assigned to y.
In python, as far as I can tell, assignment statements don't return
anything:
y = (x = 3)
The above example generates a SyntaxError.
Is this correct? I just want to make sure I've understood the
semantics.
Yes, but there is valid syntax for the common case you mentioned:
y = x = 3
What you can't do (that I really miss) is have a tree of assign-and-test
expressions:
import re
pat = re.compile('some pattern')
if m = pat.match(some_string):
do_something(m)
else if m = pat.match(other_string):
do_other_thing(m)
else:
do_default_thing()
--
http://mail.python.org/mailman/listinfo/python-list
Re: Return value of an assignment statement?
John Henry wrote: On Feb 21, 1:48 pm, John Henry [EMAIL PROTECTED] wrote: On Feb 21, 1:43 pm, mrstephengross [EMAIL PROTECTED] wrote: Hi all. In C, an assignment statement returns the value assigned. For instance: int x int y = (x = 3) In the above example, (x=3) returns 3, which is assigned to y. In python, as far as I can tell, assignment statements don't return anything: y = (x = 3) The above example generates a SyntaxError. Is this correct? I just want to make sure I've understood the semantics. Thanks, --Steve That's true, and I am happy that they decided to make that a syntax error. BTW: The less obvious issues when coming from the C world are Python syntax like these: y = x = 3 a = 4 y = x = a print x,y a = 5 print x,y That's the same behavior I would expect in C, on the grounds that C assignments do bit-wise copies. What I found confusing at first was that the same variable will either directly store or merely refer to an object, depending on the type of the object: a = [ 'hello' ] y = x = a a += [ 'world' ] print x, y ['hello', 'world'] ['hello', 'world'] -- http://mail.python.org/mailman/listinfo/python-list
Re: Return value of an assignment statement?
mrstephengross wrote:
What you can't do (that I really miss) is have a tree of assign-and-test
expressions:
import re
pat = re.compile('some pattern')
if m = pat.match(some_string):
do_something(m)
Yep, this is exactly what I am (was) trying to do. Oh well Any
clever ideas on this front?
I worked around it by defining a separate thigamabob with a result
property. A method of the thigamabob internally performs the
assignment, and returns a boolean result. The body of each branch in
the tree can then retrieve the result object from the thigamabob.
Here's an example hard-coded to match strings against patterns, but I
think the idea should be extensible to other kinds of assign-and-test
situations.
# Just for the sake of this post.
def do_something(m): pass
def do_other_thing(m): pass
def do_default_thing(): pass
import re
class Matcher(object):
def __call__(self, pattern, string):
self.result = pattern.match(string)
if __name__ == '__main__':
pat = re.compile('some pattern')
match = Matcher()
if match(pat, 'a'):
do_something(match.result)
elif match(pat, 'b'):
do_other_thing(match.result)
else:
do_default_thing()
--
http://mail.python.org/mailman/listinfo/python-list
Re: Return value of an assignment statement?
[EMAIL PROTECTED] wrote: On 21 fév, 23:19, John Henry [EMAIL PROTECTED] wrote: On Feb 21, 2:06 pm, Jeff Schwab [EMAIL PROTECTED] wrote: John Henry wrote: On Feb 21, 1:48 pm, John Henry [EMAIL PROTECTED] wrote: On Feb 21, 1:43 pm, mrstephengross [EMAIL PROTECTED] wrote: Hi all. In C, an assignment statement returns the value assigned. For instance: int x int y = (x = 3) In the above example, (x=3) returns 3, which is assigned to y. In python, as far as I can tell, assignment statements don't return anything: y = (x = 3) The above example generates a SyntaxError. Is this correct? I just want to make sure I've understood the semantics. Thanks, --Steve That's true, and I am happy that they decided to make that a syntax error. BTW: The less obvious issues when coming from the C world are Python syntax like these: y = x = 3 a = 4 y = x = a print x,y a = 5 print x,y That's the same behavior I would expect in C, on the grounds that C assignments do bit-wise copies. What I found confusing at first was that the same variable will either directly store or merely refer to an object, depending on the type of the object: a = [ 'hello' ] y = x = a a += [ 'world' ] print x, y ['hello', 'world'] ['hello', 'world'] Yep. Took me a while to realize there is mutable objects, and non- mutable objects. To be honest, I am still not too comfortable about it. For instance, I still get nervous for code like: def invoke_some_fct(parent): y = parent.x y += [ 'world' ] print y, parent.x class abc: def __init__(self): self.x=[ 'hello' ] invoke_some_fct(self) print self.x Explicitely using list.extend would make things clearer: def invoke_some_fct(parent): parent.x.extend(['world']) Whether you use += or extend has nothing to do with it. You omitted the relevant part. Using extend, it would look like: y = parent.x y.extend(['world']) The confusing part is that performing an operation on y may or may not alter parent.x, depending on whether the initial type of parent.x is immutable. If parent.x is immutable, y is a copy of the value represented by parent.x, and modifying y has not effect on the value of parent.x. If (OTOH) parent.x is mutable, then x and y are really references to the same object, and modifications to that object via y can be observed via x. In C, you use pointers to get this effect. Now there's no reason to feel nervous about this. All you have to remember is that Python never copy anything unless explicitely asked for. It's not that simple. After a statement like: a = b Whether a and b denote the same object depends on what kind of object b represented in the first place. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Carl Banks wrote: On Feb 21, 1:22 pm, Nicola Musatti [EMAIL PROTECTED] wrote: There are other downsides to garbage collection, as the fact that it makes it harder to implement the Resource Acquisition Is Initialization idiom, due to the lack of deterministic destruction. That's not a downside: it's at least a wash. In C++ you manage memory and the language manages resources. In Python you manage resources and the language manages memory. RAII is merely one way of minimizing complexity. Garbage collection is another way. If you've already got a generic, language-supported way to manage resources (like RAII with deterministic destruction), then why bother with garbage collection? I'm not trying to knock it; it was a big step up from C-style who forgot to delete a pointer games. It just seems to me like a solution to something that's no longer a problem, at least in well-written C++ code. I'll take destructors over GC any day. -- http://mail.python.org/mailman/listinfo/python-list
Re: Return value of an assignment statement?
Terry Reedy wrote: Jeff Schwab [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | That's the same behavior I would expect in C, on the grounds that C | What I found confusing at first was | that the same variable will either directly store or merely refer to an | object, depending on the type of the object: Since names and collection slots always refer to objects, I find the above confusing. Can you clarify what difference you percieve? a += b Whether a refers to the same object before and after that statement depends on what type of object it referred to before the statement. -- http://mail.python.org/mailman/listinfo/python-list
Re: Return value of an assignment statement?
[EMAIL PROTECTED] wrote: On 21 fév, 23:06, Jeff Schwab [EMAIL PROTECTED] wrote: John Henry wrote: On Feb 21, 1:48 pm, John Henry [EMAIL PROTECTED] wrote: On Feb 21, 1:43 pm, mrstephengross [EMAIL PROTECTED] wrote: Hi all. In C, an assignment statement returns the value assigned. For instance: int x int y = (x = 3) In the above example, (x=3) returns 3, which is assigned to y. In python, as far as I can tell, assignment statements don't return anything: y = (x = 3) The above example generates a SyntaxError. Is this correct? I just want to make sure I've understood the semantics. Thanks, --Steve That's true, and I am happy that they decided to make that a syntax error. BTW: The less obvious issues when coming from the C world are Python syntax like these: y = x = 3 a = 4 y = x = a print x,y a = 5 print x,y That's the same behavior I would expect in C, on the grounds that C assignments do bit-wise copies. What I found confusing at first was that the same variable will either directly store or merely refer to an object, depending on the type of the object: a = [ 'hello' ] y = x = a a += [ 'world' ] print x, y ['hello', 'world'] ['hello', 'world'] There's nothing like a variable storing anything in Python. All you have are names to (references to) objects binding in a namespace. Now the fact is that some types are mutable and other are not. In your above example, the augmented assignment does *not* rebind a, but invoke a.extend(). With integers, it would have rebind a. So while your observation is exact, your interpretation is wrong !-) Thank you for the clarification. For some reason, I had it in my head that ints were packed directly into the C structures that represent Python variables, in the same (union?) member that otherwise would store a pointer. -- http://mail.python.org/mailman/listinfo/python-list
Re: Return value of an assignment statement?
Steve Holden wrote: Jeff Schwab wrote: [EMAIL PROTECTED] wrote: [...] Now there's no reason to feel nervous about this. All you have to remember is that Python never copy anything unless explicitely asked for. It's not that simple. After a statement like: a = b Whether a and b denote the same object depends on what kind of object b represented in the first place. Surely this is exactly wrong. Is there a single example you can think of where a = b a += b (my bad) assert a is b, Oops! would raise and exception? Perhaps you meant to use an augmented assignment operation? Why, yes I did! Sorry about that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Return value of an assignment statement?
Steve Holden wrote:
mrstephengross wrote:
What you can't do (that I really miss) is have a tree of assign-and-test
expressions:
import re
pat = re.compile('some pattern')
if m = pat.match(some_string):
do_something(m)
Yep, this is exactly what I am (was) trying to do. Oh well Any
clever ideas on this front?
The syntax is the way it is precisely to discourage that kind of clever
idea. Of course, people nevertheless manage to work around the
restriction to try and make their Python read like some other language
they are more familiar with, and most of the time they get away with it.
The fat remains that in programming there *is* such a thing as being too
clever, and Python's syntax deliberately discourages that.
This isn't clever. It's what most of us were taught, from the
beginning, was best practice. In some languages (including C and C++)
the above is extremely common and perfectly acceptable.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
Carl Banks wrote:
On Feb 21, 7:17 pm, Jeff Schwab [EMAIL PROTECTED] wrote:
Carl Banks wrote:
On Feb 21, 1:22 pm, Nicola Musatti [EMAIL PROTECTED] wrote:
There are other downsides to garbage collection, as the fact that it
makes it harder to implement the Resource Acquisition Is
Initialization idiom, due to the lack of deterministic destruction.
That's not a downside: it's at least a wash.
In C++ you manage memory and the language manages resources. In
Python you manage resources and the language manages memory.
RAII is merely one way of minimizing complexity. Garbage collection
is another way.
If you've already got a generic, language-supported way to manage
resources (like RAII with deterministic destruction), then why bother
with garbage collection?
Because now you have to manage memory? Did you read my post? You
have to manage one thing or the other.
Yes, I read your post. You seem to be saying there's some kind of
trade-off between automatic management of dynamically allocated memory,
and automated management of other kinds of resources. I don't
understand why you believe that, so I asked.
If you have proper RAII and deterministic destruction, the management is
of resources is consistent, and mostly automated. Managing memory is
just not that difficult, especially if the vast majority of objects are
allocated on the stack or in static memory. A special language feature
for managing dynamically allocated memory robs the programmer of a
reliable way to clean up resources automatically, without bringing
anything of particular value to the table.
I'm not trying to knock it; it was a big step
up from C-style who forgot to delete a pointer games. It just seems
to me like a solution to something that's no longer a problem, at least
in well-written C++ code. I'll take destructors over GC any day.
About 2% of the objects I creat have resources other than memory. I
would rather manage resources of 2% of objects than manage memory of
100%.
That's not how it works. If I'm going to allocated a C++ object
dynamically, I have to assign it to some kind of handle, anyway, so I
might as well just use a smart pointer that will delete the object when
there are no more references to it. There is no extra effort involved.
The most traditional, easiest way to open a file in C++ is to use an
fstream object, so the file is guaranteed to be closed when the fstream
goes out of scope. CPython offers a similar feature, since you can
create a temporary object whose reference count will become zero at the
end of the statement where it is defined:
$ echo world hello
$ python
file('hello').read()
'world\n'
It's graceful, easy to write, and a million times better than having to
clean up the resource explicitly. A book on Python I was reading
recently (either Alex Martelli or Mark Lutz) used this idiom again and
again, and every time had to have a footnote about how it wouldn't work
right on (e.g.) JPython, because who knows if/when the resource-owning
object's finalizer will ever get called.
Admittedly, you have to know enough to use the right kinds of objects,
but that's something you have to learn anyway.
YMMV, but I suspect mine is the more common opinion, if the
recent (like, 10-year) trend in programming languages is any
indication.
I agree that support for non-deterministic GC has grown very popular
over the past ten years or so. I don't think that is evidence of it
being a good idea though; I suspect that opinion of being the product of
widespread ignorance about alternatives to unpredictable GC.
--
http://mail.python.org/mailman/listinfo/python-list
