>> output_to = compressors[name](compresslevel=complevel) >> > Your example seems to indicate a model->sequence operation, that I would > call 'encode'. Now the question becomes, given 'f', what makes more sense: > > (a) y = x.transform(f) > (b) y = x.encode(f) > (c) y = f(x) > > What do you expect the function signature of 'output_to' to be?
People brought that up in the context of stacking streams. So output_to would have a stream interface, so you would say (d) output_to.write(x) (and yes, I do recognize that the ultimate receiver of the output, e.g. the socket or such, is missing in my API) > Is it > callable? Is it something that is going to be a stream wrapper, that > has .read() and .write()? That's what I meant it to be. I'm not quite sure why you are asking these questions. > In this case using .transform() would seem to be a good fit because > there is no model, but 'obj' suffers from being directionless, so it > becomes this... > > ciph = plain.transform(obj.encrypt) > > ...which isn't substantially clearer than... > > ciph = obj.encrypt(plain) It isn't substantially clearer, and *therefore* it is a good fit??? > Parametric transformations don't bother me, but that would be an > indication that there's a lot more going on, and perhaps there are > better (and pre-existing) labels for these functions. If you are saying that we should call it .encrypt, not .transform: I completely agree. Regards, Martin _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
