Re: [Python-Dev] Loggers in the stdlib and logging configuration APIs
On Tue, Dec 28, 2010 at 6:28 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote: On 12/28/2010 12:19 AM, Vinay Sajip wrote: calls can support three levels of logger disabling: - leave all existing loggers enabled (existing option) I think you mean disabled - that's the current behaviour. - leave only flagged loggers enabled (new default behaviour) - disable all loggers not mentioned explicitly (new option) My words in his mouth, but I think he meant that the existing _default_ behavior should be changed, and the existing option (listed first), which is not default behaviour should be kept, and a third option to sort of achieve the current default behavior, but make it harder. It isn't really about making it harder - it is about changing the default behaviour in a backwards compatible way. As I see it, library level loggers (including those in the standard library) should be left enabled unless explicitly turned off, while application level loggers should be left disabled unless explicitly turned on. However, there is currently no way to indicate the default state for a given logger that isn't mentioned explicitly in a detailed config - they're all implicitly disabled (or enabled, if that option is passed in as part of the config). Changing to a 3-tier system lets libraries use logging for error messages without them being lost by the default configuration process. Cheers, Nick. -- 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] Loggers in the stdlib and logging configuration APIs
On Tue, Dec 28, 2010 at 6:53 PM, Nick Coghlan ncogh...@gmail.com wrote: On Tue, Dec 28, 2010 at 6:28 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote: On 12/28/2010 12:19 AM, Vinay Sajip wrote: calls can support three levels of logger disabling: - leave all existing loggers enabled (existing option) I think you mean disabled - that's the current behaviour. - leave only flagged loggers enabled (new default behaviour) - disable all loggers not mentioned explicitly (new option) My words in his mouth, but I think he meant that the existing _default_ behavior should be changed, and the existing option (listed first), which is not default behaviour should be kept, and a third option to sort of achieve the current default behavior, but make it harder. It isn't really about making it harder - it is about changing the default behaviour in a backwards compatible way. As I see it, library level loggers (including those in the standard library) should be left enabled unless explicitly turned off, while application level loggers should be left disabled unless explicitly turned on. To put a bit more nuance on that view: if the library uses the logger to report errors, it should *definitely* flag it to be implicitly enabled. If it is only used for info messages, then preferences will vary according to the library developer. The beauty of the logging system is that application authors can get at the logging information regardless of which default the library author chooses. Cheers, Nick. -- 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] r87518 - python/branches/py3k/Parser/tokenizer.c
Am 28.12.2010 01:07, schrieb Victor Stinner: (oops, I posted an incomplete message, stupid mailer) Le lundi 27 décembre 2010 à 22:22 +0100, Georg Brandl a écrit : Am 27.12.2010 21:12, schrieb victor.stinner: Author: victor.stinner Date: Mon Dec 27 21:12:13 2010 New Revision: 87518 Log: Issue #10778: decoding_fgets() decodes the filename from the filesystem encoding instead of UTF-8. Hmm, and in case decoding fails, we return a Unicode error (without context) instead of a syntax error? Yes, but it is very unlikely. I don't see in which case the decoder can fail. But a memory error can occur. Doesn't seem like a good trade-off when the file name is just displayed in a message. What do you suggest? If the probability is so low, it's probably not worth changing. I'm just somewhat sensitive to changes that enforce correctness by taking away useful information from the user. Georg ___ 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] [Python-checkins] r87505 - in python/branches/py3k: Doc/c-api/unicode.rst Include/unicodeobject.h
Le lundi 27 décembre 2010 à 23:13 -0500, R. David Murray a écrit : Modified: python/branches/py3k/Doc/c-api/unicode.rst == --- python/branches/py3k/Doc/c-api/unicode.rst (original) +++ python/branches/py3k/Doc/c-api/unicode.rst Mon Dec 27 02:49:29 2010 @@ -1063,7 +1063,8 @@ .. c:function:: int PyUnicode_CompareWithASCIIString(PyObject *uni, char *string) Compare a unicode object, *uni*, with *string* and return -1, 0, 1 for less - than, equal, and greater than, respectively. + than, equal, and greater than, respectively. *string* is an ASCII-encoded + string (it is interpreted as ISO-8859-1). Does it mean anything to say that an ASCII string is interpreted as ISO-8859-1? If it is ASCII-encoded it shouldn't have any bytes with the 8th bit set, leaving no room for interpretation. So presumably you mean it is (treated as) an ISO-8859-1 encoded string, despite the function name? Oh. Someone noticed :-) I would like to say that it is better to pass only ASCII-encoded string, but the function supports ISO-8859-1. Would it be more clear to say that the function expects ISO-8859-1 encoded string? But I don't want to patch the function. Victor ___ 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] [Python-checkins] r87504 - in python/branches/py3k: Doc/c-api/exceptions.rst Include/pyerrors.h Include/warnings.h
Le lundi 27 décembre 2010 à 23:07 -0500, R. David Murray a écrit : On Mon, 27 Dec 2010 02:49:27 +0100, victor.stinner python-check...@python.org wrote: Author: victor.stinner Date: Mon Dec 27 02:49:26 2010 New Revision: 87504 Log: Issue #9738: Document encodings of error and warning functions ASCII-encoded string, or ASCII encoding-string? Oh, I don't really care. Which one do you prefer? I used ASCII-encoded string and UTF-8 encoded string, because UTF-8-encoded has too many -. I should maybe be uniformized. Victor ___ 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] [Python-checkins] r87504 - in python/branches/py3k: Doc/c-api/exceptions.rst Include/pyerrors.h Include/warnings.h
Am 28.12.2010 11:28, schrieb Victor Stinner: Le lundi 27 décembre 2010 à 23:07 -0500, R. David Murray a écrit : On Mon, 27 Dec 2010 02:49:27 +0100, victor.stinner python-check...@python.org wrote: Author: victor.stinner Date: Mon Dec 27 02:49:26 2010 New Revision: 87504 Log: Issue #9738: Document encodings of error and warning functions ASCII-encoded string, or ASCII encoding-string? Oh, I don't really care. Which one do you prefer? I used ASCII-encoded string and UTF-8 encoded string, because UTF-8-encoded has too many -. I should maybe be uniformized. David's other concern was whether it should be encod*ed* or encod*ing*. It seems he would prefer encoded. Not sure what he would prefer wrt. hyphens (but apparently, you would put the hyphen after if it's encoding, and before if it's encoded; not sure why that is). 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] r87518 - python/branches/py3k/Parser/tokenizer.c
Le mardi 28 décembre 2010 à 10:12 +0100, Georg Brandl a écrit : Author: victor.stinner Date: Mon Dec 27 21:12:13 2010 New Revision: 87518 Log: Issue #10778: decoding_fgets() decodes the filename from the filesystem encoding instead of UTF-8. Hmm, and in case decoding fails, we return a Unicode error (without context) instead of a syntax error? I created an issue for this problem, but also to prepare the full support of unicode in the import machinery. I patched the import machinery of Python 3 to support undecodable bytes, but Python 3 doesn't support unencodable characters on Windows (see issue #3080). http://bugs.python.org/issue10785 Victor ___ 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] [Python-checkins] r87504 - in python/branches/py3k: Doc/c-api/exceptions.rst Include/pyerrors.h Include/warnings.h
Martin v. Löwis, 28.12.2010 11:40: Le lundi 27 décembre 2010 à 23:07 -0500, R. David Murray a écrit : ASCII-encoded string, or ASCII encoding-string? [...] apparently, you would put the hyphen after if it's encoding, and before if it's encoded; not sure why that is I think David just put it there to point to the semantic difference. It's either a string that is ASCII encoded, or an encoding string that refers to ASCII in some way. Whether you put a hyphen or not is a secondary concern. 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] Loggers in the stdlib and logging configuration APIs
Glenn Linderman v+python at g.nevcal.com writes: I thought of the idea of a flag to make loggers immune, but it seemed it could lead to an arms race, where the knee-jerk reaction of discovering that a library's logger got disabled would be to set the flag, and, of course, the knee-jerk reaction of discovering that a library's logger produced an unwanted message would cause the application to use the new option, to turn them all off again. Then a new library logger option, to become immune to the new disable them all option, would be requested. Etc. Although an arms race is theoretically possible, I doubt it would come to that. After all, people can just set a logger's disabled flag to False, and its messages would start flowing again. That would be as easy for users as making any new API call. That's why I suggested a list, although perhaps your scheme would be more backward compatible, as it defines a meaning for the default behavior that sounds somewhat similar to the current default behavior but isn't, really. Interesting that you choose to disable all loggers not mentioned explicitly (a logger white list), whereas I suggested listing the ones to disable (a logger black list). That's the backward compatible behaviour. In general, when the configuration APIs are called, the design assumption was that you want to replace any existing configuration with a new one; that now needs to change because of places where logging will be used for notifications where exceptions cannot be usefully raised. I suppose you suggested the white list, figuring that the application could choose which messages it wishes to see. An application can always choose not to see or not see messages via setting verbosity levels on specific loggers and/or handlers to the desired values. I chose a black list, figuring that new messages being introduced might be useful to the application, but if they never see them (because they are not in the white list), they wouldn't know about them. Of course, either scheme can be programmed around, given an Don't forget that any loggers created after a fileConfig/dictConfig call wouldn't be disabled; and for many many uses, logging will be set up reasonably early in the application's execution, and the only loggers which would be disabled by a configuration call would be loggers created before the call, and which are not explicitly named in the configuration. There will be relatively few of those. messages. Applications that use logging, really should be prepared for new messages to be displayed. Testing won't discover them all, disabling them could result in useful messages being suppressed. Yes, because third party libraries can introduce new messages either by themseleves or through adding a new dependency, but disabling via a config call is unlikely if the config call is made early. Should a module's documentation be expected to include lists of log messages that it may produce at any level of logging? That would never be kept up to date :-) The best we can hope for is for module authors to document that they use logging, mention any logger names used, the default level settings for at least the top-level logger, and any convenience APIs provided for configuring handlers. Suppose we just implement a leave_enabled flag on loggers and change the config code to honour this. Then, there will be no backward incompatible change until we modify stdlib loggers to set leave_enabled to True (I'm not sure if this could be done for concurrent.futures now as it's a new package in 3.2; it depends on whether this would be regarded as a new feature). I don't propose adding another optional argument to the configuration APIs unless and until there seems to be a need for it; in the absence of this argument, users would have to explicitly turn off loggers they wanted to silence in the normal way (i.e. by setting levels, and perhaps propagation flags). I would propose to document leave_enabled as part of the public API, but with a recommendation that due care and consideration be given before choosing to set it for a logger. How does that sound? Regards, Vinay Sajip ___ 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] [Python-checkins] r87504 - in python/branches/py3k: Doc/c-api/exceptions.rst Include/pyerrors.h Include/warnings.h
Le mardi 28 décembre 2010 à 11:40 +0100, Martin v. Löwis a écrit : Am 28.12.2010 11:28, schrieb Victor Stinner: Le lundi 27 décembre 2010 à 23:07 -0500, R. David Murray a écrit : On Mon, 27 Dec 2010 02:49:27 +0100, victor.stinner python-check...@python.org wrote: Author: victor.stinner Date: Mon Dec 27 02:49:26 2010 New Revision: 87504 Log: Issue #9738: Document encodings of error and warning functions ASCII-encoded string, or ASCII encoding-string? Oh, I don't really care. Which one do you prefer? I used ASCII-encoded string and UTF-8 encoded string, because UTF-8-encoded has too many -. I should maybe be uniformized. David's other concern was whether it should be encod*ed* or encod*ing*. Ooops, it's ASCII-encoded string (and not ASCII-encoding string): fixed by r87529. Victor ___ 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] [Python-checkins] r87504 - in python/branches/py3k: Doc/c-api/exceptions.rst Include/pyerrors.h Include/warnings.h
On Tue, 28 Dec 2010 13:58:24 +0100, Victor Stinner victor.stin...@haypocalc.com wrote: Le mardi 28 décembre 2010 à 11:40 +0100, Martin v. Löwis a écrit : Am 28.12.2010 11:28, schrieb Victor Stinner: Le lundi 27 décembre 2010 à 23:07 -0500, R. David Murray a écrit : On Mon, 27 Dec 2010 02:49:27 +0100, victor.stinner python-check...@python.org wrote: Author: victor.stinner Date: Mon Dec 27 02:49:26 2010 New Revision: 87504 Log: Issue #9738: Document encodings of error and warning functions ASCII-encoded string, or ASCII encoding-string? Oh, I don't really care. Which one do you prefer? I used ASCII-encoded string and UTF-8 encoded string, because UTF-8-encoded has too many -. I should maybe be uniformized. David's other concern was whether it should be encod*ed* or encod*ing*. Ooops, it's ASCII-encoded string (and not ASCII-encoding string): fixed by r87529. Yes, exactly. Sorry for being a bit too subtle in my error report. -- R. David Murray www.bitdance.com ___ 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] [Python-checkins] r87505 - in python/branches/py3k: Doc/c-api/unicode.rst Include/unicodeobject.h
On Tue, 28 Dec 2010 10:28:51 +0100, Victor Stinner victor.stin...@haypocalc.com wrote: Le lundi 27 décembre 2010 à 23:13 -0500, R. David Murray a écrit : Modified: python/branches/py3k/Doc/c-api/unicode.rst == --- python/branches/py3k/Doc/c-api/unicode.rst (original) +++ python/branches/py3k/Doc/c-api/unicode.rst Mon Dec 27 02:49:29 2010 @@ -1063,7 +1063,8 @@ .. c:function:: int PyUnicode_CompareWithASCIIString(PyObject *uni, char *string) Compare a unicode object, *uni*, with *string* and return -1, 0, 1 for less - than, equal, and greater than, respectively. + than, equal, and greater than, respectively. *string* is an ASCII-encoded + string (it is interpreted as ISO-8859-1). Does it mean anything to say that an ASCII string is interpreted as ISO-8859-1? If it is ASCII-encoded it shouldn't have any bytes with the 8th bit set, leaving no room for interpretation. So presumably you mean it is (treated as) an ISO-8859-1 encoded string, despite the function name? Oh. Someone noticed :-) I would like to say that it is better to pass only ASCII-encoded string, but the function supports ISO-8859-1. Would it be more clear to say that the function expects ISO-8859-1 encoded string? But I don't want to patch the function. I think your first paragraph is what you should put in the docs: it is best to pass only ASCII-encoded strings, but the function interprets the input string as ISO-8859-1 if it contains non-ASCII characters. A bit harder to compress that into an in-line comment in the code... -- R. David Murray www.bitdance.com ___ 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] Loggers in the stdlib and logging configuration APIs
On 12/28/2010 4:16 AM, Vinay Sajip wrote: How does that sound? Sounds pretty rational, overall. If the leave_enabled flag can be turned on/off by the application, then I agree the arms race is unlikely. I didn't dig through the logging docs to discover if there is an API that returns a list of currently known loggers such that an application could easily discover the current set. It would be nice to have such a thing, in any case, but especially in the presence of the leave_enabled flag. I also wasn't sure whether or not the default disable applied to future loggers or only preexisting loggers, but you clarified that it only applies to preexisting ones, so such an API as above would suffice to discover any that might need special handling at xxxConfig time. I hope somewhere in the parts of the documentation I haven't read yet, that there is some verbiage that discusses the fact that loggers created after xxxConfig time and not configured by it, are enabled by default? And the concept that applications that use logging should be prepared to handle messages that they haven't seen before in some manner. ___ 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] Possible optimization for LOAD_FAST ?
Consider the following code: def foobar(x): for i in range(5): x[i] = i The bytecode in python 2.7 is the following: 2 0 SETUP_LOOP 30 (to 33) 3 LOAD_GLOBAL 0 (range) 6 LOAD_CONST 1 (5) 9 CALL_FUNCTION1 12 GET_ITER 13 FOR_ITER16 (to 32) 16 STORE_FAST 1 (i) 3 19 LOAD_FAST1 (i) 22 LOAD_FAST0 (x) 25 LOAD_FAST1 (i) 28 STORE_SUBSCR 29 JUMP_ABSOLUTE 13 32 POP_BLOCK 33 LOAD_CONST 0 (None) 36 RETURN_VALUE Can't we optimize the LOAD_FAST in lines 19 and 25 to a single load and put the reference twice on the stack? There is no way that the reference of i might change in between the two lines. Also, the load_fast in lne 22 to reference x could be taken out of the loop as x will always point to the same object ___ 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] Possible optimization for LOAD_FAST ?
2010/12/28 Lukas Lueg lukas.l...@googlemail.com: Consider the following code: def foobar(x): for i in range(5): x[i] = i The bytecode in python 2.7 is the following: 2 0 SETUP_LOOP 30 (to 33) 3 LOAD_GLOBAL 0 (range) 6 LOAD_CONST 1 (5) 9 CALL_FUNCTION 1 12 GET_ITER 13 FOR_ITER 16 (to 32) 16 STORE_FAST 1 (i) 3 19 LOAD_FAST 1 (i) 22 LOAD_FAST 0 (x) 25 LOAD_FAST 1 (i) 28 STORE_SUBSCR 29 JUMP_ABSOLUTE 13 32 POP_BLOCK 33 LOAD_CONST 0 (None) 36 RETURN_VALUE Can't we optimize the LOAD_FAST in lines 19 and 25 to a single load and put the reference twice on the stack? Yes. Would it be useful? Unlikely. -- Regards, Benjamin ___ 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] Loggers in the stdlib and logging configuration APIs
Glenn Linderman v+python at g.nevcal.com writes: I didn't dig through the logging docs to discover if there is an API that returns a list of currently known loggers such that an application could easily discover the current set. It would be nice to have such a thing, in any case, but especially in the presence of the leave_enabled flag. There isn't one, though I'll see about providing it in 3.3. I hope somewhere in the parts of the documentation I haven't read yet, that there is some verbiage that discusses the fact that loggers created after xxxConfig time and not configured by it, are Not quite; the fact that existing loggers are disabled by the configuration calls is documented, as that would be the thing that might be unexpected. That newly-created loggers would be enabled isn't documented specifically, as it is what one would expect. enabled by default? And the concept that applications that use logging should be prepared to handle messages that they haven't seen before in some manner. That concept is also not mentioned explicitly, because the rationale given for having a logging module in the stdlib is that it can be used by modules from different sources (standard library, 3rd party libs, application code) and provide logs in an integrated manner. So the expectation you describe would follow naturally. Thanks for the feedback, Vinay Sajip ___ 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] Possible optimization for LOAD_FAST ?
Am 28.12.2010 18:24, schrieb Benjamin Peterson: 2010/12/28 Lukas Lueg lukas.l...@googlemail.com: Consider the following code: def foobar(x): for i in range(5): x[i] = i The bytecode in python 2.7 is the following: 2 0 SETUP_LOOP 30 (to 33) 3 LOAD_GLOBAL 0 (range) 6 LOAD_CONST 1 (5) 9 CALL_FUNCTION1 12 GET_ITER 13 FOR_ITER16 (to 32) 16 STORE_FAST 1 (i) 3 19 LOAD_FAST1 (i) 22 LOAD_FAST0 (x) 25 LOAD_FAST1 (i) 28 STORE_SUBSCR 29 JUMP_ABSOLUTE 13 32 POP_BLOCK 33 LOAD_CONST 0 (None) 36 RETURN_VALUE Can't we optimize the LOAD_FAST in lines 19 and 25 to a single load and put the reference twice on the stack? Yes. Would it be useful? Unlikely. Is it tricky to get all the corner cases right? Very probably :) Georg ___ 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] os.getpriority() and os.setpriority()
I think it would be nice to have Windows equivalents (GetPriorityClass / SetPriorityClass) as well but I'm not sure how since their notation is different. I don't mind exposing it (somewhere), however, it should keep its original name. In addition, you probably need OpenProcess, as well as Get/SetThreadPriority along with it. I think Python should incorporate something like pywin32, to expose all APIs whole-sale, in a type-safe manner (unlike ctypes). 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] [Python-checkins] r87537 - in python/branches/py3k: Doc/library/struct.rst Doc/whatsnew/3.2.rst Lib/test/test_struct.py Lib/wave.py Misc/NEWS Modules/_struct.c
On 12/28/2010 8:26 AM, victor.stinner wrote: Author: victor.stinner Date: Tue Dec 28 14:26:42 2010 New Revision: 87537 Log: Issue #10783: struct.pack() doesn't encode implicitly unicode to UTF-8 Modified: python/branches/py3k/Doc/whatsnew/3.2.rst == --- python/branches/py3k/Doc/whatsnew/3.2.rst (original) +++ python/branches/py3k/Doc/whatsnew/3.2.rst Tue Dec 28 14:26:42 2010 @@ -1705,3 +1705,7 @@ (Contributed by Georg Brandl and Mattias Brändström; `appspot issue 53094http://codereview.appspot.com/53094`_.) + +* :func:`struct.pack` doesn't encode implicitly unicode to UTF-8 anymore: That phrasing is awkward at best. I believe you mean struct.pack no longer implicitly encodes unicode to UTF-8, which will be clearer to most people. Terry ___ 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] [Python-checkins] r87537 - in python/branches/py3k: Doc/library/struct.rst Doc/whatsnew/3.2.rst Lib/test/test_struct.py Lib/wave.py Misc/NEWS Modules/_struct.c
Le mardi 28 décembre 2010 à 15:22 -0500, Terry Reedy a écrit : On 12/28/2010 8:26 AM, victor.stinner wrote: Author: victor.stinner Date: Tue Dec 28 14:26:42 2010 New Revision: 87537 Log: Issue #10783: struct.pack() doesn't encode implicitly unicode to UTF-8 Modified: python/branches/py3k/Doc/whatsnew/3.2.rst == --- python/branches/py3k/Doc/whatsnew/3.2.rst (original) +++ python/branches/py3k/Doc/whatsnew/3.2.rst Tue Dec 28 14:26:42 2010 @@ -1705,3 +1705,7 @@ (Contributed by Georg Brandl and Mattias Brändström; `appspot issue 53094http://codereview.appspot.com/53094`_.) + +* :func:`struct.pack` doesn't encode implicitly unicode to UTF-8 anymore: That phrasing is awkward at best. Sorry, I am still learning english :-) I believe you mean struct.pack no longer implicitly encodes unicode to UTF-8, which will be clearer to most people. Yes, done in r87559 Victor ___ 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] [Python-checkins] r87505 - in python/branches/py3k: Doc/c-api/unicode.rst Include/unicodeobject.h
Le mardi 28 décembre 2010 à 12:14 -0500, R. David Murray a écrit : I think your first paragraph is what you should put in the docs: it is best to pass only ASCII-encoded strings, but the function interprets the input string as ISO-8859-1 if it contains non-ASCII characters. Nice, done in r87560 Victor ___ 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] Backport troubles with mercurial
Hello, The PyPy project recently switched from svn to mercurial. Since this day I have some difficulties to perform simple tasks, and my questions did not receive satisfying answers. I was sure the Python project would have the same issues; so I started from the repositories in http://code.python.org/hg/ and tried simple merges between Python versions. I would like several people to try the same example, and tell how they handle it. I'm new to mercurial, and I may have missed something important! Let's say you have to do the simple change shown in the diff below, and want to fix the the 3 usual versions: py3k, release31-maint, release27-maint. The diff was made against py3k. How would you do it with Mercurial? Please try to do it for real! hg merge is not the correct command: it merges whole branches, a change comes with all its ancestors. What we want is to cherry-pick a single change. hg transplant fails to apply the change to release31-maint because of a tiny conflict (in the diff context!) that leaves you with an ugly hunks FAILED and a .rej file you have to parse and apply by hand. hg transplant seems to succeed in release27-maint, but the test fails to run because support should be changed to test_support. The change is already committed - to fix it another changeset is needed. This does not look clean to me: both changesets will be pushed to the repository, and diff review (on the python-checkins mailing list) is almost impossible. Furthermore, hg transplant does not keep track of integrations. There is a transplants file, but it stays in my local clone. Faced with a similar case in pypy, we finally manually copied the files between directories... and the fastest with our example is probably to do the change manually in all three directories. There is surely a better way to work with maintenance branches! PEP374 suggests to first modify the oldest release, but this does not seems right to me (I have three reasons in mind) At the moment, I feel that mercurial just cannot work for core Python development. At the very least before the migration we need precise use cases like this and recipes for common cases. Thanks for your help, -- Amaury Forgeot d'Arc diff -r 2777ae4d10d9 Lib/test/test_contextlib.py --- a/Lib/test/test_contextlib.py Tue Dec 28 22:14:34 2010 +0100 +++ b/Lib/test/test_contextlib.py Wed Dec 29 00:08:18 2010 +0100 @@ -26,6 +26,7 @@ state.append(x) self.assertEqual(state, [1, 42, 999]) +@support.cpython_only def test_contextmanager_finally(self): state = [] @contextmanager @@ -36,10 +37,10 @@ finally: state.append(999) with self.assertRaises(ZeroDivisionError): -with woohoo() as x: +with woohoo() as y: self.assertEqual(state, [1]) -self.assertEqual(x, 42) -state.append(x) +self.assertEqual(y, 42) +state.append(y) raise ZeroDivisionError() self.assertEqual(state, [1, 42, 999]) ___ 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] [Python-checkins] r87523 - python/branches/py3k/Doc/tutorial/interpreter.rst
It might still be worth saying something like: Note that this python file does something subtly different; the details are not included in this tutorial. On Tue, Dec 28, 2010 at 4:18 AM, georg.brandl python-check...@python.org wrote: Author: georg.brandl Date: Tue Dec 28 10:18:24 2010 New Revision: 87523 Log: Remove confusing paragraph -- this is relevant only to advanced users anyway and does not belong into the tutorial. Modified: python/branches/py3k/Doc/tutorial/interpreter.rst Modified: python/branches/py3k/Doc/tutorial/interpreter.rst == --- python/branches/py3k/Doc/tutorial/interpreter.rst (original) +++ python/branches/py3k/Doc/tutorial/interpreter.rst Tue Dec 28 10:18:24 2010 @@ -58,14 +58,6 @@ ``python -m module [arg] ...``, which executes the source file for *module* as if you had spelled out its full name on the command line. -Note that there is a difference between ``python file`` and ``python -file``. In the latter case, input requests from the program, such as calling -``sys.stdin.read()``, are satisfied from *file*. Since this file has already -been read until the end by the parser before the program starts executing, the -program will encounter end-of-file immediately. In the former case (which is -usually what you want) they are satisfied from whatever file or device is -connected to standard input of the Python interpreter. - When a script file is used, it is sometimes useful to be able to run the script and enter interactive mode afterwards. This can be done by passing :option:`-i` before the script. (This does not work if the script is read from standard ___ Python-checkins mailing list python-check...@python.org http://mail.python.org/mailman/listinfo/python-checkins ___ 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] [Python-checkins] r87537 - in python/branches/py3k: Doc/library/struct.rst Doc/whatsnew/3.2.rst Lib/test/test_struct.py Lib/wave.py Misc/NEWS Modules/_struct.c
On Wed, 29 Dec 2010 00:38:13 +0100, Victor Stinner victor.stin...@haypocalc.com wrote: Le mardi 28 décembre 2010 à 15:22 -0500, Terry Reedy a écrit : On 12/28/2010 8:26 AM, victor.stinner wrote: Author: victor.stinner Date: Tue Dec 28 14:26:42 2010 New Revision: 87537 Log: Issue #10783: struct.pack() doesn't encode implicitly unicode to UTF-8 Modified: python/branches/py3k/Doc/whatsnew/3.2.rst == --- python/branches/py3k/Doc/whatsnew/3.2.rst (original) +++ python/branches/py3k/Doc/whatsnew/3.2.rst Tue Dec 28 14:26:42 2010 @@ -1705,3 +1705,7 @@ (Contributed by Georg Brandl and Mattias Brändström; `appspot issue 53094http://codereview.appspot.com/53094`_.) + +* :func:`struct.pack` doesn't encode implicitly unicode to UTF-8 anymore: That phrasing is awkward at best. Sorry, I am still learning english :-) I believe you mean struct.pack no longer implicitly encodes unicode to UTF-8, which will be clearer to most people. Yes, done in r87559 You still have two words swapped. You changed it to no longer encodes implicitly unicode but it should be no longer implicitly encodes unicode -- R. David Murray www.bitdance.com ___ 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] [Python-checkins] r87523 - python/branches/py3k/Doc/tutorial/interpreter.rst
On Wed, Dec 29, 2010 at 10:35 AM, Jim Jewett jimjjew...@gmail.com wrote: It might still be worth saying something like: Note that this python file does something subtly different; the details are not included in this tutorial. No, it this in fact puzzling. I was fine with the previous paragraph and if someone found it confusing, removing it is okay. But the above suggested sentence would leave the reader with an incomplete information. -- Senthil ___ 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] Backport troubles with mercurial
On Wed, Dec 29, 2010 at 9:13 AM, Amaury Forgeot d'Arc amaur...@gmail.com wrote: Hello, The PyPy project recently switched from svn to mercurial. Since this day I have some difficulties to perform simple tasks, and my questions did not receive satisfying answers. I was sure the Python project would have the same issues; so I started from the repositories in http://code.python.org/hg/ and tried simple merges between Python versions. I would like several people to try the same example, and tell how they handle it. I'm new to mercurial, and I may have missed something important! Let's say you have to do the simple change shown in the diff below, and want to fix the the 3 usual versions: py3k, release31-maint, release27-maint. The diff was made against py3k. How would you do it with Mercurial? Please try to do it for real! The easiest way I found to emulate git cherry-pick (which does exactly what you want) with hg is to use import/export commands: http://mercurial.selenic.com/wiki/CommunicatingChanges It is indeed quite a pain to use in my experience, because you cannot easily refer to the original commit the cherry pick is coming from (i.e. no equivalent to git cherry-pick -x), and the conflict resolution is quite dumb. One alternative is to be careful about where you apply your patch (http://stackoverflow.com/questions/3926906/what-is-the-most-efficient-way-to-handle-hg-import-rejects), but that's not very convenient either. cheers, 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] [Python-checkins] r87537 - in python/branches/py3k: Doc/library/struct.rst Doc/whatsnew/3.2.rst Lib/test/test_struct.py Lib/wave.py Misc/NEWS Modules/_struct.c
Victor Stinner writes: Sorry, I am still learning english :-) Aren't we all! :-) ___ 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
