Re: [Python-Dev] int vs ssize_t in unicode

Neal Norwitz wrote: > In Include/ucnhash.h I notice some integers and wonder if those should > be Py_ssize_t. It looks like they are just names so they should be > pretty short. Right: int size is below 100; the name length of a Unicode character is below 40 (I believe). OTOH, changing them to Py

[Python-Dev] int vs ssize_t in unicode

Martin, In Include/ucnhash.h I notice some integers and wonder if those should be Py_ssize_t. It looks like they are just names so they should be pretty short. But in Objects/unicodeobject.c, I notice a bunch of ints and casts to int and wonder if they should be changed to Py_ssize_t/removed: 2

Re: [Python-Dev] unicode vs buffer (array) design issue can crash interpreter

On 3/31/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Martin v. Löwis wrote: > > Neal Norwitz wrote: > >> See http://python.org/sf/1454485 for the gory details. Basically if > >> you create a unicode array (array.array('u')) and try to append an > >> 8-bit string (ie, not unicode), you can crash

Re: [Python-Dev] TODO Wiki (was: Preserving the blamelist)

On 4/12/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [A.M. Kuchling] > >> Do we need a list of CPython cleanup projects? > >> (Compare to the Linux kernel janitors: > >> .) > > [Neal Norwitz] > > +1. Could add a page to the wiki and link to it from the dev faq

Re: [Python-Dev] TODO Wiki (was: Preserving the blamelist)

[A.M. Kuchling] >> Do we need a list of CPython cleanup projects? >> (Compare to the Linux kernel janitors: >> .) [Neal Norwitz] > +1. Could add a page to the wiki and link to it from the dev faq. Not the same thing, but I just added: http://wiki.pytho

Re: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS

Tim Peters wrote: > A less-desirable (IMO) alternative is to change the Python core to > display bare (non-dotted) exception names when it produces a > traceback. Much less desirable, considering that there are modules which define an exception just called "error" on the assumption that you're go

Re: [Python-Dev] building with C++

Looks good to me. Why don't you check it in. Jeremy On 4/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Jeremy> The code in compile.c is pretty dodgy. I'd like to think of a > Jeremy> better way to represent an array of cmpop_ty objects than > Jeremy> casting ints to void*

Re: [Python-Dev] building with C++

Jeremy> The code in compile.c is pretty dodgy. I'd like to think of a Jeremy> better way to represent an array of cmpop_ty objects than Jeremy> casting ints to void* and then back. http://python.org/sf/1469594 might be a step in the right direction. I assigned it to Anthony. Feel

Re: [Python-Dev] building with C++

So I lied - I found the time today to spread the magic pixie dust of extern "C" {} around to get the Python core to build and link with g++. (It still builds with gcc). There's still an issue with Modules/_sre.c, and now that we can run setup.py, there's lots and lots of errors from the various

Re: [Python-Dev] building with C++

On Thursday 13 April 2006 12:03, Jeremy Hylton wrote: > The code in compile.c is pretty dodgy. I'd like to think of a > better way to represent an array of cmpop_ty objects than casting > ints to void* and then back. Well, it's compiling and working with C++ now, at least. But yeah, that's prett

Re: [Python-Dev] building with C++

On 4/12/06, Anthony Baxter <[EMAIL PROTECTED]> wrote: > The code is _nearly_ building fine. there's an issue in _sre.c with > some code that either returns a Py_UNICODE* or an SRE_CHAR* (unsigned > char*) in a void*. The code probably needs a refactoring to deal with > that. There's also > Python/c

Re: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS

[Tim] >> ... >> Fine by me if we change the failing tests on the trunk to pass (noting >> that should have been done before checking in). [Phillip] > It's not fine by me if the reason for the failure is that doctests trapping > specific exceptions no longer work with the patch.> > If that's the ca

Re: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS

On Thursday 13 April 2006 11:14, Tim Peters wrote: > > Patch #860326: traceback.format_exception_only() now prepends the > > exception's module name to non-builtin exceptions, like the > > interpreter itself does. > > And all the trunk buildbot runs have failed since, in at least > test_decimal, te

Re: [Python-Dev] Request for review

[Georg Brandl] > Hm. This broke a few doctests. I can fix them, but I wonder if > doctest should accept a bare exception name if the exception > is defined in the current module. No. > Or should it ignore the module name altogether? No. doctest strives to be magic-free WYSIWYG. If someone _int

Re: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS

At 09:14 PM 4/12/2006 -0400, Tim Peters wrote: >The 2.4 backport of this patch should be reverted, since it changes >visible behavior (for example, all the 2.4 branch buildbot runs also >fail now). > >Fine by me if we change the failing tests on the trunk to pass (noting >that should have been done

Re: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS

[georg.brandl] > Author: georg.brandl > Date: Wed Apr 12 23:14:09 2006 > New Revision: 45321 > > Modified: >python/trunk/Lib/test/test_traceback.py >python/trunk/Lib/traceback.py >python/trunk/Misc/NEWS > Log: > Patch #860326: traceback.format_exception_only() now prepends the > excepti

Re: [Python-Dev] building with C++

On Thursday 13 April 2006 10:59, Skip Montanaro wrote: > > > Anthony> I've done a lot of the work to get Python to build > > > with g++ - > > > > > > Is this on a branch or available as a patch somewhere? > > > > It's the trunk. > > Is there a primer that will get me to where Anthony is? I tri

Re: [Python-Dev] building with C++

> > Anthony> I've done a lot of the work to get Python to build with g++ - > > Is this on a branch or available as a patch somewhere? > > It's the trunk. Is there a primer that will get me to where Anthony is? I tried the obvious CC=g++ ./configure --with-cxx=g++ and the build fails t

Re: [Python-Dev] Proposal: expose PEP 302 facilities via 'imp' and 'pkgutil'

Phillip J. Eby wrote: > At 08:39 PM 4/12/2006 +1000, Nick Coghlan wrote: >> In this particular case, it would be a Python module "imp.py" that >> included the line "from _imp import *" (where _imp is the current >> C-only module with a different name). > > I don't think that's going to work, sin

Re: [Python-Dev] Request for review

Georg Brandl wrote: > Seo Sanghyeon wrote: >> Can someone have a look at #860326? I got bitten by it today, and I can >> see no reason not to apply suggested patch. > > I've reviewed it and checked it in. Hm. This broke a few doctests. I can fix them, but I wonder if doctest should accept a bare

Re: [Python-Dev] Request for review

Seo Sanghyeon wrote: > Can someone have a look at #860326? I got bitten by it today, and I can > see no reason not to apply suggested patch. I've reviewed it and checked it in. Cheers, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail

Re: [Python-Dev] need info for externally maintained modules PEP

On Sat, Apr 08, 2006 at 02:47:28PM -0700, Brett Cannon wrote: > OK, I am going to write the PEP I proposed a week or so ago, listing > all modules and packages within the stdlib that are maintained > externally so we have a central place to go for contact info or where > to report bugs on issues.

[Python-Dev] cleanup list

On Wed, Apr 12, 2006 at 01:43:43PM -0400, Tim Peters wrote: > BTW, someone looking for an easy task might enjoy rewriting other > tp_traverse slots to use Py_VISIT. We even have cases now (like > super_traverse) where modules define their own workalike > traverse-visit macros, which has become con

Re: [Python-Dev] Preserving the blamelist

On 4/12/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > On Wed, Apr 12, 2006 at 01:43:43PM -0400, Tim Peters wrote: > > BTW, someone looking for an easy task might enjoy rewriting other > > tp_traverse slots to use Py_VISIT. We even have cases now (like > > super_traverse) where modules define thei

Re: [Python-Dev] Preserving the blamelist

On Wed, Apr 12, 2006 at 01:43:43PM -0400, Tim Peters wrote: > BTW, someone looking for an easy task might enjoy rewriting other > tp_traverse slots to use Py_VISIT. We even have cases now (like > super_traverse) where modules define their own workalike > traverse-visit macros, which has become con

[Python-Dev] Request for review

Can someone have a look at #860326? I got bitten by it today, and I can see no reason not to apply suggested patch. Thanks! Seo Sanghyeon ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] Preserving the blamelist

[Tim] >> Phillip, when eyeballing gen_dealloc(), I didn't understand two things: >> >> 1. Why doesn't >> >> if (gen->gi_frame->f_stacktop!=NULL) { >> >>check first to be sure that gen->gi_frame != Py_None? [Phillip] > Apparently, it's because I'm an idiot, and because nobody else reali

Re: [Python-Dev] Preserving the blamelist

[Tim ] >> I'd whine about not checking buildbot health after a code change, >> except that it's much more tempting to point out that Thomas couldn't >> have run the test suite successfully on his own box in this case :-) [Thomas] > Not with -uall, yes. Without -uall it ran fine (by chance, I admit

Re: [Python-Dev] refleaks in 2.4

Hi all, On Sun, Mar 26, 2006 at 11:39:50PM -0800, Neal Norwitz wrote: > There are 5 tests that leak references that are present in 2.4.3c1, > but not on HEAD. It would be great if someone can diagnose these and > suggest a fix. > > test_doctest leaked [1, 1, 1] references > test_pkg leaked [10,

Re: [Python-Dev] Proposal: expose PEP 302 facilities via 'imp' and 'pkgutil'

At 08:39 PM 4/12/2006 +1000, Nick Coghlan wrote: >In this particular case, it would be a Python module "imp.py" that >included the line "from _imp import *" (where _imp is the current C-only >module with a different name). I don't think that's going to work, since importing won't work until _imp

Re: [Python-Dev] Preserving the blamelist

At 03:00 AM 4/12/2006 -0400, Tim Peters wrote: >Phillip, when eyeballing gen_dealloc(), I didn't understand two things: > >1. Why doesn't > > if (gen->gi_frame->f_stacktop!=NULL) { > >check first to be sure that gen->gi_frame != Py_None? Apparently, it's because I'm an idiot, and becau

Re: [Python-Dev] building with C++

[EMAIL PROTECTED] wrote: > Anthony> I've done a lot of the work to get Python to build with g++ - > Anthony> ... I can't spend much more time on this now, but if someone > Anthony> wants to take over and finish it off, that'd be great. > > Is this on a branch or available as a patch so

Re: [Python-Dev] building with C++

Anthony> I've done a lot of the work to get Python to build with g++ - Anthony> ... I can't spend much more time on this now, but if someone Anthony> wants to take over and finish it off, that'd be great. Is this on a branch or available as a patch somewhere? Skip ___

Re: [Python-Dev] String initialization (was: The "i" string-prefix: I18n'ed strings)

A compiler hook on string initialization, eh? I have a distantly related story--this isn't important, just another random Python use case for the file. (The i"xyzzy" proposal wouldn't help this case.) In scons, your SConscripts (makefiles, essentially) are Python source code. You typically have

Re: [Python-Dev] Proposal: expose PEP 302 facilities via 'imp' and 'pkgutil'

Phillip J. Eby wrote: > At 07:43 AM 4/12/2006 +1000, Nick Coghlan wrote: >> Phillip J. Eby wrote: >> > I propose to create a new API, 'imp.find_loader()' and have it >> return a PEP >> > 302-compatible loader object, even for cases that would normally be >> handled >> > via 'imp.load_module()'.

Re: [Python-Dev] Preserving the blamelist

On 4/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > The failures might have nothing to with the changes, though: It appears > that some files are still left from earlier tests, and now the setUp > code fails because /tmp/dir already exists... That was my guess. I went in and cleaned up a

Re: [Python-Dev] Preserving the blamelist

Tim Peters wrote: > All the trunk buildbots started failing about 5 hours ago, in > test_parser. There have been enough checkins since then that the > boundary between passing and failing is about to scroll off forever. It's not lost, though; it's just not displayed anymore. It would be possible

[Python-Dev] Checking assigned bugs/patches

Can all developers try to logon to SF and take a look at the bugs/patches assigned to you? Sometimes we were assigned items and we may not have been notified (or forgot that we have outstanding items). This link should take you to your page: http://sourceforge.net/my/tracker.php If you aren't

Re: [Python-Dev] PyObject_REPR()

Jeremy Hylton wrote: > It's intended as an internal debugging API. I find it very convenient > for adding with a printf() here and there, which is how it got added > long ago. It should really have a comment mentioning that it leaks > the repr object, and starting with an _ wouldn't be bad either

Re: [Python-Dev] Preserving the blamelist

[Neal] >> ... >> I'm concerned about the negative ref leak in test_contextlib. I >> wonder if this was a result of PJE's fix for generators? [Tim] > I don't know, but if you do > > while 1: > test_contextlib.test_main() > gc.collect() > > under a debug build it eventually (> 500 iteration