The UK used to pay 17/18 year olds a small stipend (£30/week IIRC) for attending college, this was during the mid-90s to mid-00s when it was abolished by the Tories. Attendance rates climbed when it was introduced and dropped after it was abolished.
Not actually true, as Aero uses your graphics card to do the compositing, whereas the older desktop renderer was entirely CPU-based. Disabling Aero just means more work for your CPU.
When first announced here Rust looked very interesting, with some bold ideas for making programs better in the lower-level problem domain. Since then it's been under tons of development and community vigour, version 1 looked very different to 0.0.1, I need to reinvestigate!
The final switch seems like it would be a useful construct. Python doesn't really have good Enums unfortunately, just some approximations such as using namedtuple._make(). Whereas in CoffeeScript you can assign the result of an if-else block to a variable, which allows for silly conditionals always a potential:)
Well yes, but if we were Perl programmers, we'd have just both been telling jokes at each other while trying to work out what was supposed to be funny about the other's joke.
If we were PHP programmers we'd have got the punchline and the setup in the wrong order, and be getting confused over all of the similar sounding jokes that aren't funny, but never seem to go away.
If we were JavaScript programmers we'd be on StackOverflow, asking for the best joke ever and a word-by-word explanation of why it was funny.
My view is that Python is an imperative language that is moving towards functional programming - much like both Ruby and JavaScript it's never going to get there, but it's a definite shift from when I started coding it at version 1.5, and IMO it's much cleaner to consider code as a series of transforms of varying kinds than a grab bag of tools.
I suspect switch lost out due to the C-style switch-with-fallthrough and "clever" shenanigans like Duff's Device that can make them anything but obvious what's going on, and back in 1991 avoiding that probably looked like a good idea for an easy to learn language. I once worked on an application that's core consisted of a 3,000 line switch statement for handling messages, with both fall-through all over the place, and parts of it callled back into itself in what may have been an attempt at code re-use, but was probably just as stupid as it looked... *shudder*
I like Coffeescript's switch, but that's partly because I like having every construct being an expression, removing an element of the code/data divide.
Wait until you see my new triple-underscore magic methods! That's 50% more magic, and you can see their jutting prows standing firmly erect within your code.
... Python list comprehensions are not perfect and are useful only for the most common cases.
I'm sure that Guido weeps himself to sleep every night knowing that this feature is only useful for 90% of use cases and not 100%;)
Sure they're not perfect, but as you say they work for most cases and when they don't they're easy to replace with your customised solution - perfect is the enemy of better, and list comprehensions definitely make Python "better":)
True, but you can generally get by with learning one way while learning, then expand options later. For a lot of Python IMO the complexity is very well-hidden from a beginner, and little things like the help() and dir() functions make life easier.
Couldn't live without IPython now though, I've been totally spoilt by auto-call, ? and ??, the history tools, the ed command, etc etc....
After three days of watching them argue I finally resolved the issue by dropping a few convenience methods and replacing the class with a NamedTuple.
Ah, the namedtuple, love that type, makes small property bags simple and efficient, and yet you still go nuts and sub-class it if you really have to:) Can't remember what I did before it appeared - write a lot more classes, most likely.
*checks*
Looking at my user-site directory, apparently write my own Properties class - actually, three different classes for some reason, all slightly different and way more complicated than the namedtuple:)
My only niggle is the declaration syntax with the redundant type name
I think I know what you mean - once you get "under the hood" there really are ways to customise everything. Metaclasses, abstract base classes, descriptors, descriptors, context managers, types, properties... all on top of plain-old multiple inheritance;) It does take some time and restraint to not go meta-overboard - if I feel myself doing it, I just remember (trying to) work with Zope, which takes this sort of thing to a ridiculous extreme.
All that stuff came way later though, for going from zero to code Python is pretty simple - you don't need all that stuff for 98% of use cases.
All of what you stated is convention, documentation and community-agreed definition of Pythonic.
My point was that it's not just the community of people using Python, but that it's also part of the community of people who design Python, and has been from the start. The latter feeds into the former, and then vice versa, and without both sides you end up with at best where JavaScript is today - intense focus on making code better, but every single avenue has multiple options and you end up with a bewildering array of choices.
It's both. Type import this from the interpreter, and you'll get this:
The Zen of Python, by Tim Peters
Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
While it doesn't always manage it, if you read the discussions and PEPs relating to the language's design it's clear that the idea of a "Pythonic" way of doing things is one of the top considerations.
Sure it won't be quite the unanimity it was before, but the few dissenters won't prevent it from being renewed again. Only one Republican voted for this bill, most of them were loudly against weakening the PATRIOT Act in any way; come renewal time they'll extend it for another five years happily.
Why would you assume that it will go any differently in 2015 than it did in 2005, 2006 and 2011? The Republicans came out against this bill with accusations that it would help ISIS and risk another 9/11, and when the time for renewal is up in May (not January as I said), they will be in control of both houses and looking towards the primaries and the election after that - they're not going to let it expire
I don't see any chance that it won't be renewed. I'm sure there will be lots of drama, name-calling and stirring speeches, but in the end, little or no substantive changes to the act itself, and it will be 2020 before all this comes up again.
It extended 3 out of 100 provisions of the PATRIOT Act until 2017. And actually, the vote was to put it up for discussion and amendment, so it could have been possible to get rid of that.
Now the entire act will be renewed in January, all 100 provisions. Not a win.
But it's easier to parse HTML5 than it was any previous version of HTML, as there is now an actual specification which details the process exactly rather than relying on each browser's interpretation. It can't be that difficult given the number of working parsers and validators out there for HTML5.
If you need to store validated documents, then you shouldn't be storing them in HTML format! Store them as XML documents with well-defined schemas (Relax NG of course!), and then use XSLT or possibly XQuery to turn them into HTML fragments for display.
You won't get them if your karma is too high or too low, or if you browse/. too often or too infrequently. Possibly also if you post often enough you won't get them either, there are a few different factors. I went years getting none, now I get 5 points every five or six days, and occasionally 15 points instead.
Slashdot Mirror
The UK used to pay 17/18 year olds a small stipend (£30/week IIRC) for attending college, this was during the mid-90s to mid-00s when it was abolished by the Tories. Attendance rates climbed when it was introduced and dropped after it was abolished.
Not actually true, as Aero uses your graphics card to do the compositing, whereas the older desktop renderer was entirely CPU-based. Disabling Aero just means more work for your CPU.
Fucking PermGen space. It's like they've specifically added a setting that's nothing more than a ticking time bomb, just to keep people on their toes.
Thank you, I'm late enough for work as it is :)
Nothing for the Java devs here I see. Because there's nothing funny about Java. It's just stolid and lumpen.
When first announced here Rust looked very interesting, with some bold ideas for making programs better in the lower-level problem domain. Since then it's been under tons of development and community vigour, version 1 looked very different to 0.0.1, I need to reinvestigate!
The final switch seems like it would be a useful construct. Python doesn't really have good Enums unfortunately, just some approximations such as using namedtuple._make(). Whereas in CoffeeScript you can assign the result of an if-else block to a variable, which allows for silly conditionals always a potential :)
Well yes, but if we were Perl programmers, we'd have just both been telling jokes at each other while trying to work out what was supposed to be funny about the other's joke.
If we were PHP programmers we'd have got the punchline and the setup in the wrong order, and be getting confused over all of the similar sounding jokes that aren't funny, but never seem to go away.
If we were JavaScript programmers we'd be on StackOverflow, asking for the best joke ever and a word-by-word explanation of why it was funny.
I really will stop now.
My view is that Python is an imperative language that is moving towards functional programming - much like both Ruby and JavaScript it's never going to get there, but it's a definite shift from when I started coding it at version 1.5, and IMO it's much cleaner to consider code as a series of transforms of varying kinds than a grab bag of tools.
I suspect switch lost out due to the C-style switch-with-fallthrough and "clever" shenanigans like Duff's Device that can make them anything but obvious what's going on, and back in 1991 avoiding that probably looked like a good idea for an easy to learn language. I once worked on an application that's core consisted of a 3,000 line switch statement for handling messages, with both fall-through all over the place, and parts of it callled back into itself in what may have been an attempt at code re-use, but was probably just as stupid as it looked... *shudder*
I like Coffeescript's switch, but that's partly because I like having every construct being an expression, removing an element of the code/data divide.
Wait until you see my new triple-underscore magic methods! That's 50% more magic, and you can see their jutting prows standing firmly erect within your code.
Lol, it looks like i posted that anonymously in shame, rather than forgetting to login :)
I'm sure that Guido weeps himself to sleep every night knowing that this feature is only useful for 90% of use cases and not 100% ;)
Sure they're not perfect, but as you say they work for most cases and when they don't they're easy to replace with your customised solution - perfect is the enemy of better, and list comprehensions definitely make Python "better" :)
Use a generator function for mid instead, then values will only be pulled out one-by-one as needed.
True, but you can generally get by with learning one way while learning, then expand options later. For a lot of Python IMO the complexity is very well-hidden from a beginner, and little things like the help() and dir() functions make life easier.
Couldn't live without IPython now though, I've been totally spoilt by auto-call, ? and ??, the history tools, the ed command, etc etc....
Ah, the namedtuple, love that type, makes small property bags simple and efficient, and yet you still go nuts and sub-class it if you really have to :) Can't remember what I did before it appeared - write a lot more classes, most likely.
*checks*
Looking at my user-site directory, apparently write my own Properties class - actually, three different classes for some reason, all slightly different and way more complicated than the namedtuple :)
My only niggle is the declaration syntax with the redundant type name
which just looks ripe for danger lol.
I think I know what you mean - once you get "under the hood" there really are ways to customise everything. Metaclasses, abstract base classes, descriptors, descriptors, context managers, types, properties... all on top of plain-old multiple inheritance ;) It does take some time and restraint to not go meta-overboard - if I feel myself doing it, I just remember (trying to) work with Zope, which takes this sort of thing to a ridiculous extreme.
All that stuff came way later though, for going from zero to code Python is pretty simple - you don't need all that stuff for 98% of use cases.
That is something that would be a nifty construct. About the closest I can think of off the top of my head is using a nested generator expression
Which isn't too awkward IMO, it's pretty clear there's two stages: a map and then a filter, and it's more readable than e.g.
It depends :)
If compute() is a "heavy" function, then the plain loop is the best, although I'd probably use the
construction LoneTech posted earlier.
If it's a small function in a throwaway script then probably just
as you posted.
How about something like
My point was that it's not just the community of people using Python, but that it's also part of the community of people who design Python, and has been from the start. The latter feeds into the former, and then vice versa, and without both sides you end up with at best where JavaScript is today - intense focus on making code better, but every single avenue has multiple options and you end up with a bewildering array of choices.
It's both. Type import this from the interpreter, and you'll get this:
While it doesn't always manage it, if you read the discussions and PEPs relating to the language's design it's clear that the idea of a "Pythonic" way of doing things is one of the top considerations.
Oooh, I know this one. It's about Cultural Marxism, amirite?
Sure it won't be quite the unanimity it was before, but the few dissenters won't prevent it from being renewed again. Only one Republican voted for this bill, most of them were loudly against weakening the PATRIOT Act in any way; come renewal time they'll extend it for another five years happily.
Why would you assume that it will go any differently in 2015 than it did in 2005, 2006 and 2011? The Republicans came out against this bill with accusations that it would help ISIS and risk another 9/11, and when the time for renewal is up in May (not January as I said), they will be in control of both houses and looking towards the primaries and the election after that - they're not going to let it expire
I don't see any chance that it won't be renewed. I'm sure there will be lots of drama, name-calling and stirring speeches, but in the end, little or no substantive changes to the act itself, and it will be 2020 before all this comes up again.
It extended 3 out of 100 provisions of the PATRIOT Act until 2017. And actually, the vote was to put it up for discussion and amendment, so it could have been possible to get rid of that.
Now the entire act will be renewed in January, all 100 provisions. Not a win.
But it's easier to parse HTML5 than it was any previous version of HTML, as there is now an actual specification which details the process exactly rather than relying on each browser's interpretation. It can't be that difficult given the number of working parsers and validators out there for HTML5.
Plus, HTML5 can already be written using XML syntax, aka XHTML5. And searching for xhtml5.xsd or xhtml5.rng gave me plenty of links to schemas for validating XML-syntax HTML5.
If you need to store validated documents, then you shouldn't be storing them in HTML format! Store them as XML documents with well-defined schemas (Relax NG of course!), and then use XSLT or possibly XQuery to turn them into HTML fragments for display.
You won't get them if your karma is too high or too low, or if you browse /. too often or too infrequently. Possibly also if you post often enough you won't get them either, there are a few different factors. I went years getting none, now I get 5 points every five or six days, and occasionally 15 points instead.
Engineers are also more likely to be Creationists than those in other careers requiring a degree.