tiff/pbm in pyplot (ubuntu)
Does anyone know how to get support for tiff/pbm in pyplot on Ubuntu (11.04)? This used to work for me, on some system, but when I attempt to regenerate my TIFF files on a new system, it all crashes. The error message is clear; TIFF and PBM are not supported, and the exception occurs in a call to imsave(). I know that someone will suggest to use PNG instead, converting with ImageMagick. Trouble is, when I load a grayscale PNG in python I get a 3D array with three colour channels. I need a 2D array, and I'd rather avoid the hassle of modifying all the occurrences to accept a 3D array and check that the colour channels are equal. I'll be grateful for any pointers, TIA -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On 20 May 2011 06:55:35 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : On Thu, 19 May 2011 22:13:14 -0700, rusi wrote: : : [I agree with you Xah that recursion is a technical word that should not : be foisted onto lay users.] : : I think that is a patronizing remark that under-estimates the : intelligence of lay people and over-estimates the difficulty of : understanding recursion. Could we then say that «recursion is a technical word that should not /unnecessarily/ be foisted onto lay users»? -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On 20 May 2011 07:04:27 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : On Fri, 20 May 2011 05:48:50 +0100, Hans Georg Schaathun wrote: : : Either way, the assumption that your system will not be handled by : idiots is only reasonable if you yourself is the only user. : : Nonsense. How do you (generic you, not any specific person) know that : you are not an idiot? You don't, but if you are, you cannot trust any of the other assumptions either, and making this assumption is reasonable by being less of a leap than anything else you have done. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On 19 May 2011 08:47:28 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : The real barrier to cracking Oyster cards is not that the source code is : unavailable, but that the intersection of the set of those who know how : to break encryption, and the set of those who want to break Oyster cards, : is relatively small. I don't know how long it took to break the encryption, : but I'd guess that it was probably a few days of effort by somebody : skilled in the art. : : http://www.usenix.org/events/sec08/tech/full_papers/nohl/nohl_html/index.html In that paper, more than one art seem to have been applied. An open design would have eliminated the need for image analysis and reduced the requirement on hardware/electronics skills. Hence, the obfuscation has made that intersection you talk about smaller, and increased the cost of mounting the attack. As the system was broken anyway, it is hardly a victory for obfuscation, but that's beside the point. The work of that paper is almost certainly more than just «a few days of effort». There are simply to many technical issues to tackle, and they must be tackled one by one. The cost of mounting the attack is to figure out what it takes to do it, before spend the resources barking up the wrong tree. For each successful attack, there probably is a number of failed ones. Thanks for the reference. BTW. That's not the only attack on MIFARE. I cannot remember the details of the other. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Thu, 19 May 2011 10:23:47 -0700, geremy condra debat...@gmail.com wrote: : Let me get this straight: your argument is that operating *systems* : aren't systems? You referred to the kernel and not the system. The complexities of the two are hardly comparable. There probably are different uses of system; in computer security literature¹ it often refers, not only to a product (hardware/software) an actual installation and configuration of that product in a specific context. /I/ did not redefine it. Speaking of reasonable assumptions, one necessary assumption which is particularly dodgy is that whoever deploys and configures it understands all the assumptions and do not break them through ignorance. Is your concern with security purely from a developer's viewpoint, so that you don't have to worry about the context in which it will be deployed? : So what? The levels of assurance have nothing to do with standards. : The levels of assurance refer to the /confidence/ you can have that : the standards are met. : : The increasing levels of assurance don't just signify that you've : checked for problems- it certifies that you don't have them, at least : insofar as that level of testing is able to find. Insisting that this : doesn't, or shouldn't, translate into tighter security doesn't make : much sense. Tighter sure, but the security requirements and the requirement on testing and/or validation are orthogonal scales. The higher levels of assurance are based on formal methods while the lower ones are based primarily on testing. I read your initial comment to imply that if you cannot get satisfactory assurance using the lower levels, you won't get any at the higher levels. That does not make any sense. Obviously, if you were implying that no system passes the lower levels, then of course they won't pass the higher levels, but then, if that's the case, we would all know that we cannot even design /seemingly/ secure systems. And nobody has suggested that so far. ¹ e.g. Dieter Gollmann for just one ref off the top of my head. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Thu, 19 May 2011 17:56:12 -0700, geremy condra debat...@gmail.com wrote: : TL;DR version: large systems have indeed been verified for their : security properties. : (...) : Yup. Nothing is safe from idiots. The difficult part is mapping those properties to actual requirements and threat models. Formal methods do not help on that step. It takes more than a non-idiot to avoid misunderstandings on the interface betweeen professions. Either way, the assumption that your system will not be handled by idiots is only reasonable if you yourself is the only user. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On Thu, 19 May 2011 23:21:30 +0200, Rikishi42 skunkwo...@rikishi42.net wrote: : On 2011-05-18, Hans Georg Schaathun h...@schaathun.net wrote: : Now Mac OS X has maintained the folder concept of older mac generations, : and Windows has cloned it. They do not want the user to understand : recursive data structures, and therefore, naturally, avoid the word. : : You imply they want to keep their users ignorant of these structures, as if : to keep something valuable from them. Wouldn't it be more honest, more to : the point and much simpler to state they don't NEED the user to understand : recursive - or indeed any other - data structures? And that the user doesn't : NEED to understand or know about them, just to use them? Admittedly, my wording had unintended implictions. Mac OS X /targets/ users who do not need to understand the underlying structure. However, the system also has users who do. : After all they are users. They use their system for fun, learning or work. : Even a very competent or advanced use of a tool (computer, car, mobile phone, : fridge, TV, radio, toilet) in no way implies an understanding of it's inner : workings. Nor the need, nor the desire. For a general purpose computer, that is simply not true in general. : PS: Isn't this thread much ado about nothing? :-) Most threads are. : It starts with the misconception (or should I say confusion?) between : performing a recursive job and using a recursive tool to do it. And then it : blazes off in these huge discusions about semantics to define a definition : of an abstraction of a alleady theoretical problem. And explaining the source of the misconception and the varying use would be irrelevant? : And PPS: the P(P)S's don't specifically refer to your posting. Thanks :-) -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Mon, 16 May 2011 23:42:40 +0100, Rhodri James rho...@wildebst.demon.co.uk wrote: : ...which is, of course, not exactly secure either. A sufficiently : determined hacker won't have much trouble disassembling a shared library : even if you do strip out all the debug information. By chance I'm having : to do something closely related to this at work just at the moment; it's : hard, but far from impossible. But then, nothing is secure in any absolute sense. The best you can do with all your security efforts is to manage risk. Since obfuscation increases the cost of mounting an attack, it also reduces risk, and thereby provides some level of security. Obviously, if your threat sources are dedicated hackers or maybe MI5, there is no point bothering with obfuscation, but if your threat source is script kiddies, then it might be quite effective. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On Tue, 17 May 2011 15:26:42 -0700 (PDT), Xah Lee xah...@gmail.com wrote: : If you look at Windows or Mac OS X world, i don't think they ever : refer to dealing with whole dir as “recursive” in user interface. That's purely due to a difference in the level of abstraction. Mac OS introduced its own vocabulary, of folders, where Unix and DOS talked about directories. A folder is a visual element on the screen; exactly modelling a paper folder. It goes without saying that if you bin a folder, the contents goes with it. Anything else would break the model and abstraction. On Unix, the directory is just a file, listing other files by name and disk location. Then it is perfectly natural (although very rarely smart) to delete a directory without any concequences to the contents. The data structure is clearly recursive; a file is either an ordinary file or a directory, and a directory is a list of files. An operation traversing the recursive data structure is recursive regardless of how the algorithm is specified or implemented. A large, although diminishing, fraction of Unix (excluding Mac OS) users are likely to be familiar with the recursive structure of the file system. Now Mac OS X has maintained the folder concept of older mac generations, and Windows has cloned it. They do not want the user to understand recursive data structures, and therefore, naturally, avoid the word. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
[Followup-To: header set to comp.lang.python.] On 17 May 2011 23:42:20 -0700, Thomas A. Russ t...@sevak.isi.edu wrote: : Tree walks are the canonical example of what can't be done in an : iterative fashion without the addition of an explicitly managed stack Of course you can do it. It isn't nice, but it is possible. I assume that you refer to depth first walks, as breadth first is more easily described by iteration on a queue in the first place. Depth first can be achieved by looping over the nodes, with a state keeping references to the current and the previous node considered. By comparing the previous node (pointer or ID) to the current node's parent and children one will know wherefrom the current node was entered, and can choose the next child in the list as the next node, or the parent if all children have been visited. A visit action may be added in any or all times the node is visited. This node requires no stack. The only state space is constant, regardless of the size of the tree, requiring just the two pointers to previous and current. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Wed, 18 May 2011 09:54:30 -0700, geremy condra debat...@gmail.com wrote: : On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun h...@schaathun.net wrote: : But then, nothing is secure in any absolute sense. : : If you're talking security and not philosophy, there is such a thing : as a secure system. As a developer you should aim for it. You think so? Please name one, and let us know how you know that it is secure. : and thereby provides some level of security. : : The on-the-ground reality is that it doesn't. Lack of access to the : source code has not kept windows or adobe acrobat or flash player : secure, and they have large full-time security teams, and as you might : imagine from the amount of malware floating around targeting those : systems there are a lot of people who have these skills in spades. You are just demonstrating that it does not provide complete security, something which I never argued against. : Obviously, if your threat sources are dedicated hackers or maybe MI5, : there is no point bothering with obfuscation, but if your threat source : is script kiddies, then it might be quite effective. : : On the theory that any attack model without an adversary is : automatically secure? No, on the assumption that we were discussing real systems, real threats, and practical solutions, rather than models and theory. There will always be adversaries, but they have limited means, and limited interest in your system. And the limits vary. Any marginal control will stave off a few potential attackers who just could not be bothered. In theory, you can of course talk about absolute security. For instance, one can design something like AES¹, which is secure in a very limited, theoretical model. However, to be of any practical use, AES must be built into a system, interacting with other systems, and the theory and skills to prove that such a system be secure simply has not been developed. Why do you think Common Criteria have not yet specified frameworks for the top levels of assurance? ¹ Advanced Encryption Standard -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
[Followup-To: header set to comp.lang.python.] On 18 May 2011 09:16:26 -0700, Thomas A. Russ t...@sevak.isi.edu wrote: : Well, unless you have a tree with backpointers, you have to keep the : entire parent chain of nodes visited. Otherwise, you won't be able to : find the parent node when you need to backtrack. A standard tree : representation has only directional links. The array representation of a binary tree is standard, and the «back» (parent) pointers are mathematically given. /Some/ standard tree representation do not have parent pointers. You are right that I assumed parent pointers of some description; but it does demonstrate that tree walks can be done iteratively, without keeping a stack of any sort. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
[Followup-To: header set to comp.lang.python.] On Wed, 18 May 2011 20:20:01 +0200, Raymond Wiker raw@RAWMBP-2.local wrote: : I don't think anybody mentioned *binary* trees. The context was : directory traversal, in which case you would have nodes with an : arbitrary (almost) number of children. If we are being specific, then directory trees do have parent pointers. My point was really that «standard tree representations» is not a well-defined concept, and having parent pointers is as standard as not having them. : Except that the chain of parent pointers *would* constitue a : stack. In the sense that the tree itself is a stack, yes. But if we consider the tree (or one of its branches) to be a stack, then the original claim becomes a tautology. But you do have a point. Keeping a stack of nodes on the path back to root is a great deal simpler and cheaper than a call stack, and not really a significant expense in context. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Wed, 18 May 2011 12:07:49 -0700, geremy condra debat...@gmail.com wrote: : I was playing around with an HSM the other day that had originally : targeted FIPS 140-3 level 5, complete with formal verification models : and active side-channel countermeasures. I'm quite confident that it : was secure in nearly any practical sense. And you ostensibly use the word /nearly/ rather than «absolutely». It seems that we agree. BTW, according to the sources I can find quickly, FIPS 140-3 targets /modules/ and not systems. : Ah, my mistake- when you said 'some level of security' I read that as : 'some meaningful level of security'. If you were arguing that it : provided roughly as much protection to your code as the curtain of air : surrounding you does to your body, then yes- you're correct. Well, I didn't. Whether it is meaningful is relative and dependent on the context, but it sure isn't meaningful if any values at stake are. : Empirically this doesn't appear to be a successful gambit, and from an : attacker's point of view it's pretty easy to see why. When a system : I'm trying to break turns out to have done something stupid like this, : it really just ticks me off, and I know a lot of actual attackers who : think the same way. That is very true. It is a very crude measure with a marginal effect on risk. Going out of one's way to try to obfuscate the code as machine code, as was the starting point of the discussion, is surely not a good strategy, as one is then spending significant time to achieve a rather insignificant. My main concern is that the use of absolutes, «you need this», and «that is silly», is drawing attention from the main point. Rather, get to know your risks and focus on the greater ones. Consider possible controls, and choose cheap and effective ones. Even a marginally effective control may be worth-while if the cost is even less. We all seem to agree on the main point; many have argued the same way. As an aside, OTOH, don't you think MAYFARE would have been broken earlier if the source code were open? It was around for ages before it was. : In theory, you can of course talk about absolute security. For : instance, one can design something like AES¹, which is secure in : a very limited, theoretical model. However, to be of any practical : use, AES must be built into a system, interacting with other systems, : and the theory and skills to prove that such a system be secure simply : has not been developed. : : This is flatly incorrect. Which part of it? If you claim that the theory and skills to prove it exist, could you give a reference please? Of course, if you are only thinking of «nearly any practical sense» again, then we agree and always did. : Why do you think Common Criteria have not yet specified frameworks : for the top levels of assurance? : : Perhaps because the lower levels of 'assurance' don't seem to provide very much. If the lower levels do not, would that not be an argument to implement more levels? Too many governments have put too much resources into this to just throw it away if the methodology to achieve higher assurance could be codified. Or maybe it is right to say that the theory and skills do exist, but the money to gather it all in one project to demonstrate the security of a single system does not :-) -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
[Followup-To: header set to comp.lang.python.] On Wed, 18 May 2011 21:09:15 +0200, Raymond Wiker raw@RAWMBP-2.local wrote: : In the sense that the tree itself is a stack, yes. But if we : consider the tree (or one of its branches) to be a stack, then : the original claim becomes a tautology. : : No, the tree is not a stack, but the chain of parent pointers : from a particular node may be considered as a stack that records the : path taken to reach the current node. That is one of its branches, yes, path from root towards leaf. It is part of the data structure, and you don't travers a data structure without using the datastructure. : But you do have a point. Keeping a stack of nodes on the path : back to root is a great deal simpler and cheaper than a call : stack, and not really a significant expense in context. : : For this particular operation, possibly. For other tree : operations, a single parent pointer may not be sufficient. Que? What tree operations do you have in mind? We have covered all the standard textbook tree walks by now. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
[Followup-To: header set to comp.lang.python.] On Wed, 18 May 2011 22:40:28 +0200, Raymond Wiker raw@RAWMBP-2.local wrote: : I said tree operations, not tree walks. A tree operation might : involve several tree walks. OK. The original claim under dispute regarded tree walks. : Further, there has been an implicit : assumption (I think) in this discussion that the order of children is : given, or does not matter - if this is not the case, then you also need : to maintain a stack of data structures representing lists (or sets) of : children. It assumes that there is some canonical ordering on the children. If the tree nodes store their children as sets, where the implementation does not guarantee that they can be retrieved in the same order every time, then it breaks. However, that would be an unusual implementation. The tree has to store the children for each node, one way or another. The only thing I am assuming is that the children can be inspected in the same order every time the node is visited. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: obviscating python code for distribution
On Wed, 18 May 2011 14:34:46 -0700, geremy condra debat...@gmail.com wrote: : Systems can be designed that are absolutely secure under reasonable : assumptions. The fact that it has assumptions does not make your : statement true. : (...) : I can't tell if you're trying to play word games with the distinction : between system and module or if you're just saying that you aren't : sure what FIPS actually certifies. Could you please clarify? The distinction between system and module is rather significant. If you only consider modules, you have bounded your problem and drastically limited the complexity. : Again, I'm unsure what you're going for here. It sounds like you're : saying that obfuscation doesn't provide meaningful security, which is : my point. Meaningful is a relative term, and it is hard to rule out the possibility that meaning can be found in some case. Overall, we agree though. : Are you talking about the Mayfair classical cipher here? I am talking about the system used in public transport cards like Oyster and Octopus. I am not sure how classical it is, or whether mayfair/mayfare referred to the system or just a cipher. Any way, it was broken, and it took years. : The entire field of formal modeling and verification has grown around : solving this problem. My new favorite in the field is formal models : and techniques for analyzing security protocols, but there are other : works discussing OS kernel verification (which has gotten a lot of : attention lately) and tons of academic literature. Google (scholar) is : the place to go. Sure, but now you are considering modules, rather than systems again. It is when these reliable components are put together to form systems that people fail (empirically). : If you can't say with confidence that something meets minimum security : standards, the answer is not to try to say it meets high security : standards. So what? The levels of assurance have nothing to do with standards. The levels of assurance refer to the /confidence/ you can have that the standards are met. : Or maybe it is right to say that the theory and skills do exist, but the : money to gather it all in one project to demonstrate the security of : a single system does not :-) : : Sorry, but again this is not correct. You keep saying that, but whenever you try to back the claim, you keep referring to limited components and not systems at all. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On Thu, 12 May 2011 23:20:20 +1000, Chris Angelico ros...@gmail.com wrote: : Writing a program requires expertise both in programming and in the : purpose for which it's being written. Ultimately, a programmer is a : translator; without proper comprehension of the material he's : translating, he can't make a clear translation. But that's completely : different from hiring someone to do a job, and then looking at the job : afterwards; True. When you are able completely to specify the job and commission it, then it is possible to isolate the disciplines, and reduce the programmer to translator. The challenge is that that very often is not the case. The double challenge in computing is that software its development is still not as well understood as hardware or construction. We still do not have sufficient tools, experience and frameworks to project and precisely plan a software development projects. They go over time, over budget, and under specifications far more often and more seriously than projects in other disciplines. Civil and electronic engineers spend much of their time learning to project and cost solutions. Computer engineers very rarely do; they just hack it. In other trades, there tend to be clear role divisions with different roles and specialisations, complementing eachothers. We have not yet quite managed to work out what a programmer, architect, designer, engineer, et cetera are in software. We have the idea that we need them, but we have not formalised them to the point where we know what to expect from each role, and we struggle communicating between them. Therefore, a programmer is not just a translator. The language to specify precisely what is required is not good enough, and therefor the programmer also needs to be a system designer, to some extent. What extent depends much on the situation. From my point of view, it is just harder to instruct a programmer to write a code than it is to instruct a python interpreter. : if I order a concreting job, I'll look at whether it's : properly suited to the task, but I won't expect an explanation of : exactly what went into it, and I do not expect to understand the exact : chemistry of it. Only another expert in concrete would truly : comprehend it all. Now you are thinking black and white, while reality is a gray blur. You may not care about your concrete, but someone commissioning concrete to build a skyscraper would surely want to check the spec's to quite some level of detail. The construction engineers will surely need to know a lot more about the exact composition and science behind the recipe than the manager renting the top floor, and still much less than the concrete engineer. And the main difference here, is that the civil engineers have a much better language to share information. The best programmers have is the programmming language, and we ought to make that as good as possible. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On 11 May 2011 21:47:27 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : On Wed, 11 May 2011 20:13:35 +0100, Hans Georg Schaathun wrote: : One principle of object oriented programming is to bestow the objects : with properties reflecting known properties from the domain being : modelled. Lists do not have truth values in the application domain : : Yes they do. Empty lists are nothing, ergo false, and non-empty lists are : something, ergo true. What application domain has established that terminology? -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On Wed, 11 May 2011 20:16:01 -0700 (PDT), alex23 wuwe...@gmail.com wrote: : Hans Georg Schaathun h...@schaathun.net wrote: : Revolutionary indeed, so why don't we exploit the revolution : and write the programs to be as accessible as possible? : : Where do you draw the line, though? I said that, as possible. You draw it at the limit of possibility. : No decorators, as they're not intuitively obvious? No custom : descriptors, as that requires a deeper knowledge of Python internals : that utter ignorance allows? When they help clarify or simplify the code, they are good. When they do nothing of the sort, they aren't. : Both of those aspects alone seem far more complex and advanced than : treating empty collections as False. Probably, but they also seem far more useful. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On Thu, 12 May 2011 17:44:07 +1200, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: : Roy Smith wrote: : Hans Georg Schaathun h...@schaathun.net wrote: : If both are numbers, they are converted to a common type. Otherwise, : objects of different types always compare unequal Actually, I did not. :-- hg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On Thu, 12 May 2011 01:49:05 -0400, D'Arcy J.M. Cain da...@druid.net wrote: : That's not programming. That's using a canned app that a programmer : wrote that takes your unstructured input and does something useful with : it. Spreadsheets are a primitive example of that. Google is a more : advanced example. You are really trying to defend the programmers' status as a modern day priesthood, mastering a mystic art completely inaccessible to those not initiated. For ages, the literate elite deliberately made the language cryptic to protect their art and their status. Some programmers seem to do the same. The fact is that it is not black and white. There are programmers with domain expertise, programmers without domain expertise, domain experts with decent programming skills, domain experts with rudimentary programming skills, monolingual programmers, domain experts without programming skills, polyglot programmers etc. Only very narrow-purpose applications can be created by one of these groups on their own, and to collaborate their abilities must be overlapping. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On 11 May 2011 21:42:10 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : *Potentially* different tests. Which is exactly the point. Given an : arbitrary object, the developer doesn't know what test is appropriate. : Should I write len(x) == 0 or list(x) == [] or x.next is None or : something else? How can I tell which is appropriate without knowing : everything about the internals of every object I ever see? Sure, but the question asked was how to check if a /list/ is empty. You defend your answer assuming a different question. You could at least have the decency to change the subject header when you go down that route. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On Wed, 11 May 2011 20:31:45 -0700 (PDT), alex23 wuwe...@gmail.com wrote: : On May 12, 7:24 am, harrismh777 harrismh...@charter.net wrote: : We need to move away from 'canned apps' to a new day where : the masses can sit down to their computer and solve new problems with it : through intuitive language skills. Why not? : : Because the vast majority of them don't seem to want to be bothered? Why does that matter? There is a sizeable group who need computers for purposes not (sufficiently) supported by the `canned apps'. The fact that they are outnumbered by users who really only need typewriters and entertainment theatres does in no way reduce the need of those who actually need /computers/. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On Thu, 12 May 2011 16:46:38 +1000, Ben Finney ben+pyt...@benfinney.id.au wrote: : Hans Georg Schaathun h...@schaathun.net writes: : : On Wed, 11 May 2011 20:31:45 -0700 (PDT), alex23 :wuwe...@gmail.com wrote: : : On May 12, 7:24 am, harrismh777 harrismh...@charter.net wrote: : : We need to move away from 'canned apps' to a new day where : : the masses can sit down to their computer and solve new problems with it : : through intuitive language skills. Why not? : : : : Because the vast majority of them don't seem to want to be bothered? : : Why does that matter? There is a sizeable group who need computers : for purposes not (sufficiently) supported by the `canned apps'. : : Those people, outnumbered by the masses as you say, are thereby not : themselves “the masses”. So what? Do we only need solutions and systems for the masses? What about systems for those who develop systems for the masses? Or the theory necessary to develop the systems to develop more advanced systems for the masses in the future? Get real, software development and programming is more than just overpriced web systems that just almost manage to replicate the functionality of IBM page based terminals and mainframes of 1973, just slower and with more eye candy. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On Thu, 12 May 2011 22:16:10 +1000, Chris Angelico ros...@gmail.com wrote: : Anyone can join. Not everyone wants to join. Me, I'm happy here as a : priest of the software industry, and I have no desire to become a : priest of, say, automotive engineering or concrete pouring. Would an : expert concreter be expected to explain to me exactly how to make : different sorts of concrete, or would he be expected simply to fulfill : his contract and provide me with my structure? Of course he would. When a piece of software to calculate the properties or recipes for different kinds of concrete is needed. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On 07 May 2011 02:51:50 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : On Fri, 06 May 2011 14:57:21 -0700, scattered wrote: : : is there any problem with : : (3) if li == []: : : ? : : Seems to work when I test it and seems to clearly test what you are : trying to test. The only problem might be if in some contexts == has the : semantics of checking for object identity. : : Yes, if li == [] works too. But how do you know li is a list and not some : other sequence type? It says so in the Subject header :-) : The advantage of the if x test is that it is independent of the type of : x. Sure, but the question wasn't ... The problem with 'if x' is that it requires a much more detailed understanding of python. li == [] is as explicit as it gets, and leaves no room for doubt. len(li) == 0 is almost as explicit and much more flexible. Just x is as generic as it gets, but depends on python's convolved rules for duck processing and if you aim at legibility it is better avoided. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On 07 May 2011 02:49:53 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : On Fri, 06 May 2011 16:05:09 -0400, Adam Tauno Williams wrote: : : I'd never accept code like if not x as an empty test. : : So much the worse for you then. : : The point of the if x idiom is that it is a polymorphic test which is : independent of the type. Normally, polymorphisms implies multiple forms only, where the different forms has some form of common interpretation. That's what makes polymorphism useful and helpful, increasing legibility. In this case, the interpretation of an arbitrary object as a boolean is peculiar for python. An empty list is a real, existing object, and the supposition that [] be false is counter-intuitive. It can be learnt, and the shorthand may be powerful when it is, but it will confuse many readers. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On Sat, 07 May 2011 21:57:13 -0700, Ethan Furman et...@stoneleaf.us wrote: : If you're going to use a language, and use it well, you have to learn : how that language works. And if the world evolves around the compiler and you, that advice suffices. However, programming is often as much about developing ideas in a large and complex community, where perfect universal mastery of one language is not an option, because half the community do not normally use that language or aren't really programmers at all. The less you assume about the skill of the reader, the better it is. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On 11 May 2011 13:36:02 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : In this case, the interpretation of an arbitrary object as a boolean is : peculiar for python. : : Incorrect. It is widespread among many languages. Programmers have been : writing conditional tests using arbitrary values since 1958 when Lisp : introduced the concept. The fact that you need to list language by language which objects evaluate as false or equivalent to false illustrates that this has to be learnt language by language. Allowing arbitrary objects is one thing, the particular interpretation is peculiar. The fact that if and while accepts any object for the condition may be chapter 1 stuff, but the memorisation of exactly how the interpretation does not come early (unless you learn it by rote of course). : C, Forth and Visual Basic treat any non-zero number as true, and zero as : false; that's not quite arbitrary objects, but it's arbitrary integer : values. Similarly, Objective C has two different boolean types, BOOL : which is a C char where 0 is false and everything else is true, and : bool which is more like the Java boolean type. Mentioning C, with no Boolean type at all, in this context is a bit absurd. Understanding boolean evaluation in C is very little help when you want to understand it in python. : An empty list is a real, existing object, and the : supposition that [] be false is counter-intuitive. : : Not to me, nor to anyone who has an intuition about something versus : nothing. I believe this distinction is fundamental to the universe, and : that nearly every person understands this intuitively. The distinction : between something and nothing is so strong that it took centuries of : argument for the finest minds in Europe[1] to finally decide that, yes, : zero is a number -- and they only did it because the Arabs and Indians : had proven how useful it was, and Roman numerals really do suck for doing : calculations. Exactly. By now we have gotten past that old-fashioned idea that 0 is not a number. Computer scientists even tend to count 0 as a natural number. When 0 is a number as real and existent as any other, one would think that the empty list is also as real and existent as any other list. : In my experience, it does not confuse newbies or beginners. The only : people it confuses are those who are over-educated into thinking that the : One Correct Way of doing truth testing is with a dedicated boolean type, : and anything else is heresy. What kind of beginners are you talking about? Beginners to python or beginners to programming. The audience I am concerned about is the ones who are over-educated into using and having used a score of different meanings of the same symbols. They will be used to their intuition being wrong when they move into a new context. Being explicit will help them. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On 11 May 2011 12:14:46 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : Not knowing that you can write if x instead of if x == [] is like not : knowing that you can write : : elif condition : : instead of : : else: : if condition My concern was with the reader and not the writer. What could elif mean other than else: if? if x could, for instance, mean if x is defined. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On 11 May 2011 13:45:52 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : Do you think that we should avoid chained comparisons, class methods, : closures, co-routines, decorators, default values to functions, : delegation, doc tests, exceptions, factory functions, generator : expressions, inheritance, iterators, list comprehensions, operator : overloading, properties, regular expressions, tuple unpacking, or unit : tests, to say nothing of *advanced* techniques like descriptors or : metaclasses, just in case the person reading your code is a clueless n00b? Not at all. On both accounts. 1. My concern was not about clueless newbies. They need to learn. My concern is about experienced scientists and engineers who are simply new to python. They will be dealing with a dozen different languages (programming and otherwise), with a need to read more languages than they can possibly learn to master. 2. You should avoid constructs which can /reasonably/ be avoided to /increase/ legibility. Writing if x for if len(x) 0 when you know that x is of some sort of collection type with len defined does nothing to help legibility. Many of the socalled advanced constructs you mention are used to increase legibility one way or another. Others will simply allow functionality which would otherwise be impossible. I don't object to using if x in a case where x may or may not have len() defined. : We routinely and uncontroversially use all of these techniques (well, : sometimes metaclasses get a few raised eyebrows). Truth testing is MUCH : simpler than any of those. Simpler, yes, but it surely depends on more detailed knowledge. One has to remember how the boolean conversion works, for each possible data type. This requires looking up the rules for each data type. E.g. Anyone who has used list/set comprehension in Z, haskell, set theory, or whereever will understand python list comprehension immediately. : It is extremely patronizing to say that we should avoid truth-testing : arbitrary objects because it is too complicated for other people. It's : not hard, and they can learn. Again you miss the point. It is not /too/ complicated. It is /unnecessarily/ complicated. You don't noticeably gain anything by using if x instead of if len(x) 0, if you know that the latter is defined. If everyone who ever needs to see your program is a python programmer, then your approach works as well as mine. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On Wed, 11 May 2011 10:33:51 -0400, D'Arcy J.M. Cain da...@druid.net wrote: : Non-programmers should be able to program? That was not really what I suggested; I was primarily talking about reading programs and commenting on formulæ and algorithms. : Should non-doctors be able to doctor? If I were God, I might consider simplifying the anatomy to allow that, yes. :Should cars be built so that : anyone can intuitively fix them without a mechanic? Should trucks be : built so that drivers don't have to learn how to split shift? That's out of my area so I don't know. However, contrary to software, I have never seen any use of rebuilding the car to do something other than transport ... And, besides, as mechanics do not design cars or even engines, they are not analogous to programmers, but rather to computer technicians (maintenance, deployment, installation, etc). : Why is : programming so different that we can't expect people to actually learn : their discipline? It is not different from other engineering disciplines, where you would have to interact with experts from other disciplines, and understand and comment on their designs. That's the way to build a /system/. Say, you want to create the software to make weather forcasts. At the end of the day, that's programming, but no way that's going to be a task for programmers alone. You need mathematicians, algorithm theorists, physicists, programmers, and multiple specialisations within each discipline. If you can make your programs clear enough to be used as a language of communications, you will simplify the development, and allow the code to be validated by those who knows how the computation has to be done without specialising in talking to the computer. : This discussion is giving me some insight into some of the crap : programming I see these days. I wonder if you would do a better job at programming the software to crack equations from quantum physics than the physicist :-) -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On 11 May 2011 16:26:40 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : 1. My concern was not about clueless newbies. They need to :learn. My concern is about experienced scientists and engineers who :are simply new to python. : : Which makes them clueless newbies *about Python*. I don't care how : experienced they are in astrophysics or biology or calculating the : average airspeed of an unladen swallow. Someone who knows how to program is never clueless starting a new language. Newbie, may be, but he knows most of the constructions and semantic principles to look for; most of it is learning the syntax. : Yeah, life is hard and then you die, and scientists don't even get paid : that much. So what? Do physicists write their scientific papers about : string theory with the thought What if some Python programmer who knows : nothing about string theory is reading this? I better dumb it down. That depends on the purpose of that particular paper, but the real question is, who writes the software to test that string theory empirically? Please tell. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On Thu, 12 May 2011 02:05:21 +1000, Chris Angelico ros...@gmail.com wrote: : In a Bourne shell script, if ends with fi... case ends with esac... so : file would end with... hmm. Yeah, I think it's best to know the : language you're trying to comprehend, and/or actually look at context : instead of shoving a piece of code under someone's nose and saying I : bet you can't figure out what THIS does!. Code is quite often published to document algorithms, methods and formulæ for the purpose of scientific research. Since there is no universal language which suits everything and everyone, this is exactly what happens. One has to have the rudimentary knowledge to read half a dozen different languages to be able to read the code and extract the algorithms. If one tried to maintain the necessary programming skills to exploit all of those languages to their full potential, one would simply not be able to keep up with the application discipline. If all you do is to write software for computer illiterate users, YMWV. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On Wed, 11 May 2011 10:27:49 -0400, D'Arcy J.M. Cain da...@druid.net wrote: : When did we come to the idea that people should be able to program in a : language without actually learning it? The fact that Python comes so : close to that possibility is nothing short of revolutionary. Revolutionary indeed, so why don't we exploit the revolution and write the programs to be as accessible as possible? (Although, python is not the most revolutionary in this respect.) -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On Wed, 11 May 2011 10:31:59 -0600, Ian Kelly ian.g.ke...@gmail.com wrote: : (x + 3 for x in xs if x % 2 == 1) Interesting. Thanks. That might come in handy some time. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On Wed, 11 May 2011 13:50:54 -0400, Prasad, Ramit ramit.pra...@jpmchase.com wrote: : I find this argument to be flawed. Should I stop using built-in : generators instead of range/xrange for looping through lists? : Certainly for loops with loop counting are understood more widely : than generators. Should I stop using any advanced feature Python : because it is difficult to understand without knowing Python? No; I'd suggest the most legible and intuitive construct that /does/ the job. Never something which requires one extra (illegible) page to do the job, or something which does not do the job at all. : I may not have made the point well, but I cannot see any advantage : for trying to program for the lowest common denominator. Common to what? I'd try the lowest common denominator of legibility and effictiveness. It is just KISS. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On Wed, 11 May 2011 14:59:34 -0400, Prasad, Ramit ramit.pra...@jpmchase.com wrote: : Fair enough. I am a sheep, so I do what other (more knowledgeable) : people do. It is a fair assumption (for my specific code writing : environments) that everyone who is going to read my code understands : if x: notation or is expected to learn enough Python to understand it. That's fair enough. You know your code, so it is probably true. It would not be true for the code I am writing. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On Wed, 11 May 2011 12:17:33 -0700, Ethan Furman et...@stoneleaf.us wrote: : 'if li' *is* KISS. It /might/ be in some contexts, but a priori it is not, as it superimposes a truth value on a data type which is otherwise a pretty accurate model of real objects (outside python). One principle of object oriented programming is to bestow the objects with properties reflecting known properties from the domain being modelled. Lists do not have truth values in the application domain, and therefore truth values in the implementation domain is complicated. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: checking if a list is empty
On Wed, 11 May 2011 14:44:37 -0400, Prasad, Ramit ramit.pra...@jpmchase.com wrote: : Someone who knows how to program is never clueless starting a new : language. Newbie, may be, but he knows most of the constructions : and semantic principles to look for; most of it is learning the syntax. : : I claim to be able to program (Java/Python), but would be absolutely : lost programming in Lisp. It is more than just learning the syntax, : it includes a thought paradigm as well. OK. I should written 'how to program imperatively' ... 'new imperative language'. Or substitute functional/logical/whatever for imperative. You would not be completely clueless moving to ada/fortran/C/pascal/simula. There may be new concepts, and some concepts which must be adapted to another level of abstraction, but you do have a clue about the core concepts. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Overuse of try/except/else?
On Tue, 10 May 2011 07:36:42 -0400, Adam Tauno Williams awill...@whitemice.org wrote: : On Mon, 2011-05-09 at 19:40 -0500, Kyle T. Jones wrote: : It has been hard for me to determine what would constitute overuse. : : The chronic problem is under use; so I wouldn't worry much about it. : : try/except should occur as often as is required for the application to : either deal gracefully with the condition or report *meaningful* error : messages to the user/administrator. So overuse is really when you cannot do anything meaningful about the exception. The two interesting questions are really 1. where and when to catch a given exception 2. at what stage of the development cycle catching a particular (class of) exception should become a priority There is a potential overuse of exceptions, where they are used for quite ordinary and frequent (i.e. not exceptional) conditions, and the information could be passed through the return value instead. Exceptions is a very flexible, but also rather expensive means of communications. You can, actually, write any program using raise instead of return. That would be overuse. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Tue, 10 May 2011 14:05:34 + (UTC), Grant Edwards invalid@invalid.invalid wrote: : Because it's easier to communicate if everybody agrees on what a word : means. Why should we agree on that particular word? Are there any other words we agree about? Other key words, such as class, object, or function don't have universal meanings. :-) -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Wed, 11 May 2011 01:27:36 +1000, Chris Angelico ros...@gmail.com wrote: : Language is for communication. If we're not using the same meanings : for words, we will have problems. So if you adopt the word class to mean a type (or composite type), as in python, what word would you use for a class of types (as in haskell or ada)? I think there are too many meanings and too few words ... That's why some languages support overloading. I am afraid we just need to cope with it, overloading I mean. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: scipy
On Sun, 8 May 2011 03:44:06 -0700 (PDT), pb peterthe...@yahoo.com wrote: : I', having trouble with scipy. I have followed the instructions at : scipy website and have installed the following on my mac osx 10.6.6 : (...) : I'm assuming I have the wrong version of something, would that be : right? : Does anyone know how I can fix this? I had the same problem, but assumed that it was more likely to be a bug in the unit tests than a bug anywhere else. But then I mainly use linux boxen to run the stuff, so a bug on the mac installation does not bother me much. Installing software on a mac is just painful. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: vertical ordering of functions
On Tue, 3 May 2011 18:08:27 -0400, Jabba Laci jabba.l...@gmail.com wrote: : I'm just reading Robert M. Martin's book entitled Clean Code. In Ch. : 5 he says that a function that is called should be below a function : that does the calling. This creates a nice flow down from top to : bottom. My advice would be to order it in the same way as you would if you were presenting the algorithm in a paper. From such a viewpoint, it depends on whether you consider the called names to be terms which need definitions, or operations with an intutive purpose, merely requiring an explanation (implentation) of how it is done. In a paper that means that definitions must come before the theorems and lemmata very often between the theorem and its proof. If you don't write papers, that may not be particularly useful :-) In programming, it means that names which have self-explanatory name may very well be called first and defined later. The caller will give a high-level view of what is going on. The callees are building blocks whose purpose can be understood immediately, and whose inner workings can be sought further down the file. Fundamental definitions which may be as easy to implement as explain may often come first. The question here, is didactics and not programming per se. A simple rule does not make complex code significantly easier to read, but a thought structure of the code (with comments and choice of names) over-all does. And let's not forget that calls may be circular or otherwise convolved in a way that does not allow consistent sorting of caller before/after callee. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Sat, 07 May 2011 21:21:45 +1200, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: : You can manipulate them just fine by moving them : from one place to another: : : a = b : : You can use them to get at stuff they refer to: : : a = b.c : a[:] = b[:] Surely you can refer to the objects, but you cannot refer to the reference. : You can compare them: : : if a is b: : ... This could be implemented as pointer comparison, but it is not defined as such and there is no requirement that it be. : That's about all you can do with pointers in Pascal, : and I've never heard anyone argue that Pascal pointers : are any more or less abstract than any other piece of : data in that language. In Pascal a pointer is a distinct data type, and you can have variables of a given type or of type pointer to that given type. That makes the pointer a concrete concept defined by the languagedefined by the language. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Mon, 09 May 2011 12:52:27 +1200, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: : Let me save you from guessing. I'm thinking of a piece of paper with : a little box on it and the name 'a' written beside it. There is an : arrow from that box to a bigger box. : : +-+ :+---+ | | : a | --+| | :+---+ | | : +-+ The flaw of this model, and I am not discounting its merits, just pointing out that it isn't perfect, is that it creates the illusion that references are boxes (objects) just like data objects, leading the reader to think that we could have a reference to a reference. If they are all boxes, by can't we make reference thereto? -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Mon, 9 May 2011 21:18:29 +1000, Chris Angelico ros...@gmail.com wrote: : Analogies are like diagrams. Not all of them are perfect or useful. : : The boxes are different sizes. If you really want them to look : different, do one as squares and one as circles, but don't try that in : plain text. Analogies, even imperfect ones, are good when we are clear about the fact that they are analogies. Using C pointers to illustrate how to use bound names in python may be useful, but only if we are clear about the fact that it is an analogy and do not pretend that it explains it in full. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Wed, 04 May 2011 16:49:25 -0500, harrismh777 harrismh...@charter.net wrote: : Folks seem to think that because they are doing abstraction at a : high-level (well, they never maybe programmed at a lower level) that : abstraction somehow 'requires' a high level language. (not true) I never said 'requires', but when you do high-level modelling, low-level detail is a distraction. Using a low-level language for abstract modelling is therefore harder than it needs to be. : Today, high-level languages like Python (and others) allow programmers : to place some of their abstraction into their source code directly. This : does not make the high-level language any more 'suited' to abstraction : than any other lower-level language; because the abstraction is a mental : process not a language feature. It all ends up in assembly and machine : code. Indeed, except for the contradiction. The fact that you can put more of your abstraction into the source code means that it is better suited to abstraction. Mental processes depend on language; at least when you need to communicate the output. That language does not have to be computer readable (as is the case for your float charts etc). We may very well use a stack of languages and models at different levels of abstraction, but when you move down the stack you are moving away from abstraction and into implementation. C is very rarely suitable at the top of this stack. When I say that C is ill-suited for abstraction, I am not implying that it is ill-suited for implementing according to an abstract model. If you need human input in the lower layers of abstraction, C is a good choice. Using manual work to move down the layers of abstraction is possible, and given sufficient man-power should give the better result, but relying on human input when the work can be automated is ridiculously expensive. Now, python is only one level above C in abstraction, but that's a different matter. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Wed, 04 May 2011 20:11:02 -0500, harrismh777 harrismh...@charter.net wrote: : A reference is a pointer (an address). : : A value is memory (not an address). Sure, and pointers (from a hardware or C perspective) are memory, hence pointers are values. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Thu, 05 May 2011 20:55:36 +1200, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: : It's not clear to me that references are any more abstract : than objects, or to put it another way, that objects are : any less abstract than references. : : After all, in normal Python usage you never actually : *see* an object Sure, but you can refer directly to objects, pass objects around, and refer to individual objects. This is abstract in the sense that it is far removed from the memory representation. However, the concept of a reference appears only when you explain how objects are handled (semantics). You cannot reference nor manipulate a reference in python, and that IMHO makes them more abstract. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Wed, 4 May 2011 02:56:28 -0700 (PDT), Devin Jeanpierre jeanpierr...@gmail.com wrote: : Eh, that example doesn't say what you think it does. It has the same : behavior in C: http://ideone.com/Fq09N . Python is pass-by-value in a : meaningful sense, it's just that by saying that we say that the values : being passed are references/pointers. No, Python is not pass-by-value, because the pointer is abstracted away. You transmit arguments by reference only and cannot access the value of the reference. In C it is pass by value, as the pointer is explicit and do whatever you want with the pointer value. So, even though you have the same mechanism in C and Python, they do not have the same name. In the low-level C you only have pass by value, but you can use the pointer syntax to do whatever you want within pass by value. In the higher-level python, you do not have the flexibility provided by explicit pointers, so you need to explain the semantics without having a pointer concept defined a priori. :This is maybe one level of : abstraction below what's ideal, but Scheme, Java, etc. share this : terminology. (Ruby calls it pass-by-reference AFAIK. Whatever, a rose : by any other name...) Now, this is confusing, because the terminology is not universal and hardly intuitive. What is called transmission by reference in a Simula context (Bjørn Kirkerud's textbook on OO Programming with Simula for instance) is called object sharing in Wikipedia. What Wikipedia calls call by reference is transmission by name in the Simula context. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Wed, 4 May 2011 06:12:14 -0700 (PDT), Devin Jeanpierre jeanpierr...@gmail.com wrote: : I don't think of pass-by-value involving references as being an : implementation-level thing. It's a way of thinking about Python's : behavior: a model. (...) : It isn't particularly contorted. I learned Python this way and it : makes perfect sense. It's just perhaps one level of abstraction away : from the ideal of what some programmers would think in. Python's pass- : by-value conforms exactly to the pass-by-value of other languages : such as C. It is contorted and implementation-level because it is one level below the abstraction assumed by the language. It only works by assuming knowledge of C, which is language which has proved unsuitable for complex and abstract data modelling. Digging down into C should be unnecessary to explain Python. By calling it pass-by-value you introduce a new data type which is unknown to Python, namely the pointer. : The only twist is that you never get to dereference : pointers in Python, but you can in C. Not much of a twist if you ask : me, but then again, I've been thinking in this model for years. Maybe : I'm brainwashed. :) You are. You explain Python in terms of C. That's useful when you talk to other speakers of C. If you want to explain the language to a broader audience, you should use terminology from the language's own level of abstraction. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Wed, 4 May 2011 09:18:56 -0700 (PDT), Devin Jeanpierre jeanpierr...@gmail.com wrote: : I'm a bit uncomfortable with the vibe here. It's one thing for me to : self-deprecatingly suggest I'm brainwashed (with a smile), and another : for you to agree in complete seriousness. I am sorry. It was not meant to be an insult. I do think that you sit tightly in a frame of reference which is obviously not the only one appropriate, and IMNHO not the optimal one for the purpose. Brainwashed was not a word I meant to take seriously. Apologies. I should have cut the C reference too; the same frame of reference could be adopted from any number of languages. Note that it was not the use of references as a concept I objected to, but that they might be passed by value. With the references being purely abstract entities and not data objects, the idea that they have values do not make sense. And pass-by-value where the value is a reference is just confusing. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Thu, 5 May 2011 00:20:34 +1000, Chris Angelico ros...@gmail.com wrote: : Sometimes, to explain Python, you need to dig down to the underlying : hardware - even deeper than C, if you like. Sometimes you may need to narrow down the scope and explain a particular implementation of python with its hardware, OS, and interpreter. However, explaining just python, you do not know what the underlying hardware/OS/interpreter is, and digging down into it is not possible. : And that's always going to : be the way, because abstractions leak from time to time. Or I should : say, they occasionally have confidential briefings with the press. : Abstracting everything perfectly is neither possible nor desirable. Sure, but every language assumes a certain level of abstraction, and when the abstraction breaks the language fails to be unambiguous and/or portable. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Wed, 04 May 2011 14:22:38 -0500, harrismh777 harrismh...@charter.net wrote: : That statement is untrue; evidenced by the very fact the CPython's : complex and abstract data modeling has been very suitably handled by C. That's an implementation. Not modelling. : You cannot possibly mean what you have asserted... I realize there : must be a contextual problem. I have been handling complex data : abstractions with C for more than 20 years... I did not say that it is impossible. On the other hand, you are clearly not talking about abstraction or modelling at all, but rather about computation or data processing. : its quite well suited to : the task... although, I am able to do my research today faster and with : less lines of code in CPython. That does not in any way impugn C..;. : quite the contrary, given enough time, C is better suited for modeling : on a von Neumann processor, period. What has that got to do with abstraction? : Here is the thing that everyone forgets... all we have to work with : is a von Neumann processor. (same as EDVAC, ENIAC, the VIC20, etc). : Assembler is still the best language on that processor. 'C' is still : the best high-level language on that processor. CPython is implemented : in C for a reason: gcc and the von Neumann processor make it a no-brainer. Again, what has that got to do with abstraction? : Its silly to claim that one high-level language or another is better : suited to complex data abstraction... don't go there. : : Digging down into C should be unnecessary to explain Python. : : huh? You have to be kidding. Why do you suppose we want it to be : open-sourced? Python is a /language/. The /implementation/ is may be open-source (and may or may not be written in C). : Use the force Luke, read the source. If you really : want to know how Python is working you *must* dig down into the C code : which implements it. Except that whatever you learn by doing so is only valid for that one interpreter. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Wed, 04 May 2011 14:33:34 -0500, harrismh777 harrismh...@charter.net wrote: : Hans Georg Schaathun wrote: : In C it is pass by value, as the pointer : is explicit and do whatever you want with the pointer value. : : You clearly are not a C programmer. I am not really a programmer period. I am many things and run into programming from many more angles than a typical programmer does. And as to C, I no longer use C when I can avoid it (which I can most but not all of the time). A few words are missing though. C is semantically pass by value. Always. But because you have pointers are data object, you can do whatever you want with them, and pass a pointer by value. Thus you can achieve the effect of transmission by reference or by name, if you want to. : Most of my C data abstractions use dual circular linked lists of : pointers to structures of pointers. *All* of that is only ever passed : (at least in my programming) as references. My code almost never passes : data by value. Not if you do not consider pointers as data, but C does, in the sense that pointers can be manipulated in the same ways as any other kind of data. : We do not consider passing a pointer as *by value* because its an : address; by definition, that is pass-by-reference. We are not passing : the *value* of the data, we are passing the memory location (the : reference) to the data. Pass by *value* on the other hand actually : places the *value* of the data item on the call stack as a parameter. That is a useful viewpoint, but it falls a bit short when you need to explain how to deal with pointers to pointers to pointers. Pointers in C are objects. But mind you, I was not the one to suggested to refer to this as pass by value. I was explaining why it makes more sense to do so for C but not for Python. You simply end up with different wordings if you try to explain how C works, and how to model data in C. We can both be right, you know; we are just addressing the issues at different levels of abstraction. : Much of this conversation has more to do with semantics. Of course. The concepts are used to explain the semantics of the languages. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Wed, 04 May 2011 14:58:38 -0500, harrismh777 harrismh...@charter.net wrote: : True enough. If I used Jython, I would want to take a look at those : sources... as well as the Java sources... which were wrtten in, um, C. And then, suddenly, you'll be developing code which fails on CPython instead of code which fails on Jython. Except that it will still fail on Jython too, unless you happen to have the right jvm. Marvelous. : Oh, yes they are. That is the $10,000,000 dollar problem... how to : extricate ourselves from the von Neumann processor. *Everthing* comes : down to that... its hilarious to hear folks talk about lambda the : ultimate (especially those guys on Lambda the Ultimate) when there is no : such thing until such time as we have lambda the hardware architecture. The problem with your approach is that software development does not scale. Assembly worked very well with a few 100 lines of codes half a century ago. C and friends were a great step forward and reduced the complexity to allow another magnitude of lines of codes. Then came further languages further removed from von Neumann, but close enough to human cognition to handle yet a magnitude or too. Of course you can still gain useful understanding by studying assembly or von Neumann, or the instruction set of the CPU you use. And in some projects it may be an optimal strategy. However, there are many skills necessary to make an efficient system and in many projects assembly and hardware skills are far down the list. Virtualisation is there to the cut costs of rethinking solutions for multiple architectures. If you need to understand the implementation to do your programming, you are in fact disregarding one of the most significant achievements deployed in computing the last two decades. : Not conceptually, but practically. For instance, for a C programmer : to see that Python's object references are C void pointers, tells the : newbie Python ( C programmer ) much about how Python considers : variables... as references... to objects. And of course, this is useful as /one/ way to consider python variables. As long as one is aware that this is just an example, one approach out of many, then it enhances understanding. If one blindly extrapolates from one implementation, it enhances misunderstanding. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Thu, 05 May 2011 15:48:51 +1200, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: : No, it's not. With call-by-name, the caller passes a : small function (known as a thunk) that calculates the : address of the parameter. Every time the callee needs to : refer to the parameter, it evaluates this function. Well, call-by-name is not the same as transmission by name either. Transmission by name is what most posters here call call by reference, and transmission by reference is what this thread calls object sharing or call by object. No wonder I started off confused :-) It is better now. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Fibonacci series recursion error
On 03 May 2011 00:21:45 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : Python aims at acceptable performance (between 10 and 100 times slower : than C) and much easier development (between 10 and 100 times faster than : C *wink*). If that tradeoff doesn't suit you, perhaps Python is not the : language for you. It isn't the trade-off per se which bothers me, but certain features which seem to make compilation harder without making development any easier. But then, it probably depeds on what kind of development you are doing. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Fibonacci series recursion error
On Tue, 3 May 2011 07:56:26 +1000, Chris Angelico ros...@gmail.com wrote: : often recursively. The compiler should generate code the way the CPU : thinks (most optimally), i.e. iteratively. : : The CPU can function iteratively or recursively. I should have said 'hardware' rather than CPU. Iteratively it is not as optimal as the call contexts have to be stored. : But in my opinion, the programmer and the interpreter/compiler are : teammates. If you allow programmers to be stupid, you will get a lot : of stupid programmers writing code. (I think that's one of PHP's : biggest downsides.) If the human and the machine know each other well : enough, the resulting code can be orders of magnitude more efficient : to run, *without taking any more tme to code* because the programmer : already knew the right things to do. There are situations where that team is essential. However, in many more situation, the programmer has to team primarily with domain experts and work with a language in which the domain expert is fluent. The compiler and hardware are slaves of the engineers, and extra staff to team up with the compiler is an added cost and delay. : Perhaps it will take you four hours to read through something, study : it, maybe eyeball the compiler's source code, maybe do some : disassembly. If you have a few years of career ahead of you, you'll : benefit many times over from those few hours, and without spending : extra time, you'll produce better code. THAT is what distinguishes the : master from the novice. That depends on /what/ your career is, and what you need to master. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 01 May 2011 08:45:51 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : Python uses a data model of name binding and call by object (also : known as call by sharing). I trust I don't need to define my terms, but : just in case: Without having the time to get my hand around exactly what this means: Simula has three ways of transmitting arguments, namely transmission by name, by value, and by reference. Is transmission by name the same as call by object? Anyway, I have never seen anyone counting more than three ways of doing this ... -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Tue, 03 May 2011 12:33:15 -0400, Mel mwil...@the-wire.com wrote: : mwilson@tecumseth:~$ python : Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) : [GCC 4.4.3] on linux2 : Type help, copyright, credits or license for more information. : def identify_call (a_list): : ... a_list[0] = If you can see this, you don't have call-by-value : ... a_list = [If you can see this, you have call-by-reference] : ... : my_list = [None] : identify_call (my_list) : my_list : [If you can see this, you don't have call-by-value] This looks like plain old transmission by reference to me. I.e. the functions get a reference to an object and make any change to the object. Since the caller and the callee refer to the same object, changes made by the callee are seen by the caller. However, the reference cannot be changed. With transmission by name, you would get what you call call-by-reference; i.e. the variable passed as an argument is changed to refer to a completely new object. In simula this is used for output parameters. And transmission by value is of course a copy of the data. : so it's neither call-by-value nor call-by-reference as (e.g.) C or PL/I I don't know PL/I; that's the sort of thing my mother deals with. Simula explicitely offerts all three. In C you can get each of the three, by using pointers explicitely in different ways. Whether you use C or Simula, transmission by reference, that is what python appears to be doing, seems to be the normal approach for any composite data type. Thus python does not seem to do anything out of the ordinary at all. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 03 May 2011 15:20:42 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : You get credit for not falling into the trap of thinking there are only : two, call by reference and call by value, but there are *many* more than : just three. Wikipedia lists at least 13: Ah. Those 13 approaches aren't all mutually exclusive though. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Fibonacci series recursion error
On Mon, 2 May 2011 06:49:41 +1000, Chris Angelico
ros...@gmail.com wrote:
: Sure. Serialize this Python object in a way that can be given to, say, PHP:
: foo={asdf:qwer,zxcv:1234}; foo[self]=[1,2,3,foo]
: Recurse from self into the list, recurse from there into a
: dictionary... Okay, that's a rather naive recursion and fraught with
: risk, but there are more complex examples. And watching for cyclic
: references would be O(N*N) as you'd need to maintain a full list of
: every PyObject* that you've sighted (talking here from the C API, but
: the same consideration applies whichever way you do it).
Wouldn't cyclic references give infinite recursion? And remain
infinitive if you recode it iteratively?
: I'm not sure that recursion is clearer. Recursion is a way of
: expressing the two rules:
:
: 1! = 1
: n! = n * (n-1)!
:
: But iteration is a way of expressing this equivalent rule:
:
: n! = 1 * 2 * 3 * ... * n-1 * n
:
: It really depends what you're trying to say.
True. There is a place for everything. However, in the example
above, you can map the recursive definition directly into python
without further ado. In order to express the one-liner in python,
as iteration, you need to introduce additional elements, namely
a state (index variable). Hence, recursion is clearer by being
close to the language you would normally use to describe the
problem.
--
:-- Hans Georg
--
http://mail.python.org/mailman/listinfo/python-list
Re: Fibonacci series recursion error
On 02 May 2011 01:09:21 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : Ah, I see where you're coming from now! You think I'm arguing *against* : the use of recursion. Not at all. Earlier in this thread, I said: Fair enough. Somebody said something about recursion mainly being a beginner's error. I don't think it was you, but I felt that your argument in context mainly served to reinforce such a view, whether intended or not. : Consequently, the naive recursive function is ridiculously slow and : memory-hungry. : : This seems to have give rise to a myth that recursion should be avoided. : What needs to be avoided is *badly thought out* recursion. Then we agree. And badly thought-out iteration is as bad as badly thought-out recursion. : To be honest, I don't know what Python does with local variables. But I : *guess* it uses a constant-sized record which points to the locals, : because that's how I'd do it :) Maybe, but would it be able to treat specially C API functions with a large chunk of stack memory used for local variables? : Given a choice between a complicated iterative algorithm and a simple : recursive version, there's no prima facie reason to expect the recursive : version to *necessarily* be slower than iteration in Python *merely* : because it uses recursion. As always, if speed is an issue, profile and : identify the bottlenecks before deciding how to fix them. Then we are on the same page. And it is becoming increasingly clear how bizarre this discussion is in a python context. The overhead which may be caused by recursion in hardware is only one of many sources of overhead which one accepts when opting to use python in order to gain other benefits. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Fibonacci series recursion error
On 02 May 2011 08:56:57 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : I see your smiley, but there are a number of similar series as Fibonacci, : with the same recurrence but different starting values, or similar but : slightly different recurrences. E.g. Lucas, primefree, Pell, Padovan and : Perrin numbers. Well, Fibonacci isn't one unique sequence. Any sequence satisfying f(n) = f(n-1) + f(n-2) is /a/ Fibonacci sequence. Regardless of starting values. At least according to some authors. Ian Andersen (A First Course in Combinatorial Mathematics) prefer the sequence 1,2,3,5 ... Cormen, Leiserson, Rivest (Introduction to Algorithms) prefer 0,1,1,2, ... (although they also start the indexing at 0). Penguin, Dict. of Mathematics prefer 1,1,2,3,5 but they also suggest 0,1,1,2,3, ... In short, don't assume that a person talking about Fibonacci numbers assume the same base cases as you do. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Fibonacci series recursion error
On Sun, 01 May 2011 18:24:30 -0400, Terry Reedy tjre...@udel.edu wrote: : This does not make linear recursion 'bad', just impractical for general : use on finite-memory machines. While I consider it very useful for : learning, it is unnecessary because it is easy to write an iterative : version. So called tail-recursion optimization saves memory by REMOVING : RECURSION and replacing it with iteration. : (...) : Python does not do this automatically because 1) it can be a semantic : change under some circumstances; 2) one who wants the iterative version : can just as easily write it directly; That's the silliest argument I ever heard. The programmer should write the code the way he and application domain experts think, i.e. very often recursively. The compiler should generate code the way the CPU thinks (most optimally), i.e. iteratively. Of course, I am not saying that one should always model problems recursively, and thus also not that one should implement them recursively. Just that when a model is agreed recursively between the stakeholders, one should get a compiler to do the optimisation, not a programmer. I always thought of python as a step forward, in the way it allows direct expression of so many alternative modes of thinking (imperative, functional, recursion, iterators, etc). If what you say is python philosophy, it is a step backward in requiring the programmer to think more about low-level technical matters which even C has managed to leave for the compiler. :and 3) Python has a better way to : process collections that removes essentially all the boilerplate in the : recursive-call and while-loop versions: -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Fibonacci series recursion error
On 02 May 2011 16:41:37 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : You must be new to the Internet then :) OK. Maybe I heard something worse last time I was an active news users, years ago. Anyway, most of the silly things I hear do not qualify as arguments :-) : The problem is, once you include side-effects, recursion and iteration : are *not* identical. Specifically, the opposition to tail-recursion : optimization in Python is that it plays havoc with the tracebacks you get : in the event of an exception. The argument goes: Thanks for the comprehensive background. I can see the point that python may be harder to optimise correctly during compilation than many other languages. : Regardless of whether you agree with the arguments or not, they're hardly : silly. I only called one argument silly, namely the one about iterative rewriting being so simple that it is not an issue. Sometimes it isn't, but sometimes it is. The other arguments are valid. And they make me lean more towards more static, compiled languages without the excessive run-time dynamism of python. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Fibonacci series recursion error
On Sat, 30 Apr 2011 15:40:24 +0100, Paul Rudin paul.nos...@rudin.co.uk wrote: : Anytime you have enough data... there are plenty of things that are natural to : represent as recursive data structures, and often you don't know in : advance how much data your code is going to have to deal with. Sure, but one would think that if you can fit the data in memory, then you can also fit the call stack. I can also /imagine/ that one might run into a limit, but I cannot see any concrete examples where it is likely. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Fibonacci series recursion error
On 01 May 2011 09:04:27 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : Why? You might have 4000 MB of main memory, and only 2 MB (say?) of call : stack allocated. The call stack can't grow indefinitely. If it does, you : get a stack overflow: Of course you do, but you are still only saying that there might be an application where this might happen because of excessive although logically correct recursion. You have not given a single example where it actually happened. : In Python, the virtual machine protects you against stack overflow. : Before the stack overflows, Python raises RecursionError. You can : experiment by using sys.getrecursionlimit and sys.setrecursionlimit, but : be careful, if you increase the limit too high, a deeply recursive : function will overflow the stack. But the recursion limit is mainly there to protect you against faulty base cases. Obviously, since it measures the number of items on the stack and not their size. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Fibonacci series recursion error
On 01 May 2011 11:56:57 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: : Just google on stack overflow crash. And I get loads of examples of stack overflows, but I could not see anybody linking this to logically correct recursion. Wikipedia, for instance, mentions two common causes, neither of which has anything to do with logically correct recursion. : The Python virtual machine knows how big each entry on the stack needs to : be. (I don't, but it's got to be at least the size of a pointer.) So : number of items is just a multiplication away from size of the items. Does it? In a conventional stack you need to store all the local variables for the function as well. Thus, there is no limit to how much space a single element on the stack may require. : But in principle, any : sufficiently large number of function calls could overflow the stack. : (...) : If you don't like my numbers -- and you probably shouldn't, since I made : them up -- choose your own. But whatever numbers you choose, there *must* : be a maximum number of function calls before the stack overflows. But all of this is in principle, and does not constitute any valid reason to avoid recursion in practice. If you want to argue that recursion is a bad thing in /practice/ you need a /practical/ argument. There is also a limit to how far you can usefully recurse over a limited data structure. : def fact(n): : if n = 1: return 1 : return n*fact(n-1) : : and the theoretical limit above, then fact(250001) will overflow the : stack even though the base case is correct. Of course that will overflow, but you are now trying to calculate an integer of several /million/ bits. Please suggest me a current-day application where you would want to have and also be able to use such a number. There are many ways to crash a system if you want to. But if you don't deliberately try to crash it, you are much more likely to crash it because you allocate to much memory in each step than because the recursion gets to deep. Consequently, because recursion is usually a clearer form of expression than iterative loops, recursion may actually be /less/ dangerous. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Fibonacci series recursion error
On Fri, 29 Apr 2011 23:45:30 -0500, harrismh777 harrismh...@charter.net wrote: : There is much debate about this generally, but general wisdom is that : recursion is to be avoided when possible. That is context dependent at best. You have given reasons to avoid recursion in /executable code/, but that's a compiler issue. You have only given reason /for/ recursion in source code. It generally gives little and very reaadble code. In almost every non-trivial software project, the programmers will be more overworked than the computer, and therefore they are the once to consider when optimising. : Recursion is very tempting to young artists because its a ~cool trick, : and because sometimes it requires very little coding (although huge : amounts of memory!), or as in your case, recursion depth errors. Waste of memory happens only with some types of recursion, and even then it is usually negligible. The recursion depth issue is the result of a flawed base case, and nothing to do with a weakness of recursion. : Anyway, the better way to build a Fibonacci sequence generator is the : following... I have expanded things a bit so that someone not knowing : what the sequence is can see what is happening... you will notice simple : 'for' iterations, and no recursion: And surprisingly difficult to read for such a well-known operation as Fibonacci numbers. If you want to promote iteration, you had better at least try to make it legible. Your code is obviously more efficient in being O(n) whereas OP had (I think) O(2^n), but that's not a property of iteration. You can make a recursive implementation which is O(n). Any undergraduate textbook teaching recursion in any depth is likely to give it as an example; see e.g. Simon Thompson's Haskell book. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Fri, 29 Apr 2011 20:21:58 -0700 (PDT), CM cmpyt...@gmail.com wrote: : While we're on the topic, when should a lone developer bother to start : using : a VCS? At what point in the complexity of a project (say a hobby : project, but : a somewhat seriousish one, around ~5-9k LOC) is the added complexity : of : bringing a VCS into it worth it? You are asking the wrong question. It depends relatively little on the number of lines, and much more on what you are likely to do with it. One thing is certain. If you are ever going to want to use a VCS, you can just as well start yesterday. Using a VCS is not an extra hassle to use. Only an added hassle to get started with. Personally I use the VCS as 1) My backup system; naturally doing incremental backups only. 2) A means to synchronise multiple boxes (not just my laptop and my desktop, sometimes a linux and a mac system, and dedicated number crunchers too), and merge changes made out of synch. 3) The possibility to make one branch to run a suite of jobs which may take a week or more, and still continue development independently on the main branch. As you can see, the number of lines is irrelevant. 1-2 mean that everything is VC-d, not only code for which the VCS is meant. And 3 is of course about what kind of code. I branch rather little. Programming is not my day job -- nor my main hobby, and I simply have not got the capacity to keep track of multiple branches. Even at 12-15kloc I have little use of the VCS for its intended purposes. If you take your development project more seriously, you may do more of that within the first 500 loc... But then, using VCS is not sufficient. You need to /think/ VC. In other words, taking up a VCS when the system is large enough to require it is too late. You need time to learn the thinking. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Fibonacci series recursion error
On Sat, 30 Apr 2011 06:43:42 +0100, Paul Rudin paul.nos...@rudin.co.uk wrote: : Writing recurive code is acceptable and is a nice clear way of : expressing things when you have naturally recursive data structures, and : can lead to perfectly good compiled code. The problem in CPython is the : lack of tail optimization, so it's not a good idea for python . Some : language standards guarantee tail optimization... Well, if you run into a case where tail optimisation really makes a difference, you probably want to reimplement it for a compiler that guarantees tail optimisation, rather than reimplement it without recursion within python. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Fibonacci series recursion error
On Sat, 30 Apr 2011 12:29:00 +0100, Paul Rudin paul.nos...@rudin.co.uk wrote: : Clearly it makes a difference in any case where you'd hit the recursion : limit. What kind of problems make you hit the limit? Other than when you forget the base case, I mean. : It's no big deal to do your own unwinding of the recursion to a : loop, but the code is typically less clear. Sure. And you have to live with your less clear code when you maintain the system later. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] From svn to something else? (was: VCS tools)
Hmmm. I am still using svn. How easy and reliable is it to import my svn version history into one of the three big DVCS-s mentioned here? I am fairly happy with svn, but then I use it more as a backup system and a means to synchronise multiple systems. Something better would not hurt, but loosing the version history would ... I am particularly interested in git, not because of any qualities it may have but because that's what my colleague pushes, and he seems to be pushing our students into it, so it would be useful for me to be familiar with it. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] From svn to something else?
On Fri, 29 Apr 2011 06:50:52 -0500, Tim Chase python.l...@tim.thechases.com wrote: : I'd say that one of the things SVN has going for it is that it's : the lingua-franca of VCSes, so just about everything (especially : the 3 big names mentioned in this thread: hg, bzr, git) can talk : to svn pretty uneventfully. As a matter of fact, last I checked, : Django is hosted in SVN, but most of the developers use DVCS : tools to check in/out from the main repository to their own local : hg/bzr/git repos, do their work locally (with the option to work : offline, branch/merge easily, etc), and then push changesets back : up when they have a patch they're happy with. I am not sure I get the implications right. Are you suggesting that I could keep my svn server, switch to a DVCS client, and reap the benefits? -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Wed, 27 Apr 2011 14:24:30 +0200, Jean-Michel Pichavant jeanmic...@sequans.com wrote: : I was talking about merge *issue* i.e merge resulting in conflicts that : are not easy to solve. With a single user most of the merge will be : solved automatically by any decent VCS. Exactly, and with svn that can be a true nightmare when directories are involved. The rumour is that git handles this much better. I call it a rumour not because I doubt it (I don't), but because I have not seen for myself. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: client-server parallellised number crunching
On Tue, 26 Apr 2011 14:31:59 -0700, geremy condra debat...@gmail.com wrote: : Without knowledge of what you're doing it's hard to comment : intelligently, I need to calculate map( foobar, L ) where foobar() is a pure function with no dependency on the global state, L is a list of tuples, each containing two numpy arrays, currently 500-1000 floats each + a scalar or two. The result is a pair of floats. The foobar() function is sufficiently heavy to merit demonstratably parallellisation. The CPU-s I have available to spread the load further are not clustered. They are prone to crash without warning and I do not have root access. I don't have exclusive use. I do not even have physical access, so I cannot use a liveCD. (They are, however, equipped with a batch queue system (torque).) : but I'd try something like CHAOS or OpenSSI to see if : you can't get what you need for free, if that doesn't do it then try : dropping a liveCD with Hadoop on it in each machine and running it : that way. If that can't work, try MPI. If you've gotten that far and : nothing does the trick then you're probably going to have to give more : details. TANSTAFL :-) There is always the learning curve If I understand it correctly, openSSI requires root access; is that right? For CHAOS I need more details to be able to google; I found a fractals toolbox, but that did not seem relevant :-) MPI I have tried before. Unless there is a new, massively more sophisticated MPI library around now, I would certainly have to do my own code to cope with lost clients. Hadoop sounds intresting. I had encountered it before, but did not think about it. However, the liveCD is clearly not an option. Thanks for the tip; I'll read up on map-reduce at least. :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: client-server parallellised number crunching
On Tue, 26 Apr 2011 23:54:24 -0700, geremy condra debat...@gmail.com wrote: : This sounds like a hadoop job, with the caveat that you still have to : get your objects across the network somehow. Have you tried xdrlib or : the struct module? I suspect either would save you some time. Packing the objects up does not appear as a problem at the moment. Pickled objects work just fine as long as I stick to relatively simple data types and avoid any redundant information from my own data structure. When the CPU-s run a about 85% with a naive com's format, I am not going to waste any time to speed up com's. The problem would occur when a client holding a task crashes. : Hmm. I guess I'd boil it down to this: if you have the ability to : install software on them, give hadoop a try. If, OTOH you can't : disturb normal lab operation at all and need a lot of CPU power, you : should probably start weighing what your time is worth against the : cost of firing up a few EC2 instances and being done with it- I use it : for cryptanalytic work with a similar structure all the time, and you : can get a hell of a cluster going over there for about $15-20 an hour. That is an interesting thought for future work, but with the trial and error I do at the moment, the cost of EC2 would be quite significant, especially when I have so many idle CPU-s at my finger tips. : If you're an academic (it sounds like you are) you may also be able to : use things like planetlab and emulab, which are free and reasonably : easy to use. I am. Based on other answers, I should be able to hack together the necessary error checking to handle lost clients with my current solution using the standard socket and threading API-s. With the added benefit that the familiarity with sockets and threads will be useful for teaching in the foreseeable future. It seems that all the tools you suggest will require much more reading with less potential for reusing the knowledge. It will be very useful when I can commit more resources for a longer period of time, and certainly worth remembering for any fully-funded project in the future. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: client-server parallellised number crunching
On Wed, 27 Apr 2011 11:35:16 +0200, Thomas Rachel nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa...@spamschutz.glglgl.de wrote: : As far as I understand, you acquire a job, send it to a remote host via : a socket and then wait for the answer. Is that correct? That's correct. And the client initiates the connection. At the moment, I use one thread per connection, and don't really want to spend the time to figure out how to do it singlethreadedly. : In this case, I would put running jobs together with the respective : socket in a running queue. If you detect a broken connection, put that : job into the todo queue again. Probably not a queue. Maybe a dictionary. After all I need to look up the job later. : Of course, why not? It might depend on some settings you set (keepalive : etc.); but generally you should get an exception when trying a : communication over a disconnected connection (over a disconnection? ;-)) There are several challenges there and more than one solution. One concern of mine, which is not necessarily justified, is that I do not quite know if I know of all the possible error cases. I suppose your solution works if I run a relatively short timeout on the server and send regular ping messages from the client. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: client-server parallellised number crunching
On Wed, 27 Apr 2011 23:35:06 +1000, Chris Angelico ros...@gmail.com wrote: : On Wed, Apr 27, 2011 at 10:21 PM, Hans Georg Schaathun : h...@schaathun.net wrote: : That's correct. And the client initiates the connection. At the : moment, I use one thread per connection, and don't really want to : spend the time to figure out how to do it singlethreadedly. : : Threads work quite happily in Python if they're I/O bound, which they : will be if they're waiting for the client to do something. Quite. I was referring to some tutorials and documentation recommending to use non-blocking sockets and select() within a single thread. I cannot say that I understand why, but I can imagine the benefit with heavy traffic. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: client-server parallellised number crunching
On Thu, 28 Apr 2011 00:58:22 +1000, Chris Angelico ros...@gmail.com wrote: : thousand threads? a couple of million? In Python, it'll probably end : up pretty similar; chances are you won't be taking much advantage of : multiple CPUs/cores (because the threads will all be waiting for : socket read, or the single thread will mostly be waiting in select()), : so it's mainly a resource usage issue. Probably worth testing with : your actual code. For my own application, the performance issue is rather negligible. I don't have more than about 50 idle CPU-s which I can access easily, and even if I had, it would always stop at 6-7000 functions calls to evaluate. In the current test runs using 4 clients and one master on a quad-core, the master never uses more than around 7% of a core, and that includes some simple post-processing as well as com's. In short, my philosophy is that it works, so why change it? But, I am aware that some more technical adept programmers think otherwise, and I am quite happy with that :-) -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
client-server parallellised number crunching
I wonder if anyone has any experience with this ... I try to set up a simple client-server system to do some number crunching, using a simple ad hoc protocol over TCP/IP. I use two Queue objects on the server side to manage the input and the output of the client process. A basic system running seemingly fine on a single quad-core box was surprisingly simple to set up, and it seems to give me a reasonable speed-up of a factor of around 3-3.5 using four client processes in addition to the master process. (If anyone wants more details, please ask.) Now, I would like to use remote hosts as well, more precisely, student lab boxen which are rather unreliable. By experience I'd expect to lose roughly 4-5 jobs in 100 CPU hours on average. Thus I need some way of detecting lost connections and requeue unfinished tasks, avoiding any serious delays in this detection. What is the best way to do this in python? It is, of course, possible for the master thread upon processing the results, to requeue the tasks for any missing results, but it seems to me to be a cleaner solution if I could detect disconnects and requeue the tasks from the networking threads. Is that possible using python sockets? Somebody will probably ask why I am not using one of the multiprocessing libraries. I have tried at least two, and got trapped by the overhead of passing complex pickled objects across. Doing it myself has at least helped me clarify what can be parallelised effectively. Now, understanding the parallelisable subproblems better, I could try again, if I can trust that these libraries can robustly handle lost clients. That I don't know if I can. Any ideas? TIA -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: De-tupleizing a list
On Wed, 27 Apr 2011 04:30:01 +1000, Algis Kabaila akaba...@pcug.org.au wrote: : I would prefer that to using a ready made module, as it would : be quicker than learning about the module, OTH, learning about : a module may be useful for other problems. A standard dilema... More importantly, list comprehension is very readable to /other/ people. I don't know exactly what the pythonic philosopy is, but when I started using python, more readable and intuitive code was one of the main motivators, and the only one which favours python both over C/java and over Matlab ... List comprehension is understood even by readers with no experience with python. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: client-server parallellised number crunching
On Tue, Apr 26, 2011 at 1:20 PM, Chris Angelico ros...@gmail.com wrote: But question: Why are you doing major number crunching in Python? On your quad-core machine, recode in C and see if you can do the whole job without bothering the unreliable boxen at all. The reason is very simple. I cannot afford the time to code it in C. Furthermore, the work is research and the system is experimental, making the legibility of the code paramount. On Tue, 26 Apr 2011 13:33:25 -0700, Dan Stromberg drsali...@gmail.com wrote: : I'd suggest that rewriting an entire software system in C because of : one inner loop, is overkill. 'better to rewrite just the inner loop : (if needed after profiling), and leave the rest in Python. Well, that's the other reason. The most intense number crunching in this part of the project is basic vector and matrix operations done in numpy. AFAIU that means I use exactly the same libraries underneath as I would have done in C. Please correct me if I am wrong. I could run a profiler and squeeze out some performance by coding another couple of components in C, but I cannot afford the programming time whereas I can afford to waste the CPU cycles. And once I get the client/server parallellisation working, I shall be able to reuse it at negligible cost on other subproblems, whereas the profiling and C reimplementation would cost almost as much time for every subsystem. Does that answer your question, Chris? -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: De-tupleizing a list
On Tue, 26 Apr 2011 13:37:40 -0700, Ethan Furman et...@stoneleaf.us wrote: : Hans Georg Schaathun wrote: : List comprehension is understood even by readers with no experience : with python. : : There's nothing magically understandable about a list comp -- the first : time I saw one (which was in Python), I had to learn about them. Well, there is a first time for everything. For all the other proposals, the first time is bound to be in python. List comprehension is found in many languages, as just list comprehension, and rather quickly comprehensible by analogy to anyone familiar with set comprehension in mathematics. The syntax is slightly different, but python's use of plain English keywords make the transission fairly simple. (-: and I did not say by /all/ readers :-) -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: About threads in python
On Fri, 22 Apr 2011 12:19:56 -0700 (PDT), sturlamolden sturlamol...@yahoo.no wrote: : To optimise computational code, notice that Python itself : gives you a 200x performance penalty. That is much more : important than not using all 4 cores on a quadcore processor. : In this case, start by identifying bottlenecks using the : profiler. Then apply C libraries or these or rewrite to Cython. : If that is not sufficient, you can start to think about using : more hardware (e.g. multithreading in C or Cython). This advice : only applies to computational code though. And not necessarily even there. The extra programmers to recode in C come with more than a 200x cost factor. It is almost trivial to make a multithread map implementation which could have exploited umpteen core box were it not for GIL. That would be a cheap gain. It matters little that you could gain 100x more at 200x cost ... Besides, the bottleneck is likely to be deeply embedded in some library like numpy or scipy already. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
sockets: bind to external interface
Is there a simple way to find the external interface and bind a socket to it, when the hostname returned by socket.gethostname() maps to localhost? What seems to be the standard ubuntu configuration lists the local hostname with 127.0.0.1 in /etc/hosts. (I checked this on two ubuntu boxen, on only one of which I am root.) Thus, the standard solution of binding to whatever socket.gethostname() returns does not work. Has anyone found a simple solution that can be administered without root privileges? I mean simpler than passing the ip address manually :-) TIA -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: sockets: bind to external interface
On Tue, 26 Apr 2011 05:49:07 +1000, Chris Angelico ros...@gmail.com wrote: : You can run 'ifconfig' without being root, so there must be a way. At : very worst, parse ifconfig's output. Of course, but I am not sure that's simpler than the manual solution. Especially since there is more than one version of ifconfig ... : The way you talk of the external interface, I'm assuming this : computer has only one. Is there a reason for not simply binding to : INADDR_ANY aka 0.0.0.0? Ah. That's what I really wanted. Thanks a lot. I wonder why that was not mentioned in the tutorial I used ... -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: sockets: bind to external interface
On Mon, 25 Apr 2011 21:14:51 +0100, Hans Georg Schaathun h...@schaathun.net wrote: : : The way you talk of the external interface, I'm assuming this : : computer has only one. Is there a reason for not simply binding to : : INADDR_ANY aka 0.0.0.0? : : Ah. That's what I really wanted. Thanks a lot. I wonder why that : was not mentioned in the tutorial I used ... Hmmm. socket.INADDR_ANY is an integer and bind insists on a string for the hostname (Python 2.6). Is there any use for the integer constant? 0.0.0.0 does exactly what I wanted though. Thanks again. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: sockets: bind to external interface
On Mon, 25 Apr 2011 23:18:05 +0200, Thomas Rachel nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa...@spamschutz.glglgl.de wrote: : That is right, but I cannot see where he mentions the direction of the : socket. My fist thought was that he tries to have a server socket... Quite right. I thought it was implied by the need to bind :-) Sorry for the lack of detail. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Literate Programming
On Fri, 8 Apr 2011 12:58:34 -0400, Tim Arnold tim.arn...@sas.com wrote: : If you already know LaTeX, you might experiment with the *.dtx docstrip : capability. Hi. Hmmm. That's a new thought. I never thought of using docstrip with anything but LaTeX. It sounds like a rather primitive tool for handling python code, and I would expect some serious trouble getting sensible highlighting in vim/eclim (or most other editors for that matter). But I'll give it a thought. Thanks. : It has some pain points if you're developing from scratch, but I use it once : I've got a system in reasonable shape. Hmmm. I wonder if I am every going to reach that stage :-) : You have full control over the : display and you can make the code files go anywhere you like when you run : pdflatex on your file. If you use docstrip with python, what packages do you use to highlight code and markup programming concepts (methods/classes/variables)? If I may ask ... -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Literate Programming
On Sat, 9 Apr 2011 03:45:55 -0700 (PDT), Jim jim.heffe...@gmail.com wrote: : I'm sorry; I don't understand commenting code within a block but I : wondered if it meant you were not fully familiar with the idea of the : web-type programs. The idea was pretty clear from the web page you cited. The web system allows merging code and doc's within one file, but it does not provide a markup language. Hence I need to find a markup language with suitable markup to go with it. : Before each chunk comes the description of what that chunk does. Sure, and reST does this fine if every chunk is at the same level of indentation, but if I split an indented block with a comment, reST does not preserve the correct indentation. Similarily, if the else clause is in a different chunk from the corresponding if clause, sphinx looses track and will not highlight consistently. I posted an example of what I wanted to do in reply to Robert Kern's post. : Alternatively, I could use pyweb directly with LaTeX. However, then : I would need to find or create macro packages which provide the : features of reST directly in LaTeX. Do you know of a good candidate? : : What features? Standardised and well thought-out markup for functions/methods/classes etc., as well as highlighting. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 vs Java 1.6
On Sat, 9 Apr 2011 01:32:17 +1000, Chris Angelico ros...@gmail.com wrote: : On Sat, Apr 9, 2011 at 1:21 AM, km srikrishnamo...@gmail.com wrote: : How does python 3.2 fare compared to Java 1.6 in terms of performance ? : any pointers or observations ? : : How do apples compare to oranges in terms of performance? My performance is much better for apples, as I do not waste any time peeling. For similar reasons, I get much better performance out of python than I get with Java ... -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Literate Programming
On Thu, 07 Apr 2011 16:21:52 -0500, Robert Kern robert.k...@gmail.com wrote: : http://sphinx.pocoo.org/markup/code.html : : As far as I can tell, it just works. See here for an example: : : http://ipython.scipy.org/doc/nightly/html/interactive/reference.html Maybe I did not express myself clearly. I don't have a problem with highlighting or indentation within a single, complete and continuous block of code. I get trouble when I insert explaining text within nested blocks, especially when I do it at different levels of indentation. In the pages you cite, I cannot find a single example which tries to do this. So something like this is fine: code # This is a long and complex block:: if mytest(): for i in myList(): foobar(i) else: for i in yourList(): boofar(i) /code If I do the following, sphinx cannot keep up ... code # This block should be explained step by step:: if mytest(): # Bla, blah blah... # # :: for i in myList(): # The :func:`foobar` function is an interesting choice here ... blah # # :: foobar(i) # Otherwise, myList might not be defined, so we need yours:: else: # More blah... # # :: for i in yourList(): # And here we go again:: boofar(i) /code Highlighting tends to break starting from `else', and indentation breaks at the second or third level. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Literate Programming
On Fri, 8 Apr 2011 05:22:01 -0700 (PDT), Jim jim.heffe...@gmail.com wrote: : On Apr 7, 2:09 pm, Hans Georg Schaathun h...@schaathun.net wrote: : Has anyone found a good system for literate programming in python? : : Are you aware of pyweb http://sourceforge.net/projects/pywebtool/ ? Interesting tool, but it solves only part of the problem. I could use it as a replacement for pylit, but I would then still have the problem of commenting code within a block, which is a reST/sphinx problem. Alternatively, I could use pyweb directly with LaTeX. However, then I would need to find or create macro packages which provide the features of reST directly in LaTeX. Do you know of a good candidate? -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Literate Programming
Has anyone found a good system for literate programming in python? I have been trying to use pylit/sphinx/pdflatex to generate technical documentation. The application is scientific/numerical programming, so discussing maths in maths syntax in between python syntax is important. While I like the style, there are several things which do not work as they should. One problem is that reST strips the indentation of code. When documentation intersperses nested blocks, it would look better if indentation was preserved so that the semantics of the code is clear in the documentation. Are there any tricks to achieve this in sphinx, or other systems which get it right? Another problem is the the syntax highlighting sometimes get confused. Most of the time, keywords are highlighted, but sometimes they don't. For instance, documentation between if and else in a conditional, seems to prevent sphinx from recognising else. I also have some problems with 'def´ not being recognised, where I have absolutely no clue as to why. Are there any solutions to this? Third problem, when I use automethod to get the docstring prettyprinted, it would be neat if the verbatim docstring definition did not appear as well. Any hints? I am not dead set on keeping pylit/sphinx, although it would be good to minimise the amount of doc code requiring rewriting. The most important thing is to get a working system where I could write a tutorial explaining both the python syntax and the maths of a problem completely unambiguously. TIA -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
