Re: [Python-Dev] 2.5 PEP
Hi, 2 questions: - is (c)ElementTree still planned for inclusion ? - isn't the current implementation of itertools.tee (cache of previous generated values) incompatible with the new possibility to feed a generator (PEP 342) ? Regards Neal Norwitz a écrit : > Attached is the 2.5 release PEP 356. It's also available from: > http://www.python.org/peps/pep-0356.html > > Does anyone have any comments? Is this good or bad? Feel free to > send to me comments. > > We need to ensure that PEPs 308, 328, and 343 are implemented. We > have possible volunteers for 308 and 343, but not 328. Brett is doing > 352 and Martin is doing 353. > > We also need to resolve a bunch of other implementation details about > providing the C AST to Python, bdist_* issues and a few more possible > stdlib modules. Don't be shy, tell the world what you think about > these. > > Can someone go through PEP 4 and 11 and determine what work needs to be > done? > > The more we distribute the work, the easier it will be on everyone. > You don't really want to listen to me whine any more do you? ;-) > > Thank you, ___ 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
Re: [Python-Dev] PEP 342: simple example, closure alternative
Le Vendredi 26 Août 2005 16:57, Guido van Rossum a écrit : > On 8/25/05, Ian Bicking <[EMAIL PROTECTED]> wrote: > > More generally, I've been doing some language comparisons, and I don't > > like literal but non-idiomatic translations of programming patterns. > > True. (But that doesn't mean I think using generators for this example > is great either.) > > > So I'm considering better ways to translate some of the same use cases. > > Remember that this particuar example was invented to show the > superiority of Lisp; it has no practical value when taken literally. > If you substitute a method call for the "acc += incr" operation, the > Python translation using nested functions is very natural. For larger > examples, I'd recommend defining a class as always. For example, I often use this class to help me in functional programming : _marker = () class var: def __init__(self, v=None): self.v = v def __call__(self, v=_marker): if v is not _marker: self.v = v return self.v and so the nested functions become very functional : def accum(n): acc = var(n) return lambda incr: acc(acc()+incr) ___ 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
