Re: [Python-Dev] Memoryviews should expose the underlying memory address

2012-09-21 Thread Nick Coghlan 
On Fri, Sep 21, 2012 at 4:12 PM, Greg Ewing  wrote:
> Nick Coghlan wrote:
>>
>> I'm fine with exposing a memoryview.buffer_address attribute in 3.4.
>
>
> What about objects whose buffer address can change
> when the buffer isn't locked?

Managing the lifecycle issues will be up to the application. If they
let the memoryview object go away, then the buffer it references may
also go away. This isn't any different from the situation with
array.buffer_info() - the address from that is only valid as long as
the array object itself is still around.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
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] Memoryviews should expose the underlying memory address

2012-09-21 Thread Maciej Fijalkowski 
On Fri, Sep 21, 2012 at 1:16 AM, Glyph  wrote:
> Le Sep 20, 2012 à 11:35 AM, David Beazley  a écrit :
>
>> Well, if it's supposed to do that, it certainly doesn't work for me in 3.3.  
>> I get a type error about it wanting a ctypes pointer object.Even if this 
>> worked, it still doesn't address the need to get the pointer value possibly 
>> for some other purpose such as handling it off to a bunch of code generated 
>> via LLVM.
>
> It seems like there's no reason to need to get the pointer value out as a 
> Python integer.  If you are trying to get a pointer from a memoryview into 
> some C code, or into some LLVM generated code, you still need to do the 
> Python int object → C integer-of-some-kind → C pointer type conversion.  
> Better to just go straight from Python memoryview object → C pointer in one 
> supported API call.  Isn't this what the y* w* s* format codes are for?
>
> Every time I have something that's a big number and I need to turn it into a 
> pointer, I have to stare at the table in 
>  for like 30 seconds. 
>  I'd rather have some Python API do the staring for me.  David, I realize 
> that table is probably permanently visible in the heads-up display that your 
> cybernetic implants afford you, but some of us need to make our way through C 
> code with humbler faculties ;-).
>
> -g

This is also kind of a problem with PyPy and CFFI, where we actively
discourage people from using C. Passing address as an int sounds like
a very reasonable solution.

Cheers,
fijal
___
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] Memoryviews should expose the underlying memory address

2012-09-21 Thread David Beazley 

On Sep 21, 2012, at 4:45 AM, Maciej Fijalkowski wrote:
> 
> This is also kind of a problem with PyPy and CFFI, where we actively
> discourage people from using C. Passing address as an int sounds like
> a very reasonable solution.
> 

I just wanted to add that getting the address as an integer is useful because 
one might actually want to do math with it.   Since memoryviews also expose the 
shape, itemsize, and other information, it's conceivable that one might combine 
these with the base address to compute locations within the array.  Example: 
take a memoryview, slice up the buffer into partitions and hand them off to 
worker functions running in a thread pool.

Cheers,
Dave

___
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] [Python-checkins] peps: add stub for wheel spec

2012-09-21 Thread Brett Cannon 
We don't put stubs of PEPs into the repository, especially when they have
not been vetted on python-ideas or some other public mailing list that is
appropriate for the subject.

You also mis-capitalized PyPy in this commit.

On Thu, Sep 20, 2012 at 6:44 PM, daniel.holth wrote:

> http://hg.python.org/peps/rev/4ac055623f2a
> changeset:   4514:4ac055623f2a
> user:Daniel Holth 
> date:Thu Sep 20 18:43:53 2012 -0400
> summary:
>   add stub for wheel spec
>
> files:
>   pep-0425.txt |   7 +++
>   pep-0427.txt |  30 ++
>   2 files changed, 33 insertions(+), 4 deletions(-)
>
>
> diff --git a/pep-0425.txt b/pep-0425.txt
> --- a/pep-0425.txt
> +++ b/pep-0425.txt
> @@ -81,10 +81,9 @@
>
>  Other Python implementations should use `sys.implementation.name`.
>
> -The version is `py_version_nodot`.  CPython gets away with no dot, but
> -if one is needed the underscore `_` is used instead.  Pypy uses versions
> that
> -do not track the Python language version and should probably use its own
> -versions here `pp18`, `pp19`.
> +The version is `py_version_nodot`.  CPython gets away with no dot,
> +but if one is needed the underscore `_` is used instead.  Pypy should
> +probably use its own versions here `pp18`, `pp19`.
>
>  The version can be just the major version `2` or `3` `py2`, `py3` for
>  many pure-Python distributions.
> diff --git a/pep-0427.txt b/pep-0427.txt
> new file mode 100644
> --- /dev/null
> +++ b/pep-0427.txt
> @@ -0,0 +1,30 @@
> +PEP: 426
> +Title: The Wheel Binary Package Format 1.0
> +Version: $Revision$
> +Last-Modified: $Date$
> +Author: Daniel Holth 
> +Discussions-To: Distutils SIG
> +Status: Draft
> +Type: Standards Track
> +Content-Type: text/x-rst
> +Created: 20 Sep 2012
> +
> +
> +Abstract
> +
> +
> +This PEP describes a binary format for Python called wheel.
> +
> +Copyright
> +=
> +
> +This document has been placed in the public domain.
> +
> +
> +..
> +   Local Variables:
> +   mode: indented-text
> +   indent-tabs-mode: nil
> +   sentence-end-double-space: t
> +   fill-column: 70
> +   End:
>
> --
> Repository URL: http://hg.python.org/peps
>
> ___
> Python-checkins mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-checkins
>
>
___
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] Summary of Python tracker Issues

2012-09-21 Thread Python tracker 

ACTIVITY SUMMARY (2012-09-14 - 2012-09-21)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open3731 (+30)
  closed 24045 (+25)
  total  27776 (+55)

Open issues with patches: 1650 


Issues opened (44)
==

#15945: memoryview + bytes fails
http://bugs.python.org/issue15945  opened by exarkun

#15947: Assigning new values to instance of pointer types does not che
http://bugs.python.org/issue15947  opened by facundobatista

#15948: Unchecked return value of I/O functions
http://bugs.python.org/issue15948  opened by christian.heimes

#15949: docs.python.org not getting updated
http://bugs.python.org/issue15949  opened by cjerdonek

#15951: string.Formatter returns str for empty unicode template
http://bugs.python.org/issue15951  opened by Aleksey.Sivokon

#15952: format(value) and value.__format__() behave differently with u
http://bugs.python.org/issue15952  opened by cjerdonek

#15953: Incorrect some fields declaration in the PyTypeObject document
http://bugs.python.org/issue15953  opened by storchaka

#15954: No error checking after using of the wcsxfrm()
http://bugs.python.org/issue15954  opened by storchaka

#15955: gzip, bz2, lzma: add method to get decompressed size
http://bugs.python.org/issue15955  opened by christian.heimes

#15956: backreference to named group does not work
http://bugs.python.org/issue15956  opened by steve.newcomb

#15957: README.txt points to broken "contributing" url in python wiki
http://bugs.python.org/issue15957  opened by jcd

#15958: bytes.join() should allow arbitrary buffer objects
http://bugs.python.org/issue15958  opened by pitrou

#15961: Missing return value in ``system_message``
http://bugs.python.org/issue15961  opened by malthe

#15962: Windows STDIN/STDOUT Redirection is actually FIXED
http://bugs.python.org/issue15962  opened by Nacsa.Kristóf

#15963: Improve ./configure's support for 32/64-bit debug|release|prof
http://bugs.python.org/issue15963  opened by trent

#15964: SyntaxError in asdl when building 2.7 with system Python 3
http://bugs.python.org/issue15964  opened by cjerdonek

#15966: concurrent.futures: Executor.submit keyword arguments may not 
http://bugs.python.org/issue15966  opened by mark.dickinson

#15967: Slaves don't seem to clean up their /tmp mess if a step fails.
http://bugs.python.org/issue15967  opened by trent

#15968: Incorporate Tcl/Tk/Tix into the Windows build process
http://bugs.python.org/issue15968  opened by jkloth

#15969: faulthandler: drop S from dump_tracebacks_later() function nam
http://bugs.python.org/issue15969  opened by haypo

#15971: Sporadic failure in test_dump_tracebacks_later_file (test_faul
http://bugs.python.org/issue15971  opened by ezio.melotti

#15972: wrong error message for os.path.getsize
http://bugs.python.org/issue15972  opened by jftuga

#15973: Segmentation fault on timezone comparison
http://bugs.python.org/issue15973  opened by lanhel

#15974: Optional compact and colored output for regrest
http://bugs.python.org/issue15974  opened by brett.cannon

#15976: Inconsistent behavior of search_for_exec_prefix() results in s
http://bugs.python.org/issue15976  opened by foutrelis

#15977: Memory leak in _ssl.c
http://bugs.python.org/issue15977  opened by Daniel.Sommermann

#15978: asyncore: included batteries don't fit
http://bugs.python.org/issue15978  opened by chrysn

#15979: Improve timeit documentation
http://bugs.python.org/issue15979  opened by ezio.melotti

#15982: asyncore.dispatcher does not handle windows socket error code 
http://bugs.python.org/issue15982  opened by McNetic

#15983: multiprocessing JoinableQueue's join function with timeout
http://bugs.python.org/issue15983  opened by legordian

#15984: Wrong documentation for PyUnicode_FromObject()
http://bugs.python.org/issue15984  opened by storchaka

#15986: memoryview: expose 'buf' attribute
http://bugs.python.org/issue15986  opened by skrah

#15987: Provide a way to compare AST nodes for equality recursively
http://bugs.python.org/issue15987  opened by Julian

#15988: Inconsistency in overflow error messages of integer argument
http://bugs.python.org/issue15988  opened by storchaka

#15989: Possible integer overflow of PyLong_AsLong() results
http://bugs.python.org/issue15989  opened by storchaka

#15990: solidify argument/parameter terminology
http://bugs.python.org/issue15990  opened by cjerdonek

#15991: BaseHTTPServer with ThreadingMixIn serving wrong data sometime
http://bugs.python.org/issue15991  opened by theamk

#15992: Strict aliasing violations in Objects/unicodeobject.c
http://bugs.python.org/issue15992  opened by mark.dickinson

#15993: Windows: 3.3.0-rc2.msi: test_buffer fails
http://bugs.python.org/issue15993  opened by skrah

#15994: memoryview to freed memory can cause segfault
http://bugs.python.org/issue15994  opened by sbt

#15996: pow() for complex numbers is rough around t

[Python-Dev] 3.3 release

2012-09-21 Thread Yury Selivanov 
Hello,

What's the status of 3.3?  Is it going to be released tomorrow?

(I see that we still have a few release-blockers in the tracker,
and the whatsnew section is probably due to be updated by Raymond...)

-
Yury
___
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