Re: [Python-Dev] functools.compose to chain functions together
>> PEP 309 was written, discussed, approved, and implemented - that's how >> partial ended up in the stdlib. > > Ok, I'm surprised that a single addition to a module needed a PEP in > order to be approved. A PEP is generally needed if there is no easy consent achievable. It's not (primarily) the size of a feature that determines the need for a formal process, but but whether the community considers a certain change "obviously" correct and desirable. >> def foo(data): >> return compose(a, b(data), c) >> > > Ok, here's my attempt without looking at the patch: > > def foo(data): > def bar(*args, **kwargs): > return a(b(data)(c(*args, **kwargs))) > return bar Ok, that's also what the patch has proposed. I was puzzled when I read l.sort(key=compose(itemgetter(1), itemgetter(0 because I expected it to mean l.sort(key=lambda x:x[1][0]) when it would really mean l.sort(key=lambda x:x[0][1]) > Whether or not it is easier to read to the "average Python programmer" > is not that important I think. I completely disagree. It is one of Python's strength that it is "executable pseudo-code", which originates from the code being easy to read, and meaning the obvious thing even to a reader not familiar with the language. The proposed compose function breaks this important property, in a way that allows misinterpretation (i.e. you think you know what it does, and it actually does something different). I, personally, was not able to understand the compose function correctly, so I remain opposed. > We have lots of things that certainly > aren't, and yet still exist (all of the functions in the operator > module, for example; or `partial` itself for that matter). They are > there for advanced programmers. It's quite ok if only advanced programmers know that they are there, and know how to write them. However, I still think it is desirable that "lesser" programmers are then able to read them, or atleast notice that they mean something that they will need to learn first (such as a keyword they had never seen before). Regards, Martin ___ 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] functools.compose to chain functions together
Greg Ewing wrote:
> Jason R. Coombs wrote:
>> I had a use case that was compelling enough that I thought there
>> should be something in functools to do what I wanted.
>
> I think this is one of those things that a small minority of
> people would use frequently, but everyone else would use
> very rarely or never. The decision on whether to include
> something in the stdlib needs to be based on the wider
> picture.
>
> In this case, it's trivial to write your own if you want
> it. As they say, "not every one-line function needs to
> be in the stdlib".
>
I have never found these arguments compelling. They are obviously not
true (e.g., itertools.compress()[1] added in 2.7/3.1), and so what I
really hear is: "I don't like it and I outrank you."
I can't help invoke part of PEP309's justification for
functools.partial()[2]:
"""
I agree that lambda is usually good enough, just not always. And I want
the possibility of useful introspection and subclassing.
"""
The same reasoning would seem to apply here. In the OP's example, the
meta-decorator becomes opaque due to the use of a lambda. If one could
introspect a compose(), then introspection tools could actually know the
set of decorators being applied. As it is, the "preferred" method of
using a lambda actually makes it quite hard to know anything.
class compose():
def __init__(self, *funcs):
if not funcs:
raise ValueError(funcs)
self.funcs = funcs
def __call__(self, *args, **kwargs):
v = self.funcs[-1](*args, **kwargs)
for func in reversed(self.funcs[:-1]):
v = func(v)
return v
meta = functools.compose(decorator_a, decorator_b)
print meta.funcs
meta = lambda f: decorator_a(decorator_b(f))
# impossible, short of disassembling the lambda
-Scott
[1] http://docs.python.org/3.1/library/itertools.html#itertools.compress
"""
def compress(data, selectors):
# compress('ABCDEF', [1,0,1,0,1,1]) --> A C E F
return (d for d, s in zip(data, selectors) if s)
"""
___
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] functools.compose to chain functions together
On Mon, 17 Aug 2009 08:10:16 am Martin v. Löwis wrote: > I don't think he did. Comparing it to the one obvious solution (use > a lambda expression), his only reasoning was "it is much easier to > read". I truly cannot believe that a compose function would be > easier to read to the average Python programmer: if you have > > def foo(data): > return compose(a, b(data), c) > > what would you expect that to mean? foo is a factory function that, given an argument `data`, generates a function b(data), then composes it with two other functions a and c, and returns the result, also a function. > Please rewrite it as a regular > Python expression, preferably without looking at the patch that > has been proposed first. I bet there is a 50% chance that you get > it wrong (because there are two possible interpretations). But surely only one of them will agree with the standard definition of function composition. Both Mathworld and Wikipedia agree that f∘g(x) is equivalent to f(g(x)): http://mathworld.wolfram.com/Composition.html http://en.wikipedia.org/wiki/Function_composition and I don't see any reason why a compose() function shouldn't do the same. (Aside: how do I look at the patch? The only link I have is here: http://mail.python.org/pipermail/patches/2007-February/021687.html but I can't see how to get to the patch from there.) foo could be written as: def foo(data): return lambda *args, **kwargs: a(b(data)(c(*args, **kwargs))) Or without lambda: def foo(data): def composed(*args, **kwargs): return a(b(data)(c(*args, **kwargs))) return composed This soon gets unwieldy: def foo(arg1, arg2, arg3): return compose( f, g, h, factory(arg1), factory(arg2), factory(arg3) ) versus def foo(arg1, arg2, arg3): return lambda *a, **kw: ( f(g(h(factory(arg1)(factory(arg2)(factory(arg3)(*a, **kw)) ) but presumably composing six functions is rare. A further advantage of compose() is that one could, if desired, generate a sensible name and doc string for the returned function. Depends on how heavyweight you want compose() to become. I think the compose() version is far more readable and understandable, but another factor is the performance cost of the generated function compared to a hand-made lambda. For the record, Haskell makes compose a built-in operator: http://www.haskell.org/haskellwiki/Function_composition It doesn't appear to be standard in Ruby, but it seems to be commonly requested, and a version is on Facets: http://facets.rubyforge.org/apidoc/api/core/classes/Proc.html#M000161 -- Steven D'Aprano ___ 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] functools.compose to chain functions together
Antoine Pitrou wrote: > Raymond Hettinger rcn.com> writes: >> IMO, its only virtue is that people coming from functional languages >> are used to having compose. Otherwise, it's a YAGNI. > > Then I wonder how partial() ended up in the stdlib. It seems hardly more > useful than compose(). I would certainly consider it more useful, but that aside, it's also a lot simpler to understand and use than the proposed compose() function. I think the main difference is that compose() requires functional/math skills to be used and read correctly (and might still be surprising in some corner cases), whereas partial() only requires you to understand how to set a function argument. Totally different level of mental complexity, IMHO. Stefan ___ 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] functools.compose to chain functions together
Antoine Pitrou wrote: >> PEP 309 was written, discussed, approved, and implemented - that's how >> partial ended up in the stdlib. > > Ok, I'm surprised that a single addition to a module needed a PEP in > order to be approved. It makes a little more sense once you realise that there was no functools module before the implementation of PEP 309. The other functions it contains in Python 2.5 (update_wrapper() and wraps()) were added later in the development cycle and reduce() didn't get added to it until 2.6/3.0. If a concrete proposal is made that emphasises the improved introspection capabilities and raw speed increase that a function composition approach can offer over the use of lambda then I'd personally be willing to support this idea, since it was at least in part those two ideas that sold the idea of partial(). (partial() did have a big advantage over compose() in that the former's readability gains were far more obvious to most readers). Cheers, Nick. P.S. PEP 309 is wrong when it says a C version probably isn't worthwhile - between the time the PEP was first implemented and the time 2.5 was actually released, enough investigation was done to show that the speed gain from Hye-Shik Chang's C version was well worth the additional code complexity. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] functools.compose to chain functions together
Le lundi 17 août 2009 à 09:07 +0200, "Martin v. Löwis" a écrit : > Ok, that's also what the patch has proposed. I was puzzled when I read > >l.sort(key=compose(itemgetter(1), itemgetter(0 > > because I expected it to mean > >l.sort(key=lambda x:x[1][0]) But that's itemgetter's fault, not compose's. Because itemgetter's obvious equivalent (the [] operator) uses postfix notation, combining several itemgetters reverses the lexical order of appearance. Besides, the argument order is similar to the one in the function composition notation in mathematics (which isn't really advanced stuff and should have been taught to every former scientific/technical student out there). Regards Antoine. ___ 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] functools.compose to chain functions together
Le lundi 17 août 2009 à 20:53 +1000, Nick Coghlan a écrit : > P.S. PEP 309 is wrong when it says a C version probably isn't worthwhile > - between the time the PEP was first implemented and the time 2.5 was > actually released, enough investigation was done to show that the speed > gain from Hye-Shik Chang's C version was well worth the additional code > complexity. Yes, one-line Python wrappers can kill performance of pure C code. Seen that in the IO lib, again. Regards Antoine. ___ 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] functools.compose to chain functions together
On 17 Aug 2009, at 09:43 , Steven D'Aprano wrote: On Mon, 17 Aug 2009 08:10:16 am Martin v. Löwis wrote: I don't think he did. Comparing it to the one obvious solution (use a lambda expression), his only reasoning was "it is much easier to read". I truly cannot believe that a compose function would be easier to read to the average Python programmer: if you have def foo(data): return compose(a, b(data), c) what would you expect that to mean? foo is a factory function that, given an argument `data`, generates a function b(data), then composes it with two other functions a and c, and returns the result, also a function. From his messages, I think Martin's issue with `compose` is with the composition order rather than the fact that it "pipes" functions: compose uses the mathematical order, (f ∘ g)(x) = f(g(x)) (so g, the last function of the composition, is applied first), rather than a "shell pipe" order of `(f >>> g)(x) = g(f(x))` (where g, the last function of the composition, is applied last). For the record, Haskell makes compose a built-in operator: http://www.haskell.org/haskellwiki/Function_composition Yes, but Haskell also has a left-to-right composition, the (>>>) operator: http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html#v :>>> ___ 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
[Python-Dev] VC++ versions to match python versions?
Hi All, Is the Express Edition of Visual C++ 2008 suitable for compiling packages for Python 2.6 on Windows? (And Python 2.6 itself for that matter...) Ditto for 2.5, 3.1 and the trunk (which I guess becomes 3.2?) cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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] VC++ versions to match python versions?
On Mon, Aug 17, 2009 at 03:22:50PM +0100, Chris Withers wrote: > Is the Express Edition of Visual C++ 2008 suitable for compiling > packages for Python 2.6 on Windows? > (And Python 2.6 itself for that matter...) > > Ditto for 2.5, 3.1 and the trunk (which I guess becomes 3.2?) These two I know for sure: Python 2.5: MSVC-7.1 (VC++ 2003) Python 2.6: MSVC-9.0 (VS 2008) Oleg. -- Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] VC++ versions to match python versions?
Chris Withers wrote: Hi All, Is the Express Edition of Visual C++ 2008 suitable for compiling packages for Python 2.6 on Windows? (And Python 2.6 itself for that matter...) I would think so - all you really need is the compiler (which the express version definitely includes). You may need to manually add some directories to the path. I haven't actually tried it, but then nor have you from the sound of it. Ditto for 2.5, 3.1 and the trunk (which I guess becomes 3.2?) Python 3.1 / 3.2 are built with VS 2008. 2.5 is built with 2003 which is difficult to download unless you have an MSDN subscription. VS 2008 can't (reliably) be used to build extensions for 2005 I believe. I'm sure someone will correct me if this information is incorrect. Michael cheers, Chris -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] VC++ versions to match python versions?
Michael Foord wrote: Chris Withers wrote: Hi All, Is the Express Edition of Visual C++ 2008 suitable for compiling packages for Python 2.6 on Windows? (And Python 2.6 itself for that matter...) I would think so - all you really need is the compiler (which the express version definitely includes). You may need to manually add some directories to the path. I haven't actually tried it, but then nor have you from the sound of it. Ditto for 2.5, 3.1 and the trunk (which I guess becomes 3.2?) Python 3.1 / 3.2 are built with VS 2008. 2.5 is built with 2003 which is difficult to download unless you have an MSDN subscription. VS 2008 can't (reliably) be used to build extensions for 2005 I believe. D'oh. For 2.5 I mean. It may be *possible* though - just as you *can* build extensions for Python 2.5 on windows with mingw (with the appropriate distutils configuration), but there are pitfalls with doing this. Michael I'm sure someone will correct me if this information is incorrect. Michael cheers, Chris -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] VC++ versions to match python versions?
Michael Foord wrote: D'oh. For 2.5 I mean. It may be *possible* though - just as you *can* build extensions for Python 2.5 on windows with mingw (with the appropriate distutils configuration), but there are pitfalls with doing this. Yes, in my case I'm trying to compile guppy (for heapy, which is an amazing tool) but that blows up with mingw... (But I'm also likely to want to do some python dev on windows, httplib download problems and all...) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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
[Python-Dev] PEP Submission
Several days ago, around the time the python.org servers went down, I submitted a PEP to edi...@python.org. When things to have been worked, I submitted the PEP again. I have not seen any activity on the PEP in Python-Dev or any reply acknowledging that it was received. Did I misunderstand the process of submitting a PEP? ___ 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] VC++ versions to match python versions?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: > Michael Foord wrote: >> D'oh. For 2.5 I mean. It may be *possible* though - just as you *can* >> build extensions for Python 2.5 on windows with mingw (with the >> appropriate distutils configuration), but there are pitfalls with >> doing this. > > Yes, in my case I'm trying to compile guppy (for heapy, which is an > amazing tool) but that blows up with mingw... > > (But I'm also likely to want to do some python dev on windows, httplib > download problems and all...) > > Chris > Guppy doesn't compile on Windows. Pretty much full-stop. It uses static references to DLL functions, which on Windows is not allowed. I've tried patching it to remove such things, and I finally got it to compile, only to have it go "boom!" in actual use. If you can get it to work, certainly post something so that I can cheer. John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqJc8EACgkQJdeBCYSNAAPFWgCghbyZ4MDcA3xich0mBOO1/VoY 5mcAnjjv1kS8Ln3dhbG6/W75zmGacWQw =x6ZX -END PGP SIGNATURE- ___ 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] VC++ versions to match python versions?
John Arbash Meinel wrote: Guppy doesn't compile on Windows. Pretty much full-stop. It uses static references to DLL functions, which on Windows is not allowed. This is no longer true as of the latest version of guppy... I've tried patching it to remove such things, and I finally got it to compile, only to have it go "boom!" in actual use. If you can get it to work, certainly post something so that I can cheer. Are you on the guppy list? Someone posted a patch to it (which may have been you?) which has made it into the latest release. I haven't tried to get it working myself yet, but John Machin (who maintains xlrd) has with the Express compiler. I was just checking I had the right version and what version I should use if I want to try with Python 2.5. I also wanted to know what versions I should be using for python core development should I be foolhardy enough to try any of that on Windows... (he says, staring down the barrel of slow httplib downloads on Windows :'( ) Will let you know what I find... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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
[Python-Dev] FAO John Arbash Meinel
Mail Delivery System wrote: This is the mail system at host server1.simplistix.co.uk. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : host mail2.domainpeople.com[204.174.223.74] said: 550 relay not permitted (in reply to RCPT TO command) Looks like something is not happy with your mail setup... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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 Submission
Hm... I thought the address was p...@python.org? On Mon, Aug 17, 2009 at 8:19 AM, Eric Pruitt wrote: > Several days ago, around the time the python.org servers went down, I > submitted a PEP to edi...@python.org. When things to have been worked, > I submitted the PEP again. I have not seen any activity on the PEP in > Python-Dev or any reply acknowledging that it was received. Did I > misunderstand the process of submitting a PEP? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] another Py_TPFLAGS_HEAPTYPE question
On Sun, Aug 16, 2009 at 11:53 PM, "Martin v. Löwis" wrote: >> Thanks for the pointer. I noticed that subtype_dealloc is only called for >> types >> that are allocated using type_new(). Does this mean that it is not >> safe to create >> types in C using just PyType_Ready() and set Py_TPFLAGS_HEAPTYPE on >> them? The documentation is not clear on this point. > > As Benjamin says, this is getting off-topic - python-dev is not a place > to ask for help in your project. Please let me know where is a more suitable place to discuss the implementation of the cPython as it pertains to C extensions. I wrote to python-dev only because the other lists appeared to be more focused on Python-the-language. > I believe setting flags on a type is inherently unsafe. Clearly this is not true in general. Take Py_TPFLAGS_BASETYPE, which C types are expected to set if they can be subclassed. Or Py_TPFLAGS_HAVE_GC, which C types set if they participate in cyclic reference collection. The docs do not distinguish (AFAICS) between flags that C types may set directly and those that they may not. My reading of the docs left me with the impression that a type could set Py_TPFLAGS_HEAPTYPE if it had allocated that type on the heap and wanted it INCREF'd and DECREF'd by instances. I now know that there is much more to this flag than I anticipated (see http://thread.gmane.org/gmane.comp.python.devel/105648), I am just giving you feedback about why the docs led me to this incorrect conclusion. In any case, I think I will experiment with a different approach, where instead of creating types in C dynamically at runtime, I will create a type whose instances "pretend" to be types (they will create instances when called). Still, I would appreciate knowing where I should direct further questions of this type, which are not questions about how to use Python but rather questions about how to properly implement extensions. >> Here is what I would like to do when I create my types dynamically: >> >> - implement tp_alloc and tp_dealloc() to INCREF and DECREF the type. >> - not set Py_TPFLAGS_HEAPTYPE. >> - set Py_TPFLAGS_HAVE_GC (because instances of my obj can create cycles) >> >> Does this seem safe? I notice that subtype_dealloc() does some funky >> GC/trashcan stuff. Is it safe for me not to call subtype_dealloc? Can I >> safely implement my tp_dealloc function like this? > > If you bypass documented API, you really need to study the code, > understand its motivation, judge whether certain usage is "safe" wrt. > to the current implementation, and judge the likelihood of this code > not getting changed in future versions. It was not my intention to bypass the documented API. Py_TPFLAGS_HEAPTYPE is documented here, with no note that the flag should not be set explicitly by C types: http://docs.python.org/c-api/typeobj.html#Py_TPFLAGS_HEAPTYPE Also, INCREF'ing and DECREF'ing my type from the tp_new and tp_dealloc functions doesn't seem outside of the documented API. Thanks, Josh ___ 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] another Py_TPFLAGS_HEAPTYPE question
>> As Benjamin says, this is getting off-topic - python-dev is not a place >> to ask for help in your project. > > Please let me know where is a more suitable place to discuss the > implementation of the cPython as it pertains to C extensions. I wrote > to python-dev only because the other lists appeared to be more focused > on Python-the-language. The general python-list, or, more specifically, capi-sig. python-dev is exclusively reserved for current development of Python (including PEP discussions). It is out-of-scope to ask questions of the form "how do I do XYZ?". Regards, Martin ___ 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] functools.compose to chain functions together
> and I don't see any reason why a compose() function shouldn't do the
> same.
I was tricked into reading it different when used with getters, i.e.
l.sort(key=compose(attrgetter('name'),attrgetter('age')))
is too easy (IMO) to read as applying foo.name.age on all elements of
the list.
> (Aside: how do I look at the patch? The only link I have is here:
> http://mail.python.org/pipermail/patches/2007-February/021687.html
> but I can't see how to get to the patch from there.)
It's best to search for "compose" in the bug tracker:
http://bugs.python.org/issue1660179
Regards,
Martin
___
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] functools.compose to chain functions together
> I have never found these arguments compelling. They are obviously not > true (e.g., itertools.compress()[1] added in 2.7/3.1), and so what I > really hear is: "I don't like it and I outrank you." That certainly contributes to it - if you are not a committer, you have to find a committer that finds the feature important enough to work with you to integrate it. Fortunately, there is a process to overcome this problem: the PEP process. If you you really really want the feature, and can't find a committer that supports it yet, write a PEP. Then it will be up to Guido van Rossum to reject it. > The same reasoning would seem to apply here. In the OP's example, the > meta-decorator becomes opaque due to the use of a lambda. If one could > introspect a compose(), then introspection tools could actually know the > set of decorators being applied. As it is, the "preferred" method of > using a lambda actually makes it quite hard to know anything. That makes it even more necessary to write a PEP. I would have never guessed that introspection on the compose result is desirable. AFAICT, operator.attrgetter isn't introspectable, either, nor would the patch proposed in #7762 give you an introspectable getter. ISTM that people have fairly different requirements wrt. that feature. Regards, Martin ___ 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] VC++ versions to match python versions?
Chris Withers writes: > Is the Express Edition of Visual C++ 2008 suitable for compiling > packages for Python 2.6 on Windows? > (And Python 2.6 itself for that matter...) Yes - it's currently being used on my buildbot, for example, to build Python itself. Works for 2.6 and later. > Ditto for 2.5, 3.1 and the trunk (which I guess becomes 3.2?) 2.5 needs VS 2003. -- David ___ 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 Submission
Guido van Rossum wrote: > Hm... I thought the address was p...@python.org? > > On Mon, Aug 17, 2009 at 8:19 AM, Eric Pruitt wrote: >> Several days ago, around the time the python.org servers went down, I >> submitted a PEP to edi...@python.org. When things to have been worked, >> I submitted the PEP again. I have not seen any activity on the PEP in >> Python-Dev or any reply acknowledging that it was received. Did I >> misunderstand the process of submitting a PEP? > Correct - that's what PEP 1 says. edi...@python.org goes to the HOWTO editor, which is a...@python.org. Not sure whether this alias is still useful. Regards, Martin ___ 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] another Py_TPFLAGS_HEAPTYPE question
On Mon, Aug 17, 2009 at 1:41 PM, "Martin v. Löwis" wrote: >>> As Benjamin says, this is getting off-topic - python-dev is not a place >>> to ask for help in your project. >> >> Please let me know where is a more suitable place to discuss the >> implementation of the cPython as it pertains to C extensions. I wrote >> to python-dev only because the other lists appeared to be more focused >> on Python-the-language. > > The general python-list, or, more specifically, capi-sig. > > python-dev is exclusively reserved for current development of Python > (including PEP discussions). It is out-of-scope to ask questions of > the form "how do I do XYZ?". Ok, I will direct future questions of this sort to one of those two places -- thanks and sorry for posting off-topic. Josh ___ 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
