Re: [Python-Dev] PEP 309
Raymond Hettinger wrote: Are you sure about that? Contriving examples is easy, but download a few modules, scan them for use cases, and you may find, as I did, that partial() rarely applies. The argument order tends to be problematic. So would you like to see the decision to accept PEP 309 reverted? Regards, Martin ___ Python-Dev mailing list [email protected] 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 309
On Sun, 27 Feb 2005 09:31:26 +0100, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Raymond Hettinger wrote: > > Are you sure about that? Contriving examples is easy, but download a > > few modules, scan them for use cases, and you may find, as I did, that > > partial() rarely applies. The argument order tends to be problematic. > > So would you like to see the decision to accept PEP 309 reverted? Either revert the decision, or apply the patch. I don't feel comfortable advocating that the decision be reverted - according to the CVS log, PEP 309 was accepted by Guido on 31 March 2004, so I don't think it's for me to argue against that decision... (I've already stated my position - I don't have any problem with the function as it stands, and speed is not crucial to me so I have no preference between the C and Python implementations. But it's not the end of the world whatever happens...). Paul. ___ Python-Dev mailing list [email protected] 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 309
> > Are you sure about that? Contriving examples is easy, but download a > > few modules, scan them for use cases, and you may find, as I did, that > > partial() rarely applies. The argument order tends to be problematic. > > So would you like to see the decision to accept PEP 309 reverted? I would like for the principal advocates to reach a consensus that the proposed implementation is a winner. Ideally, that decision should be informed by trying it out on their own, real code and seeing whether it offers genuine improvements. Along the way, they should assess whether it is as applicable as expected, whether the existing limitations are problematic, and whether performance is an issue. All four issues are in question. My concern is that with Guido having approved the idea in abstract form, the actual implementation has escaped scrutiny. Also, if the API is different from the PEP, acceptance should not be automatic. If functional.partial() isn't a clear winner, it may be a reasonable to ask that it be released in the wild and evolve before being solidified in the standard library. My sense is that that the current implementation is far from its highest state of evolution. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Patch review & request
This is my last patch review in a series of five; next time I'll send them in a
bunch of five as requested. I reviewed the following patches:
[ 684500 ] extending readline functionality
[ 723201 ] PyArg_ParseTuple problem with 'L' format
[ 981773 ] crach link c++ extension by mingw
[ 985713 ] bug skipping optional keyword arguments of type "w#"
[ 1093585 ] sanity check for readline remove/replace
I'd like to ask your attention for patch #1121234, which is a bug fix for a
reference count problem in Tkinter. Nothing complicated, don't worry.
Thanks!
--Michiel.
Patch [ 985713 ] bug skipping optional keyword arguments of type "w#"
-
The convertsimple function in Python/getargs.c converts arguments for
PyArg_Parse, PyArg_ParseTuple etc. The function skipitem takes care of skipping
optional keyword arguments. Some of the valid formats are included in
convertsimple but missing in skipitem. The patch shows the example of the "w#"
format. If the argument format is "s|w#H" with corresponding keywords "string",
"buffer", "ushort", you can skip the "ushort" keyword but not the "buffer"
keyword. So this works:
>>> my_dummy_func("text", buffer=my_buffer)
but this doesn't:
>>> my_dummy_func("text", ushort=my_ushort)
It results in the error message
Traceback (most recent call last):
File "", line 1, in ?
TypeError: argument 2 impossible
The patch fixes this by adding the appropriate formats to the skipitem function.
The patch was written for the "w#" format; other formats that are missing are
listed in the patch description.
It seems that the missing formats in the skipitem function are simply due to an
oversight. Running the test suite revealed no problems with this patch. So I
think it can be applied.
--
Michiel de Hoon, Assistant Professor
University of Tokyo, Institute of Medical Science
Human Genome Center
4-6-1 Shirokane-dai, Minato-ku
Tokyo 108-8639
Japan
http://bonsai.ims.u-tokyo.ac.jp/~mdehoon
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Yet another patch review batch + request
I've taken a look at the following patches and made comments on the associated tracker items: patch [977553] Speed up EnumKey call Looks like a good idea, but needs some cleanup and at least one test case. I think I know enough about the Windows registry functions to finish this one up if the original author doesn't have time. patch [1075147] Flush stdout/stderr if closed (fix for bug 1074011) Looking at current sysmodule.c shows that this change (plus some error checking) has already been made, and the referenced bug has already been closed. patch [1104111] setup.py --help and --help-commands altered. Simple, helpful changes; got one 1+ and no negative comments over on distutils-sig: http://mail.python.org/pipermail/distutils-sig/2005-January/004378.html patch [1107973] tarfile.ExFileObject iterators Doesn't break anything and makes ExFileObject more file-like, so I'm for it. Passes regression tests. patch [1110248] patch for gzip.GzipFile.flush() related to bug 1110242 Seems reasonable & is simple. Passes regression tests. I would appreciate it if somebody could have a look at my patch: [1121142] ZipFile.open - read-only file-like obj for files in archive Another patch related to mine: patch [992750] zipfile and big zipped file This is the patch that I looked at before I submitted patch 1121142; if my patch is accepted (or rejected, I guess :-), this one should probably be closed since they implement the same idea. Thanks, Alan ___ Python-Dev mailing list [email protected] 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 309
Raymond Hettinger wrote: I would like for the principal advocates to reach a consensus that the proposed implementation is a winner. That I cannot understand. Do you want the advocates to verify that the implementation conforms to the specification? or that the implementation of the PEP is faster than any other existing implementation of the PEP? These two hold, I believe. Ideally, that decision should be informed by trying it out on their own, real code and seeing whether it offers genuine improvements. Performance-wise, or usability-wise? Because usability-wise, all implementations of the PEP are identical, so all implementations of the PEP should offer the precisely same improvements. Along the way, they should assess whether it is as applicable as expected, whether the existing limitations are problematic, and whether performance is an issue. Ah, so you question the specification, not the implementation of it. My concern is that with Guido having approved the idea in abstract form, the actual implementation has escaped scrutiny. Also, if the API is different from the PEP, acceptance should not be automatic. AFAICT, the proposed patch implements the behaviour of the PEP exactly. If functional.partial() isn't a clear winner, it may be a reasonable to ask that it be released in the wild and evolve before being solidified in the standard library. My sense is that that the current implementation is far from its highest state of evolution. Again, this I cannot understand. I do believe that there is no better way to implement the PEP. The PEP very explicitly defines what precisely functional.partial is, and the implementation follows that specification very closely. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] textwrap.py wordsep_re
> On 2005-02-24 05:04 PST, Greg Ward writes: Greg> Post a patch to SF and assign it to me. Make sure the Greg> unit tests still pass, and add a new one that doesn't Greg> pass without your fix. Done. Patch id 1149508. -- Karl 2005-02-27 10:29 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Quick access to Python bug reports in Thunderbird
I find that I frequently need to open a bug report whose bug number is in a python-dev email I read with Mozilla Thunderbird. I now tried to automate things a bit more, and found the excellent DictionarySearch plugin: http://dictionarysearch.mozdev.org/index.html To install, follow these steps: 1. Download the plugin (for Thunderbird, make sure to download to disk) http://dictionarysearch.mozdev.org/download.php/http://downloads.mozdev.org/dictionarysearch/dictionarysearch_0.8.xpi 2. In Thunderbird, open Tools/Extensions/Install, select the file downloaded 3. Open Tools/Extensions again, double-click DictionarySearch. 4. In "Dictionary 1", fill in Text: Python Bug $ Access Key: y (as P will conflict with Print) URL: http://www.python.org/sf/$ To use the plugin, select a bug report number in a message, select the context menu, and type y (or click the Python Bug menu entry). Regards, Martin P.S. In case you wonder why this plugin is DictionarySearch: it is meant to lookup words in an email in a dictionary, e.g. Wikipedia. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Quick access to Python bug reports in Thunderbird
Martin, Thanks; that works very well (in Firefox, too). I got it to work for patches, but the URL is a bit uglier (like this: http://sourceforge.net/tracker/index.php?func=detail&aid=$&group_id=5470&atid=305470). I assume there's a way to shorten that some, but it works as is and I probably won't change it. :-) Alan Martin v. Löwis wrote: I find that I frequently need to open a bug report whose bug number is in a python-dev email I read with Mozilla Thunderbird. I now tried to automate things a bit more, and found the excellent DictionarySearch plugin: http://dictionarysearch.mozdev.org/index.html To install, follow these steps: 1. Download the plugin (for Thunderbird, make sure to download to disk) http://dictionarysearch.mozdev.org/download.php/http://downloads.mozdev.org/dictionarysearch/dictionarysearch_0.8.xpi 2. In Thunderbird, open Tools/Extensions/Install, select the file downloaded 3. Open Tools/Extensions again, double-click DictionarySearch. 4. In "Dictionary 1", fill in Text: Python Bug $ Access Key: y (as P will conflict with Print) URL: http://www.python.org/sf/$ To use the plugin, select a bug report number in a message, select the context menu, and type y (or click the Python Bug menu entry). Regards, Martin P.S. In case you wonder why this plugin is DictionarySearch: it is meant to lookup words in an email in a dictionary, e.g. Wikipedia. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/alan.mcintyre%40esrgtech.com ___ Python-Dev mailing list [email protected] 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 309
On Sun, 27 Feb 2005 19:05:18 +0100, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Again, this I cannot understand. I do believe that there is no better > way to implement the PEP. The PEP very explicitly defines what precisely > functional.partial is, and the implementation follows that specification > very closely. This is where I get confused as well. PEP 309 specifies a function, and this specification has been accepted for inclusion in Python. The discussion seems to centre around whether that acceptance was correct. While I'm not saying that it's too late to attempt to persuade Guido to reverse himself, it does seem to me to be a lot of fuss over a fairly small function - and no-one said anything like this at the time. When I put up 5 reviews to get Martin to look at this, I honestly believed that it was a simple case of an accepted PEP with a complete implementation (admittedly scattered over a couple of SF patches), and would simply be a matter of committing it. IMHO, the burden is on those who want the "Accepted" status revoking to persuade Guido to pronounce to that effect. Otherwise, based on the standard PEP workflow process, it's time to move on, and ensure that the patches provide a complete implementation, and assuming they do to commit them. (But I don't want to put myself up as a big "champion" of PEP 309 - I like it, and I'd like to get the "accepted and there's a patch, but not yet implemented" status resolved, but that's all. I'm not going to switch to Perl if the patch isn't accepted :-)) Paul ___ Python-Dev mailing list [email protected] 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 309
> > Along the way, they should assess whether
> > it is as applicable as expected, whether the existing limitations
are
> > problematic, and whether performance is an issue.
>
> Ah, so you question the specification, not the implementation of it.
My only issue with the PEP is that it seemed much more promising when
reading it than when looking for real code that could benefit from it. I
liked it much better until I tried to use it. My hope is that the
advocates will try it for themselves before pushing this one in on
faith.
> I do believe that there is no better
> way to implement the PEP. The PEP very explicitly defines what
precisely
> functional.partial is, and the implementation follows that
specification
> very closely.
My reading of the PEP did not include making the structure members
public. This complicates and slows the implementation. The notion of
introducing mutable state to the PFA is at odds with the driving forces
behind functional programming (i.e. statelessness).
If necessary for introspection, the structure members can be made
read-only.
Also, there may be room to improve the implementation by building on the
passed-in dictionary rather than creating a copy of the one in the
partial object. The current choice may be the correct one because it
has the outer call override the defaults in the event of a keyword
conflict -- if so, that should be documented.
The test for callability is redundant and can be removed.
The traverse() function can be simplified with the PyVISIT macro.
Overall, I have no major objections to the PEP or the patch. Before it
goes in on auto-pilot, it would be darned nice if the proponents said
that they've found it helpful in real code and that they are satisfied
with the timings.
partial(str.__add__, 'Ray')('mond')
___
Python-Dev mailing list
[email protected]
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 309 enhancements
Nick Coghlan wrote: The initial suggestion was to provide a __get__ method on partial objects, which forces the insertion of the reference to self at the beginning of the argument list instead of at the end: def __get__(self, obj, type=None): if obj is None: return self return partial(self.fn, obj, *self.args, **self.kw) just a note: I don't see why this is not also a possible definition: return partial(self.fn, *(self.args+(obj,)), **self.kw) it may be impractical, but it would implement the direct mechanics of partial should behave like a function. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Quick access to Python bug reports in Thunderbird
On Sun, Feb 27, 2005 at 03:45:37PM -0500, Alan McIntyre wrote: > Martin, > > Thanks; that works very well (in Firefox, too). I got it to work > for patches, but the URL is a bit uglier (like this: > http://sourceforge.net/tracker/index.php?func=detail&aid=$&group_id=5470&atid=305470). > I assume there's a way to shorten that some, but it works as is > and I probably won't change it. :-) The URL used by Martin should work for patches as well. Johannes ___ Python-Dev mailing list [email protected] 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 309
Paul Moore wrote: While I'm not saying that it's too late to attempt to persuade Guido to reverse himself, it does seem to me to be a lot of fuss over a fairly small function - and no-one said anything like this at the time. I would probably fuss much less if it would not simultaneously introduce a new module as well. When I put up 5 reviews to get Martin to look at this, I honestly believed that it was a simple case of an accepted PEP with a complete implementation (admittedly scattered over a couple of SF patches), and would simply be a matter of committing it. That was a fair assumption. However, it turned out that a) people still have doubts about the proposed functionality of the PEP. For some, it does too much, for others, too little. Changing the PEP now would be much cheaper than first committing the changes, and then redoing the PEP again, as we might need to deprecate the functional.partial first. So as part of the review, I need to confirm that there still is no opposition to the PEP (which now appears to be the case) b) it is not obvious that the patch is complete. It probably is, but I would have committed a single patch much quicker than collecting bits and pieces from multiple patches, only to find out that they won't integrate properly. c) it appears that the implementation of the PEP is incorrect (as Raymond just discovered). Again, it is better to require a perfect implementation before committing the changes, instead of pushing the contributor afterwards to add the missing changes. IMHO, the burden is on those who want the "Accepted" status revoking to persuade Guido to pronounce to that effect. Most certainly. So far, nobody stepped forward and requested that this status is revoked, so no persuading is necessary. However, as part of the review process, it *is* necessary to check again whether somebody would have preferred that the PEP is revoked - atleast when the acceptance of the PEP is many months old. Otherwise, based on the standard PEP workflow process, it's time to move on, and ensure that the patches provide a complete implementation, and assuming they do to commit them. Correct. I would have done so more readily if I knew how the "Accepted" status got into the document. I could have researched that (going through old email archives), or I could just ask whether people agree that the status is indeed "Accepted". (But I don't want to put myself up as a big "champion" of PEP 309 - I like it, and I'd like to get the "accepted and there's a patch, but not yet implemented" status resolved, but that's all. I'm not going to switch to Perl if the patch isn't accepted :-)) It seems to me that the patch will be committed shortly, assuming somebody corrects the remaining flaws in the implementation. I could do that, but I would prefer if somebody contributed an updated patch. Regards, Martin ___ Python-Dev mailing list [email protected] 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 309
Raymond Hettinger wrote:
My reading of the PEP did not include making the structure members
public. This complicates and slows the implementation. The notion of
introducing mutable state to the PFA is at odds with the driving forces
behind functional programming (i.e. statelessness).
Notice that the C code is (or atleast is meant as) a faithful
implementation of the "Example Implementation" in the PEP, including
the literal spelling of the class attributes. Now, it is not clear
what is meant as normative in the PEP; I would agree that these member
names are not meant to be exposed.
If necessary for introspection, the structure members can be made
read-only.
This issue is not discussed in the PEP. If exposed, I think I would
prefer different names. Starting all names with p_, might be
appropriate, and I would rename "fn" to "func" (following method
objects). Not sure what names would be appropriate for arguments
and keywords.
Notice that the proposed documentation says this:
"""Partial objects are callable objects that are created, and mostly
behave, like the functions created by \function{partial}. The main
difference is that because they are Python objects, they have attributes
that can be inspected or modified."""
So it was atleast the intention of the PEP author that partial functions
are mutable.
Also, there may be room to improve the implementation by building on the
passed-in dictionary rather than creating a copy of the one in the
partial object.
Couldn't this cause the modifications be passed to the caller? This
would not be acceptable, but I could not figure out whether
CALL_FUNCTION* will always create a new kwdict, or whether it might
pass through a dict from the original caller.
The current choice may be the correct one because it
has the outer call override the defaults in the event of a keyword
conflict -- if so, that should be documented.
Notice that the "Example Implementation" specifies this:
if kw and self.kw:
d = self.kw.copy()
d.update(kw)
else:
d = kw or self.kw
In any case - the fine points of the semantics primarily need to go into
the documentation, which currently says
"""and keyword arguments override those provided when the new function
was created."""
Overall, I have no major objections to the PEP or the patch. Before it
goes in on auto-pilot, it would be darned nice if the proponents said
that they've found it helpful in real code and that they are satisfied
with the timings.
I guess "darned nice" is the best you can hope for. Not sure if Peter
Harris is still around.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Quick access to Python bug reports in Thunderbird
Alan McIntyre wrote: Thanks, somehow I managed to be oblivious to patches & bugs being essentially the same thing on SF. :-) The SF URLs are different (or atleast, they used to be (*), as they also include the "tracker ID" and the "project ID", and SF complains if you guess either wrong. Therefore, I wrote http://www.python.org/sf/ (also accessible through sf?id=) which looks an ID up in all trackers, in sequence, and caches the result in a file. Unfortunately, this a) fails if the item gets moved between trackers b) takes some time on the first access Nevertheless, it works in most cases, and it is easier to remember - especially as the shortest form is python.org/sf/ (browsers will add the http://, DNS will add the www., and the script will forward to SF index.php) Regards, Martin (*) Apparently, SF now supports an (apparently undocumented) URL format of http://sourceforge.net/support/tracker.php?aid= I'ld like to try this some day more systematically, to see whether it would help simplifying the current Python script on python.org. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Quick access to Python bug reports in Thunderbird
Johannes Gijsbers wrote: On Sun, Feb 27, 2005 at 03:45:37PM -0500, Alan McIntyre wrote: Martin, Thanks; that works very well (in Firefox, too). I got it to work for patches, but the URL is a bit uglier (like this: http://sourceforge.net/tracker/index.php?func=detail&aid=$&group_id=5470&atid=305470). I assume there's a way to shorten that some, but it works as is and I probably won't change it. :-) The URL used by Martin should work for patches as well. Johannes & Paul, Thanks, somehow I managed to be oblivious to patches & bugs being essentially the same thing on SF. :-) Alan ___ Python-Dev mailing list [email protected] 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 309
[Martin] > It seems to me that the patch will be committed shortly, assuming > somebody corrects the remaining flaws in the implementation. I could > do that, but I would prefer if somebody contributed an updated patch. Done. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
