Re: [Python-Dev] [Python-checkins] r83893 - python/branches/release27-maint/Misc/ACKS
Benjamin Peterson writes: > 2010/8/9 Nick Coghlan : > > On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky > > wrote: > >> +PS: In the standard Python distribution, this file is encoded > >> in UTF-8 +and the list is in rough alphabetical order by last > >> names. > >> > >> David Abrahams > >> Jim Ahlstrom > >> @@ -28,6 +29,7 @@ > >> Éric Araujo > >> Jason Asbahr > >> David Ascher > >> +Peter Åstrand > > From my recollection of the discussion when Peter was added, the > > >first > > character in his last name actually sorts after Z (despite its > > resemblance to an A). > This is correct. Don't think of Å as a kind of "A". It's its own > letter, which sorts after Z in Swedish. That's true, but IIRC there are a fairly large number of letters where different languages collate them in different positions. Is it worth actually asking appropriate humans to think about this, or would it be better to use Unicode code point order for simplicity? ___ 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] Adding a token
On 8 Aug, 2010, at 6:15, Greg Ewing wrote: > Aaargh, I think I've found out what the problem is. > > I'm using framework builds on MacOSX. I have two experimental > builds of Python 3.1 around, plus a standard one installed in > /Library. It's picking up the version of Python.framework in > /Library/Frameworks instead of the one in the local build > directory that python.exe was explicitly linked with. Check the RUNPY definition in the Makefile, you should start python.exe using DYLD_FRAMEWORK_PATH=$PWD ./python.exe (Assuming your running from the build directory, adjusting this for other situations should be easy) > > Now I'm confused about why my *other* experimental build > worked -- the one I've been using for yield-from and codef -- > because it should have suffered from the same problem. And > when I tried to use it again just now, it did indeed not work. > > Does anyone know if there's a way to tell Apple's linker to > use a framework from a specific location and not go looking > anywhere else? Use the '--with-framework-name' option to configure, this enables you to build the framework with an alternate name and therefore have two framework installs side-by-side. I use this to have a regular python build as well as a --with-pydebug build. Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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] [Python-checkins] r83893 - python/branches/release27-maint/Misc/ACKS
2010/8/10 Stephen J. Turnbull : > Benjamin Peterson writes: > > 2010/8/9 Nick Coghlan : > > > On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky > > > wrote: > > >> +PS: In the standard Python distribution, this file is encoded > > >> in UTF-8 +and the list is in rough alphabetical order by last > > >> names. > > >> > > >> David Abrahams > > >> Jim Ahlstrom > > >> @@ -28,6 +29,7 @@ > > >> Éric Araujo > > >> Jason Asbahr > > >> David Ascher > > >> +Peter Åstrand > > > From my recollection of the discussion when Peter was added, the > > > >first > > > character in his last name actually sorts after Z (despite its > > > resemblance to an A). > > This is correct. Don't think of Å as a kind of "A". It's its own > > letter, which sorts after Z in Swedish. > > That's true, but IIRC there are a fairly large number of letters where > different languages collate them in different positions. > > Is it worth actually asking appropriate humans to think about this, or > would it be better to use Unicode code point order for simplicity? I think it's largely a unimportant discussion. If people have an opinion of where their name should appear, they can by all means change it. However, "rough" is probably as best as it'll ever get. -- Regards, Benjamin ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2010-08-01 - 2010-08-07)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues stats:
open2640 (+35)
closed 18679 (+194)
total 21319 (+57)
Open issues with patches: 1112
Issues opened (35)
==
#8821: Range check on unicode repr
http://bugs.python.org/issue8821 reopened by pitrou
#8959: WINFUNCTYPE wrapped ctypes callbacks not functioning correctly
http://bugs.python.org/issue8959 reopened by brian.curtin
#9323: trace.py bug with the main file being traced
http://bugs.python.org/issue9323 reopened by belopolsky
#9446: urllib2 tests fail when offline
http://bugs.python.org/issue9446 opened by guandalino
#9453: pulldom.SAX2DOM Doesn't support processing instructions before
http://bugs.python.org/issue9453 opened by mark.smith
#9456: Apparent memory leak in PC/bdist_wininst/install.c
http://bugs.python.org/issue9456 opened by Zachary.Blair
#9458: xml.etree.ElementTree.ElementTree.write(): encoding handling p
http://bugs.python.org/issue9458 opened by kune
#9495: argparse unittest tracebacks are confusing if an error is rais
http://bugs.python.org/issue9495 opened by r.david.murray
#9499: Python C/API Execution namespace undocumented. (patch included
http://bugs.python.org/issue9499 opened by ideasman42
#9500: urllib2: Content-Encoding
http://bugs.python.org/issue9500 opened by guest
#9501: Logging shutdown regressions with weakrefs
http://bugs.python.org/issue9501 opened by gz
#9503: print statement hangs Windows service
http://bugs.python.org/issue9503 opened by rgpitts
#9504: signal.signal/signal.alarm not working as expected
http://bugs.python.org/issue9504 opened by alanwilter
#9506: sqlite3 mogrify - return query string
http://bugs.python.org/issue9506 opened by goatbar
#9508: python3.2 reversal of distutils reintrocud macos9 support
http://bugs.python.org/issue9508 opened by ronaldoussoren
#9509: argparse FileType raises ugly exception for missing file
http://bugs.python.org/issue9509 opened by doughellmann
#9511: CharacterEncoderError when reading from sys.stdin from piped i
http://bugs.python.org/issue9511 opened by pbos
#9512: logging.handlers.RotatingFileHandler - mode argument not respe
http://bugs.python.org/issue9512 opened by fridrik
#9514: platform.linux_distribution() under Ubuntu returns ('debian',
http://bugs.python.org/issue9514 opened by pitrou
#9516: sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3" but
http://bugs.python.org/issue9516 opened by srid
#9517: Make test.script_helper more comprehensive, and use it in the
http://bugs.python.org/issue9517 opened by pitrou
#9518: PyModuleDef_HEAD_INIT does not explicitly initialize all field
http://bugs.python.org/issue9518 opened by dmalcolm
#9520: Add Patricia Trie high performance container
http://bugs.python.org/issue9520 opened by dmtr
#9521: xml.etree.ElementTree strips XML declaration and procesing ins
http://bugs.python.org/issue9521 opened by mark
#9522: xml.etree.ElementTree forgets the encoding
http://bugs.python.org/issue9522 opened by mark
#9523: Improve dbm module
http://bugs.python.org/issue9523 opened by ysj.ray
#9524: Document CTRL_C_EVENT and CTRL_BREAK_EVENT usage on Windows
http://bugs.python.org/issue9524 opened by valgog
#9527: Add aware local time support to datetime module
http://bugs.python.org/issue9527 opened by belopolsky
#9528: Add pure Python implementation of time module to CPython
http://bugs.python.org/issue9528 opened by belopolsky
#9529: Converge re.findall and re.finditer
http://bugs.python.org/issue9529 opened by MizardX
#9530: integer undefined behaviors
http://bugs.python.org/issue9530 opened by regehr
#9532: pipe.read hang, when calling commands.getstatusoutput in multi
http://bugs.python.org/issue9532 opened by denny
#9533: metaclass can't derive from ABC
http://bugs.python.org/issue9533 opened by roalddevries
#9535: Pending signals are inherited by child processes
http://bugs.python.org/issue9535 opened by gdb
#9536: defaultdict doc makes incorrect reference to __missing__ metho
http://bugs.python.org/issue9536 opened by jjposner
Recent issues with no replies (15)
==
#9535: Pending signals are inherited by child processes
http://bugs.python.org/issue9535
#9533: metaclass can't derive from ABC
http://bugs.python.org/issue9533
#9523: Improve dbm module
http://bugs.python.org/issue9523
#9521: xml.etree.ElementTree strips XML declaration and procesing ins
http://bugs.python.org/issue9521
#9518: PyModuleDef_HEAD_INIT does not explicitly initialize all field
http://bugs.python.org/issue9518
#9509: argparse FileType raises ugly exception for missing file
http://bugs.python.org/issue9509
#9508: python3.2 reversal of distutils reintrocud macos9 support
http://bugs.python.org/issue9508
#9504: signal.signal/signal.alarm not working as expected
Re: [Python-Dev] mingw support?
On Mon, Aug 09, 2010 at 06:55:29PM -0400, Terry Reedy wrote: > On 8/9/2010 2:47 PM, Sturla Molden wrote: > >> Terry Reedy: > > > >> MingW has become less attractive in recent years by the difficulty > >> in downloading and installing a current version and finding out how to > >> do so. Some projects have moved on to the TDM packaging of MingW. > >> > >> http://tdm-gcc.tdragon.net/ > > Someone else deserves credit for writing that and giving that link ;-) Yes, that was a great link, thanks. It works fine for me. The reason I was bringing up this topic again was that I think the gnu autotools have been made for exactly this purpose, to port software to different platforms, and it might in the long run be easier to have a working mingw plus autotools platform to develop python (as well as other software) on. Besides, one day it would be nice even on windows to have a kind of GNU/Windows system where you could just type win-emerge gtk or win-emerge python or whatever. Gabriel ___ 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] Summary of Python tracker Issues
Hi, lately I've been working on the new summary of Python tracker issues. This is the result. On 10/08/2010 16.39, Python tracker wrote: ACTIVITY SUMMARY (2010-08-01 - 2010-08-07) This is the period that is considered for the following stats. By default it shows the activity of the last week. (This was supposed to be the report for last week, but it's from Monday to Sunday instead of from Saturday to Friday because I specified the wrong dates.) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues stats: open2640 (+35) closed 18679 (+194) total 21319 (+57) The +35 means that there are 35 more issues opened since the last week. This is not the number of issues that have been created during the last week, but the number of new issues that have been created or reopened that are still open. Also note that 'pending' and 'languishing' are considered as 'open' too. The +194 means that are 194 more issues closed since last week that are still closed. Both the open and closed issues are listed later. The +57 means that overall the tracker has 57 more issues since last week. This also mean that about 25 issues created this week are already closed (i.e. 57 new - (35 still open - 3 older that got reopened) = 25 issues). Open issues with patches: 1112 This is the total number of open issues with the 'patch' keyword. Issues opened (35) == #8821: Range check on unicode repr http://bugs.python.org/issue8821 reopened by pitrou [...] This is the list of *all* the issues created or reopened during the last week *that are still open*. Recent issues with no replies (15) == #9535: Pending signals are inherited by child processes http://bugs.python.org/issue9535 [...] This is the list of the open issues with only 1 message, sorted by creation date. The list is limited to max 15 issues but is not limited to the last week. This means that issues older than a week are included here if less than 15 issues with only 1 message have been created this week. Issues waiting for review (15) == #1474680: pickling files works with protocol=2. http://bugs.python.org/issue1474680 [...] This is the list of issues with 'patch' or 'needs review' keywords or 'patch review' stage that have been active during the last week. The list is limited to max 15 issues. Top issues most discussed (10) == #9079: Make gettimeofday available in time module http://bugs.python.org/issue9079 42 msgs [...] This is the list of issues with activity in the last week sorted by number of message. This list is limited to max 10 issues. Issues closed (154) === #1474680: pickling files works with protocol=2. http://bugs.python.org/issue1474680 closed by alexandre.vassalotti [...] This is the list of *all* the issues closed in the last week *that are still closed*. Since this list might be quite long I put it at the end, to make it easier to reach the other lists. The previous report also had the average and median durations of open issues. While I was refactoring the function that calculated them, I realized that these values are not so useful/clear so I decided to remove them. These values could be added back if they are needed, but it might be more interesting to know how long does it usually take for an issue to be closed, rather than for how long the open issues are around. For more information see http://psf.upfronthosting.co.za/roundup/meta/issue284. Best Regards, Ezio Melotti P.S.: Thanks to R. David Murray that helped me out with the testing and to all the people who provided (and will provide) feedback. ___ 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] Summary of Python tracker Issues
On Tue, 10 Aug 2010 17:28:18 +0300, Ezio Melotti wrote: > Hi, > lately I've been working on the new summary of Python tracker issues. > This is the result. Thanks for working on this, Ezio! > > Issues stats: > >open2640 (+35) > >closed 18679 (+194) > >total 21319 (+57) > > The +35 means that there are 35 more issues opened since the last week. > This is not the number of issues that have been created during the last > week, but the number of new issues that have been created or reopened > that are still open. Also note that 'pending' and 'languishing' are > considered as 'open' too. How about changing the label to 'not closed' to make that clear? > > Issues opened (35) > > == > > > > #8821: Range check on unicode repr > > http://bugs.python.org/issue8821 reopened by pitrou > > [...] > > This is the list of *all* the issues created or reopened during the last > week *that are still open*. I wonder if it would be useful to split this into two tables, one for new issues still open and one for reopened issues. I think the mental space in which one considers re-opened issues is different from the one for new issues. In particular, a developer who doesn't have time to scan the new issues might notice a reopened issue they were involved in but haven't yet looked at their 'nosy' email about. Perhaps not worth the effort, it's just a thought. > > Recent issues with no replies (15) > > == > > > > #9535: Pending signals are inherited by child processes > > http://bugs.python.org/issue9535 > > [...] > > This is the list of the open issues with only 1 message, sorted by > creation date. > The list is limited to max 15 issues but is not limited to the last > week. This means that issues older than a week are included here if less > than 15 issues with only 1 message have been created this week. > > > Issues waiting for review (15) > > == > > > > #1474680: pickling files works with protocol=2. > > http://bugs.python.org/issue1474680 > > [...] > > This is the list of issues with 'patch' or 'needs review' keywords or > 'patch review' stage that have been active during the last week. > The list is limited to max 15 issues. For both of these I think it is important that the fact that they are limited to 15 be mentioned in the section header. The issues needing review is a great addition, probably every bit as valuable as the no replies report. I hope that it, too, will draw on the previous weeks if there are less than fifteen that were active in the current week? > > Top issues most discussed (10) > > == > > > > #9079: Make gettimeofday available in time module > > http://bugs.python.org/issue9079 42 msgs > > [...] > > This is the list of issues with activity in the last week sorted by > number of message. > This list is limited to max 10 issues. I've already talked with Ezio in IRC about the fact that this list represents a regression from the old report, since the old report gave the issues with the most messages *during the week* whereas his current looks at the *total* message count for any issue that has had *any* activity during the current week. He's going to fix that. > > Issues closed (154) > > === > > > > #1474680: pickling files works with protocol=2. > > http://bugs.python.org/issue1474680 closed by alexandre.vassalotti > > [...] > > This is the list of *all* the issues closed in the last week *that are > still closed*. > Since this list might be quite long I put it at the end, to make it > easier to reach the other lists. It would be lovely if we could manage to get this one to be the longest table in the report each week :) -- R. David Murray www.bitdance.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] [Python-checkins] r83893 - python/branches/release27-maint/Misc/ACKS
On Tue, Aug 10, 2010 at 1:53 AM, "Martin v. Löwis" wrote: .. > People need to recognize that any kind of reference is really irrelevant > here. There is no "right" order that is better than any other "right" > order. I'd personally object to any English language dictionary telling > me how my name sorts in the alphabet. > Even when an English language dictionary follows German rules? :-) BTW, I did quietly bring Peter Åstrand back to the end of the list yesterday and I agree that this is rather unimportant. > (and yes, I do think it's "wrong" that it got sorted after Lyngvig - > in Germany, we put the ö as if it was "oe" - unlike the Swedes, which > put the very same letter after the rest of the alphabet. So the > ö in Chrigström sorts in a different way than the ö in Löwis. If I move > to Sweden, the file would have to change :-) I did search the mail archives for the discussion of Å's sorting order and now I think that the reference to Swedish rules is an ex-post rationalization. It looks like the original order was by Latin-1 code point and that explains both Å and ö positions. (I actually believe that the Swedish rules are fairly modern as well. Unlike other nations, Swedes don't mind breaking with traditions for modern conveniences. As far as I know, Sweden is the only nation where polite "you" (plural) was abolished by a language reform.) I raised this issue after one of my early check-ins got a response that acknowledgments should be alphabetized rather than added at the end of the list. [1] I pointed out that given that the file is encoded in UTF-8, it can potentially have last names starting with any unicode character and I was not familiar with any formal procedure that would define an alphabetic order in this case. A short brainstorming session on IRC and the tracker resulted with an agreement that no formal rule exists and the best we can do is to define the order as "rough". I am not 100% happy with this because I am sure people will keep discovering that the order in the file does not match the order suggested by their favorite sort program. I was also hoping to learn from this discussion what the state of the art in in sorting unicode words is. I believe this issue is addressed by some obscure parts of the unicode standard, but I am not familiar with them. [1] http://mail.python.org/pipermail/python-checkins/2010-May/093650.html ___ 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] mingw support?
On Tue, Aug 10, 2010 at 11:06 PM, wrote: > On Mon, Aug 09, 2010 at 06:55:29PM -0400, Terry Reedy wrote: >> On 8/9/2010 2:47 PM, Sturla Molden wrote: >> >> Terry Reedy: >> > >> >> MingW has become less attractive in recent years by the difficulty >> >> in downloading and installing a current version and finding out how to >> >> do so. Some projects have moved on to the TDM packaging of MingW. >> >> >> >> http://tdm-gcc.tdragon.net/ >> >> Someone else deserves credit for writing that and giving that link ;-) > > Yes, that was a great link, thanks. It works fine for me. > > The reason I was bringing up this topic again was that I think the gnu > autotools have been made for exactly this purpose, to port software to > different platforms, Autotools only help for posix-like platforms. They are certainly a big hindrance on windows platform in general, cheers, David ___ 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] Summary of Python tracker Issues
On 8/10/2010 10:28 AM, Ezio Melotti wrote: This is the list of *all* the issues created or reopened during the last week *that are still open*. Thank you for removing the duplication of listing issues opened and closed twice. I otherwise pretty much agree with RDM's comments. -- Terry Jan Reedy ___ 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] r83893 - python/branches/release27-maint/Misc/ACKS
On 8/10/2010 9:13 AM, Benjamin Peterson wrote: 2010/8/10 Stephen J. Turnbull: Benjamin Peterson writes: > 2010/8/9 Nick Coghlan: > > On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky > >wrote: > >> +PS: In the standard Python distribution, this file is encoded > >> in UTF-8 +and the list is in rough alphabetical order by last > >> names. > >> > >>David Abrahams > >>Jim Ahlstrom > >> @@ -28,6 +29,7 @@ > >>Éric Araujo > >>Jason Asbahr > >>David Ascher > >> +Peter Åstrand > > From my recollection of the discussion when Peter was added, the > > >first > > character in his last name actually sorts after Z (despite its > > resemblance to an A). > This is correct. Don't think of Å as a kind of "A". It's its own > letter, which sorts after Z in Swedish. That's true, but IIRC there are a fairly large number of letters where different languages collate them in different positions. Is it worth actually asking appropriate humans to think about this, or would it be better to use Unicode code point order for simplicity? I think it's largely a unimportant discussion. If people have an opinion of where their name should appear, they can by all means change it. However, "rough" is probably as best as it'll ever get. If I were committing a patch and was checking to see whether a name that started with a decorated A (or any other letter) were already in the list, I would look in the appropriate place in the A (or other) section, not after Z. Everyone working on the English-based Python distribution knows the order of the 26 English letters. Please use that order (including for decorated versions and tranliterations) instead of various idiosyncratic and possibly conflicting nationality-based rules. For instance, suppose a 'Jean Charbol' posts a patch? Should we really have to ask his/her 'nationality' before adding the name to the list? Suppose 'Charbol' was born in Spain but works in France? In Spain, at least, 'ch' words are alphabetized in dictionaries between 'c' and 'd' words. Did everyone already know that? I an mot ever sure if all Spanish-speaking countries still do that. I am under the impression that either the Irish or Scots have some fussy rules for Mc/Mac/O names but I don't know them and don't think we should observe them in our list. Librarians who filed author cards by birth nationality rules made the now-obsolete card catalogs less useful for users who not know both birth nationality and rule. Lets not repeat that mistake. -- Terry Jan Reedy ___ 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] r83893 - python/branches/release27-maint/Misc/ACKS
On 8/10/2010 3:25 PM, Terry Reedy wrote: Everyone working on the English-based Python distribution knows the order of the 26 English letters. Please use that order (including for decorated versions and tranliterations) instead of various idiosyncratic and possibly conflicting nationality-based rules. Since the list is now utf-8 instead of latin-1 encoded, we could include the actual native character name, if supplied, in parentheses after the English-alphabetized transliteration. If we were to follow native rules, all Japanese names, for instance, should be separately listed and ordered according to the Japanese order, which is quite different from the European orders. -- Terry Jan Reedy ___ 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] r83893 - python/branches/release27-maint/Misc/ACKS
2010/8/10 Terry Reedy : > On 8/10/2010 9:13 AM, Benjamin Peterson wrote: >> >> 2010/8/10 Stephen J. Turnbull: >>> >>> Benjamin Peterson writes: >>> > 2010/8/9 Nick Coghlan: >>> > > On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky >>> > > wrote: >>> > >> +PS: In the standard Python distribution, this file is encoded >>> > >> in UTF-8 +and the list is in rough alphabetical order by last >>> > >> names. >>> > >> >>> > >> David Abrahams >>> > >> Jim Ahlstrom >>> > >> @@ -28,6 +29,7 @@ >>> > >> Éric Araujo >>> > >> Jason Asbahr >>> > >> David Ascher >>> > >> +Peter Åstrand >>> > > From my recollection of the discussion when Peter was added, the >>> > > >first >>> > > character in his last name actually sorts after Z (despite its >>> > > resemblance to an A). >>> > This is correct. Don't think of Å as a kind of "A". It's its own >>> > letter, which sorts after Z in Swedish. >>> >>> That's true, but IIRC there are a fairly large number of letters where >>> different languages collate them in different positions. >>> >>> Is it worth actually asking appropriate humans to think about this, or >>> would it be better to use Unicode code point order for simplicity? >> >> I think it's largely a unimportant discussion. If people have an >> opinion of where their name should appear, they can by all means >> change it. However, "rough" is probably as best as it'll ever get. > > If I were committing a patch and was checking to see whether a name that > started with a decorated A (or any other letter) were already in the list, I > would look in the appropriate place in the A (or other) section, not after > Z. > > Everyone working on the English-based Python distribution knows the order of > the 26 English letters. Please use that order (including for decorated > versions and tranliterations) instead of various idiosyncratic and possibly > conflicting nationality-based rules. > > For instance, suppose a 'Jean Charbol' posts a patch? Should we really have > to ask his/her 'nationality' before adding the name to the list? No, but if he complains about it, we should change it. > Librarians who filed author cards by birth nationality rules made the > now-obsolete card catalogs less useful for users who not know both birth > nationality and rule. Lets not repeat that mistake. How often are people trying to search through Misc/ACKS, though? -- Regards, Benjamin ___ 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] r83893 - python/branches/release27-maint/Misc/ACKS
On Tue, Aug 10, 2010 at 3:25 PM, Terry Reedy wrote: .. > If I were committing a patch and was checking to see whether a name that > started with a decorated A (or any other letter) were already in the list, I > would look in the appropriate place in the A (or other) section, not after > Z. > > Everyone working on the English-based Python distribution knows the order of > the 26 English letters. Please use that order (including for decorated > versions and tranliterations) instead of various idiosyncratic and possibly > conflicting nationality-based rules. > I believe, the golden standard for this type of works can be found in the index pages of The Art of Computer Programming, http://www-cs-faculty.stanford.edu/~knuth/help.html#exotic It would be quite an effort to redo Misc/ACKS in that way, and even with ASCII transliteration of every name, there is still ambiguity: is "Van Rossum" sorted under "V", or under "R"? (See http://www.python.org/~guido/ for an answer.) Since it is apparent that no formal rule can be agreed upon, I think best effort "rough alphabetical" order is just fine. BTW, what is Arfrever Frehtes Taifersar Arahesis' last name? :-) ___ 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] r83893 - python/branches/release27-maint/Misc/ACKS
On 8/10/2010 3:44 PM, Benjamin Peterson wrote: No, but if he complains about it, we should change it. If "In rough English alphabetical order" is extended with "unless the person requests otherwise", then it should also be extended with "in which case the name is suffixed with '(phbr)' [or something similar] for 'put here by request'" so that a later, diligent person seeking to improve the ordering will not think that it out of standard order by accident or initial committer laziness and move it back. I believe we are having this discussion in part precisedly because Astrand after Z was not so tagged and was thought to have just been quickly appended. -- Terry Jan Reedy ___ 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] [Python-checkins] r83893 - python/branches/release27-maint/Misc/ACKS
> I am not 100% happy with this because I am sure people will keep > discovering that the order in the file does not match the order > suggested by their favorite sort program. I was also hoping to learn > from this discussion what the state of the art in in sorting unicode > words is. I believe this issue is addressed by some obscure parts of > the unicode standard, but I am not familiar with them. Actually, it's not. Rather, Unicode acknowledges that collation depends on the locale, see http://unicode.org/reports/tr10/ Of course, it would be possible to follow the Default Unicode Collation Element Table (DUCET). 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] r83893 - python/branches/release27-maint/Misc/ACKS
> If I were committing a patch and was checking to see whether a name that > started with a decorated A (or any other letter) were already in the > list, I would look in the appropriate place in the A (or other) section, > not after Z. > > Everyone working on the English-based Python distribution knows the > order of the 26 English letters. Please use that order (including for > decorated versions and tranliterations) instead of various idiosyncratic > and possibly conflicting nationality-based rules. So where do you put Γεώργιος Μπουτσιούκης? 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] r83893 - python/branches/release27-maint/Misc/ACKS
On Tue, Aug 10, 2010 at 6:29 PM, "Martin v. Löwis" wrote: .. > So where do you put Γεώργιος Μπουτσιούκης? > or Александр Белопольский for that matter? :-) ___ 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] r83893 - python/branches/release27-maint/Misc/ACKS
On Wed, Aug 11, 2010 at 12:35 AM, Alexander Belopolsky wrote: > On Tue, Aug 10, 2010 at 6:29 PM, "Martin v. Löwis" wrote: > .. >> So where do you put Γεώργιος Μπουτσιούκης? >> > > or Александр Белопольский for that matter? :-) James Tauber did a UCA implementation in Python it seems: http://jtauber.com/blog/2006/01/27/python_unicode_collation_algorithm/, we could use this as a pre-commit hook to check changes on ACKS ;) ___ 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] r83893 - python/branches/release27-maint/Misc/ACKS
Am 11.08.2010 00:35, schrieb Alexander Belopolsky: > On Tue, Aug 10, 2010 at 6:29 PM, "Martin v. Löwis" wrote: > .. >> So where do you put Γεώργιος Μπουτσιούκης? >> > > or Александр Белопольский for that matter? :-) If you care about that, feel free to add that spelling to the file. Somebody proposed to put it along with some latin transliteration, which I can sympathize with. If just the nickname in cyrillic is fine with you, it's of course fine, as well. 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] r83893 - python/branches/release27-maint/Misc/ACKS
On Tue, Aug 10, 2010 at 6:50 PM, "Martin v. Löwis" wrote:
..
>> or Александр Белопольский for that matter? :-)
>
> If you care about that, feel free to add that spelling to the file.
> Somebody proposed to put it along with some latin transliteration,
> which I can sympathize with.
>
That was Donald Knuth:
http://www-cs-faculty.stanford.edu/~knuth/help.html#exotic
> If just the nickname in cyrillic is fine with you, it's of course
> fine, as well.
I am more than happy with my entry in its current form. :-)
BTW, does anybody know if
Jiba = Jean-Baptiste LAMY ("Jiba")?
CCing SF address to find out.
___
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] Proposed tweaks to functools.wraps
Based on a pair of tracker issues (#3445 and #9396) I'm considering a couple of adjustments to functools.wraps for 3.2. The first (#3445) is a request from ages ago to make update_wrapper more forgiving when it encounters a missing attribute. Instead of throwing AttributeError (as it does now), it would just skip the missing attribute. This would allow wraps to be used with other callables that don't fully mimic the function API. I was initially opposed to the idea, but over time I've come to think this is a case where practicality beats purity (since that really sums up functools.wraps in general - it is already the case that the copied info isn't quite right for the decorated function, but it's still better than using the wrapper function's own metadata). The second (#9396) came up in the context of the new cache decorators added to functools, and allowing applications to choose their own caching strategies. I suggested exposing the original (uncached) function, and Raymond suggested that the easiest way to enable that would be for functools.update_wrapper to add a new attribute that provides a reference to the original function. Some time back, we considered doing this automatically as an integral part of decoration, but decided that wasn't appropriate. However, building it into the explicit wrapping functions makes sense to me. To avoid namespace conflicts, I plan to use "__wraps__" as the name for the reference to the original function. Thoughts? Concerns? Better ideas? Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Proposed tweaks to functools.wraps
2010/8/10 Nick Coghlan : > Based on a pair of tracker issues (#3445 and #9396) I'm considering a > couple of adjustments to functools.wraps for 3.2. > > The first (#3445) is a request from ages ago to make update_wrapper > more forgiving when it encounters a missing attribute. Instead of > throwing AttributeError (as it does now), it would just skip the > missing attribute. This would allow wraps to be used with other > callables that don't fully mimic the function API. I was initially > opposed to the idea, but over time I've come to think this is a case > where practicality beats purity (since that really sums up > functools.wraps in general - it is already the case that the copied > info isn't quite right for the decorated function, but it's still > better than using the wrapper function's own metadata). That seems fine. With class decorators, I suppose it might be possible to have something like: def class_deco(cls): @functools.wraps(cls) class Spam: pass @class_deco class Eggs: pass which would require ignoring the absence of __annotations__. > > The second (#9396) came up in the context of the new cache decorators > added to functools, and allowing applications to choose their own > caching strategies. I suggested exposing the original (uncached) > function, and Raymond suggested that the easiest way to enable that > would be for functools.update_wrapper to add a new attribute that > provides a reference to the original function. Some time back, we > considered doing this automatically as an integral part of decoration, > but decided that wasn't appropriate. However, building it into the > explicit wrapping functions makes sense to me. To avoid namespace > conflicts, I plan to use "__wraps__" as the name for the reference to > the original function. Namespace conflict with what? I would prefer "wraps" unless it's standardized as a behavior for all decorators. -- Regards, Benjamin ___ 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] Proposed tweaks to functools.wraps
> The second (#9396) came up in the context of the new cache decorators > added to functools, and allowing applications to choose their own > caching strategies. I suggested exposing the original (uncached) > function, and Raymond suggested that the easiest way to enable that > would be for functools.update_wrapper to add a new attribute that > provides a reference to the original function. I moved this feature request to its own bug after brief IRC discussion with RDM: http://bugs.python.org/issue9567 The idea was to separate concerns and eventually get feedback from people reading new-bugs-announce, but your email actually does that :) I say “add attribute to partial objects” in the bug title since I don’t know if it’s feasible in wraps only; while update_wrapper is simple Python code, wraps merely delegates to _functools.partial, so please change the title (and maybe add easy keyword) if appropriate. Regards ___ 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] Proposed tweaks to functools.wraps
On Wed, Aug 11, 2010 at 12:48 PM, Éric Araujo wrote: >> The second (#9396) came up in the context of the new cache decorators >> added to functools, and allowing applications to choose their own >> caching strategies. I suggested exposing the original (uncached) >> function, and Raymond suggested that the easiest way to enable that >> would be for functools.update_wrapper to add a new attribute that >> provides a reference to the original function. > > I moved this feature request to its own bug after brief IRC discussion > with RDM: http://bugs.python.org/issue9567 > > The idea was to separate concerns and eventually get feedback from > people reading new-bugs-announce, but your email actually does that :) > > I say “add attribute to partial objects” in the bug title since I don’t > know if it’s feasible in wraps only; while update_wrapper is simple > Python code, wraps merely delegates to _functools.partial, so please > change the title (and maybe add easy keyword) if appropriate. Ah, that's the trick though - the partial object is the *decorator*, so when you write @wraps(f) def wrapper: # it is equivalent to: def wrapper: # wrapper = partial(update_wrapper, wrapped=f)(wrapper) The partial object is a transient thing during the decoration process - the wrapper function itself is the object that persists. So it's only update_wrapper that needs changing to add the new attribute. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Proposed tweaks to functools.wraps
On Wed, Aug 11, 2010 at 12:39 PM, Benjamin Peterson wrote: >> The second (#9396) came up in the context of the new cache decorators >> added to functools, and allowing applications to choose their own >> caching strategies. I suggested exposing the original (uncached) >> function, and Raymond suggested that the easiest way to enable that >> would be for functools.update_wrapper to add a new attribute that >> provides a reference to the original function. Some time back, we >> considered doing this automatically as an integral part of decoration, >> but decided that wasn't appropriate. However, building it into the >> explicit wrapping functions makes sense to me. To avoid namespace >> conflicts, I plan to use "__wraps__" as the name for the reference to >> the original function. > > Namespace conflict with what? I would prefer "wraps" unless it's > standardized as a behavior for all decorators. With any existing attributes on the function - there's a reason update_wrapper includes a call to __dict__.update(). Using a normal attribute means having to consider the implications of what to do if the object being wrapped already has an attribute with that name. By using a system-reserved name, we can duck that question entirely. My recollection of previous discussions is that the reason we didn't make it an implicit part of the decoration process is because not all decoration is about creating wrapper functions, so it gets messy trying to decide whether or not it should be added. The explicit use of the @wraps decorator when creating the wrapper function resolves that particular concern nicely. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Proposed tweaks to functools.wraps
On Wed, Aug 11, 2010 at 12:39 PM, Benjamin Peterson wrote: > which would require ignoring the absence of __annotations__. It turns out the patch that added __annotations__ support also made a change to make all of the copied attributes optional. So I'll be tidying up the implementation of that, extending it to the updated attributes and adding unit tests to make sure they're all optional. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Proposed tweaks to functools.wraps
On 8/10/2010 10:58 PM, Nick Coghlan wrote: > On Wed, Aug 11, 2010 at 12:48 PM, Éric Araujo wrote: >>> The second (#9396) came up in the context of the new cache decorators >>> added to functools, and allowing applications to choose their own >>> caching strategies. I suggested exposing the original (uncached) >>> function, and Raymond suggested that the easiest way to enable that >>> would be for functools.update_wrapper to add a new attribute that >>> provides a reference to the original function. >> >> I moved this feature request to its own bug after brief IRC discussion >> with RDM: http://bugs.python.org/issue9567 >> >> The idea was to separate concerns and eventually get feedback from >> people reading new-bugs-announce, but your email actually does that :) >> >> I say “add attribute to partial objects” in the bug title since I don’t >> know if it’s feasible in wraps only; while update_wrapper is simple >> Python code, wraps merely delegates to _functools.partial, so please >> change the title (and maybe add easy keyword) if appropriate. > > Ah, that's the trick though - the partial object is the *decorator*, > so when you write > > @wraps(f) > def wrapper: ># > > it is equivalent to: > > def wrapper: ># > > wrapper = partial(update_wrapper, wrapped=f)(wrapper) > > The partial object is a transient thing during the decoration process > - the wrapper function itself is the object that persists. > > So it's only update_wrapper that needs changing to add the new attribute. > One of the things that's slightly irking about the decorator syntax is that a decorator is always called with exactly one argument, and that if you want to write a parameterized decorator you therefore end up writing a function that returns a function that returns a function. I've scratched my head about how partials (or indeed anything else) could be used to make the extra level of indirection necessary, but haven' come up with anything that even I could regard as acceptable. But I can't escape this feeling that there must be a way. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.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] Proposed tweaks to functools.wraps
On Tue, Aug 10, 2010 at 8:22 PM, Steve Holden wrote: > One of the things that's slightly irking about the decorator syntax is > that a decorator is always called with exactly one argument, and that if > you want to write a parameterized decorator you therefore end up writing > a function that returns a function that returns a function. > > I've scratched my head about how partials (or indeed anything else) > could be used to make the extra level of indirection necessary, but > haven' come up with anything that even I could regard as acceptable. But > I can't escape this feeling that there must be a way. Someone at EuroPython brought up this very criticism. But my argument against it is: you should be able to write either @bar(args) def func(): ... or foo = bar(args) @foo def func(): ... and you should be able to predict how these two relate using standard knowledge about what it means to say foo = bar(args) and then use foo in an expression. That pretty much rules out solutions using partial IMO. (Not that I mind -- I find examples using partial as hard to read as code using reduce()... :-) -- --Guido van Rossum (python.org/~guido) ___ 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] Proposed tweaks to functools.wraps
On Wed, Aug 11, 2010 at 1:22 PM, Steve Holden wrote: > One of the things that's slightly irking about the decorator syntax is > that a decorator is always called with exactly one argument, and that if > you want to write a parameterized decorator you therefore end up writing > a function that returns a function that returns a function. > > I've scratched my head about how partials (or indeed anything else) > could be used to make the extra level of indirection necessary, but > haven' come up with anything that even I could regard as acceptable. But > I can't escape this feeling that there must be a way. Making the parameterised decorator a callable rather than a function can sometimes help, provided there are only a few parameters actually needed in the wrapper function. Making parameterised decorators easier to parse mentally was pointed out [1] as a possible benefit of pursuing PEP 3150 (statement local namespaces). That PEP as a whole is still sitting in "not enough practical benefit to justify the pain" territory though. Cheers, Nick. [1] http://mail.python.org/pipermail/python-ideas/2010-July/007691.html -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] r83893 - python/branches/release27-maint/Misc/ACKS
On 8/10/2010 6:29 PM, "Martin v. Löwis" wrote: If I were committing a patch and was checking to see whether a name that started with a decorated A (or any other letter) were already in the list, I would look in the appropriate place in the A (or other) section, not after Z. Everyone working on the English-based Python distribution knows the order of the 26 English letters. Please use that order (including for decorated versions and tranliterations) instead of various idiosyncratic and possibly conflicting nationality-based rules. So where do you put Γεώργιος Μπουτσιούκης? As I said above, where the transliterated version Geor.. goes, with the tranliteration followed by '(Γεώργιος Μπουτσιούκης)' as I suggested elsewhere -- Terry Jan Reedy ___ 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
