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.
I really will stop now.
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
... 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"
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....
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
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
Point = namedtuple("Point", "x y")
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
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
borbs = [b for b in (compute(orn) for orn in orns) if b > 12]
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.
borbs = list(filter(lambda b: b > 12, map(compute, orns)))
If compute() is a "heavy" function, then the plain loop is the best, although I'd probably use the
borbs = [b for b in map(compute, orns) if b > 12]
construction LoneTech posted earlier.
If it's a small function in a throwaway script then probably just
borbs = [compute(orn) for orn in orns if compute(orn) > 12]
as you posted.
How about something like
from itertools import dropwhile
for i in l:
yield i * 2
borbs = list(dropwhile(lambda b: b <= 12, compute(orns)))
All of what you stated is convention, documentation and community-agreed definition of Pythonic.