Re: [Python-Dev] PEP 3118: Extended buffer protocol (new version)
Greg Ewing wrote: > Travis Oliphant wrote: > >> 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. > > What happens if the base object changes its memory > layout in such a way that the stored offsets, lengths > and skips are no longer correct for the slice that > was requested? When the memory view object gets the buffer info again from the base object, it will be able to figure this out and raise an error. -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)
Travis Oliphant wrote: > 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) I don't see how these three form a progression. From the other things you say, it appears you mean Py_BUF_SIMPLE to mean both readable and writeable. But then Py_BUF_READONLY is turning off a capability (being able to write to the buffer) rather than turning one on. Seems to me the "simplest possible" buffer is a read-only one (assuming we don't want to allow for write-only buffers -- or do we?), in which case a more logical arrangement to my mind would be Py_BUF_READONLY = 0x00 # simplest possible PY_BUF_READWRITE = 0x01 If we do want write-only buffers, then there isn't a single simplest possible buffer, except for one that's neither readable nor writable, which doesn't seem very useful. So we would have Py_BUF_READABLE = 0x01 Py_BUF_WRITABLE = 0x02 Py_BUF_READWRITE = 0x03 -- 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
[Python-Dev] my 2.5 checkins
Hello all. I made two checkins to the 25 maintainance branch before Martin kindly pointed out to me that it is frozen. These are quite simple fixes to real crashes I have experienced. The fix in frameobject.c will be necessary if you work with opcodes > 128, which we routinely do at CCP J. Security through opcode randomization Anyway, just let me know if you like me to roll them back. Cheers, Kristján ___ 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: > 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. What happens if the base object changes its memory layout in such a way that the stored offsets, lengths and skips are no longer correct for the slice that was requested? -- 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] Changes to decimal.py
On 4/13/07, Tim Peters <[EMAIL PROTECTED]> wrote: > One low-effort approach is to use a general root-finding algorithm and > build ln(x) on top of exp() via (numerically) solving the equation > exp(ln(x)) == x for ln(x). That appears to be what Don Peterson did > in his implementation of transcendental functions for Decimal: > > http://cheeseshop.python.org/pypi/decimalfuncs/1.4 > > In a bit of disguised form, that appears to be what Brian Beck and > Christopher Hesse also did: > > http://cheeseshop.python.org/pypi/dmath/0.9 > Whatever they do, they are very slow :-) I get the following timings with decimalfuncs (dmath is even slower): exp(Decimal(1)): 0.02 seconds at 28 digits, 0.2 seconds at 100 digits ln(Decimal(2)): 0.1 seconds at 28 digits, 0.6 seconds at 100 digits A while back I implemented exp and ln using fixed-point integer arithmetic, which unsurprisingly turned out to be much faster than working with Decimals. If I convert a decimal input to fixed-point, calculate exp or log, and convert the output back to decimal, I get the following timings: exp(1): 0.0008 seconds at 28 digits, 0.001 seconds at 100 digits ln(2): 0.001 seconds at 28 digits, 0.007 seconds at 100 digits [Note: I didn't use the exact numbers 1 and 2 for these timings; I added noise digits to make sure the decimal conversion code wasn't taking any shortcuts.] I use the Taylor series for exp(x) but first divide x by 2^32 to improve the convergence rate and finally square the sum 32 times. (32 could be replaced by any number; 32 just happens to be fast for a large range of precisions on my system.) Looking more closely at the 28-digit exp calculation: 0.0005 s is spent converting the Decimal to fixed-point 0.0001 s is spent summing the Taylor series (integer arithmetic) 0.0002 s is spent converting the fixed-point number back to Decimal For comparison, multiplying two 28-digit decimals takes 0.0003 seconds. So, computing exp this way is only about twice as expensive as multiplication at 28-digit precision; at 100 digit precision, I find that they are equally expensive. This approach assumes that the input has magnitude close to 1. For very large or very small numbers, you have to use the functional properties of exp to get a number close to 1, then convert back, all probably best (at least most easily) done entirely using Decimal arithmetic. For ln, I use Newton's method to invert exp, with an initial estimate from math.log, doubling the working precision at each iteration so that only one full-precision evaluation of exp is necessary. Using fixed-point internally during the Newton iteration, ln should be at most twice as slow as exp. Of course, this could all be irrelevant if the decimal module ever gets replaced by a C implementation... Fredrik ___ 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] ok to just checkin minor obvious fixes?
Trent Mick schrieb: > Is it generally accepted to just checkin obviously non-controversial > fixes (*) (as long as there is no code freeze), or is it still preferred > that I go through adding a patch to the SF tracker and getting review? > > Trent > > (*) In my case a tweak to the old VC6 Windows build files to ensure a > clean build works (_ctypes project must depend on pythoncore proj). Feel free to check in anything you consider appropriate, and use SF for cases where you want review (in particular, if you want the review recorded). Fixing the VC6 project files is certainly uncontroversial. Notice that the 2.5 branch is currently frozen (for 2.5.1); any commits to the branch need approval on python-dev. 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
[Python-Dev] ok to just checkin minor obvious fixes?
Is it generally accepted to just checkin obviously non-controversial fixes (*) (as long as there is no code freeze), or is it still preferred that I go through adding a patch to the SF tracker and getting review? Trent (*) In my case a tweak to the old VC6 Windows build files to ensure a clean build works (_ctypes project must depend on pythoncore proj). -- Trent Mick trentm at activestate.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] Changes to decimal.py
[Raymond Hettinger] > ... > Likewise, consider soliciting Tim's input on how to implement the ln() > operation. That one will be tricky to get done efficiently and correctly. One low-effort approach is to use a general root-finding algorithm and build ln(x) on top of exp() via (numerically) solving the equation exp(ln(x)) == x for ln(x). That appears to be what Don Peterson did in his implementation of transcendental functions for Decimal: http://cheeseshop.python.org/pypi/decimalfuncs/1.4 In a bit of disguised form, that appears to be what Brian Beck and Christopher Hesse also did: http://cheeseshop.python.org/pypi/dmath/0.9 The former is GPL-licensed and the latter MIT, so the latter would be easier to start from for core (re)distribution. However, the IBM spec requires < 1 ULP worst-case error, and that may be unreasonably hard to meet with a root-finding approach. If this can wait a couple months, I'd be happy to own it. A possible saving grace for ln() is that while the mathematical function is one-to-one, in any fixed precision it's necessarily many-to-one (e.g., log10 of the representable numbers between 10 and 1e100 must be a representable number between 1 and 100, and there are a lot more of the former than of the latter -- many distinct representable numbers must map to the same representable log). ___ 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] Extended Buffer Protocol - simple use examples
Paul Moore wrote: > On 09/04/07, Travis Oliphant <[EMAIL PROTECTED]> wrote: > >>>I have skimmed (briefly, I'll admit!) the pre-PEP, but I've found it >>>extremely difficult to find a simple example of the basic (in my view) >>>use case of an undifferentiated block of bytes. >>> >> >>This is a great suggestion and it was on my to-do list. I've included >>some examples of this use-case in the new PEP. > > > Nice - those look clear to me. One question - if a producer is > generating a more complex data format (for example, the RGBA example > in the PEP) then would the "simple consumer" code (Ex. 3) still get a > pointer (or would the RGBA code need to go through extra effort to > allow this)? Sorry, again this is probably clear from reading the PEP > details, but my eyes glaze over when I read about strides, shapes, > etc... Unless, the exporter took some measures to create a contiguous copy of its buffer in situations like that, the exporter would have to raise an error if a consumer asked for a simple contiguous buffer. > > My motivation here is that it would be a shame if "old-style" code > that was prepared to guess the format of a memory block stopped > working when the producer of the memory added shape information (that > the consumer didn't care about, except to validate its guess). No, it wouldn't stop working, because right now, an error would get raised anyway. For example, in NumPy, you can get an "old-style" buffer from an ndarray only as long as it is contiguous. If it is discontiguous you will get an error. Example: >>> a = numpy.array([[1,2,3],[4,5,6]]) >>> b = a[::2,::2] >>> buffer(a)[:] >>> buffer(b)[:] # the last statement will raise an error in current Python. Part of the intent of the extended buffer protocol is to allow you to share even discontiguous memory with those that know how to handle it. In addition, the two C-API calls that allow copying data to and from a contiguous buffer is to create a standard way to work with "any" object for routines that only know how to deal with contiguous memory. -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] test_pty.py hangs in verbose mode on Mac OS X?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 13, 2007, at 11:07 AM, Jean-Paul Calderone wrote: > Likely differing buffering behavior. Prior to Linux 2.6, the pipe > implementation allowed only a single buffer (that is, the bytes from > a single write call) in a pipe at a time, and blocked subsequent > writes until that buffer was read. Recently this has changed to allow > multiple buffers up to 4k total length, so multiple short writes won't > block anymore. OS X may have some other buffering behavior which is > causing writes to block where they don't on Linux. All these details > are left to the platform, and there are a variety of behaviors which > can be considered valid. > > Of course, I don't actually /know/ the cause of the problem here, but > this explanation seems plausible to me, and I'd investigate it before > looking for platform-specific pty bugs (although OS X is a good > platform > on which to go looking for those ;). Seems plausible to me too. If I change the child writes to > 4000 bytes, Linux w/2.6 kernel will block too. I'm going to change the test_pty.py code to read from the master_fd. You have to wrap the read in a try/except to catch the OSError input/ output error you'll get on Linux when you read past the end of the buffer and the child process has already exited. Thanks, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRh+gO3EjvBPtnXfVAQJkQAP9E2Jp/EeF3ChIeNZEPVMDeG4Kd+PVslSs blNFO2oO6eO8Yn9X3hlnLwCe3W6+89bS9u7MyN1C2CCZTBz6N1QAkfDaAnxuhbNC 3hfvytMguTY0v3RiZhEVY+y/h2PfbWe6fJGXeBIfcth1HWhP0KWIgAoDA+odDm1B vZSvcxBRN1Y= =fDrh -END PGP 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
[Python-Dev] Pydoc Rewrite Discussion at doc-sig list.
If anyone is interested in participating in discussing the details of the PyDoc rewrite/refactoring I've been working on, a discussion is being started on the doc-sig list. [EMAIL PROTECTED] The goal of this discussion will be to get it to a final finished form so a patch can be submitted and a final discussion can take place on the python-dev list at a later date. Thanks and Regards, Ron Adam ___ 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] test_pty.py hangs in verbose mode on Mac OS X?
On Fri, 13 Apr 2007 11:02:01 -0400, Barry Warsaw <[EMAIL PROTECTED]> wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >On Apr 13, 2007, at 10:57 AM, Jean-Paul Calderone wrote: >>>I don't know if this is caused by a bug in the Mac's pty >>>implementation or something we're doing wrong on that platform. I >>>played around with several modifications to pty.fork() on the Mac, >>>including letting it drop down to the openpty()/os.fork() code, even >>>adding an explicit ioctl(slave_fd, TIOCSCTTY) call which Stevens >>>chapter 19 recommends for 4.3+BSD. I can't get it to not block. >> >>What about reading from the child in the parent before calling waitpid? > >Yep, this is what I suggested below. Porting the same change over to Linux >produced an OSError, but that's probably just because I wasn't as careful >as I should have been late last night. >>>Barring a fix to pty.fork() (or possibly os.forkpty()) for the Mac, >>>then I would like to at least make test_pty.py not block when run in >>>verbose mode. A very simple hack would add something like this to >>>the "if pid == pty.CHILD" stanza: "def debug(msg): pass", possibly >>>protected by a "if verbose:". A less icky hack would be to read the >>>output from the master_fd in the parent, though you have to be >>>careful with that on Linux else the read can throw an input/output >>>error. >>> >>>Disabling debug output is band-aid yes, and any application on the >>>Mac like the above snippet will still fail. If anybody has any >>>suggestions, I'm all ears, but I've reached the limit of my pty-fu. >> >>I don't think this is an OS X PTY bug. Writing to a blocking file >>descriptor can block. Programs that do this need to account for the >>possibility. > >Why doesn't it block on Linux then? > Likely differing buffering behavior. Prior to Linux 2.6, the pipe implementation allowed only a single buffer (that is, the bytes from a single write call) in a pipe at a time, and blocked subsequent writes until that buffer was read. Recently this has changed to allow multiple buffers up to 4k total length, so multiple short writes won't block anymore. OS X may have some other buffering behavior which is causing writes to block where they don't on Linux. All these details are left to the platform, and there are a variety of behaviors which can be considered valid. Of course, I don't actually /know/ the cause of the problem here, but this explanation seems plausible to me, and I'd investigate it before looking for platform-specific pty bugs (although OS X is a good platform on which to go looking for those ;). Jean-Paul ___ 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] test_pty.py hangs in verbose mode on Mac OS X?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 13, 2007, at 10:57 AM, Jean-Paul Calderone wrote: >> I don't know if this is caused by a bug in the Mac's pty >> implementation or something we're doing wrong on that platform. I >> played around with several modifications to pty.fork() on the Mac, >> including letting it drop down to the openpty()/os.fork() code, even >> adding an explicit ioctl(slave_fd, TIOCSCTTY) call which Stevens >> chapter 19 recommends for 4.3+BSD. I can't get it to not block. > > What about reading from the child in the parent before calling > waitpid? Yep, this is what I suggested below. Porting the same change over to Linux produced an OSError, but that's probably just because I wasn't as careful as I should have been late last night. >> Barring a fix to pty.fork() (or possibly os.forkpty()) for the Mac, >> then I would like to at least make test_pty.py not block when run in >> verbose mode. A very simple hack would add something like this to >> the "if pid == pty.CHILD" stanza: "def debug(msg): pass", possibly >> protected by a "if verbose:". A less icky hack would be to read the >> output from the master_fd in the parent, though you have to be >> careful with that on Linux else the read can throw an input/output >> error. >> >> Disabling debug output is band-aid yes, and any application on the >> Mac like the above snippet will still fail. If anybody has any >> suggestions, I'm all ears, but I've reached the limit of my pty-fu. >> > > I don't think this is an OS X PTY bug. Writing to a blocking file > descriptor can block. Programs that do this need to account for the > possibility. Why doesn't it block on Linux then? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRh+banEjvBPtnXfVAQJxFQP+LRAdGVHuqquvGNT9fncGeJFuCjGm+dsS VnE8cirvfoSEdJ0nZ11wHMoMH2vtbXyfjLJJ4G/sROMmHKWJ2t5ieNIxmVutiiLa OPyls2bzuXL8IoyYh+c8tKRyBd76O5GN2EZABxGm2Tie5nt72ezVSEfiDovc6qEu 4lYERTD1YKA= =fZaZ -END PGP 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] test_pty.py hangs in verbose mode on Mac OS X?
On Fri, 13 Apr 2007 10:32:28 -0400, Barry Warsaw <[EMAIL PROTECTED]> wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >I've been getting some test failures in Python 2.5 svn head on Mac OS >X 10.4.9 which I'm not getting on Linux (Ubuntu feisty beta). >test_sqlite and test_zipimport both fail, however, when run in >verbose mode (e.g. ./python.exe Lib/test/test_sqlite.py) both pass. > >But that's not exactly why I'm writing this email . In the >course of trying to debug this, I ran the following on my Mac: > >make TESTOPTS=-v test > >This runs the entire test suite in verbose mode, and you do get a lot >of output. However the test suite hangs on test_pty.py. In fact, if >you run that test alone: > >./python.exe Lib/test/test_pty.py > >it too hangs for me. The reason is that in verbose mode, debug() >actually prints stuff to stdout and on the Mac, when the child of the >pty.fork() writes to its stdout, it blocks and so the parent's waitpid >() never returns. This doesn't happen on Linux though; the child's >stdout prints don't block, it exits, and the parent continues after >the waitpid(). > >Here's a very simple program that reproduces the problem: > >- -snip snip- >import os, pty, sys > >pid, fd = pty.fork() >print >> sys.stderr, pid, fd >if pid: > os.waitpid(pid, 0) >else: > os._exit(0) >- -snip snip- > >stderr, stdout, doesn't matter. This hangs on the Mac but completes >successfully on Linux. Of course, in neither case do you see the >child's output. > >I don't know if this is caused by a bug in the Mac's pty >implementation or something we're doing wrong on that platform. I >played around with several modifications to pty.fork() on the Mac, >including letting it drop down to the openpty()/os.fork() code, even >adding an explicit ioctl(slave_fd, TIOCSCTTY) call which Stevens >chapter 19 recommends for 4.3+BSD. I can't get it to not block. What about reading from the child in the parent before calling waitpid? > >Barring a fix to pty.fork() (or possibly os.forkpty()) for the Mac, >then I would like to at least make test_pty.py not block when run in >verbose mode. A very simple hack would add something like this to >the "if pid == pty.CHILD" stanza: "def debug(msg): pass", possibly >protected by a "if verbose:". A less icky hack would be to read the >output from the master_fd in the parent, though you have to be >careful with that on Linux else the read can throw an input/output >error. > >Disabling debug output is band-aid yes, and any application on the >Mac like the above snippet will still fail. If anybody has any >suggestions, I'm all ears, but I've reached the limit of my pty-fu. > I don't think this is an OS X PTY bug. Writing to a blocking file descriptor can block. Programs that do this need to account for the possibility. Jean-Paul ___ 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] test_pty.py hangs in verbose mode on Mac OS X?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've been getting some test failures in Python 2.5 svn head on Mac OS X 10.4.9 which I'm not getting on Linux (Ubuntu feisty beta). test_sqlite and test_zipimport both fail, however, when run in verbose mode (e.g. ./python.exe Lib/test/test_sqlite.py) both pass. But that's not exactly why I'm writing this email . In the course of trying to debug this, I ran the following on my Mac: make TESTOPTS=-v test This runs the entire test suite in verbose mode, and you do get a lot of output. However the test suite hangs on test_pty.py. In fact, if you run that test alone: ./python.exe Lib/test/test_pty.py it too hangs for me. The reason is that in verbose mode, debug() actually prints stuff to stdout and on the Mac, when the child of the pty.fork() writes to its stdout, it blocks and so the parent's waitpid () never returns. This doesn't happen on Linux though; the child's stdout prints don't block, it exits, and the parent continues after the waitpid(). Here's a very simple program that reproduces the problem: - -snip snip- import os, pty, sys pid, fd = pty.fork() print >> sys.stderr, pid, fd if pid: os.waitpid(pid, 0) else: os._exit(0) - -snip snip- stderr, stdout, doesn't matter. This hangs on the Mac but completes successfully on Linux. Of course, in neither case do you see the child's output. I don't know if this is caused by a bug in the Mac's pty implementation or something we're doing wrong on that platform. I played around with several modifications to pty.fork() on the Mac, including letting it drop down to the openpty()/os.fork() code, even adding an explicit ioctl(slave_fd, TIOCSCTTY) call which Stevens chapter 19 recommends for 4.3+BSD. I can't get it to not block. Barring a fix to pty.fork() (or possibly os.forkpty()) for the Mac, then I would like to at least make test_pty.py not block when run in verbose mode. A very simple hack would add something like this to the "if pid == pty.CHILD" stanza: "def debug(msg): pass", possibly protected by a "if verbose:". A less icky hack would be to read the output from the master_fd in the parent, though you have to be careful with that on Linux else the read can throw an input/output error. Disabling debug output is band-aid yes, and any application on the Mac like the above snippet will still fail. If anybody has any suggestions, I'm all ears, but I've reached the limit of my pty-fu. mr-t-says-i-pty-the-fu-ly y'rs, - -Barry P.S. chime on on the test_sqlite and test_zipimport oddities if you want. :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRh+Ug3EjvBPtnXfVAQJ4HgQAkm3XUq27GPBDKJj1NaIHuYijUerSE2oW 9YWiCYNQ+hBaYJJ16gdqZ2f7t/ENYVBzj3r9fNj+uyI1a6OFFMlE1tOdDFscQWUE e04XGwxo1fEPelJveIw8/dLHCPCpmCqvzLrT8fAtr7HL3thW3rk8s69i9i+CtJ1L LP7AY/SYXxg= =I+pF -END PGP 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] PEP 3118: Extended buffer protocol (new version)
On 4/13/07, Travis Oliphant <[EMAIL PROTECTED]> wrote: > >> 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. > I think now the memory perhaps should be allocated with PyMem_New and deallocated with PyMem_Free. Additionally, the return should perhaps indicate success or failure, and a new argument should be passed in order to know if a copy was made, something like int PyObject_GetContiguous(PyObject *obj, void **buf, Py_ssize_t *len, int *copy, char layout) -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ 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
On 4/13/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > 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. Thanks. I found that make_buildinfo project failed with some unresolved symbol errors causing the missing getbuildinfo2.c. Once I fixed it, python got built just fine. ___ 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 and DOM level 2
On 4/13/07, Andrew Clover <[EMAIL PROTECTED]> wrote:
> Jason Orendorff wrote:
> > I don't suppose you'd be willing to update it for Python 2.5, would you?
>
> Can do, but at this point I'm not aware of any work having been done on
> the issues listed there between the 2.3 and 2.5 releases.
I've been running the DOM test suite against trunk, using your test
harness. It's kind of alarming at first that over 100 tests fail. :)
But many of the failures involve entity references.
An even larger portion involve error cases: we accept things we should
check and reject. For example, doc.createElement('\t') should fail.
These are certainly bugs, and they're easy to fix. I'm working
through them.
> The danger is people may be used to the "wrong" minidom behaviours,
> given they have been static for so long and are in many cases central to
> how minidom works.
When I get to these, I'll post about it.
-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] RELEASED Python 2.5.1, release candidate 1
On Thu, Apr 12, 2007 at 12:12:48PM -0400, Terry Reedy wrote: > | Open http://www.python.org/2.5/highlights.html > | > | The title of the page says "Highlights: Python 2.4" Ah, so it's a 2.5 page, not a 2.5.1 page; that's why my grep didn't find it. Fixed now; thanks! --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] minidom and DOM level 2
Jason Orendorff wrote: > I don't suppose you'd be willing to update it for Python 2.5, would you? Can do, but at this point I'm not aware of any work having been done on the issues listed there between the 2.3 and 2.5 releases. The danger is people may be used to the "wrong" minidom behaviours, given they have been static for so long and are in many cases central to how minidom works. -- And Clover mailto:[EMAIL PROTECTED] http://www.doxdesk.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
