Ah - a true Python believer, huh? So, you'd rather believe that someone who wants to have the freedom to format their own code is a horrendous coder rather than accept that maybe - just maybe - there are real occasion when deviating from the rigid Python rules might actually ADD to the readability of certain kinds of code. I don't doubt that there will be occasions when breaking the rules is ok. But there are very few cases. I have not come across such a case. If you do need to break the rules, you're more likely to be doing something silly and need to rethink your design.
If you were writing code for the Linux kernel, say, you'd follow Linus' style guide, which mandates 8-space indents. Now, if your code had more than five levels of indent such as to become unreadable, would you jump up and down about how the style is no good? Not if you actually want to get your code included. You'd recast some of the inner levels into their own functions, and inline them if you like. This makes the code much more readable. If this is ever a bad idea, it will be clear to the reader why you're breaking the rules. But in general, breaking the rules means you need to rethink your design for readability.
I guess we should never split a string across multiple lines or a function either. What makes you say that? The following ways work great, and are easy enough to follow: foo(bar,
baz) blee = "bl" +\
"uu"
I guess copying and pasting code from a source that doesn't preserve formatting (like, oh say, a web page or e-mail) has never bitten you because indenting wasn't preserved correctly. Sure, but you learn quickly:) some forums don't support pre tags, and some (though few) people use horrible email readers that don't preserve the format of text emails, and you learn quickly when that is the case. For email, most code is sent in a.py/.diff/.tar attachment. If you want to mix comments and code in a forum that doesn't support pre-tags, you can write a 3-liner to convert indents to non-breaking spaces, or whatever format system the forum uses.
The rest of us will go on indenting our Perl/C#/Java/Ruby/C++/whaterver code for readability and practicality and leave the the true belivers in the One-Python-Way to their religion. I've never EVER had someone point me out to anything in PEP-8 that would be better done some other way. If code formatted to PEP-8 is ever unreadable, can you point out what you'd change?
Most people who use Python do use other languages regularly. Many of us write extensions in C/Java/whatever.Net, and many of us enjoy other languages too- I myself use C, Scheme and D daily; but I don't think any of us (who use Python daily, at least) would ever argue that another language would be as easy to read as Python.
The other thing these would be great for is as a GPGPU- open drivers and hooks for libraries such as the GSL could allow visualisation workstations to double as mini-supercomputers after hours.
I doubt any people that actually understand python have had problems in this regard. Cut + paste is not the major coding tool as it is in Java. If you're almost repeating code more than once, you need another level of abstraction. Also, if you're nesting deep enough for the indentation to be a problem, you should be breaking that up into functions.
1 & 3 are horrible. 1 makes the code more difficult to read, 3 gives developers options for formatting, which is a bad idea- have you seen the way some people format?! What you do with code that doesn't leave your bedroom is up to you, you can write your own the-matt-mobile-syntax -> 4-sp-indents converter so you can format however you like, but if I ever have to maintain your code, I will not be happy. Uniformity is a good thing in this respect.
Oh, and as for self, type "import this" and note the second line.
It's actually linked in Andy's follow up of TFA, and written by the brilliant Jonathan Shapiro. He does miss the opportunity, however, to point out to Linus that address spaces need not be exclusive of each other, ie, data sharing is not so difficult to do in most microkernels.
http://www.coyotos.org/docs/misc/linus-rebuttal.html
why not take a leadership role in GNU/Hurd and get that project going, again? The Hurd going along swimmingly, thankyou. They don't have vast Hurds of unix-replacing developers, but they do have people who enjoy what they do and know it inside out.
I doubt Andy would be so interested in the Hurd, he is very much the message-passing fan. He also doesn't like the GPL.
I quite like what Coyotos does here- it treats the memory as one giant disk cache, and includes the pager in the TCB. Maybe not for everyone, but there are pages and pages on how well a similar setup performed in EROS.
Mapping pages requires modifying page tables which is often more expensive than copying. Even if you were correct (strictly speaking, it may be correct on a kernel such as Linux where kernel calls are so expensive), you only have to do it once. Now the driver has almost everything it needs right there in userspace, and writing to the hardware appears no slower than a regular memory write.
Most users do not care so much about implementation details, no. But design details do make many higher level features easier to implement. Things like virtualisation, userspace mount, and the gnome-vfs would have been (or have been) easier and fit more naturally with a system designed on a microkernel. Being able to put together a special file or filesystem in a minute or two and using it immediately without root privileges doesn't mean much on its own to the non-geek, but the things it allows application programmers to do does.
And of course there are people serving web sites, for example, that have different requirements to the typical home user.
Of course, most CAPTCHA that do this make the junk lines a different thickness to the text, which makes them easy to pick out algorithmically. Further, most segmentation-based CAPTCHA can be solved by looking at derivatives of edges of colour and thus continuing the line. Fuzzy-homological methods are probably the way to go with the current round of captcha. The question then will be, how do you fool that kind of algorithm? Perhaps by being creative with colour and texture?
The simple solution is to leave your tabs on a blank line:) I'd believed that an indented block after a blank line was a syntax error- that back-tabbing always closed the block, except when in a parenthesized expression (it does in the REPL). It's probably better for your editor to scream at the practice, not that it helps with code that someone else has written.
You can't just send somebody some Python code in a medium that isn't whitespace-safe. True. I can only think of one example, HTML, and you can always programmatically insert non-breaking spaces in that case. You can do this efficiently in four lines of Python code, or a couple more in elisp when copying to the clipboard.
Indentation preferences vary among programmers, are arbitrary, and some people feel strongly about 4-space, 2 space, tabs, etc. Python uses this as a syntax element and forces everyone working on a particular file to share the same indentation scheme or risk breaking the code. In free-form languages, one guy who forgets to change his 4-space tab into actual spaces isn't going to break things. That's why we have coding standards. The Python world settled upon 4-space indents a long time ago. If you're going to fly in the face of coding standards, expect to have to implement yet another four liner when you want to actually work with anyone.
You can't use brace-matching. You aren't quite clear what you mean on this. If you mean you have no visual indication where a code block ends, you're a retard. Indentation is far easier to vgrep than braces. If you mean you have to think differently to write Python code programmatically, well yes, you do. Thankfully, there are simple libraries that do most of the work for you.
FTFA:
In the background, however, the attacker would have crafted a script that exploited the Firefox vulnerability to redirect the username and password entered by the user to the hacker's server instead of the real deal. Don't allow untrusted sites to run Javascript, of course. This exploit needs scripts enabled in order to post back.
And don't anyone dare say "oh, well they'll 100% protect it so only their code can run" cuz that's not gonna happen. I would like to point you at http://coyotos.org/ , they are putting together a provably secure operating system, which is to say, it can be proven with software whether two objects in the system can interact. Even if the design weirds you out at first, the literature is well worth a look if you're interested in computer security.
[potential flamers: yes, the main Hurd-NG developers were talking about a port to it, it looks very very unlikely. Coyotos development is going swimmingly, but a secure, Free, complete, distributed Unix-like is still but a dream. *goes back to hacking*]
It'd be neato if every government around the world suddenly apologised to all the people they had killed in wars during their existence- I'm sure we've all had relatives lose lives due to the behaviour of some stupid bureaucrats. But would the payout be worth it? What benefit does it bring to the country as a whole?
Frankly, I've got enough things to pay for. My tax dollars already go to enough people on handouts without going to orphans that are (almost always [1]) big enough and ugly enough to look after themselves.
And after all, I'm not sorry. I didn't do anything wrong. The rest of Australia didn't do anything wrong. If you think making up for the injustice is that important to you, start a fund. There are better places my tax money can go. [Admittedly, not where it's going now.]
[1] Which brings up the real issues, including child abuse and mental trauma associated with the stolen generation. But a *blanket* handout, which is what will happen, won't help anyone.
Python does not get the benefit of syntactical sugar purely for the purposes of matrix manipulation- for example, matrix multiplication in scipy/numpy is a = matrixmultiply(b,c). However, Python is far more powerful (especially with libraries such as scipy) and simple to use in general, and in any real world application it makes a big difference. Python is the sort of language you don't actually have to think about- you think about the problem rather than how to solve it using the pathetic set of matlab tools. It's really more on par with Mathematica in terms of power and simplicity of code (albeit without symbolic manipulation, which is where Mathematica shines- but then there's always Sage;-).
Two reasons. Fencepost error?:)
I have spent the last 13 years writing matlab code There are a lot of people like you, and of course that is the point. I avoid matlab where I can, but considering the sheer number of lines of matlab code used in industry, you can't be rid of it completely. Besides, if your office is using matlab, you usually have little choice besides Octave and Matplotlib.
It is especially good at writing vectorized code without having to think about it too much. Well, that's a good point. Python as a language does not have any inherent problem that prevents it from doing those sorts of optimisations in the background, but none of the current implementations do. They have all been written from a single threaded point of view (see discussions on the Global Interpreter Lock for the C Python case).
However, if you're using Numpy, the situation isn't so dire. It uses the system's math libraries for matrix manipulation among other things, so only these need to be parallelised (as they do for FORTRAN or C code, so they almost always are).
If you are trying to parallelize a section of code, having a routine mess with array values through pointers renders the code unparallelizable [sic]. Actually, that's usually the only way to write parallel code in C:) but you are right, that means it needs to be written to be parallel explicitly.
I should also point out that it is very easy to get FORTRAN and C to play nice with Python, often easier than writing more FORTRAN or C code.
Slashdot Mirror
If you were writing code for the Linux kernel, say, you'd follow Linus' style guide, which mandates 8-space indents. Now, if your code had more than five levels of indent such as to become unreadable, would you jump up and down about how the style is no good? Not if you actually want to get your code included. You'd recast some of the inner levels into their own functions, and inline them if you like. This makes the code much more readable. If this is ever a bad idea, it will be clear to the reader why you're breaking the rules. But in general, breaking the rules means you need to rethink your design for readability. I guess we should never split a string across multiple lines or a function either. What makes you say that? The following ways work great, and are easy enough to follow:
foo(bar,
baz)
blee = "bl" +\
"uu" I guess copying and pasting code from a source that doesn't preserve formatting (like, oh say, a web page or e-mail) has never bitten you because indenting wasn't preserved correctly. Sure, but you learn quickly
Most people who use Python do use other languages regularly. Many of us write extensions in C/Java/whatever.Net, and many of us enjoy other languages too- I myself use C, Scheme and D daily; but I don't think any of us (who use Python daily, at least) would ever argue that another language would be as easy to read as Python.
The other thing these would be great for is as a GPGPU- open drivers and hooks for libraries such as the GSL could allow visualisation workstations to double as mini-supercomputers after hours.
No doubt that guy with the drum kit made of buckets on the corner of Swanston and LaTrobe is giving them a run for their money.
I doubt any people that actually understand python have had problems in this regard. Cut + paste is not the major coding tool as it is in Java. If you're almost repeating code more than once, you need another level of abstraction. Also, if you're nesting deep enough for the indentation to be a problem, you should be breaking that up into functions.
1 & 3 are horrible. 1 makes the code more difficult to read, 3 gives developers options for formatting, which is a bad idea- have you seen the way some people format?! What you do with code that doesn't leave your bedroom is up to you, you can write your own the-matt-mobile-syntax -> 4-sp-indents converter so you can format however you like, but if I ever have to maintain your code, I will not be happy. Uniformity is a good thing in this respect.
Oh, and as for self, type "import this" and note the second line.
It's actually linked in Andy's follow up of TFA, and written by the brilliant Jonathan Shapiro. He does miss the opportunity, however, to point out to Linus that address spaces need not be exclusive of each other, ie, data sharing is not so difficult to do in most microkernels.
http://www.coyotos.org/docs/misc/linus-rebuttal.html
I doubt Andy would be so interested in the Hurd, he is very much the message-passing fan. He also doesn't like the GPL.
I quite like what Coyotos does here- it treats the memory as one giant disk cache, and includes the pager in the TCB. Maybe not for everyone, but there are pages and pages on how well a similar setup performed in EROS.
Most users do not care so much about implementation details, no. But design details do make many higher level features easier to implement. Things like virtualisation, userspace mount, and the gnome-vfs would have been (or have been) easier and fit more naturally with a system designed on a microkernel. Being able to put together a special file or filesystem in a minute or two and using it immediately without root privileges doesn't mean much on its own to the non-geek, but the things it allows application programmers to do does.
And of course there are people serving web sites, for example, that have different requirements to the typical home user.
You can provide the kernel interface from a userspace daemon and virtualise the remaining few instructions = instant backward compatibility.
Of course, most CAPTCHA that do this make the junk lines a different thickness to the text, which makes them easy to pick out algorithmically. Further, most segmentation-based CAPTCHA can be solved by looking at derivatives of edges of colour and thus continuing the line. Fuzzy-homological methods are probably the way to go with the current round of captcha. The question then will be, how do you fool that kind of algorithm? Perhaps by being creative with colour and texture?
The simple solution is to leave your tabs on a blank line :) I'd believed that an indented block after a blank line was a syntax error- that back-tabbing always closed the block, except when in a parenthesized expression (it does in the REPL). It's probably better for your editor to scream at the practice, not that it helps with code that someone else has written.
What are you talking about? A handful of idiomatic lambda uses have largely been replaced, sure, but lambda is still pretty common in Python code.
I feel silly that I would have bought one if I knew the HURD would run on it.
[potential flamers: yes, the main Hurd-NG developers were talking about a port to it, it looks very very unlikely. Coyotos development is going swimmingly, but a secure, Free, complete, distributed Unix-like is still but a dream. *goes back to hacking*]
Ah, I see your point went right over my head.
I'm not really convinced, but it doesn't make a lot of difference now- at least it will be over and done with.
It'd be neato if every government around the world suddenly apologised to all the people they had killed in wars during their existence- I'm sure we've all had relatives lose lives due to the behaviour of some stupid bureaucrats. But would the payout be worth it? What benefit does it bring to the country as a whole?
Frankly, I've got enough things to pay for. My tax dollars already go to enough people on handouts without going to orphans that are (almost always [1]) big enough and ugly enough to look after themselves.
And after all, I'm not sorry. I didn't do anything wrong. The rest of Australia didn't do anything wrong. If you think making up for the injustice is that important to you, start a fund. There are better places my tax money can go. [Admittedly, not where it's going now.]
[1] Which brings up the real issues, including child abuse and mental trauma associated with the stolen generation. But a *blanket* handout, which is what will happen, won't help anyone.
I concur- big, bright lights and shiny surfaces. I hope it's not his OWN retina that he's mapping.
The short answer is yes.
;-).
Python does not get the benefit of syntactical sugar purely for the purposes of matrix manipulation- for example, matrix multiplication in scipy/numpy is a = matrixmultiply(b,c). However, Python is far more powerful (especially with libraries such as scipy) and simple to use in general, and in any real world application it makes a big difference. Python is the sort of language you don't actually have to think about- you think about the problem rather than how to solve it using the pathetic set of matlab tools. It's really more on par with Mathematica in terms of power and simplicity of code (albeit without symbolic manipulation, which is where Mathematica shines- but then there's always Sage
However, if you're using Numpy, the situation isn't so dire. It uses the system's math libraries for matrix manipulation among other things, so only these need to be parallelised (as they do for FORTRAN or C code, so they almost always are). If you are trying to parallelize a section of code, having a routine mess with array values through pointers renders the code unparallelizable [sic]. Actually, that's usually the only way to write parallel code in C
I should also point out that it is very easy to get FORTRAN and C to play nice with Python, often easier than writing more FORTRAN or C code.
Their first ".", which is surprising as MP3 is already 16 years old- but I guess everyone is different.