>> The idea is not yet ready for prime-time. If I do it for one of the named >> operations, I will do it for all (to keep the interface uniform).
> Which named operations are you thinking of? s.union(t), s.intersection(t), s.difference(t), s.symmetric_difference(t), s.update(t), s.intersection_update(t), s.difference_update(t), s.symmetric_difference_update(t) > if you can't make vararg PySet_Update() insanely fast, > does that mean you won't add a vararg version? Right. Please leave this one alone. I still need to work on this part of the API and do not currently have the spare clock cycles to do it right now. You don't HAVE to jam something in right away. Please let it continue to cook and not muck it up through over-enthusiasm. If I had time to explain/debate every darned aspect of what is under consideration, then it would have been done already. The fierce insistence for the patch is pre-mature and is grotesquely out-of-proportion to any potential benefit. Please do not jam this one down my throat -- the function is not necessary to have right away -- you're talking about nanoseconds of efficiency and a microscopically shorter call. Sorry, I need to stop wasting time on this thread. It has consumed far too much development time already. Please write a one-line macro for yourself and leave this alone so I can continue the development efforts at a thoughtful pace. Raymond _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
