I'm curious, on the Currying (Standard Library) slide, the author uses `attrgetter` from the `operator` module -- I've always used `getattr` to achieve the same thing. Am I missing something by not using `attrgetter`?
In [1]: from operator import attrgetter
In [2]: class Person:
...: def __init__(self, name):
...: self.name = name
...:
In [3]: me = Person('walrus')
In [4]: getattr(me, 'name')
Out[4]: 'walrus'
In [5]: attrgetter('name')(me)
Out[5]: 'walrus'
This is potentially useful if you're using `map`:
In [6]: people = [me, Person('aschwo')]
In [7]: list(map(lambda obj: getattr(obj, 'name'), people))
Out[7]: ['walrus', 'aschwo']
In [8]: list(map(attrgetter('name'), people))
Out[8]: ['walrus', 'aschwo']
Really, though, the functional programming idioms don't meld too well with Python. I think this is a lot nicer:
In [9]: [person.name for person in people]
Out[9]: ['walrus', 'aschwo']
On the last point, a list comprehension is just a much a functional programming idiom--Python got them from Haskell! I use both in my code, whichever is shortest.
PS: map returns a list, no need to call list() on it.
attrgetter takes an attribute name and returns a function that, when passed an object, returns that attribute from that object. So it's a curried getattr. These are equivalent:
Having worked on node-graph UIs in the past and used software that relies on this metaphor, it's a dangerous thing to not build in undo/redo support. It's too easy to delete an edge, and spend a bunch of time trying to redo your work. That really pisses off users.
Also, not giving the edges of the graph a direction is a problem -- it's hard to quickly grasp what the 'result' node should be. Ditto for not using fixed-position plugs on the nodes: input plugs should be at the top, outputs at the bottom (or left and right).
In the end, I'm not sure who this is for: if you just want to click a button to deploy some services, it's doubtful that you'll want to muck around with wiring up nodes; and if you're putting these packages together, it'll probably be faster to just use a text editor.
Or is there a tool that needs to be created that will compile a fragment shader for WebGL down to .js, kind of like CoffeeScript?
Now all you need is for someone to write an OpenEXR implementation in JS or WebKit and you'll have all you need to build a Nuke killer in the browser. Well, you'll still need the UI framework for the node graph.
This is a great development for decoding ProRes with non-OSX OSes. What are the legal implications? Will ffmpeg need to pay to license the ProRes codec from Apple? Does Apple even offer a license for the codec?
- if ffmpeg [developers] were overly scared about even remote risks of being sued, they'd stop.
- if ffmpeg [developers] wanted to abide by the law, they'd have to stop.
and the second interpretation is quite unfair IMHO.
I meant it both ways, however the second interpretation is really only true under US law. A lot of parties would want a lot of money to license things, how would they pay?
Windows is read only (although clipster somehow manages to write out prores files). There are two licensed products (hardware) that write out prores that I am aware of - ARRI Alexa cameras and AJA ki pro.
Exactly! If they had done this before killing off Shake, I bet we'd still have a half decent competitor to Nuke in the high end compositing space, instead of nothing.
Instead, Apple killed Shake and let big studios buy the source code from them so they could continue to use it.
There is a massive difference to Motion and the highend compositing apps like Shake, Nuke, Fusion, Softimage(Illusion+Matador=FXTree), Houdini(COPS), Flame, Toxik(Autodesk Composite). After Effects and Combustion are time-line based like Motion, but Motion doesn't begin to compare to them. Even Blender has fantastic compositing tools.
Shake was serious business. It's last well known big project was 'The Dark Knight' which Framestore CFC mangled a 64bit wrapper around it to better manage the 8k-frame workload. Shake was ported to Intel, then killed off, with no intention to take it to 64bit. I don't think you can buy the source code anymore.
The Foundry is absolutely kicking everyone else's ass with Nuke. They have an interesting business model as well: don't do much research in house, instead work with studios with big R&D budgets and license their tools when they're mature, bringing it to a wider audience.
They've done it with Digital Domain and Nuke (compositing), Weta and Mari (3d paint), and now Sony and Katana (lighting).
I've known more than one colleague that has commuted from Portland to the Bay Area. In each case they were older men with wives and children that didn't want to (or couldn't) leave Portland. They rented small, cheap places during the week then spent the weekends at home with their families.
Even when considering professional cameras, it's more about the size of the sensor than raw megapixel output:
"Bigger chips mean so many good things. Big chips mean shallower depth-of-field at equivalent settings. Big chips
mean big pixels, which means more light hits each photosite. More light means less gain, less noise per pixel. Less noise means more dynamic range. Bigger chips mean better pictures."
