Re: [Python-Dev] minidom -> new-style classes?
On 4/17/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Perhaps a rewrite could target 3.0 and 2.6 could use a backported > version of this *if* py3k compatibility mode is enabled? I'd love to > see at least the 3.0 version cleaned up. A lot of these bugs can be fixed without forking. I've been conservative so far. I looked at a diff this morning. Even pickled documents shouldn't break. If this patch lands, I can look at further cleanup after that. Thanks everyone, -j ___ 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] minidom -> new-style classes?
Great -- if you target 2.6, it'll automatically be merged into 3.0 the next time somebody runs svnmerge. (Thomas?) --Guido On 4/18/07, Jason Orendorff <[EMAIL PROTECTED]> wrote: > On 4/17/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Perhaps a rewrite could target 3.0 and 2.6 could use a backported > > version of this *if* py3k compatibility mode is enabled? I'd love to > > see at least the 3.0 version cleaned up. > > A lot of these bugs can be fixed without forking. I've been > conservative so far. I looked at a diff this morning. Even > pickled documents shouldn't break. > > If this patch lands, I can look at further cleanup after that. > > Thanks everyone, > -j > -- --Guido van Rossum (home page: http://www.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] Proposal: Allow any mapping after ** in calls
Alexander Belopolsky schrieb: > Python allows arbitrary sequences after * in calls, but an expression > following ** must be a (subclass of) dict. I believe * and ** should > be treated similarly and since f(*UserList(..)) is valid, > f(**UserDict(..)) should be valid as well. > > Of course, I can work around this limitation by writing > f(**dict(UserDict(..))), but this is unnatural given that I don't have > to do f(*tuple(UserList(..))). > > I have submitted a patch on SF that makes Python accept arbitrary > mappings after **. Ping! Nobody interested in this? Georg ___ 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] Proposal: Allow any mapping after ** in calls
I'm +1 on the idea, but have no time to review the change. On 4/18/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > Alexander Belopolsky schrieb: > > Python allows arbitrary sequences after * in calls, but an expression > > following ** must be a (subclass of) dict. I believe * and ** should > > be treated similarly and since f(*UserList(..)) is valid, > > f(**UserDict(..)) should be valid as well. > > > > Of course, I can work around this limitation by writing > > f(**dict(UserDict(..))), but this is unnatural given that I don't have > > to do f(*tuple(UserList(..))). > > > > I have submitted a patch on SF that makes Python accept arbitrary > > mappings after **. > > Ping! Nobody interested in this? > > Georg > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.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] SystemErrors in generator (just happened in 2.5)
>> *** The following messages occur in other successful tests too:
>> a DOS box should flash briefly ...
>
> Always happens in test_subprocess, during the Windows-specific
> test_creationflags. This is expected. When you /watch/ the tests
> running on Windows, it's intended to prevent panic when a mysterious
> DOS box appears ;-)
>
>> find_library('c') -> None
>> find_library('m') -> None
>
> Mysterious. Looks like debug/trace(!) output while running
> Lib/ctypes/test/test_loading.py's test_find().
I enabled these prints to have a way to examine what find_library() returns
on the buildbots, without checking for a certain result in a test.
Should these prints be removed again?
Thomas
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3118: Extended buffer protocol (new version)
Greg Ewing wrote: > Carl Banks wrote: > >> Py_BUF_REQUIRE_READONLY - Raise excpetion if the buffer is writable. > > Is there a use case for this? Yes. The idea is used in NumPy all the time. Suppose you want to write to an array but only have an algorithm that works with contiguous data. Then you need to make a copy of the data into a contiguous buffer but you would like to make the original memory read-only until you are done with the algorithm and have copied the data back into memory. That way when you release the GIL, the memory area will now be read-only and so other instances won't write to it (because any writes will be eradicated by the copy back when the algorithm is done). NumPy uses this idea all the time in its UPDATE_IF_COPY flag. -Travis ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3118: Extended buffer protocol (new version)
Jim Jewett wrote: > Reading this message without the entire PEP in front of me showed some > confusing usage. (Details below) Most (but not all) I could resolve > from the PEP itself, but they could be clarified with different > constant names. > I'm going to adapt some suggestions made by you and Carl Banks. Look for an updated flags section of the PEP shortly. -Travis ___ 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] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 357 open ( +8) / 3745 closed ( +8) / 4102 total (+16) Bugs: 958 open (+19) / 6657 closed ( +9) / 7615 total (+28) RFE : 251 open ( +2) / 280 closed ( +2) / 531 total ( +4) New / Reopened Patches __ Help with Python codebase (2007-04-11) CLOSED http://python.org/sf/1698723 opened by Munawar Update to Macintosh library documentation (2007-04-11) http://python.org/sf/1698768 opened by Kevin Walzer ZipFile.printdir fix (2.5) (2007-04-11) http://python.org/sf/1698915 opened by Alan McIntyre ZipFile.printdir fix (2.6) (2007-04-11) http://python.org/sf/1698917 opened by Alan McIntyre Bastion and rexec message out-of-date (2007-04-12) http://python.org/sf/1698951 opened by Gabriel Genellina getstate/setstate for incremental codecs (2007-04-12) CLOSED http://python.org/sf/1698994 opened by Walter Dörwald replacing char* with const char* in sysmodule.c/.h (2007-04-12) http://python.org/sf/1699259 opened by sebastinas Armin's method cache optimization updated for Python 2.6 (2007-04-13) http://python.org/sf/1700288 opened by Kevin Jacobs VC6 build patch for trunk (2007-04-14) http://python.org/sf/1700463 opened by Hirokazu Yamamoto stack size of python_d.exe on VC6 (2007-04-14) http://python.org/sf/1700467 opened by Hirokazu Yamamoto link_objects in setup.cfg crashes build (2007-04-18) http://python.org/sf/1703178 opened by Markus Schatten silenced a compiler warning (2007-04-18) http://python.org/sf/1703268 opened by Alexander Belopolsky missing declaration in readline.c (2007-04-18) http://python.org/sf/1703270 opened by Alexander Belopolsky bug fix: ctypes truncates 64-bit pointers (2007-04-18) http://python.org/sf/1703286 opened by Alexander Belopolsky fixes non ansi c declarations in libffi (2007-04-18) http://python.org/sf/1703300 opened by Alexander Belopolsky Refactor test_frozen.py to use unittest. (2007-04-18) http://python.org/sf/1703379 opened by Jerry Seutter Patches Closed __ Fix test_urllib on Windows buildbots (2007-04-07) http://python.org/sf/1695862 closed by zseil Don't block on Queue get/put when time is moved back (2007-03-29) http://python.org/sf/1690578 closed by loewis struct.pack() on 64bit architectures (2004-03-30) http://python.org/sf/925932 closed by zseil bug# 1607041: Condition.wait timeout fails on clock change (2006-12-01) http://python.org/sf/1607149 closed by loewis Add IllegalStateError (2007-03-21) http://python.org/sf/1685642 closed by gvanrossum Help with Python codebase (2007-04-11) http://python.org/sf/1698723 closed by gbrandl getstate/setstate for incremental codecs (2007-04-12) http://python.org/sf/1698994 closed by doerwalter Change *args from a tuple to list (2006-05-31) http://python.org/sf/1498441 closed by collinwinter New / Reopened Bugs ___ README is referencing obsolete? http://starship.python.net (2007-04-09) http://python.org/sf/1696740 opened by Jiri Navratil package.pth file name not used as described. (2007-04-09) http://python.org/sf/1697169 opened by cfk winreg module for cygwin? (2007-04-09) http://python.org/sf/1697175 opened by Zooko O'Whielacronx Property with -> annotation triggers assert (2007-04-09) http://python.org/sf/1697248 opened by Guido van Rossum types.InstanceType is missing but used by pydoc (2007-04-10) http://python.org/sf/1697782 reopened by gbrandl types.InstanceType is missing but used by pydoc (2007-04-10) http://python.org/sf/1697782 opened by Christian Heimes __getslice__ still used in built-in types (2007-04-10) http://python.org/sf/1697820 opened by Torsten Bronger Segfaults on memory error (2007-04-10) http://python.org/sf/1697916 reopened by gbrandl Segfaults on memory error (2007-04-10) http://python.org/sf/1697916 opened by STINNER Victor msgfmt cannot cope with BOM (2007-04-10) http://python.org/sf/1697943 opened by Christoph Zwerschke xml.etree document element.tag (2007-04-11) http://python.org/sf/1698167 opened by paul rubin wrong % of params for format string in ZipFile.printdir() (2007-04-11) http://python.org/sf/1698398 opened by Szabolcs Berecz dtdparser discards last line (2007-04-11) CLOSED http://python.org/sf/1698944 opened by L. Peter Deutsch shlex fails to parse strings correctly (2007-04-12) http://python.org/sf/1699594 opened by Collin Winter pickle example contains errors (2007-04-13) http://python.org/sf/1699759 opened by Mark Edgington locale.getlocale() output fails as setlocale() input (2007-04-13) http://python.org/sf/1699853 opened by Bernhard Reiter import and capital lett
Re: [Python-Dev] PEP 3118: Extended buffer protocol (new version)
Carl Banks wrote:
> Ok, I've thought quite a bit about this, and I have an idea that I
> think will be ok with you, and I'll be able to drop my main
> objection. It's not a big change, either. The key is to explicitly
> say whether the flag allows or requires. But I made a few other
> changes as well.
I'm good with using an identifier to differentiate between an "allowed"
flag and a "require" flag. I'm not a big fan of
VERY_LONG_IDENTIFIER_NAMES though. Just enough to understand what it
means but not so much that it takes forever to type and uses up
horizontal real-estate.
We use flags in NumPy quite a bit, and I'm obviously trying to adapt
some of this to the general case here, but I'm biased by my 10 years of
experience with the way I think about NumPy arrays.
Thanks for helping out and offering your fresh approach. I like a lot
of what you've come up with. There are a few modifications I would
make, though.
>
> First of all, let me define how I'm using the word "contiguous": it's
> a single buffer with no gaps. So, if you were to do this:
> "memset(bufinfo->buf,0,bufinfo->len)", you would not touch any data
> that isn't being exported.
Sure, we call this NPY_ONESEGMENT in NumPy-speak, though, because
contiguous could be NPY_C_CONTIGUOUS or NPY_F_CONTIGUOUS. We also
don't use the terms ROW_MAJOR and COLUMN_MAJOR and so I'm not a big fan
of bringing them up in the Python space because the NumPy community has
already learned the C_ and F_ terminology which also generalizes to
multiple-dimensions more clearly without using 2-d concepts.
>
> Without further ado, here is my proposal:
>
>
> --
>
> With no flags, the PyObject_GetBuffer will raise an exception if the
> buffer is not direct, contiguous, and one-dimensional. Here are the
> flags and how they affect that:
I'm not sure what you mean by "direct" here. But, this looks like the
Py_BUF_SIMPLE case (which was a named-constant for 0) in my proposal.
The exporter receiving no flags would need to return a simple buffer
(and it wouldn't need to fill in the format character either ---
valuable information for the exporter to know).
>
> Py_BUF_REQUIRE_WRITABLE - Raise exception if the buffer isn't writable.
WRITEABLE is an alternative spelling and the one that NumPy uses. So,
either include both of these as alternatives or just use WRITEABLE.
>
> Py_BUF_REQUIRE_READONLY - Raise excpetion if the buffer is writable.
Or if the object memory can't be made read-only if it is writeable.
>
> Py_BUF_ALLOW_NONCONTIGUOUS - Allow noncontiguous buffers. (This turns
> on "shape" and "strides".)
>
Fine.
> Py_BUF_ALLOW_MULTIDIMENSIONAL - Allow multidimensional buffers. (Also
> turns on "shape" and "strides".)
Just use ND instead of MULTIDIMENSIONAL and only turn on shape if it
is present.
>
> (Neither of the above two flags implies the other.)
>
> Py_BUF_ALLOW_INDIRECT - Allow indirect buffers. Implies
> Py_BUF_ALLOW_NONCONTIGUOUS and Py_BUF_ALLOW_MULTIDIMENSIONAL. (Turns
> on "shape", "strides", and "suboffsets".)
If we go with this consumer-oriented naming scheme, I like indirect also.
>
> Py_BUF_REQUIRE_CONTIGUOUS_C_ARRAY or Py_BUF_REQUIRE_ROW_MAJOR - Raise
> an exception if the array isn't a contiguous array with in C
> (row-major) format.
>
> Py_BUF_REQUIRE_CONTIGUOUS_FORTRAN_ARRAY or Py_BUF_REQUIRE_COLUMN_MAJOR
> - Raise an exception if the array isn't a contiguous array with in
> Fortran (column-major) format.
Just name them C_CONTIGUOUS and F_CONTIGUOUS like in NumPy.
>
> Py_BUF_ALLOW_NONCONTIGUOUS, Py_BUF_REQUIRE_CONTIGUOUS_C_ARRAY, and
> Py_BUF_REQUIRE_CONTIGUOUS_FORTRAN_ARRAY all conflict with each other,
> and an exception should be raised if more than one are set.
>
> (I would go with ROW_MAJOR and COLUMN_MAJOR: even though the terms
> only make sense for 2D arrays, I believe the terms are commonly
> generalized to other dimensions.)
As I mentioned there is already a well-established history with NumPy.
We've dealt with this issue already.
>
> Possible pseudo-flags:
>
> Py_BUF_SIMPLE = 0;
> Py_BUF_ALLOW_STRIDED = Py_BUF_ALLOW_NONCONTIGUOUS
>| Py_BUF_ALLOW_MULTIDIMENSIONAL;
>
> --
>
> Now, for each flag, there should be an associated function to test the
> condition, given a bufferinfo struct. (Though I suppose they don't
> necessarily have to map one-to-one, I'll do that here.)
>
> int PyBufferInfo_IsReadonly(struct bufferinfo*);
> int PyBufferInfo_IsWritable(struct bufferinfo*);
> int PyBufferInfo_IsContiguous(struct bufferinfo*);
> int PyBufferInfo_IsMultidimensional(struct bufferinfo*);
> int PyBufferInfo_IsIndirect(struct bufferinfo*);
> int PyBufferInfo_IsRowMajor(struct bufferinfo*);
> int PyBufferInfo_IsColumnMajor(struct bufferinfo*);
>
> The function PyObject_GetBuffer then has a pretty obvious
> implementation. Here is an except:
>
> if ((flags & Py_BUF_REQUIRE_READONLY) &&
> !PyBufferInfo_IsReadonly(&bufinfo)) {
> PyExc_
[Python-Dev] PEP 3118: Extended buffer protocol (new version)
Travis Oliphant wrote: > Carl Banks wrote: >> Ok, I've thought quite a bit about this, and I have an idea that I >> think will be ok with you, and I'll be able to drop my main >> objection. It's not a big change, either. The key is to explicitly >> say whether the flag allows or requires. But I made a few other >> changes as well. > I'm good with using an identifier to differentiate between an "allowed" > flag and a "require" flag. I'm not a big fan of > VERY_LONG_IDENTIFIER_NAMES though. Just enough to understand what it > means but not so much that it takes forever to type and uses up > horizontal real-estate. That's fine with me. I'm not very particular about spellings, as long as they're not misleading. >> Now, here is a key point: for these functions to work (indeed, for >> PyObject_GetBuffer to work at all), you need enough information in >> bufinfo to figure it out. The bufferinfo struct should be >> self-contained; you should not need to know what flags were passed to >> PyObject_GetBuffer in order to know exactly what data you're looking at. > Naturally. > >> Therefore, format must always be supplied by getbuffer. You cannot >> tell if an array is contiguous without the format string. (But see >> below.) > > No, I don't think this is quite true. You don't need to know what > "kind" of data you are looking at if you don't get strides. If you use > the SIMPLE interface, then both consumer and exporter know the object is > looking at "bytes" which always has an itemsize of 1. But doesn't this violate the above maxim? Suppose these are the contents of bufinfo: ndim = 1 len = 20 shape = (10,) strides = (2,) format = NULL How does it know whether it's looking at contiguous array of 10 two-byte objects, or a discontiguous array of 10 one-byte objects, without having at least an item size? Since item size is now in the mix, it's moot, of course. The idea that Py_BUF_SIMPLE implies bytes is news to me. What if you want a contiguous, one-dimensional array of an arbitrary type? I was thinking this would be acceptable with Py_BUF_SIMPLE. It seems you want to require Py_BUF_FORMAT for that, which would suggest to me that Py_BUF_ALLOW_ND amd Py_BUF_ALLOW_NONCONTIGUOUS, etc., would imply Py_BUF_FORMAT? IOW, pretty much anything that's not SIMPLE implies FORMAT? If that's the case, then most of the issues I brought up about item size don't apply. Also, if that's the case, you're right that Py_BUF_FORMAT makes more sense than Py_BUF_DONT_NEED_FORAMT. But it now it seems even more unnecessary than it did before. Wouldn't any consumer that just wants to look at a chunk of bytes always use Py_BUF_FORMAT, especially if there's danger of a presumptuous exporter raising an exception? > I'll update the PEP with my adaptation of your suggestions in a little > while. Ok. Thanks for taking the lead, and for putting up with my verbiose nitpicking. :) Carl Banks ___ 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
