According to the consensus (and loosely following the Google spreadsheet
I created for that purpose), I have removed the Demo directory from py3k.
Most demos have been deleted; some have been moved into Tools or into the
docs as an example. If I removed something you think should have stayed,
please speak up.
I kept a few less-useful ones in a new directory called Tools/demo that
aims to give a broad overview of what you can do with a few lines of Python.
Please feel free to remove and/or add demos there, if you find better ones.
Georg
In python-list thread "Does Python 3.1 accept \r\n in compile()?"
jmfauth notes that
compile('print(999)\r\n', '<in>', 'exec')
works in 2.7 but not 3.1 (and 3.2 not checked) because 3.1 sees '\r' as
SyntaxError.
I started to respond that this is part of Py3 cleanup with newlines
converted on input and back-compatibility with ancient Python not
needed. Then I saw in 3.2 manual
"Changed in version 3.2: Allowed use of Windows and Mac newlines. Also
input in 'exec' mode does not have to end in a newline anymore. Added
the optimize parameter."
I verified second statement ("print(999)" works) (and remember commit
for third), but original above gives same error. Should "Allowed use of
Windows and Mac newlines." be deleted? What else could it mean other
than use of '\r' or '\r\n'?
--
Terry Jan Reedy
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 53094<http://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
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-checkins(a)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-checkins(a)python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
On Mon, 27 Dec 2010 02:49:29 +0100, victor.stinner <python-checkins(a)python.org> wrote:
> Author: victor.stinner
> Date: Mon Dec 27 02:49:29 2010
> New Revision: 87505
>
> Log:
> Issue #9738: document encodings of unicode functions
>
> Modified:
> python/branches/py3k/Doc/c-api/unicode.rst
> python/branches/py3k/Include/unicodeobject.h
>
> 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?
--
R. David Murray www.bitdance.com
The logging configuration calls fileConfig and dictConfig disable all existing
loggers, and enable only loggers explicitly named in the configuration (and
their children). Although there is a disable_existing_loggers option for each
configuration API, which can be used to prevent disabling of existing loggers,
the default value of this option is True (for backward compatibility) and so
existing ("old") loggers are disabled by default.
This can lead to unexpected behaviour when loggers are used by the standard
library. A recent issue,
http://bugs.python.org/issue10626
relates to test_concurrent_futures failing, but only when exercised twice with a
test_logging call in between, as in
regrtest.py test_concurrent_futures test_logging test_concurrent_futures
I've fixed test_logging so that it remembers the disabled state of existing
loggers and restores it, and now the above test works fine. However, since
recent changes in logging, we are expecting to use it to e.g. display messages
on stderr when exceptions can't be raised in stdlib code. Thus, I think I may
need to change the way disabling of loggers works, so I wanted to get some
feedback from python-dev both about possible approaches and when to apply them
(With 3.2 so close to release I'm not proposing to do anything precipitate, just
raising the issue for discussion).
Essentially, some or all of the loggers in the stdlib itself should perhaps be
immune to the "disable existing loggers" logic. Otherwise, a fileConfig() or
dictConfig() call with default semantics will prevent a stdlib message (logged
when exceptions can't be raised) from being displayed, unless a user explicitly
names those stdlib loggers in their configuration. This is not practical because
users would need to update their configurations whenever a new logger appeared
in the stdlib. Some possible approaches are:
1. Change the default configuration behaviour so that by default, existing
loggers are NOT disabled. This is of course strongly backwards-incompatible, but
would it make sense to consider it for 3.3? Perhaps we should add a warning?
2. Change the disabling logic so that it never disables stdlib loggers. This
raises the question of how to identify them, and there are several loggers in
the stdlib in 3.2:
"py.warnings" (used by the logging package when warnings are redirected to
logging),
"concurrent.futures",
"http.cookiejar",
"multiprocessing"
However, it would be good to have some consistency of naming stdlib loggers
- perhaps using __name__ as is recommended practice for library and application
developers, but with a prefix such as "py." to indicate that it's a part of the
stdlib. This would make the disabling logic change easier as it could just check
the "py." prefix rather than have an internal list of logger names, which would
need more maintenance and be more error-prone.
There are quite possibly other approaches I haven't thought of. I'd be grateful
for your suggestions, as I'd like to minimise the impact on users, while making
it easy to add more logging to the stdlib.
Regards,
Vinay Sajip
On Mon, 27 Dec 2010 02:49:27 +0100, victor.stinner <python-checkins(a)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
>
> Modified:
> python/branches/py3k/Doc/c-api/exceptions.rst
> python/branches/py3k/Include/pyerrors.h
> python/branches/py3k/Include/warnings.h
>
> Modified: python/branches/py3k/Doc/c-api/exceptions.rst
> ==============================================================================
> --- python/branches/py3k/Doc/c-api/exceptions.rst (original)
> +++ python/branches/py3k/Doc/c-api/exceptions.rst Mon Dec 27 02:49:26 2010
> @@ -148,7 +148,8 @@
> This function sets the error indicator and returns *NULL*. *exception*
> should be a Python exception class. The *format* and subsequent
> parameters help format the error message; they have the same meaning and
> - values as in :c:func:`PyUnicode_FromFormat`.
> + values as in :c:func:`PyUnicode_FromFormat`. *format* is an ASCII-encoding
> + string.
ASCII-encoded string, or ASCII encoding-string?
> .. c:function:: int PyErr_WarnFormat(PyObject *category, Py_ssize_t stack_level, const char *format, ...)
>
> Function similar to :c:func:`PyErr_WarnEx`, but use
> - :c:func:`PyUnicode_FromFormat` to format the warning message.
> + :c:func:`PyUnicode_FromFormat` to format the warning message. *format* is
> + an ASCII-encoded string.
So, the former, I'd guess :)
--
R. David Murray www.bitdance.com
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.
>
>
> Modified:
> python/branches/py3k/Parser/tokenizer.c
>
> Modified: python/branches/py3k/Parser/tokenizer.c
> ==============================================================================
> --- python/branches/py3k/Parser/tokenizer.c (original)
> +++ python/branches/py3k/Parser/tokenizer.c Mon Dec 27 21:12:13 2010
> @@ -545,6 +545,7 @@
> {
> char *line = NULL;
> int badchar = 0;
> + PyObject *filename;
> for (;;) {
> if (tok->decoding_state == STATE_NORMAL) {
> /* We already have a codec associated with
> @@ -585,12 +586,16 @@
> if (badchar) {
> /* Need to add 1 to the line number, since this line
> has not been counted, yet. */
> - PyErr_Format(PyExc_SyntaxError,
> - "Non-UTF-8 code starting with '\\x%.2x' "
> - "in file %.200s on line %i, "
> - "but no encoding declared; "
> - "see http://python.org/dev/peps/pep-0263/ for details",
> - badchar, tok->filename, tok->lineno + 1);
> + filename = PyUnicode_DecodeFSDefault(tok->filename);
> + if (filename != NULL) {
> + PyErr_Format(PyExc_SyntaxError,
> + "Non-UTF-8 code starting with '\\x%.2x' "
> + "in file %.200U on line %i, "
> + "but no encoding declared; "
> + "see http://python.org/dev/peps/pep-0263/ for details",
> + badchar, filename, tok->lineno + 1);
> + Py_DECREF(filename);
> + }
Hmm, and in case decoding fails, we return a Unicode error (without context)
instead of a syntax error? Doesn't seem like a good trade-off when the file
name is just displayed in a message.
Georg