Re: [Python-Dev] Python 2.5.1c1 pickle problem
Ralf, your issue is arising because of revision 53655 which fixes SF 1615701. Subclasses of builtins are pickled using obj.__reduce_ex__() which returns a tuple with a _reconstructor function and a tuple of arguments to that function. That tuple of arguments include the subclass name, the base class, and a state which is computed as state=base(obj). So, in your case, state=dict(yourobject). Formerly, casting a dict subclass to a dict would use a fast internal copying method which duplicated the hash table directly. The OP for SF 1615701 felt strongly that this was buggy behavior because it would bypass the custom __getitem__ () method implemented by his subclass. An argument in favor of the bugfix was that dict(m) or dict.update(m) shouldn't behave differently depending on whether m was a dict-subclass or another mapping-like object. For the latter, writing dict(m) is the semantic equivalent for writing dict((k,m[k]) for k in m.keys()). This is where your __getitem__() call comes from. At first, I did not agree with the proposed bugfix because 1) it would unnecessarily slowdown several operations on dict subclasses and make them less attractive; 2) it violated the OpenClosedPrinciple where the subclass has no business knowing how the internals of the base class are implemented (in this case, the subclass should not depend on whether dict(m) is implemented in terms of keys/getitem, in terms of iteritems, or through direct access to the hash table); and 3) because there were clearer and more reliable ways to implement the use cases suggested by the OP. The matter was briefly discussed on SF and python-dev where the OP found other proponents. It became clear that if left alone, the existing implementation would continue to defy the expectations of some folks subclassing builtins. Those expectations arise naturally from a mental model of builtins behaving just like a fast version of the most natural pure-Python equivalents. I'm not sure what your code was doing where the bugfix would cause breakage. If its __getitem__() override returned a meaningful value for each element in obj.keys(), then it should have worked fine. Of course, if it was raising an exception or triggering a side-effect, then one could argue that the bugfix was working as intended by allowing the subclasser to affect how the base class goes about its business. Am leaving this open for others to discuss and decide. The old behavior was surprising to some, but the revised behavior also appears to have some unforeseen consequences. Raymond P.S. In addition to rev 53655, a number of similar changes were made to sets. ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [PATCH] pep 0324 URL update
The old URL still works, but will probably not in the future. thanks, Pádraig. --- pep-0324.txt 2007-04-12 10:10:38.0 + +++ pep-0324.txt.new 2007-04-12 10:12:45.0 + @@ -535,7 +535,7 @@ [2] Python Dialog http://pythondialog.sourceforge.net/ -[3] http://www.iol.ie/~padraiga/libs/subProcess.py +[3] http://www.pixelbeat.org/libs/subProcess.py [4] http://starship.python.net/crew/tmick/ ___ 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] RELEASED Python 2.5.1, release candidate 1
On Wed, Apr 11, 2007 at 03:03:47PM -0400, Gustavo Tabares wrote: > The title for the highlights page also says Python 2.4 I've fixed the broken download links that Thomas reported. I can't find the above error, though the bugs and license pages did have a 'Python 2.4.4' heading. --amk ___ 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] RELEASED Python 2.5.1, release candidate 1
Open http://www.python.org/2.5/highlights.html The title of the page says "Highlights: Python 2.4" On 4/12/07, A.M. Kuchling <[EMAIL PROTECTED]> wrote: On Wed, Apr 11, 2007 at 03:03:47PM -0400, Gustavo Tabares wrote: > The title for the highlights page also says Python 2.4 I've fixed the broken download links that Thomas reported. I can't find the above error, though the bugs and license pages did have a 'Python 2.4.4' heading. --amk ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/gustavotabares%40gmail.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] HTTP responses and errors
On 4/10/07, Facundo Batista <[EMAIL PROTECTED]> wrote: > Facundo Batista wrote: > > > Martin v. Löwis wrote: > > ... > > > >> think it should treat all 2xx responses as success. Callers can > >> then still check the response code themselves if they need to. > > > > The same I think. If nobody has a conflic with this decission, I'll fix > > this. > > Nobody raised any objection, I'll fix this these days. +1 Jeremy ___ 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] Just saying hello
On Wed, Apr 11, 2007, Ryan Kelley wrote: > > I just got accepted on the google summer of code to work on a project > for python. I just wanted to say hello to everyone out there as i know > i will end up asking a few questions before the summers over. Congrats! -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ Help a hearing-impaired person: http://rule6.info/hearing.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] RELEASED Python 2.5.1, release candidate 1
"Gustavo Tabares" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | Open http://www.python.org/2.5/highlights.html | | The title of the page says "Highlights: Python 2.4" To be clear, it is not the heading/title *on* the page, which was changed, but the title *of* the page displayed on the browser's title bar (and the Windows task bar). ___ 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] build problem on windows: unable to find getbuildinfo2.c
Hi, I am trying to build latest python on Windows XP and ran into the following error: "c1 : fatal error C1083: Cannot open source file: '.\getbuildinfo2.c': No such file or directory" I am using Visual C++ 2005 Express Edition to build. I opened "PCbuilld8/pcbuild.sln" and did a "release" build of "pythoncore". I didn't find getbuildinfo2.c in the source. Can some one tell me if I am missing some thing here? Are there any additional steps need to follow on windows? Thanks, Raghu. ___ 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] build problem on windows: unable to find getbuildinfo2.c
This is not the right list to ask for technical support. Please either ask some place like comp.lang.python or file a bug report. -Brett On 4/12/07, Raghuram Devarakonda <[EMAIL PROTECTED]> wrote: Hi, I am trying to build latest python on Windows XP and ran into the following error: "c1 : fatal error C1083: Cannot open source file: '.\getbuildinfo2.c': No such file or directory" I am using Visual C++ 2005 Express Edition to build. I opened "PCbuilld8/pcbuild.sln" and did a "release" build of "pythoncore". I didn't find getbuildinfo2.c in the source. Can some one tell me if I am missing some thing here? Are there any additional steps need to follow on windows? Thanks, Raghu. ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3118: Extended buffer protocol (new version)
Travis Oliphant wrote: > Because slicing NumPy array's already does it by holding on to a view, I > guess having an object that doesn't hold on to a view in Python but > "re-gets" it every time it is needed, would be useful. I guess this problem doesn't arise in NumPy, because the size of the memory block doesn't change once the array is created, so locking isn't an issue. But in the more general case, I think it would be surprising if one object refused to carry out some operation just because of the existence of some other object. Also, keep in mind that dropping references to an object isn't a guarantee that it will be deallocated immediately, so there would need to be some kind of explicit closing operation on the view object, making things more messy. -- Greg ___ 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)
Neil Hodgson wrote: > Travis Oliphant: > >> PEP: 3118 >> ... > > I'd like to see the PEP include discussion of what to do when an > incompatible request is received while locked. Should there be a > standard "Can't do that: my buffer has been got" exception? I'm not sure what standard to make a decision about that by. Sure, why not? It's not something I'd considered. -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)
Lisandro Dalcin wrote:
> On 4/9/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
> Travis, all this is far better and simpler than previous approaches...
> Just a few comments
Thanks for your wonderful suggestions. I've incorporated many of them.
>
> 1) I assume that 'bufferinfo' structure will be part of public Python
> API. In such a case, I think it should be renamed and prefixed.
> Something like 'PyBufferInfo' sounds good?
I prefer that as well.
>
> 2) I also think 'bufferinfo' could also have an 'itemsize' field
> filled if Py_BUF_ITEMSIZE flag is passed. What do you think? Exporters
> can possibly fill this field more efficiently than next parsing
> 'format' string, it can also save consumers from an API call.
I think the itemsize member is a good idea. I'm re-visiting what the
flags should be after suggestions by Carl.
>
> 3) It does make sense to make 'format' be 'const char *' ?
Yes,
>
> 4) I am not sure about this, but perhaps 'buferingo' should save the
> flags passed to 'getbuffer' in a 'flags' field. This can be possibly
> needed at 'releasebuffer' call.
>
I think this is un-necessary.
>
>> typedef struct {
>> PyObject_HEAD
>> PyObject *base;
>> struct bufferinfo view;
>> int itemsize;
>> int flags;
>> } PyMemoryViewObject;
>
> 5) If my previous comments go in, so 'PyMemoryViewObject' will not
> need 'itemsize' and 'flags' fields (they are in 'bufferinfo'
> structure).
>
After suggestions by Greg, I like the idea of the PyMemoryViewObject
holding a pointer to another object (from which it gets memory on
request) as well as information about a slice of that memory.
Thus, the memory view object is something like:
typedef struct {
PyObject_HEAD
PyObject *base;
int ndims;
Py_ssize_t *offsets;/* slice starts */
Py_ssize_t *lengths; /* slice stops */
Py_ssize_t *skips; /* slice steps */
} PyMemoryViewObject;
It is more convenient to store any slicing information (so a memory view
object could store an arbitrary slice of another object) as offsets,
lengths, and skips which can be used to adjust the memory buffer
returned by base.
>> int PyObject_GetContiguous(PyObject *obj, void **buf, Py_ssize_t
>> *len,
>>int fortran)
>>
>> Return a contiguous chunk of memory representing the buffer. If a
>> copy is made then return 1. If no copy was needed return 0.
>
> 8) If a copy was made, What should consumers call to free memory?
You are right. We need a free function.
> 9) What about using a char, like 'c' or 'C', and 'f' or 'F', and 0 or
> 'a' or 'A' (any) ?
I'm happy with that too.
>
>> int PyObject_CopyToObject(PyObject *obj, void *buf, Py_ssize_t len,
>> int fortran)
>
> 10) Better name? Perhaps PyObject_CopyBuffer or PyObject_CopyMemory?
I'm not sure why those are better names. The current name reflects the
idea of copying the data into the object.
>
>> int PyObject_SizeFromFormat(char *)
>>
>> int PyObject_IsContiguous(struct bufferinfo *view, int fortran);
>>
>> void PyObject_FillContiguousStrides(int *ndims, Py_ssize_t *shape,
>> int itemsize,
>> Py_ssize_t *strides, int
>> fortran)
>>
>> int PyObject_FillBufferInfo(struct bufferinfo *view, void *buf,
>> Py_ssize_t len,
>> int readonly, int infoflags)
>>
>
> 11) Perhaps the 'PyObject_' prefix is wrong, as those functions does
> not operate with Python objects.
Agreed.
-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] build problem on windows: unable to find getbuildinfo2.c
> I didn't find getbuildinfo2.c in the source. Can some one tell me if > I am missing some thing here? Are there any additional steps need to > follow on windows? It's a generated file. Search all build description files for that file name to find out how it is generated, and then research why generating it fails on your machine. Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3118: Extended buffer protocol (new version)
Carl Banks wrote: > > The thing that bothers me about this whole flags setup is that > different flags can do opposite things. > > Some of the flags RESTRICT the kind of buffers that can be > exported (Py_BUF_WRITABLE); other flags EXPAND the kind of buffers that > can be exported (Py_BUF_INDIRECT). That is highly confusing and I'm -1 > on any proposal that includes both behaviors. (Mutually exclusive sets > of flags are a minor exception: they can be thought of as either > RESTICTING or EXPANDING, so they could be mixed with either.) The mutually exclusive set is the one example of the restriction that you gave. I think the flags setup I've described is much closer to your Venn diagram concept than you give it credit for. I've re-worded some of the discussion (see http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/numpy/doc/pep_buffer.txt ) so that it is more clear that each flag is a description what kind of buffer the consumer is prepared to deal with. For example, if the consumer cares about what's 'in' the array, it uses Py_BUF_FORMAT. Exporters are free to do what they want with this information. I agree that NumPy would not force you to use it's buffer only as a region of some specific type, but some other object may want to be much more restrictive and only export to consumers who will recognize the data stored for what it is.I think it's up to the exporters to decide whether or not to raise an error when a certain kind of buffer is requested. Basically, every flag corresponds to a different property of the buffer that the consumer is requesting: Py_BUF_SIMPLE --- you are requesting the simplest possible (0x00) Py_BUF_WRITEABLE -- get a writeable buffer (0x01) Py_BUF_READONLY -- get a read-only buffer(0x02) Py_BUF_FORMAT -- get a "formatted" buffer. (0x04) Py_BUF_SHAPE -- get a buffer with shape information (0x08) Py_BUF_STRIDES -- get a buffer with stride information (and shape) (0x18) Py_BUF_OFFSET -- get a buffer with suboffsets (and strides and shape) (0x38) This is a logical sequence. There is progression. Each flag is a bit that indicates something about how the consumer can use the buffer. In other words, the consumer states what kind of buffer is being requested. The exporter obliges (and can save possibly significant time if the consumer is not requesting the information it must otherwise produce). > I originally suggested a small set of flags that expand the set of > allowed buffers. Here's a little Venn diagram of buffers to > illustrate what I was thinking: > > http://www.aerojockey.com/temp/venn.png > > With no flags, the only buffers allowed to be returned are in the "All" > circle but no others. Add Py_BUF_WRITABLE and now you can export > writable buffers as well. Add Py_BUF_STRIDED and the strided circle is > opened to you, and so on. > > My recommendation is, any flag should turn on some circle in the Venn > diagram (it could be a circle I didn't draw--shaped arrays, for > example--but it should be *some* circle). I don't think your Venn diagram is broad enough and it un-necessarily limits the use of flags to communicate between consumer and exporter. We don't have to ram these flags down that point-of-view for them to be productive.If you have a specific alternative proposal, or specific criticisms, then I'm very willing to hear them. I've thought through the flags again, and I'm not sure how I would change them. They make sense to me. Especially in light of past usages of the buffer protocol (where most people request read-or-write buffers i.e. Py_BUF_SIMPLE. I'm also not sure our mental diagrams are both oriented the same. For me, the most restrictive requests are PY_BUF_WRITEABLE | Py_BUF_FORMAT and Py_BUF_READONLY | Py_BUF_FORMAT The most un-restrictive request (the largest circle in my mental Venn diagram) is Py_BUF_OFFSETS followed by Py_BUF_STRIDES followed by Py_BUF_SHAPE adding Py_BUF_FORMATS, Py_BUF_WRITEABLE, or Py_BUF_READONLY serves to restrict any of the other circles Is this dual use of flags what bothers you? (i.e. use of some flags for restricting circles in your Venn diagram that are turned on by other flags? --- you say Py_BUF_OFFSETS | Py_BUF_WRITEABLE to get the intersection of the Py_BUF_OFFSETS largest circle with the WRITEABLE subset?) Such concerns are not convincing to me. Just don't think of the flags in that way. Think of them as turning "on" members of the bufferinfo structure. > > Py_BUF_FORMAT The consumer will be using the format string information so make sure thatmember is filled correctly. >>> >>> Is the idea to throw an exception if there's some other data format >>> besides "b", and this flag isn't set? It seems superfluous otherwise. >> >> The idea is that a consumer may not care about the format and the >> exporter may want to know that to simplify the interface.In other >> words the flag
