Re: [Python-3000] Possible py3k problem resolved.

Lambert, David W (S&T) schrieb: > Martin's "read the manual" answer is quite satisfying. > Unfortunately, it doesn't fix core dump of Issue4309. > I became excited thinking the problems could be related. Issue4309 is basically this problem calling the printf function: libc = CDLL(find_library("

Re: [Python-3000] Possible py3k problem.

Victor Stinner schrieb: > Le Wednesday 19 November 2008 15:39:43 Martin (gzlist), vous avez écrit : >> This is covered in the documentation, isn't it? >> >> >> >> Important note for callback functions: >> >> Make sure you keep referenc

Re: [Python-3000] PEP 3121 implemented

Martin v. Löwis schrieb: > I just finished a PEP 3121 implementation, uploaded at > > http://codereview.appspot.com/1962 > > It contains all the API changes proposed in the PEP, > and updates all modules to conform to a minimal level > of the API. I'd like to commit the change later today, > so t

Re: [Python-3000] the release gods are angry at python

Christian Heimes schrieb: > Georg Brandl schrieb: >> Perhaps make it an optional resource? > > In the py3k branch I've assigned the audio resource to the winsound > tests. Only regrtest.py -uall or -uaudio runs the winsound test. Reason: > the test sound was freaking out my poor cat. :/ I feel wi

Re: [Python-3000] the release gods are angry at python

>> test_winsound on this buildbot only passes when I have an open remote desktop >> connection to the (virtual) machine. I have not found any other way to make >> these >> tests pass (I tried 'net stop beep', disabling the sound driver, removing the >> sound driver, disconnecting the hosts sound

Re: [Python-3000] the release gods are angry at python

Neal Norwitz schrieb: > The next releases of 2.6/3.0 are planned for April 2, just over a week > from now. There is much work that needs to be done. The buildbots > are in a pretty sad state and the gods are seeing too much red. > > http://www.python.org/dev/buildbot/stable/ > http://www.pyt

Re: [Python-3000] PEP 361: Python 2.6/3.0 release schedule

Barry Warsaw schrieb: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Mar 18, 2008, at 2:04 AM, Travis Oliphant wrote: >> >> Hey Barry, >> >> Thanks for putting this PEP together. This is really helpful. > > Hi Travis... thanks! > >> I didn't see discussion of PEP 3118 and it's feature

Re: [Python-3000] python-safethread project status

Adam Olsen schrieb: > On Tue, Mar 18, 2008 at 9:21 AM, Steven Bethard > <[EMAIL PROTECTED]> wrote: >> On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowalczyk >> <[EMAIL PROTECTED]> wrote: >> > Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze: >> > >> > > I've replaced __del__ AP

Re: [Python-3000] [Python-ideas] Namespaces are one honking great idea -- let's do more of those!

Christian Heimes schrieb: > Phillip J. Eby wrote: >> FYI, setuptools uses and supports #! lines on Windows, with the >> executable path in quotes if it contains spaces. For a given script >> "foo", it generates two files: >> >> foo.exe >> foo-script.py >> >> And the .exe is just a st

Re: [Python-3000] Useless methods in Queue module

Raymond Hettinger schrieb: > I proposed to remove three methods from the queue module, qsize(), > empty(), and full(). These are not reliable. The RightWay (tm) is > to trap the Empty and Full exceptions or use the .join() approach. I am actively using empty(). This code example receives and pr

Re: [Python-3000] PyInt_ to PyLong_ rename

Jim Jewett schrieb: > On 12/3/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On Dec 3, 2007 12:12 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> > >> Sure. However, you could also use >> > >> _testcapi.PY_SSIZE_T_MAX, or >> > >> ctypes.sizeof(ctypes.py_object). > >> > > Much less intuitiv

[Python-3000] win64 buildbot hangs in test

The win64 buildbot testing stage hangs. The only thing that I can see is (I have no time to investigate further) in processexplorer: 'python -E -tt ../lib/test/regrtest.py -uall -rw' has started this process which hangs: 'cmd /c ""C:\Program Files (x86)\Microsoft Visual Studio 8\VC\vcvarsall.ba

Re: [Python-3000] Python 3.0a2 release

Christian Heimes schrieb: > Martin v. Löwis wrote: >> I would be opposed unless a complete automation of that is possible and >> can be contributed. For AMD64, I see little hope for that, as I build >> the releases in a cross-compilation environment, so I can't run them >> on the build machine. >

Re: [Python-3000] Python 3.0a2 release

Martin v. Löwis schrieb: >> Not that it changes anything, but VS 2008 it was released today. > > Actually, it may. I'll see whether I can release 3.0a2 with VS 2008. > (which depends on whether I can get it through our MSDN subscription, > and on whether Christian's project files work well enough)

Re: [Python-3000] Win64 buildbot

Guido van Rossum schrieb: > On Nov 15, 2007 12:14 PM, Thomas Heller <[EMAIL PROTECTED]> wrote: >> I'll make the change. > > Thanks! > >> And, btw: after a manual clean, the win64 buildbot compiles again. > > Hm, how about running a cleanup step at the

Re: [Python-3000] Win64 buildbot

Guido van Rossum schrieb: > On Nov 15, 2007 11:35 AM, Thomas Heller <[EMAIL PROTECTED]> wrote: >> Guido van Rossum schrieb: >> > Perhaps changing the remaining occurrences to PyObject_Str will fix this? >> >> If PyObject_Unicode is #defined for backwards c

Re: [Python-3000] Win64 buildbot

Guido van Rossum schrieb: > On Nov 15, 2007 11:22 AM, Thomas Heller <[EMAIL PROTECTED]> wrote: >> The Win64 buildbot currently fails to link python30.dll and _testcapi.pyd >> because of an unresolved symbol PyObject_Unicode: >> >> http://python.org/dev/buildbot/3.0

[Python-3000] Win64 buildbot

The Win64 buildbot currently fails to link python30.dll and _testcapi.pyd because of an unresolved symbol PyObject_Unicode: http://python.org/dev/buildbot/3.0/amd64%20XP%203.0/builds/242/step-compile/0 Does anyone have an idea why? Thomas ___ Python-3

Re: [Python-3000] status of buildbots

Neal Norwitz schrieb: > Other platform specific problems: > > Win64 has a few more: > test_csv test_dumbdbm test_fileinput test_format test_getargs2 > test_gettext test_mailbox test_netrc test_pep277 test_subprocess > test_winsound > http://python.org/dev/buildbot/3.0/amd64%20XP%203.0/bui

Re: [Python-3000] Unicode and OS strings

Jean-Paul Calderone schrieb: > On Fri, 21 Sep 2007 10:00:38 -0400, Jim Jewett <[EMAIL PROTECTED]> wrote: >> [snip] >> >>It does sound like we need a way to get to the original bytes, similar >>to sys.stdin.buffer. Is it reasonable to expose sys.argv.buffer? >>(Since this would be bytes rather than

Re: [Python-3000] Solaris support in 3.0?

While we're at solaris, I would appreciate if some solaris expert(s) could take a look at http://bugs.python.org/issue1777530 Thanks, Thomas ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubsc

[Python-3000] Confused about getattr() and special methods

I was looking into the Lib\test\test_uuid on Windows, which fails with this traceback: test test_uuid failed -- Traceback (most recent call last): File "C:\buildbot\work\3.0.heller-windows\build\lib\test\test_uuid.py", line 323, in test_ipconfig_getnode node = uuid._ipconfig_getnode() Fi

[Python-3000] Merging between trunk and py3k?

Will commits still be merged between trunk and py3k in the future (after the 3.0a1 release), or must this now be down by the developers themselves? Or is it less work for the one who does the merge if applicable bug fixes are comitted to both trunk and py3k branch? Thomas ___

Re: [Python-3000] buildbots

Martin v. Löwis schrieb: >> Any suggestions? > > I've now backed out my first patch, and implemented an extension > to msvcrt, as well as a command line option for regrtest. Let's > see how this works. > > Regards, > Martin At least the tests on the win32 buildbot now do not hang any longer if I

Re: [Python-3000] buildbots

Martin v. Löwis schrieb: >> Agreed, thus my original suggestion of a standalone wrapper executable >> (or using ctypes). > > That doesn't work well, either - how do we get this wrapper onto the > build slaves? It would work if such wrapper shipped with the > operating system. > >> I just think th

Re: [Python-3000] current status

Neal Norwitz schrieb: > * On Win64, there's this assert: >SystemError: Objects\longobject.c:412: bad argument to internal function > I don't see how it's getting triggered based on the traceback though Python/getargs.c, line 672: ival = PyInt_AsSsize_t(arg); calls Objects/long

Re: [Python-3000] buildbots

Martin v. Löwis schrieb: >> So, an environment variable would be useful, but maybe there should also be >> a Python function available that calls set_error_mode(). >> sys.set_error_mode()? > > Even though this would be somewhat lying - I'd put it into > msvcrt.set_error_mode. For the _CrtSet fun

Re: [Python-3000] buildbots

Martin v. Löwis schrieb: >> New patch (still detects the debug build because the name of the C runtime >> dll depends on it): > > I know it will be difficult to talk you into not using ctypes :-), > but... > > I think this should go into the interpreter code itself. One problem > with your patch

Re: [Python-3000] buildbots

Martin v. Löwis schrieb: >> I suggest to apply this patch, which sets an environment variable in the >> Tools\buildbot\test.bat script, detects the Windows debug build, and calls >> SetErrorMode(7) as David suggested: > > Sounds fine with me - although I would leave out the test for debug > build,

Re: [Python-3000] buildbots

Thomas Heller schrieb: > > I suggest to apply this patch, which sets an environment variable in the > Tools\buildbot\test.bat script, detects the Windows debug build, and calls > SetErrorMode(7) as David suggested: If noone objects, I would like to apply this patch first, see if i

Re: [Python-3000] buildbots

David Bolen schrieb: > David Bolen <[EMAIL PROTECTED]> writes: > >> "Martin v. Löwis" <[EMAIL PROTECTED]> writes: >> These messageboxes of course hang the tests on the windows build servers, so probably it would be good if they could be disabled completely. >>> >>> I think this will be v

Re: [Python-3000] buildbots

Martin v. Löwis schrieb: >> Do you know if it is possible to configure windows so that debug assertions >> do NOT >> display a message box (it is very convenient for interactive testing, but >> not so >> for automatic tests)? > > You can use _set_error_mode(_OUT_TO_STDERR) to make assert() go to

Re: [Python-3000] buildbots

Unfortunately, I read nearly all my mailing lists through gmane with nntp - and gmane is down currently (it doesn't deliver new messages any more). So I cannot write a reply in the original thread :-( Neal: > > We got 'em. Let the spam begin! :-) > > > > This page is not linked from the web anyw

Re: [Python-3000] buildbots

Unfortunately, I read nearly all my mailing lists through gmane with nntp - and gmane is down currently (it doesn't deliver new messages any more). So I cannot write a reply in the original thread :-( Neal: > We got 'em. Let the spam begin! :-) > > This page is not linked from the web anywhere:

Re: [Python-3000] buildbots

Thomas Heller schrieb: > Martin v. Löwis schrieb: >>> Since the tests fail on the trunk (on the windows machines), >>> the 'clean' step is not run. >> >> No. The 'clean' step is run even if the test step failed. >> >> The problem

Re: [Python-3000] buildbots

Unfortunately, I read nearly all my mailing lists through gmane with nntp - and gmane is down currently (it doesn't deliver new messages any more). So I cannot write a reply in the original thread :-( Neal: > > We got 'em. Let the spam begin! :-) > > > > This page is not linked from the web anyw

Re: [Python-3000] status (preparing for first alpha)

Thomas Heller schrieb: > Neal Norwitz schrieb: >> Py3k is progressing nicely. We are planning the first alpha sometime >> this week. The tests are mostly passing. With all the churn over the >> last week, I'm sure it's about to change. :-) AFAIK, nearly all the

Re: [Python-3000] status (preparing for first alpha)

Neal Norwitz schrieb: > Py3k is progressing nicely. We are planning the first alpha sometime > this week. The tests are mostly passing. With all the churn over the > last week, I'm sure it's about to change. :-) AFAIK, nearly all the > tests pass on Linux and Mac OS X. There was a report that

Re: [Python-3000] Move to a "py3k" branch *DONE*

Neal Norwitz schrieb: > On 8/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> This is done. The new py3k branch is ready for business. >> >> Left to do: >> >> - switch the buildbot and the doc builder to use the new branch (Neal) Shouldn't there be a py3k buildbot at http://www.python.org/dev/

Re: [Python-3000] Pleaswe help with the countdown to zero failing tests in the struni branch!

Martin v. Löwis schrieb: >>> It's in Modules/timemodule.c, line 691: >>> PyModule_AddObject(m, "tzname", >>>Py_BuildValue("(zz)", tzname[0], tzname[1])); >>> >>> According to MSDN, tzname is a global variable; the contents is somehow >>> derived from the TZ envir

Re: [Python-3000] bytes regular expression?

Victor Stinner schrieb: > > I prefer str8 which looks to be a good candidate for "frozenbytes" type. > I love this idea! Leave str8 as it is, maybe extend Python so that it understands the s"..." literals and we are done. Thomas ___ Python-3000 mai

Re: [Python-3000] py3k-struni: proposition to fix ctypes bug, ctypes c_char creates bytes

Victor Stinner schrieb: > Hi, > > I hear Guido's request to fix last py3k-struni bugs. I downloaded subversion > trunk and started to work on ctypes tests. > > The problem is that ctypes c_char (and c_char_p) creates unicode string > instead of byte string. I attached a proposition (patch) to c

Re: [Python-3000] Pleaswe help with the countdown to zero failing tests in the struni branch!

Guido van Rossum schrieb: > On 8/7/07, Thomas Heller <[EMAIL PROTECTED]> wrote: >> Guido van Rossum schrieb: >> > test_ctypes >> > Recently one test started failing again, after Martin changed >> > PyUnicode_FromStringAndSize() to use UTF8 instead of La

Re: [Python-3000] C API cleanup str

Martin v. Löwis schrieb: >> One issue with just putting this in the C API docs is that I believe >> (tell me if I'm wrong) that these haven't been kept up to date in the >> struni branch so we'll need to make a lot more changes than just this >> one... > > That's certainly the case. However, if we

Re: [Python-3000] Pleaswe help with the countdown to zero failing tests in the struni branch!

Guido van Rossum schrieb: > We're down to 11 failing test in the struni branch. I'd like to get > this down to zero ASAP so that we can retire the old p3yk (yes, with > typo!) branch and rename py3k-struni to py3k. > > Please help! Here's the list of failing tests: > > test_ctypes > Recently one

[Python-3000] pep3115 - metaclasses in python 3000

playing a little with py3k... pep3115 mentions that "__prepare__ returns a dictionary-like object which is used to store the class member definitions during evaluation of the class body." It does not mention whether this dict-like object is used afterwards as the class-dictionary of the created c

Re: [Python-3000] [Python-Dev] Need help fixing failing Py3k Unittests in py3k-struni

Amaury Forgeot d'Arc schrieb: > Re-hello, > > Thomas Heller wrote: >> > On 7/11/07, Amaury Forgeot d'Arc wrote: >> >> Thomas Heller wrote: >> >> > I would love to look into these, but I prefer debugging on Windows. >> >> >

Re: [Python-3000] Need help fixing failing Py3k Unittests in py3k-struni

Walter Dörwald schrieb: > > I guess for the final version of Py3000 type_set_name() in typeobject.c > will not downgrade unicode strings to str8, but instead upgrade str8 > objects to unicode. I'm currently working on type_set_name, see the other message with subject 'Heaptypes'. Thomas __

[Python-3000] Heaptypes

ctypes creates heaptypes with this call, in _ctypes.c, line 3986 (slightly simplified): result = PyObject_CallFunction((PyObject *)&ArrayType_Type, "s(O){s:n,s:O}", name, &

Re: [Python-3000] Heaptypes

Guido van Rossum schrieb: > There are currently three "string" types, here shown with there repr styles: > > - str = 'same as unicode in 2.x' > - bytes = b'new, mutable list of small ints' > - str8 = s'same as str in 2.x' > > The s'...' notation means it's an 8-bit string (not a bytes array). > T

Re: [Python-3000] [Python-Dev] Need help fixing failing Py3k Unittests in py3k-struni

Guido van Rossum schrieb: > That would be great! Assign it to theller who can test it much better > than I can. > > On 7/11/07, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote: >> Thomas Heller wrote: >> > I would love to look into these, but I prefer d

Re: [Python-3000] Py3k doesn't understand octal literals (on Windows)

Thomas Heller schrieb: > In a break from real work, I wanted to play a little with 3.0. Did svn > update, and built on Windows. > Unfortunately, the resulting Python does not understand the new octal > literals like 0o777, so > importing 'os' fails: > > &

[Python-3000] Py3k doesn't understand octal literals (on Windows)

In a break from real work, I wanted to play a little with 3.0. Did svn update, and built on Windows. Unfortunately, the resulting Python does not understand the new octal literals like 0o777, so importing 'os' fails: 'import site' failed; use -v for traceback Python 3.0x (p3yk:55071M, May 2 20

Re: [Python-3000] __debug__

Brett Cannon schrieb: > On 5/31/07, Georg Brandl <[EMAIL PROTECTED]> wrote: >> >> Guido just fixed a case in the py3k branch where you could assign to >> "None" in a function call. >> >> __debug__ has similar problems: it can't be assigned to normally, but via >> keyword arguments it is possible. >

Re: [Python-3000] the future of the GIL

Greg Ewing schrieb: > James Y Knight wrote: > >> This just isn't true. Python can do an atomic increment in a fast >> platform specific way. > > The problem with this, from what I've heard, is that > atomic increment instructions tend to be on the order > of 100 times slower than normal memory

Re: [Python-3000] the future of the GIL

Guido van Rossum schrieb: > On 5/8/07, Luis P Caamano <[EMAIL PROTECTED]> wrote: >> On 5/7/07, "Guido van Rossum" wrote: >> > Around '99 Greg Stein and Mark Hammond tried to get rid of the GIL. >> > They removed most of the global mutable data structures, added >> > explicit locks to the remaining

Re: [Python-3000] I18N identifiers

Martin v. Löwis schrieb: > Giovanni Bajo schrieb: >>> What is the status of I18N identifiers? Has any progress been made? >>> If not, I'd like to write a PEP, and mentor a SoC student to work on >>> that (if one shows up). >> >> Is there any agreement over this feature in the first place? > > Th

Re: [Python-3000] PEP Draft: Enhancing the buffer protcol

Travis E. Oliphant schrieb: > Attached is my current draft of the enhanced buffer protocol for Python > 3000. It is basically what has been discussed except for some issues > with non single-segment memory areas (such as a sub-array). > > Comments are welcome. > > -Travis Oliphant > Addition

Re: [Python-3000] Metaclasses in Py3K

Talin schrieb: > Guido van Rossum wrote: >> I've been thinking about this too, and I think it's reasonable to let >> the metaclass provide the dict to be used as locals. This is easier >> when the metaclass is given in the class header, e.g. by way of a base >> class, or through the default metacla

Re: [Python-3000] Removing __var

Bob Ippolito schrieb: > On 9/22/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote: >> On Friday 22 September 2006 13:05, Christian Tanzer wrote: >> > It is useful in some situations, though. In particular, I use a >> > metaclass that sets `__super` to the right value. This wouldn't work >> > with

Re: [Python-3000] Small Py3k task: fix modulefinder.py

Guido van Rossum schrieb: > Is anyone familiar enough with modulefinder.py to fix its breakage in > Py3k? It chokes in a nasty way (exceeding the recursion limit) on the > relative import syntax. I suspect this is also a problem for 2.5, when > people use that syntax; hence the cross-post. There's

Re: [Python-3000] threading, part 2 --- + a bit of ctypes FFI worry

Tim Peters schrieb: > [Josiah Carlson] >> ... >> Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on >> win32 >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import ctypes >> >>> import threading >> >>> import time >> >>> def foo(): >> ...

Re: [Python-3000] Ctypes as cross-interpreter C calling interface

Greg Ewing schrieb: > Paul Prescod wrote: >> It seems that the emerging >> consensus (bar a security question from Guido) is that ctypes it the way >> forward for calling C code in Python 3000. I'd like to clarify what this >> might mean: > > What's the state of play concerning ctypes support >

Re: [Python-3000] Ctypes as cross-interpreter C calling interface

Greg Ewing schrieb: > Another thought about ctypes: What if you want to pass > a Python function into C as a callback? Does ctypes > have a way of handling that? > Sure. The tutorial has an example that calls qsort with a Python comparison function: http://docs.python.org/dev/lib/ctypes-callback

Re: [Python-3000] Unicode identifiers (Was: sets in P3K?)

Boris Borcic wrote: > Martin v. Löwis wrote: > > Guido van Rossum wrote: > >> I want good Unicode support for string literals and comments. > >> Everything else in the language ought to be ASCII. > > > > Does that include restricting identifiers to ASCII as well? > > I am late on this subthre

Re: [Python-3000] Is reference counting still needed?

Greg Ewing wrote: > Tim Peters wrote: > >> Yes, but I don't think anyone's offering to build a P3K chip for us ;-) > > Since you mention it, one of the things that's been > occupying my mind in idle moments recently is trying to > imagine what a Python chip *would* be like, and maybe > even desig