[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 Python-Dev@

[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 wit

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.o

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

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 addre

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.