Re: Python evolution: Unease
[EMAIL PROTECTED] writes: Dunno about Fedora, I stopped using Red Hat just because they were *not* using the standard Python distribution, and the version they shipped was cripped in various ways. Eh? I used Red Hat for a long while and don't remember their crippling the Python distribution. I do remember their believing the Python advocates that Python was a stable language, and therefore building critical features around it, and being unwilling to upgrade between major Python releases during minor Red Hat release cycles. The result was that RH 7.x shipped with Python 1.5.x for quite a long time after Python 2.x had been released. However I don't remember anything being crippled about the 1.5.x installations. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
EP [EMAIL PROTECTED] writes: Python: it tastes so good it makes you hungrier. QOTW -- http://mail.python.org/mailman/listinfo/python-list
Re: Concepts RE: Python evolution: Unease
Roman Suzi [EMAIL PROTECTED] writes: As for concepts, they are from Generic Programming (by Musser and Stepanov) and I feel that Python is in position to implement them to the fullest extent. And IMHO it will be nicer than just Java-like interfaces or Eiffel's contract approach. I keep hearing that term (GP). Can someone explain in a few sentences what it means, without resorting to marketing buzzwords? There is nothing in Wikipedia about it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Concepts RE: Python evolution: Unease
Paul Rubin http://[EMAIL PROTECTED] writes: There is nothing in Wikipedia about [Generic programming]. Oops: http://en.wikipedia.org/wiki/Generic_programming This helps. But I don't see how it's different from what used to be called polymorphism. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
Ville Vainio [EMAIL PROTECTED] writes: Paul I can't parse that. It says two contradictory things. Paul Sentence 2 says that if something essential is not in the Paul (Python) distro then the (Python) distro maintainers have Paul screwed up. Sentence 1 says it's the Fedora maintainer's Paul job to deal with it. Huh? By distro I meant the Linux distribution, not the Python distribution. Distro is a customary term for a Linux distribution so I didn't qualify the word at the time. Oh ok, but it's the Python distribution that's missing components that are essential to Python. Fedora and other Linux distros are collections of subsystems like Python. Linux distro maintainers get asked to include a subsystem, they check that the subsystem has a reasonable reputation (Python does), they install it in the distro and run some basic tests, and they ship it. They can't be expected to immerse themselves in its intricacies and hang out on the user forums to identify all the missing components that they should also hunt down and ship. So the Python needs to take care of that stuff. I realize that in the old days, people used to write big applications without makefiles, and later when they started using makefiles, they didn't use configure scripts. So to install a package, you had to do a bunch of hand configuration for your particular environment before you could compile it, and maybe you even had to say cc -O -Dthisflag=thatnumber xyz.c pqr.c frob.c -o frob on the command line instead of typing make to build the program. That kind of thing really doesn't fly any more. The standards for what constitutes a properly engineered release of something have gotten higher. You really need automatic configuration and build and installation. Likewise, if you're trying to market something as a complete drop-in system (batteries included, to use the Python terminology), it should not be missing any essential pieces that the user has to hunt down separately. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python more popular than coldfusion?
[EMAIL PROTECTED] writes: But Python IS tied for first. This may indicate that the relatively small number of jobs listing Python as a requirement is due in part to a relatively small supply of Python programmers, not lack of demand for such programmers. I think it mostly means Python programmers tend to be further up the overall experience and proficiency scale than, say, .NET programmers. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
Skip Montanaro [EMAIL PROTECTED] writes: Okay, then start doing the work necessary to incorporate that stuff into the core. Get Fredrik to say okay to including his Tkinter docs, then do what it takes to incorporate it. The fact that Fredrik can check those docs in himself but hasn't after several years suggests that he prefers the status quo for one or more reasons. I thought that we had been through this already, and permission from Frederik was not forthcoming. Either he has his own plans for those docs, or he has some obligation to someone else to not release them. The Tkinter reference at http://infohost.nmt.edu/tcc/help/pubs/lang.html is actually the best doc I've seen on tkinter so far, but it's only available in ps/pdf format and again, would need permission for inclusion in Python. There is a reference manual section for SocketServer, btw: http://www.python.org/doc/current/lib/module-SocketServer.html If that needs examples or corrections or is incomplete, feel free to submit a patch to either SourceForge or by email to [EMAIL PROTECTED] It's been a while since I really had to wrestle with SocketServer, but that its docs were quite inadequate and I had to study the source code for quite a while to grok how to use it. Look, I don't have much free time, and what free time I do have I mostly spend moonlighting on other software (much to my wife's chagrin). I imagine most of the other people who contribute to the Python distribution are similarly time-afflicted. Here are a couple ideas: Thanks, but I'm not in the business of promoting Python. I like to think I contribute in some minor ways by submitting bug reports and occasional small patches. I made a conscious decision to not spend time on big patches since Python is non-GPL, and I'd rather spend my limited volunteer time on GPL projects, working on non-GPL projects only if I'm getting paid for it. I offered to make an exception once to contribute some functionality that I felt was important for Python users, but it was declined. What I see going on in clpy all the time though, is people asking whether Python is good for some type of project, and always getting told yes no matter what the project is. If the yes means that in addition to doing your own project, you find out in the middle that you also have to add features to Python that other languages already support, that makes your project finish behind schedule and whoever told you Python was good for your project really did you a disservice. I'm reacting to that phenomenon in this thread, along with possible others. 1. Do you have more money than time? Donate a few bucks to the PSF: Nah, I'd rather donate to the FSF if I have the bucks to spare. If I want to fund the development of proprietary Microsoft products, I'm better off sending the money directly to Bill G. Of course I'm happy if PSF gets corporate donations, but that's different than someone like me operating as a free software activist. 2. Do you have more time than money? Write a proposal to the PSF to implement/improve/polish off some aspect of the distribution: Huh? Do you mean like a funding proposal, where PSF would use some of those donations to hire me to develop something? I guess I'd consider that in principle, but I'm probably not PSF's favorite person right now, and unlikely to get hired. And anyway, I have other commitments right now and couldn't take on anything like that. Where did I say to go write a browser or a native-code Python compiler? If that's your bag you can try resurrecting something Grail-like (browser) or contribute time top PyPy or Psyco. When I said write, I literally meant write, as in English text. I don't experience much difference between writing text and writing code. If I say the docs are missing something and you tell me to fix them, that's not much different than telling me to go write missing code. Re browsers and compilers: I think a Python browser depends on a good GUI toolkit and right now Python only has Tkinter. (There are toolkits like wxpython but Python doesn't have them; they exist separately). I think the PyPy group is doing real well with compilers, or at least knows what its doing. I want to wait til PyPy is actually deployed before I pay too much attention to Python compilation, since I think supporting good compilation should actually drive the Python 3000 language design, and PyPy will make it much easier to experiment with new or changing language features. Paul Having to piece together info from a dozen obscure and Paul inconsistent PEP's and stuff in the CVS tree and source comments Paul is not what most people think of as documentation. I was suggesting that maybe you might like to take the pieces and make them something coherent. If it was trivial it would have probably been done by now. I just avoid using those features. If they're not documented they probably
Re: Securing a future for anonymous functions in Python
Nick Coghlan [EMAIL PROTECTED] writes: Do you consider generator expressions or list comprehensions deficient because they don't allow several statements in the body of the for loop? I don't see what it would mean to do otherwise. -- http://mail.python.org/mailman/listinfo/python-list
Re: sorting on keys in a list of dicts
J Berends [EMAIL PROTECTED] writes: Suppose I have a list of dictionaries and each dict has a common keyname with a (sortable) value in it. How can I shuffle their position in the list in such way that they become sorted. Do I understand the question right? Can't you just say thelist.sort(lambda x,y: cmp(x['keyname'], y['keyname'])) or something like that? -- http://mail.python.org/mailman/listinfo/python-list
Re: Embedding a restricted python interpreter
Jp Calderone [EMAIL PROTECTED] writes: A Python sandbox would be useful, but the hosting provider's excuse for not allowing you to use mod_python is completely bogus. All the necessary security tools for that situation are provided by the platform in the form of process and user separation. But mod_python is an apache module and runs in the same apache process with other users' scripts. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Industry choice
[EMAIL PROTECTED] (Alex Martelli) writes: Yes, apart from libraries and similar cases (frameworks etc), it's no doubt rare for closed-source end-user packages to be sold with licenses that include source and allow you to do anything with it. However, allowing customization (at least for internal use within the customer organization), while rare, is far from unheard of. There's no obstacle to doing that with GPL'd software either. -- http://mail.python.org/mailman/listinfo/python-list
Re: Embedding a restricted python interpreter
Peter Maas [EMAIL PROTECTED] writes: I think PHP has a safe mode which solves the probem of isolating scripts of different users on application level. This is not optimal but better than nothing. Best solution would probably be to create a thread for each request that can operate only with the id of an authenticated user. But this seems to be a problem with Apache or with Linux? Threads wouldn't do it--you'd need separate processes. For example, multiple threads in the same process can access each other's file descriptors. -- http://mail.python.org/mailman/listinfo/python-list
Re: Embedding a restricted python interpreter
Gerhard Haering [EMAIL PROTECTED] writes: But mod_python is an apache module and runs in the same apache process with other users' scripts. Which is why it's a good idea for each customer to have it's own system user and their virtual hosts running under this uid. Which was the idea for the perchild MPM for Apache 2 - which is abandoned now :-( muxmpm is a replacement project in beta. I'm not familiar with perchild MPM or muxmpm, but it sounds like you'd need a separate process per user for it to work. That would seriously increase the cost of operating mass vhosts. It's not uncommon for one apache/mod_php server to support thousands of users. - go back to Apache 1.3.x, missing some nice improvements - use different webservers per user, put them together with mod_proxy (yuck!) If it's for low-traffic vhosts without enormous processing complexity, you could use Python cgi's instead of mod_python. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Industry choice
Jeff Shannon [EMAIL PROTECTED] writes: Note that the so-called 'viral' nature of GPL code only applies to *modifications you make* to the GPL software. Well, only under an unusually broad notion of modification. The GPL applies to any program incorporating GPL'd components, e.g. if I distribute a Python compiler that incorporates some component from GCC, then my entire Python compiler must be GPL'd even though the GCC component is isolated inside the Python compiler and I wrote the rest of the Python compiler myself. If I don't like this, I have an obvious recourse, which is don't use GCC components in my Python compiler. The notion here is that the GCC components are attractive enough that being able to use them provides an incentive to GPL my Python compiler, which I might not do otherwise. (Problems may come if someone licenses a library under the GPL; that's what the LGPL was invented for. But the issue here is not that the GPL is bad, it's that the author used the wrong form of it.) The problem is not a problem except that in the case of some libraries, simply being able to use a library module is often not enough incentive to GPL a large application if the library module's functionality is available some other way (including by reimplemntation). If the library does something really unique and difficult, there's more reason to GPL it instead of LGPL'ing it. The 'infective' nature of the GPL *only* comes when you make use of the *extra* privelidges that open source grants. So yes, those extra privelidges come with a price (which is that you share what you've done); but if you don't want to pay that price, you have the choice of not using those privelidges. This does not, in any way, prevent you from using GPL'ed software as a user. Well put. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Industry choice
Bulba! [EMAIL PROTECTED] writes: Making derived work proprietary in no way implies that the base work is publicly unavailable anymore. Since you want to be able to incorporate GPL code in your proprietary products, and say there's no problem since the base work is still available from the same places it was available from before, fairness would say you shouldn't mind that people incorporate code from your products into THEIR products, since your version is still available from you. Really, you're just a freeloader looking for handouts. -- http://mail.python.org/mailman/listinfo/python-list
Re: Securing a future for anonymous functions in Python
Jeff Shannon [EMAIL PROTECTED] writes: It seems to me that in other, less-dynamic languages, lambdas are significantly different from functions in that lambdas can be created at runtime. What languages are those, where you can create anonymous functions at runtime, but not named functions?! That notion is very surprising to me. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Industry choice
[EMAIL PROTECTED] (Aahz) writes: I don't like what I perceive as end effect of what GPL license writers are attempting to achieve: vendor lock-in. And my counter-argument is that I believe your perception is wrong. If I agreed with your focus on lock-in, I'd say that what the GPL is trying to lock in is a specific legal philosophy by subverting the existing system. Bulba's perception is wrong in a different way too. The GPL tries to encourage the enlargement of a public resource, namely a codebase shareable by a worldwide community of users and developers, a cyber equivalent of a public park whose facilities anyone can visit and use but nobody can take away and exclude others from using. The idea of referring to such a shared community resource as a vendor is just bizarre. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
Terry Reedy [EMAIL PROTECTED] writes: Would it be possible, at least for Windows, to write a Python script implementing a 'virtual distribution'? IE, download Python, install it, download next package, install it, etc. -- prefereably table driven? I just don't understand why you'd want to do that, instead of putting all the files in the distro in the first place. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
adamc [EMAIL PROTECTED] writes: I've not experienced problems installing wxPython on Debian (unstable). It just *works* out of the box with apt-get. Perhaps this is more of a problem with the package maintainers? I think the problem I encountered was that the version of WxWidgets currently on the WxWidgets.com site was trying to use some obsolete function in GTK. If Debian is using an older version of GTK than what comes with FC3, then it might work. -- http://mail.python.org/mailman/listinfo/python-list
Re: Excluded and other middles in licensing
Robert Kern [EMAIL PROTECTED] writes: http://en.wikipedia.org/wiki/Closed_source any program whose licensing terms do not qualify as open source. A definition with a nice big This article may need to be reworded to conform to a neutral point of view warning at the top. ;-) ... There seems to be such an edit on the way: http://en.wikipedia.org/wiki/Talk:Closed_source After they're done defining closed source, maybe they can work on compact source (a bounded closed-source program, i.e. one that, unlike Windows, doesn't try to take over every computer in the world). Note also from the Heine-Borel theorem that every closed source program can be covered by some finite collection of open source programs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Excluded and other middles in licensing
[EMAIL PROTECTED] (Alex Martelli) writes: Note also from the Heine-Borel theorem that every closed source program can be covered by some finite collection of open source programs. Every _compact_ one, surely? Quoting by heart from old memories, but, isn't Heine-Borel about (being able reduce any open covering of X to a finite subcovering) - (X is compact) ...? Yeah, whoops, that's what I meant; your old memories are clearer than mine. Actually sometimes the definitions and theorems interchange. I do remember something about Tikhonov's Theorem that says that no matter how often bounded closed source programs multiply, the product is still closed source. So, for example, Adobe Acrobat is still closed source even if you can download it from Adobe's web site infinitely often. But that theorem doesn't apply to noncompact (i.e. unbounded) closed source programs. So ordering Microsoft to release parts of Windows as open source was one of the potential remedies discussed in the penalty phase of the US Justice Dept's antitrust suit. Unfortunately, the DoJ lawyers were not good topologists so they didn't give enough consideration to this possibility. -- http://mail.python.org/mailman/listinfo/python-list
Re: Securing a future for anonymous functions in Python
Anna [EMAIL PROTECTED] writes: Having taken some calculus (derivatives, limits, some integrals) but never even heard of lambda calculus, to me, lambda means absolutely NOTHING. Less than nothing. Lambda calculus is from mathematical logic, but more to the point lambda has been the term used in Lisp for this operation since time immemorial. Since the kinds of programmers who want to use anonymous functions have probably been exposed to Lisp at one time or another, lambda should not cause any confusion. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
[EMAIL PROTECTED] (Alex Martelli) writes: Paul Rubin http://[EMAIL PROTECTED] wrote: Really, I just want to buy a new computer, turn it on, and have everything there. That's generally impossible without running satanware from Redmond The princes of insufficient light from Cupertino will in fact be very happy to sell you such computers, I actually do sometimes advise nontechnical people to buy those things and run the installed software since GNU/Linux is really not there yet with a number of types of apps, and is more of a maintenance headache. But if I bought one myself, I'd feel oblige to reformat the hard drive to get rid of the darkware (= no source) just like I do with a PC. I've played with that notion at different times since the hardware is actually rather nice. and _their_ definition of everything includes a bit more than the Redmonders' (e.g., Python is there, perl is there, gcc is there, so is Apache, a good development GUI-based IDE, Oh cool, you mean emacs/gud/gdb. emacs, a solid firewall, a _usable_ Terminal/commandline program to run bash or tcsh on, ...), Yes, shell mode in Emacs works fine, I haven't had much need to use anything else. Xterm also works. though it's no doubt still missing many pieces that you or I might want as parts of *our* everything (gvim rather than just vim, I'm not sure what the difference is supposed to be... I remember someone explaining you can't spell vile without vi. GUI/IDEs for Python, I remember there was a gud interface for Python but it didn't work pretty well. There's also IDLE which is pretty crude and flaky. I think I'll just wait for Pypy deployment before worrying about this situation too much. Is there something else I can download? Python add-ons such as numarray, gmpy, ctypes, ...) -- all of those you still have to download and install, just as you would for the satanware. That's unfortunate, that stuff should be included with Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Securing a future for anonymous functions in Python
Steve Holden [EMAIL PROTECTED] writes: Perhaps what we really need is a good Lisp subsystem for Python? I've thought the other way around, it would be nice to have a Python subsystem for Lisp. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Industry choice
Bulba! [EMAIL PROTECTED] writes: From the viewpoint of looking at availability of source code A, it's completely irrelevant if those guys are fishmongers or make derived work A' and redistribute only binary of A'. Not a single line of publicly available source code appeared or disappeared as the result of whatever they do. Amounts of binaries - yes, that is affected. But not the source code. From the viewpoint of the availability of Adobe Photoshop, it's completely irrelevant if I run off a few hundred thousand copies on CD in a warehouse by the waterfront and then sell them out of the back of a truck at the flea market. Not a single shrink-wrapped retail copy of Photoshop disappeared from any stores as the result. But Adobe will still send the US Marshals to raid my operation with guns and stuff. I don't think you would approve of my illicit Photoshop replication either. So why should the situation be any different with GPL code? If someone wants to copy it, they need to do so according to the license. -- http://mail.python.org/mailman/listinfo/python-list
Re: Securing a future for anonymous functions in Python
Nick Coghlan [EMAIL PROTECTED] writes: Add in the fact that there are many, many Python programmers with non-CS backgrounds, and the term 'lambda' sticks out like a sore thumb from amongst Python's other English-based keywords. 'def' is probably the second-most cryptic when you first encounter it, but it is a good mnemonic for define a function, so it's still easy to parse. Lambda is the term mathematicians use to refer to an anonymous function is nowhere near as grokkable ;) Richard Feynman told a story about being on a review committee for some grade-school science textbooks. One of these book said something about counting numbers and it took him a while to figure out that this was a new term for what he'd been used to calling integers. Integer is a math term but I think that if we need to use the concept of integers with someone unfamiliar with the term, it's best to just introduce the term and then use it, rather than make up new terminology like counting numbers even if those words sound more like conversational English. For the same reason I don't have any problem with lambda, though it's not that big a deal. I also just can't believe that Pythonistas keep getting into these arguments over whether lambda is too confusing, while at the same time there's no such discussion over far more abstruse Python features like metaclasses. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
[EMAIL PROTECTED] (Michael Hobbs) writes: The problem when using Python instead of C for OS development is that C was *specifically designed* to create an OS, while Python was designed for completely different purposes. If you want to write an OS, it would be wise to use a language that is suited for that purpose. If you dislike C so much and prefer Python so much more, your first step should be to design a Python dialect that is more appropriate for writing OS's. But I thought Python was an all-purpose language. After all, OS's have been written in Lisp before too. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Donn Cave [EMAIL PROTECTED] writes: I don't by any means agree that this notation is worth adopting, and in general I think this kind of readability issue is more or less a lost cause for a language with Python's scoping rules, but the motive makes sense to me. But we're talking about the mythical/hypothetical Python 3, so maybe there's a chance of fixing the scoping rules, which it seems to me are currently pretty badly broken. -- http://mail.python.org/mailman/listinfo/python-list
Re: DOS problem (simple fix??)
Gavin Bauer [EMAIL PROTECTED] writes: Thank you, and please make all answers simple enough to be understood by a highschool student and his father :) . You might like to try IDLE, which is included with Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: A Fundamental Turn Toward Concurrency in Software
aurora [EMAIL PROTECTED] writes: Just gone though an article via Slashdot titled The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software [http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues that the continous CPU performance gain we've seen is finally over. And that future gain would primary be in the area of software concurrency taking advantage hyperthreading and multicore architectures. Well, another gain could be had in making the software less wasteful of cpu cycles. I'm a pretty experienced programmer by most people's standards but I see a lot of systems where I can't for the life of me figure out how they manage to be so slow. It might be caused by environmental pollutants emanating from Redmond. -- http://mail.python.org/mailman/listinfo/python-list
Re: how to extract columns like awk $1 $5
[EMAIL PROTECTED] (Roy Smith) writes: Something along the lines of: words = input.split() print words[4], words[5] That throws an exception if there are fewer than 6 fields, which might or might not be what you want. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
Arich Chanachai [EMAIL PROTECTED] writes: But I thought Python was an all-purpose language. After all, OS's have been written in Lisp before too. Pure Lisp? Or a Lisp/C/Asm combo? Lisp has a compiled flavor by the way. Compiled flavor? Lisp has been compiled since the 1950's. No, there was no C code on Lisp machines. There was some low-level code at the bottom whose capabilities were such that you could accurately call it asm, but it was Lisp too, just a very restricted form. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Nick Coghlan [EMAIL PROTECTED] writes: Usage could be something like: res = [ f(i) for i in objects ] where: def f(x): #do something Hmm, this is actually a really interesting idea. Avoiding accidental namespace conflicts is certainly one of the advantages of using lambdas. I like it too. Seems a little perl-ish, but what the hey. In fact, any subexpressions in a complicated expression can be extracted and named for clarity without fear of screwing up the containing namespace, which would be an enormous boon for software maintainers. Sure, why not: x = (-b + sqrt(discriminant))/(2*a) where: discriminant = b*b - 4*a*c Maybe you could just have a where: suite that binds variables within the suite: where: def f(x): #do something res = [ f(i) for i in objects ] where: discriminant = b*b - 4*a*c x = (-b + sqrt(discriminant))/(2*a) Syntax is where: suite statement the suite has its own scope so any variable created there is local to the suite plus the following statement. The scope vanishes after the statement. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
Roose [EMAIL PROTECTED] writes: An OS is NOT an application. It is a completely different kind of program. Do you guys understand the difference between user and kernel mode? Do you know what address spaces and hardware interrupts are? Python is not equipped to handle these things. You would end up doing so much in C extensions that it could barely be called Python. You'd need some library functions to let Python access device registers and you'd need some low level code to dispatch interrupts into Python code. I am not trying to be insulting... but unless someone would like to educate me otherwise, the idea of an OS written in Python is almost ludicrous. Is an OS written in Lisp also ludicrous? Because it's been done. When Unix was first written, people thought implementing an OS in C was ludicrous. Everyone knew OS's had to be written in assembler. Also I am no threading expert, but I would imagine it would be very hard to write a task scheduler in Python given that it has the whole GIL thing. (As I said that isn't my domain of expertise but I'm sure someone here could expound on that.) The GIL is not part of the Python language. It's just an artifact of one particular implementation. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
AdSR [EMAIL PROTECTED] writes: Killer app for this keyword: class C(object): x = property(get, set) where: def get(self): return Silly property def set(self, val): self.x = Told you it was silly Hey, this is super-elegant! Heh, even further: z = C() where: class C(object): ... Lets you make anonymous classes and singleton objects. -- http://mail.python.org/mailman/listinfo/python-list
Re: The best way to do web apps with Python?
worzel [EMAIL PROTECTED] writes: What is the best way to web developemnt with Python? Is there anything close to PHP style in-page script placement that can create and use other Python objects? I am not really interested in Zope (I believe that is more a CMS than anything else?) I am also looking for something a little more structured than a series of CGI Scripts. Basically, yes, there are various Python template systems similar to PHP. I won't name them because other people more knowledgeable than me will do a better job than I could. I'll say that Python is a better language than PHP, but getting a basic dynamic web app running in PHP is much simpler than it is in Python. Python's advantage starts to shine once the app gets complicated. While on the topic - what is the expectataion of Python for this kind of stuff? Would one use Python for certain other things but turn to PHP for web apps - or would one use their Python skills in place of PHP? TIA It's sort of a difficult trade-off and it depends a lot on your application, who will develop and maintain it, who will use it, where it will be deployed, etc. Lots more people know PHP than Python, PHP is easier to get started with, and cheap PHP hosting is available all over. So if you're building some simple app that you want to distribute widely and run everywhere, PHP is attractive. If you're building a complex system which you'll run on a server that you have more control over, and you'll have relatively high-powered developers on hand to maintain the code, Python beats PHP. -- http://mail.python.org/mailman/listinfo/python-list
Re: Embedding a restricted python interpreter
Dieter Maurer [EMAIL PROTECTED] writes: It uses a specialized compiler that prevents dangerous bytecode operations to be generated and enforces a restricted builtin environment. Does it stop the user from generating his own bytecode strings and demarshalling them? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
Roose [EMAIL PROTECTED] writes: Is an OS written in Lisp also ludicrous? Because it's been done. Can you point me to this? I'd like to see how truly Lisp it is. http://en.wikipedia.org/wiki/Lisp_machine My first guess would be -- not very. And I'd like to install it on my PC. Although written with federal funds at a university, it was never released to the public, but was instead offered for sale from some companies. The conflicts over this led to the birth of the free software movement. Also, it was never intended to run on PC's (which didn't exist at that time). It needed special hardware that was built for the purpose of running Lisp. Lately there are people trying to program PC's to simulate the Lisp hardware and to get the Lisp Machine software released (now that the commercial market for it has long since dried up). However, both of those projects have a ways to go. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pre/Postconditions with decorators
Stephen Thorne [EMAIL PROTECTED] writes: Unresolved Problems: 1) How do you handle duck types, i.e. a method that accepts StringIO, cStringIO or any other object that has a .readlines(), .seek() and .read() method? That should really be done through having those classes inherit a file-operations mixin, or else through interfaces (which might get added to Python). 2) How do you turn off the type checking for production code? It should be left on. Leaving it in for development and turning it off for production is like wearing a parachute during ground training and taking it off once you're in the air. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Carl Banks [EMAIL PROTECTED] writes: You misunderstand. There where is not part of the expression but the statement. The above example would be a modified print statement, a print...where statement, if you will. Under this suggestion, there would be modified versions of various simple statements. You mean I can't say # compute sqrt(2) + sqrt(3) x = (sqrt(a) where: a = 2.) \ + sqrt (a) where: a = 3. Hmmm. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Carl Banks [EMAIL PROTECTED] writes: # compute sqrt(2) + sqrt(3) x = (sqrt(a) where: a = 2.) \ + sqrt (a) where: a = 3. Hmmm. What would be the advantage of that over this? . x = sqrt(a) + sqrt(b) where: . a = 2.0 . b = 3.0 The idea of where is to allow re-using variable names instead of having to keep track of which ones are in use. I just tried to give a very simple example of how you might do that more than once in a statement. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Nick Coghlan [EMAIL PROTECTED] writes: I think having to keep the names unique within the statement you are currently writing is a reasonable request :) Um, you could say the same thing about the function, the module, etc. ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Nick Coghlan [EMAIL PROTECTED] writes: x = (sqrt(a) where (a=2.0)) + (sqrt(b) where (a=3.0)) Hmm, I like that too. -- http://mail.python.org/mailman/listinfo/python-list
Re: The best way to do web apps with Python?
Steve Holden [EMAIL PROTECTED] writes: You can read about it in Philip Eby's excellent PEP at http://www.python.org/peps/pep-0333.html I looked at this and I have the impression that it tries to do something worthwhile, but I can't tell precisely what. The rationale and goals section explains good reasons why it doesn't do various certain things. What's not explained is what DOES it do. The only thing I can tell is that it connects to an abstracted web server, and builds up what looks like traditional CGI variables from the incoming requests. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pre/Postconditions with decorators
Stephen Thorne [EMAIL PROTECTED] writes: It should be left on. Leaving it in for development and turning it off for production is like wearing a parachute during ground training and taking it off once you're in the air. So we can't use this for a case where we have an extremely large list then ;). Its an O(n) operation to just call a function that takes a list of a specific type. The condition should be enforced at the time whenever list itself is mutated. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Nick Coghlan [EMAIL PROTECTED] writes: Trying to push it a level further (down to expressions) would, IMO, be a lot of effort for something which would hurt readability a lot. I think we should just try to do things in a simple and general way and not try to enforce readability. For example, the slightly-overcomplex code that I proposed might have been generated by a macro, or even by a compiler from some other language. No human would ever have to look at it, so it doesn't matter whether it's easily readable. There's no reason to add needless constraints on the language just to make writing ugly code difficult. The main goal should be to make writing clear code easy, not to worry about whether someone might also write ugly code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Old Paranoia Game in Python
Oh cool, I sort of remember that game from back in the day. I didn't play it very much so never got very far in it. I'll have to try your version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python3: on removing map, reduce, filter
Andrey Tatarinov [EMAIL PROTECTED] writes: How does GvR suggestions on removing map(), reduce(), filter() correlate with the following that he wrote himself (afaik): http://www.python.org/doc/essays/list2str.html I think that article was written before list comprehensions were added to Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python3: on removing map, reduce, filter
Andrey Tatarinov [EMAIL PROTECTED] writes: anyway list comprehensions are just syntaxic sugar for for var in list: smth = ... res.append(smth) (is that correct?) I would expect lc's to work more like map does. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
Roose [EMAIL PROTECTED] writes: I've written file systems in Python, and task schedulers in Javascript, and they were fine for their purposes Uh, not to be rude, but what are you talking about? If I'm not mistaken Javascript is that scripting language that runs inside a browser, Correct. an application. How are you going to save and restore CPU state in Javascript, or even call assembly that does it in Javascript? How do you switch into kernel mode in Javascript? We are on completely different pages apparently. Correct. Upon reading back in the thread I see that you mean compiled Lisp, no? I was thinking that there would be a Lisp interpreter in a kernel, which afaik doesn't exist. Yes, compiled Lisp. There are Python compilers too. In any case, as I said before I don't think it is impossible, just a poor engineering decision and I don't see the rationale behind it. I don't see a convincing case against writing an OS even in interpreted Python, though of course I'd want it to be compiled if possible. What do you think OS's do, that Python wouldn't be suitable for? Your examples of task switching and virtual memory are unconvincing. Those just require setting up some suitable tables and then calling a low-level routine to poke some CPU registers. File systems can be more performance intensive, but again, in those, much of the cpu drain can be relegated to low-level routines and the complexity can be handled in Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
Arich Chanachai [EMAIL PROTECTED] writes: Yes, compiled Lisp. There are Python compilers too.\ ??? You mean like Pyrex or some such? I wouldn't exactly call these Python compilers, as that kind of obscures some underlying (critical) facts. Also psyco. And I think Pypy is currently set up to compile Python into Pyrex and then run the Pyrex results through GCC. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
Roose [EMAIL PROTECTED] writes: Are you actually going to answer any of my questions? Let's see this JavaScript task scheduler you have written! I wrote it at a company and can't release it. It ran inside a browser. There was nothing terribly amazing about it. Obviously the tasks it scheduled were not kernel tasks. Do you know how Stackless Python (with continuations) used to work? That had task switching, but those were not kernel tasks either. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
Arich Chanachai [EMAIL PROTECTED] writes: And I think Pypy is currently set up to compile Python into Pyrex and then run the Pyrex results through GCC. But of course, who's going to argue that Pyrex produces compiled Python? Pyrex produces compiled Python in the same sense that asm produces compiled C. PyPy contains a Python compiler which reads Python source and produces Pyrex output. The Pyrex output then gets compiled by the Pyrex compiler and then the C compiler before ending up with machine code. There is nothing terribly bizarre about this kind of compiler. For example, Gnu Common Lisp compiles Lisp code into C, then runs the C code through gcc. For that matter, the Yacc/Bison parser generators do something similiar. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Carl Banks [EMAIL PROTECTED] writes: So do you approve of the movement to get rid of the print statement? Any little incremental change in Python you could make by having or not having a print statement would be minor compared to the H-Bomb of ugliness we'd get if suites of statements were to be allowed inside Python expressions. Having or not having a print statement might violate some small aspect of the Zen, but it won't rape the whole list. How about macros? Some pretty horrible things have been done in C programs with the C preprocessor. But there's a movememnt afloat to add hygienic macros to Python. Got any thoughts about that? So I don't know what point you're trying to make. Why should you care whether the output of a macro is ugly or not, if no human is ever going to look at it? But to answer your question, I would prefer a Python without a print statement, since a print method could do anything the print statement could. A print -method-?!! You /really/ want to say your_name = Carl your_favorite_cereal = cornflakes (Hi, your_name, how about a nice bowl of, your_favorite_cereal).print() instead of your_name = Carl your_favorite_cereal = cornflakes print Hi, your_name, how about a nice bowl of, your_favorite_cereal I've heard of people wanting to replace print with a function, but hadn't heard of replacing it with a method. Are you trying to turn Python into Ruby? -- http://mail.python.org/mailman/listinfo/python-list
Re: Port blocking
Mark Carter [EMAIL PROTECTED] writes: Supposing I decide to write a server-side application using something like corba or pyro. What's the chance that in big corporations, the client's ports (in both senses of the word: fee-paying, and application) will be blocked, thereby immediately scuppering whatever I have written? Has this problem ever arisen for anyone? Usually you wouldn't run a public corba or pyro service over the internet. You'd use something like XMLRPC over HTTP port 80 partly for the precise purpose of not getting blocked by firewalls. Also, is there a good tool for writing database UIs? Yes, quite a few. -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Carl Banks [EMAIL PROTECTED] writes: Paul Rubin wrote: Carl Banks [EMAIL PROTECTED] writes: So do you approve of the movement to get rid of the print statement? Any little incremental change in Python you could make by having or not having a print statement would be minor compared to the H-Bomb of ugliness we'd get if suites of statements were to be allowed inside Python expressions. Having or not having a print statement might violate some small aspect of the Zen, but it won't rape the whole list. How about macros? Some pretty horrible things have been done in C programs with the C preprocessor. But there's a movememnt afloat to add hygienic macros to Python. Got any thoughts about that? How about this: Why don't you go to a Python prompt, type import this, and read the Zen of Python. Consider each line, and whether adding macros to the language would be going against that line or for it. After you've done that, make an educated guess of what you think I'd think about macros, citing various Zens to support your guess. Then I'll tell you what my my thoughts about it are. The Zen of Python, by Tim Peters Beautiful is better than ugly. = +1 macros Explicit is better than implicit. = +1 macros Simple is better than complex. = +1 macros Complex is better than complicated. = I don't understand this, +0 Flat is better than nested. = not sure, +0 Sparse is better than dense. = +1 macros Readability counts. = +1 macros Special cases aren't special enough to break the rules. = +1 macros Although practicality beats purity. = +1 macros Errors should never pass silently. = +1 macros Unless explicitly silenced. = +1 macros In the face of ambiguity, refuse the temptation to guess. = +1 macros There should be one-- and preferably only one --obvious way to do it. = -1 Although that way may not be obvious at first unless you're Dutch. = ??? Now is better than never. = +1 macros, let's do it Although never is often better than *right* now. = +1 If the implementation is hard to explain, it's a bad idea. = unknown, +0 If the implementation is easy to explain, it may be a good idea. = +0 Namespaces are one honking great idea -- let's do more of those! = +1 I'm -1 on doing stuff by received dogma, but in this particular case it looks to me like the dogma is +12 for macros. What are your thoughts? -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
Carl Banks [EMAIL PROTECTED] writes: When I asked you to do this, it was just a rhetorical way to tell you that I didn't intend to play this game. It's plain as day you're trying to get me to admit something. I'm not falling for it. If you have a point to make, why don't you just make it? You asked me to compare the notion of macros with the Zen list. I did so. I didn't see any serious conflict, and reported that finding. Now you've changed your mind and you say you didn't really want me to make that comparison after all. An amazing amount of the headaches that both newbies and experienced users have with Python, could be solved by macros. That's why there's been an active interest in macros for quite a while. It's not clear what the best way to do design them is, but their existence can have a profound effect on how best to do these ad-hoc syntax extensions like where. Arbitrary limitations that are fairly harmless without macros become a more serious pain in the neck if we have macros. So, we shouldn't consider these topics separately from each other. They are likely to end up being deeply related. -- http://mail.python.org/mailman/listinfo/python-list
Re: Making immutable instances
Mike Meyer [EMAIL PROTECTED] writes: Lots of people seem to want immutable instances. Nobody seems to have a use case for them. What is the use case for immutable strings? Why shouldn't strings be mutable like they are in Scheme? Generally if I know I don't plan to mutate something, I'd want to make it immutable so the runtime system can notice if I make an error. It's like an assert statement spread through the whole program. -- http://mail.python.org/mailman/listinfo/python-list
Re: General question about Python design goals
Donn Cave [EMAIL PROTECTED] writes: Right. After devoting a lengthy post to the defense of tuples as a structured type, I have to admit that they're not a very good one ... Another theme that occasionally comes up in advice from the learned has been use a class. There's a historical issue too: when tuples started first being used this way in Python, classes had not yet been introduced. -- http://mail.python.org/mailman/listinfo/python-list
Re: General question about Python design goals
Donn Cave [EMAIL PROTECTED] writes: There's a historical issue too: when tuples started first being used this way in Python, classes had not yet been introduced. When was that, old-timer? It was before my time, but I have the impression that classes arrived with 1.3 or somewhere around then. Maybe some of the oldbies here remember. I started using Python around when 2.1 was released, I think. -- http://mail.python.org/mailman/listinfo/python-list
Re: General question about Python design goals
Fredrik Lundh [EMAIL PROTECTED] writes: fwiw, the tuple and class implementation were both checked into CVS in october 1990. maybe he's talking about ABC? No I think I'm just plain mistaken. For some reason I thought classes came much later. It was way before my time so I defer to your wisdom. -- http://mail.python.org/mailman/listinfo/python-list
Re: JOB: Telecommute Python Programmer - IMMEDIATE NEED
Beau Gould [EMAIL PROTECTED] writes: JOB: Telecommute Python Programmer - IMMEDIATE NEED Please see www.superiorss.com/jobs.htm I hope this person is not trying to spam web BBS's, wikis, etc. -- http://mail.python.org/mailman/listinfo/python-list
Re: what's wrong with lambda x : print x/60,x%60
Sybren Stuvel [EMAIL PROTECTED] writes: No, it is not merely a shortcut. It often allows one to avoid polluting the namespace with a completely superfluous function name, thus reducing code smell. Which can also be done by using inner functions. Inner functions with no names? It can also avoid a multi-line function defintion which often pushes other relevant code off the current page and out of view, and thus lambda can increase program readability. def somefunc(x): return x*5 How is that a multi-line function definition? def mult_by_five(): def somefunc(x): return x*5 return somefunc is multi-line, as opposed to: def mult_by_five(): return lambda x: x*5 -- http://mail.python.org/mailman/listinfo/python-list
Re: Bitching about the documentation...
François Pinard [EMAIL PROTECTED] writes: Let me repeat this for the umpteenth time: You do not have to learn LaTeX to contribute to docs. Submit plain text. One of us with some LaTeX knowledge will do the markup. Content is the hard part. Markup is nothing, so don't let it be a barrier for you. More than LaTeX, the main frozener is when people in charge tell you to use bug trackers to speak to them. More than latex and bug trackers, the main obstacle is that people wanting better docs want them for the precise reason that the existing docs don't make it clear what the code does. Writing a good doc patch (and the patches needed are often sweeping rewrites) requires studying and understanding the code being documented, and the application area that the code tries to implement. Maybe it also requires studying relevant standards that the code implements (to note gaps in the implementation), comparing the implementation to other implementations in other languages, etc. For example, writing a good doc patch for urllib2 would mean checking RFC 2616(?) against the urllib2 code to see what parts of the RFC got implemented and what parts didn't. It might also mean comparing urllib2 with other libraries like LWP (Perl) or whatever the equivalent is in Java. By the time the requester/patch writer gets through studying the code to figure out what it does, maybe s/he has answered his/her own questions and doesn't need docs any more. The person best qualified to know what the code does is the code author, who could answer all the questions immediately. The solution is clear: the distro maintainers should require that all code contributions must come with good docs. When a code submission comes in, the distro maintainers should critically review the accompanying docs, note any shortcomings and constructively ask for improvements from the contributor until the docs are good. The distro committers are all very skilled and experienced people. So there's a certain amount of mentoring going on whenever a committer works with a contributor to accept a code patch. By communicating what it takes to bring documentation up to snuff, the committers can share their wisdom with contributors and thereby raise the quality standard of not just the distro, but also of the whole contributor community. Passing skills on to others is after all what being a community is about. Many of us who have acquired any skill at putting docs together, acquired them in precisely this fashion, and should try to pass them on. -- http://mail.python.org/mailman/listinfo/python-list
Re: what's wrong with lambda x : print x/60,x%60
Steve Holden [EMAIL PROTECTED] writes: Defining a function, and giving it a name, isn't polluting the namespace, any more than assigning sub-expressions to temporary variables is polluting the namespace. Nor any less. Why use temporary variables when all you have to do is make your expressions three lines long to avoid polluting the namespace? Indeed. I'd much rather say x = a + b + (c * d) + e than temp1 = a + b temp2 = c * d temp3 = temp1 + temp2 x = temp3 + e I don't understand why the critics of lambda don't understand that having to use so many temp variables, for either numbers or functions, can work against both concision and clarity. Even without shouting Namespaces are a honking good idea, let's do more of those, I should just like to make a small plea for everyone to remember that namespaces are there specifically to allow us to name things! Not everything needs a name. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bitching about the documentation...
[EMAIL PROTECTED] writes: Sounds like a subject matter expert is needed here, not a garden variety tech writer or Python programmer. Documentation of esoteric stuff requires, well, esoteric knowledge. Yes, that's what I mean; coding a library module for an esoteric function requires that same esoteric knowledge, and those are the modules for which the docs need the most help. So the person coding the library module is the logical person to write the doc. The doc writing task can't in general be handed off to some random programmer or writer. It should be written by the same person who wrote the code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bitching about the documentation...
Steve Holden [EMAIL PROTECTED] writes: Or, better still, by an accomplished writer who has access to the code's author. This was indeed my experience in writing the docs for previously undocumented modules. The author was happy to help me by answering questions, and this did make the docs better than they'd otherwise have been. Yes, this can work pretty well for some modules, especially when there's in-person contact rather than just email. The total amount of work done between the two people may be more than would be needed if the coder just wrote the docs and got it over with. But any way that gets it done is fine. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bitching about the documentation...
[EMAIL PROTECTED] writes: Redhat's Fedora project seems to have a fairly well developed program for recruiting and encouraging writers. Frankly I haven't been that impressed with the Fedora docs I've seen. The LDP docs have generally been better. Maybe I'm looking at the wrong Fedora docs. Fedora Core 4 also broke or changed a bunch of code that worked perfectly well in FC3, as a side issue. For a language environment like Python, the example I'd look to for quality docs is probably CLtL2: http://www.cliki.net/CLtL2 The CMU link seems to be down right now. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bitching about the documentation...
BartlebyScrivener [EMAIL PROTECTED] writes: The solution is clear: the distro maintainers should require that all code contributions must come with good docs. Well, that might be asking a bit too much of the programmers, who perhaps don't exactly enjoy mucking about in the lowlands of English grammar and syntax. I've generally found good coders are also good writers, despite the stereotype of the uncommunicative geek. Some coders don't like documenting because it's less exciting than writing code, but that doesn't mean they're incapable of it. After a while you learn to just slog it out. Docs written by non-native English speakers generally need to be cleaned up before publication, but that's no big deal. All I was saying is you should court writers and mid-level programmers with writing skills (not saying I'M mid-level, I'm still learning) to HELP with creating good documentation. When a writer thinks about helping they go to a page where they are greeted by a bug report menu or CSV notices or some such. I just don't know to what extent a program like Python can really benefit from docs written by non-experts in the thing being documented. Of course there are other types of programs, like some desktop applications, which can be documented by non-experts. That's why most of your really good stuff for beginners is on separately created web pages, where writers simply take matters into their own hands. Also fine, not saying it should be different. I don't know about this. Again, taking something like Bengt Richter's suggestion as just one example. To me the module docs are almost incomprehensible without good examples. Why not have a button where people could submit nice SHORT examples illustrating otherwise pure theoretical code and geek-speak. Of course, the editors would decide in a survival-of-the-fittest contest which example gets used, but the point is you'd get good free examples this way. PHP has a system sort of like that, where each library function has its own doc page and anyone can submit comments and examples, sort of like a blog. E.g.: http://us2.php.net/manual/en/function.metaphone.php There's been some discussion of doing the same thing for Python, but it hasn't been happening. Generally, it seems to me, the parts of the docs that can be improved much by easy additions like an example here and there, are already usable with a little extra effort. The docs that need improvement the most (because they're almost unusable as-is) need extensive additions and rewrites that really have to to be done by experts. In general, I'd be happy to help a programmer with writing if it meant I would learn programming along the way. It should be that easy. Maybe you'd enjoy going to a user group meeting and trying to find people to collaborate with. Doing that kind of thing in person is much more fun than doing it over the net. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs bad
[EMAIL PROTECTED] (Björn Lindström) writes: Actually using tabs for eight spaces and then filling out with spaces to the correct indentation is the convention for Emacs Lisp. Of course, since everyone coding Emacs Lisp does it with the same editor, it's no problem. The variable `indent-tabs-mode' controls this. I like no tabs. -- http://mail.python.org/mailman/listinfo/python-list
Re: what's wrong with lambda x : print x/60,x%60
[EMAIL PROTECTED] writes: I think there is, for python. Not that I agree with it. The language doesn't prevent you from using the short one-liner style but the idioms prefer the line by line(and one single op/action per line) style. Are you serious?!! You're saying idiomatic Python prefers temp1 = a + b temp2 = c * d temp3 = temp1 + temp2 x = temp3 + e to x = a + b + (c * d) + e ???!!! I don't think you look at the same Python code I do ;-). -- http://mail.python.org/mailman/listinfo/python-list
Re: Bitching about the documentation...
François Pinard [EMAIL PROTECTED] writes: You may suggest that I should process my e-mail more promptly. No, I'm not suggesting you how to work, no more that I would accept that you force me into working your way. If any of us wants to force the other to speak through robots, that one is not far from unspeakable... In the old days, it was possible to post stuff to Python's sourceforge pages without logging in. That was turned off for various reasons that weren't bogus, but that didn't strike me as overwhelmingly compelling. Maybe that could be revisited, at least for the category of documentation bugs and patches. -- http://mail.python.org/mailman/listinfo/python-list
Re: Documentation suggestions
Steve Holden [EMAIL PROTECTED] writes: I proposed a documentation sprint for PyCon a couple of years ago, but nobody thought it was important enough to work on. It would be a good idea next year, too. IMO this should definitely be done. That nobody thought docs were important enough to work on, explains a lot of why the docs have such problems. Generating better docs and keeping them up to date needs more than keystrokes--it needs an attitude change. So the first thing to do is decide for real that good docs are important. Until that's decided and taken to heart, no amount of piddling around will affect the problem much. -- http://mail.python.org/mailman/listinfo/python-list
Re: Output: Number of digits in exponent?
Jens Bloch Helmers [EMAIL PROTECTED] writes: How can I control the number of digits in the exponent when writing floats to a file? It seems that Python2.4.2(winXP) prints three digits anyway. print 1.0e50 1e+050 That's weird; must be version and/or OS dependent. On Fedora Core 4: Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type help, copyright, credits or license for more information. print 1e50 1e+50 Can this be done in Python? Speed is an issue so I don't like the idea of rolling my own output function. It should be possible to do: print '%12.5.2e' % (1.0e50) 1.000e+50 How's this (untested): def efmt(x): s = '%12.5e' % x assert s[-5] == 'e' and s[-3] == '0' return s[:-4] + s[-2:] -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
Antoon Pardon [EMAIL PROTECTED] writes: But lately I have been wondering about doing the following: end = None ... if ...: ... end IMO it looks better, but I'm reluctant because it suggest some checking by the compilor, which just doesn't happen. I don't think you can always do that. try: ... end except blah: ... looks syntactically invalid. -- http://mail.python.org/mailman/listinfo/python-list
Re: what's wrong with lambda x : print x/60,x%60
Steve Holden [EMAIL PROTECTED] writes: All joking aside, when I have names (temporary variables or scaffolding functions) that I need to initialise a module or data structure, but then outlive their usefulness, I del the name afterwards. Am I the only one? I can't say I've seen anyone else doing that, and it feels icky to me (for no reason I can put my finger on) -- what do others think? I do that too sometimes. I think it's a Python weakness that you can't declare a local var like in other languages, to go out of scope at the end of the current block, e.g.: if cond: my x = 7# make a new scope for x, goes out of scope at end of if I don't generally speaking see the point: unless the name is referencing something potentially large (like the results of a database query) and won't be going out of scope soon (which typically happens at the end of the current method or function) I just leave it to happen automatically. If it doesn't happen (because the name exists at module scope) thwn what the heck. Well, that makes the code a little bit confusing. If you say x = some_intermediate_result(...) do_something_with (x) do you know for sure whether x will be needed again? Are you sure you didn't use the name x further up in the function for something that's still needed? This is one of the areas where there's tension between Python the scripting language, that gains by saving a few keystrokes when throwing together a quick hack, and Python the language for developing long-lasting applications that have to be maintained by multiple people. In Haskell you can even have temporary variables inside an expression: x = y + y*y + 3 where y=5 sets x to 33. I believe (not absolutely sure) that the scope of y is limited to that expression. -- http://mail.python.org/mailman/listinfo/python-list
Re: what's wrong with lambda x : print x/60,x%60
Steve Holden [EMAIL PROTECTED] writes: if cond: my x = 7# make a new scope for x, goes out of scope at end of if If this genuinely troubles you then you can always isolate the scope with a function, though of course you also no longer have the code inline then. I don't generally speaking see the point: The point is something like: it's normal to write if cond: x = 7 do_something_with(x) # now you don't care about x any more. Years later, there's some production problem in the middle of the night and someone has to put in a patch, and they re-use the value in x for something later in the function, i.e. y = x + 3# since x is still in scope from way up there and check it in. Years after THAT, yet another person re-uses the name x for something, etc. Yeah, yeah, bad programming practice, blah, blah, blah, but anyone who's maintained code in the real world knows this stuff happens all the time. Well, as warts go the inability to tightly control the scope of variables isn't really that terrible, is it? I wouldn't say it's as terrible as some things might be, but it contributes to a sense of sloppiness about Python, that there are always all these dirty dishes laying around. Even the encrustation we call Perl doesn't have this problem; it can not only control scope, but it has the -T (taint checking) feature that analyzes actual dataflow from one variable to another and flags you if you do something dangerous with unchecked user input. This turns out to be very useful. I wish Python had something like it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie question
Steven D'Aprano [EMAIL PROTECTED] writes: Yes. Reaching through objects to do things is usually a bad idea. I don't necessarily disagree, but I don't understand why you say this. Why it is bad? The traditional OOP spirit is to encapsulate the object's entire behavior in the class definition. -- http://mail.python.org/mailman/listinfo/python-list
Re: Documentation suggestions
Mike Meyer [EMAIL PROTECTED] writes: I'm working on puttingn this up for Python. I'm planning on using AJAX to pass the input string to eval on the server. I.e. - you'll be limited to expressions, which is what it seems like the Ruby thing is limited to. On the other hand, with iterators, generators and list comprehensions, you can do quite a lot with eval. How will you stop the server from getting hosed? -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on object representation in a dictionary
py [EMAIL PROTECTED] writes: Well the other thing is that I am allowed to store strings in this dictionary...so I can't just store the Engine and Body object and later use them. this is just a requirement (which i dont understand either)...but its what I have to do. Probably so that the object store can later be moved offline, with the shelve module or DB API or something like that. So my question is there a good way of storing this information in a nested dictionary such that if I receive this dictionary I could easily pull it apart and create Engine and Body objects with the information? Any suggestions at all? keep in mind I am limited to using a dictionary of strings...thats it. The spirit of the thing would be serialize the objects, maybe with cPickle, as Steven suggests. A kludgy way to thwart the policy might be to store the objects in a list instead of a dictionary: x[0], x[1], etc. Then have a dictionary mapping keys to subscripts in the list. The subscripts would be stringified ints: '0','1',... . -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie question
[EMAIL PROTECTED] (Alex Martelli) writes: You could make a case for a 2D coordinate class being sufficiently primitive to have immutable instances, of course (by analogy with numbers and strings) -- in that design, you would provide no mutators, and therefore neither would you provide setters (with any syntax) for x and y, obviously. However, a framework for 2D geometry entirely based on immutable-instance classes would probably be unwieldy I could imagine using Python's built-in complex numbers to represent 2D points. They're immutable, last I checked. I don't see a big conflict. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie question
[EMAIL PROTECTED] (Alex Martelli) writes: I could imagine using Python's built-in complex numbers to represent 2D points. They're immutable, last I checked. I don't see a big conflict. No big conflict at all -- as I recall, last I checked, computation on complex numbers was optimized enough to make them an excellent choice for 2D points' internal representations. I suspect you wouldn't want to *expose* them as such (e.g. by inheriting) but rather wrap them, because referring to the .real and .imag coordinates of a point (rather than .x and .y) IS rather weird. Wrapping would also leave you the choice of making 2D coordinates a class with mutable instances, if you wish, reducing the choice of a complex rather than two reals to a mere implementation detail;-). Right, you could use properties to make point.x get the real part of an internal complex number. But now you're back to point.x being an accessor function; you've just set things up so you can call it without parentheses, like in Perl. E.g. a = point.x b = point.x assert (a is b)# can fail for that matter assert (point.x is point.x) can fail. These attributes aren't member variables any more. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie question
Steven D'Aprano [EMAIL PROTECTED] writes: The fact that sys is a module and not a class is a red herring. If the Law of Demeter makes sense for classes, it makes just as much sense for modules as well -- it is about reducing coupling between pieces of code, not something specific to classes. I don't see that. If a source line refers to some module you can get instantly to the module's code. But you can't tell where any given class instance comes from. That's one of the usual criticisms of OOP, that the flow of control is obscured compared with pure procedural programming. One dot good, two dots bad. Easy to fix. Instead of sys.stdout.write(...) say from sys import stdout from then on you can use stdout.write(...) instead of sys.stdout.write. -- http://mail.python.org/mailman/listinfo/python-list
Re: lambda (and reduce) are valuable
Chris Mellon [EMAIL PROTECTED] writes: As someone who does a tremendous amount of event-driven GUI programming, I'd like to take a moment to speak out against people using us as a testament to the virtues of lamda. Event handlers are the most important part of event-driven code, and making them real functions with real names is crucial to maintainable code. The only reason to ever use a lamdba in Python is because you don't want to give a function a name, and that is just not a compelling use case for GUI events. I thought stuff like the following was idiomatic in GUI programming. Do you really want separate names for all those callbacks? # generate calculator keypad buttons Button(label='7', command=lambda: user_pressed(7)).grid(column=1, row=1) Button(label='8', command=lambda: user_pressed(8)).grid(column=2, row=1) Button(label='9', command=lambda: user_pressed(9)).grid(column=3, row=1) Button(label='4', command=lambda: user_pressed(4)).grid(column=1, row=2) Button(label='5', command=lambda: user_pressed(5)).grid(column=2, row=2) Button(label='6', command=lambda: user_pressed(6)).grid(column=3, row=2) ... -- http://mail.python.org/mailman/listinfo/python-list
Re: lambda (and reduce) are valuable
Fredrik Lundh [EMAIL PROTECTED] writes:
a temporary factory function should be sufficient:
def digit(label, x, y):
def callback():
# print BUTTON PRESS, label # debug!
user_pressed(int(label))
Button(label=label, command=callback).grid(column=x, row=y)
Looking at the calculator program I wrote a while back (one of my
first Python programs, written just to play with tkinter), I see that
I actually did something like that for the buttons. However, it also
contained (in the other order):
unops = {'sqrt': math.sqrt,
'sin': math.sin,
'cos': math.cos,
'tan': math.tan,
'ln': math.log,
'log': lambda x: math.log(x)/math.log(10),
'clr x': lambda x: 0
}
binops = {'+': (lambda x,y: x+y),
'-': (lambda x,y: x-y),
'*': (lambda x,y: x*y),
'/': (lambda x,y: x/y),
'**': (lambda x,y: x**y)
}
How would you refactor that, with no lambda?
--
http://mail.python.org/mailman/listinfo/python-list
Re: lambda (and reduce) are valuable
Paul Rubin http://[EMAIL PROTECTED] writes:
binops = {'+': (lambda x,y: x+y),
'-': (lambda x,y: x-y),
'*': (lambda x,y: x*y),
'/': (lambda x,y: x/y),
'**': (lambda x,y: x**y)
}
How would you refactor that, with no lambda?
Ok, with operator.add and so forth. I don't remember if I knew about
those at the time. You can easily see though, how additional such
simple functions might be wanted, that aren't in the operator module.
--
http://mail.python.org/mailman/listinfo/python-list
Re: lambda (and reduce) are valuable
[EMAIL PROTECTED] writes: How would you refactor that, with no lambda? Or, why would you want to refactor that ? I like it the way it was written. I'm not the one saying lambda is bogus. -- http://mail.python.org/mailman/listinfo/python-list
Re: how does exception mechanism work?
[EMAIL PROTECTED] writes: Is this model correct or wrong? Where can I read about the mechanism behind exceptions? Usually you push exception handlers and finally clauses onto the activation stack like you push return addresses for function calls. When something raises an exception, you scan the activation stack backwards, popping stuff from it as you scan and executing finally clauses as you find them, until you find a handler for the raised exception. Good book: Structure and Interpretation of Computer Programming by Abelson and Sussman, http://mitpress.mit.edu/sicp/ It explains all this stuff (uses a different language from Python, but principles are similar). Full text is online. -- http://mail.python.org/mailman/listinfo/python-list
Re: lambda (and reduce) are valuable
[EMAIL PROTECTED] (Bengt Richter) writes: for tup in ((str(d+1), d%3+1,3-d//3) for d in xrange(9)): digit(*tup) tweak 'til correct ;-) GMTA. See: http://www.nightsong.com/phr/python/calc.py written a couple years ago. It uses: for i in xrange(1,10): add_button(5+2-(i-1)/3, (i-1)%3, str(i)) -- http://mail.python.org/mailman/listinfo/python-list
Re: 0 in [True,False] returns True
Steve Holden [EMAIL PROTECTED] writes: The really interesting question your post raises, though, is Why do you feel it's necessary to test to see whether a variable is a Boolean?. What's the point of having Booleans, if you can't tell them from integers? -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: generate a function based on an expression
Jacob Rael [EMAIL PROTECTED] writes: I read about the security concerns involved in using eval(). I don't expect this project to grow to the point where I require a web interface. However, since I am learning, I might as well learn the right way. I think you're going to have to write an actual parser and evaluator. There are various tools that can help you do that (PyParse, etc.) but if it's for a learning project, you might like to try doing it from scratch. -- http://mail.python.org/mailman/listinfo/python-list
Re: I want a Python Puppy !
Claudio Grondi [EMAIL PROTECTED] writes: Currently Ubuntu is my favorite, because it seems to be at the moment the only Linux distribution supporting already Python 2.4.2 out of the box, Are you seriously saying that whatever distro came out most recently (and therefore have the latest Python version) gets to be your favorite? You're going to have to change favorites practically every week. I'm currently using Fedora Core 4 which comes with Python 2.4.1. I won't exactly say FC4 is my favorite, but it's what I'm used to. I've also been wanting to check out Ubuntu and Gentoo, but slight coincidences of the release schedule shouldn't be that big a deal in choosing between them. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bad marshal data
Michael McGarry [EMAIL PROTECTED] writes: Marshal should save the data in a readable text format, but I guess it does not. Any help would be appreciated, RTFM. Marshal is not intended for what you're doing. Use Pickle, which is. -- http://mail.python.org/mailman/listinfo/python-list
Re: Still Loving Python
[EMAIL PROTECTED] (Alex Martelli) writes: Try Interface Builder on a Mac: it builds interfaces as _data_ files, not generated code. You can then use the same UI from Objective C, Java, Python (w/PyObjC), AppleScript... interface-painters which generate code are a really bad idea. Glade also does something like that. We see the same thing in HTML. Lots of people including serious designers use wysiwyg HTML layout programs. For fancy layouts they're almost indispensible. I hand-code my HTML but I keep it simple. -- http://mail.python.org/mailman/listinfo/python-list
Re: How do (not) I distribute my Python progz?
Tolga [EMAIL PROTECTED] writes: Let's suppose that I have written a Python program and, of course, want to show it to the world ;-) So, do I have to distrubute my source code? Or is there a way to hide my code? You're not really showing it to the world, if you hide the source. -- http://mail.python.org/mailman/listinfo/python-list
Re: Developing a network protocol with Python
Laszlo Zsolt Nagy [EMAIL PROTECTED] writes: I already have my own classes. My objects are in object ownership trees, and they are referencing to each other (weakly and strongly). These classes have their own streaming methods, and they can be pickled safely. Standard warning: if you're accepting requests from potentially hostile sources, don't use pickle. -- http://mail.python.org/mailman/listinfo/python-list
Re: Developing a network protocol with Python
Laszlo Zsolt Nagy [EMAIL PROTECTED] writes: But how can I transfer pure python objects otherwise? Pyro also uses Pickle and it also transfers bytecode. Pyro in the past used pickle in an insecure way. I'd heard it had been fixed and I didn't realize it still uses pickle. I read somewhere that Pickle had a security problem before Python 2.2, but after 2.2 it has been solved. If you use pickle in the obvious way, it's definitely still insecure. There is some info in the docs about how to use some special pickle features to protect yourself from the insecurity, but you have to go out of your way for that. I'm skeptical that they really protect you in all cases, so I'd avoid unpickling any untrusted data. But I don't know a specific exploit BTW how CORBA or COM does this? They can do object marshaling safely. I think they don't let you marshal arbitrary class instances and have the class constructors called as part of demarshalling (COM anyway, I don't know about CORBA). Can we do the same with Python? Yes, of course, it's possible in principle, but pickle doesn't do it that way. See SF RFE #467384 and bug #471893 for some more discussion of this. Basically I think these issues are better understood now than they were a few years ago. Isn't it enough to implement find_global of a cPickler ? I can't definitely say the answer is no but I feel quite paranoid about it. The cPickle code needs careful review which I don't think it's gotten. It was not written with security in mind, though some security hacks were added as afterthoughts. I continue to believe that Python should have a deserializer designed to be absolutely bulletproof no matter what anyone throws at it, and it doesn't currently have one. I've gotten by with limited, ad hoc wire formats for the applications where I've needed them. -- http://mail.python.org/mailman/listinfo/python-list
Re: Which Python web framework is most like Ruby on Rails?
[EMAIL PROTECTED] (Alex Martelli) writes: To put it another way: one reason I love Python is that I strongly subscribe to the idea that there should preferably be only one obvious way to do something. Unfortunately, this principle is very badly broken by the multiplicity of Python web frameworks. This also has to be a big part of why PHP is kicking the pants off of Python for popularity in web development. -- http://mail.python.org/mailman/listinfo/python-list
Re: Enumeration idioms: Values from different enumerations
Ben Finney [EMAIL PROTECTED] writes: This gives meaning to the equal value comparisons, but ensures that other comparisons are errors. Comments so far? What does copy.copy of an enumeration value do? What happens if you have a list with some enumeration values inside, and you make a deepcopy of it? What happens if you pickle an enum, then unpickle the pickle and compare what comes out to the other enum? All in all, comparing by object identity doesn't sound too good. Maybe you want to have the enum contain its own name internally, and do a string comparison. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wed Development - Dynamically Generated News Index
[EMAIL PROTECTED] writes: I am building a simple MySQL news database, which would contain, a headline, a date, main story(body) and a graphic associated with each story. I would like to generate an index of the pages in this database ( ie a news index with links to the articles) an to have a news administrator upload and delete stories graphic etc. Why don't you look at Django, which was built for that purpose. -- http://mail.python.org/mailman/listinfo/python-list
