If Thomas Heller and Richard Jones haven't recently received email from
me (and are reading this list, naturally) I'd appreciate it if they'd
get in touch with me in the next day or so.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd ww
On 4/13/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> Rather than delete a leak test, perhaps we could simply move it into a
> new old-leaking-tests subdirectory? Likewise for crash tests. When
> the bug reappears, it's helfpul to have the focussed (whittled-down)
> old test that provoked it hand
On 4/13/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> >
> > Does this mean you would like to see this patch checked in to 2.5?
>
> Yes.
Ok, I checked this in to 2.5 (minus the syntax error).
> I also think that changing the type from signed to unsigned
> by backporting the configure fix will onl
[Phillip J. Eby]
> I'd like to create a branch for maintaining the setuptools 0.6 line through
> its beta and final release, while new work proceeds on the trunk for
> integration with Python 2.5 and beginning the 0.7 line. Is there any
> special procedure I should follow, or can I just make a 'se
I'd like to create a branch for maintaining the setuptools 0.6 line through
its beta and final release, while new work proceeds on the trunk for
integration with Python 2.5 and beginning the 0.7 line. Is there any
special procedure I should follow, or can I just make a 'setuptools-0.6'
branch
Okay, so I've spent a bit more time thinking this through, and I think I
have a plan that can work, and deals with all the weird little corner
issues, including overlapping code with pkg_resources (a new module that's
to-be-added by setuptools).
My basic idea is as follows:
1. Move the support
On Friday 14 April 2006 02:31, Martin v. Löwis wrote:
> Tim Peters wrote:
> >> I'm not the one to decide, but at some time the traceback module
> >> should be rewritten to match the interpreter behavior.
> >
> > No argument from me about that.
>
> I also think the traceback module should be correct
Patch / Bug Summary
___
Patches : 383 open ( -8) / 3156 closed (+14) / 3539 total ( +6)
Bugs: 886 open (-12) / 5759 closed (+28) / 6645 total (+16)
RFE : 210 open ( -5) / 212 closed ( +5) / 422 total ( +0)
New / Reopened Patches
__
socket.py
On 4/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 02:21 PM 4/13/2006 -0600, Steven Bethard wrote:
[snip examples using class/__metaclass__ statements to create non-types]
> >The question is, is the intent still clear?
>
> Depends on your use case. I'm just saying that the PEP would be ton
Steven Bethard wrote:
> On 4/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
>>Steven Bethard wrote:
>>
>>>I know 2.5's not out yet, but since I now have a PEP number, I'm going
>>>to go ahead and post this for discussion. Currently, the target
>>>version is Python 2.6. You can also see th
I've just added some instructions on how to build Python on Windows
with the free MS Toolkit C++ compiler. They are at
http://wiki.python.org/moin/Building_Python_with_the_free_MS_C_Toolkit.
Most of the credit for this goes to David Murmann, whose posting on
the subject to python-list pointed out
At 02:21 PM 4/13/2006 -0600, Steven Bethard wrote:
>On 4/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 01:51 PM 4/13/2006 -0600, Steven Bethard wrote:
> > >Sorry, I'm not clear on exactly what you're suggesting. Are you
> > >suggesting I try to implement the make-statement using context
"Jim Jewett" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>>>> # No syntax errors when creating m()
>>>> class C:
>def m(): pass
>
> but the method can't actually be called
Unless it is wrapped as a staticmethod ;-)
...
>>>> C().m()
>
>Traceback (most rece
On 4/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 01:51 PM 4/13/2006 -0600, Steven Bethard wrote:
> >Sorry, I'm not clear on exactly what you're suggesting. Are you
> >suggesting I try to implement the make-statement using context
> >managers? Or that I use a context manager to address M
At 01:51 PM 4/13/2006 -0600, Steven Bethard wrote:
>Sorry, I'm not clear on exactly what you're suggesting. Are you
>suggesting I try to implement the make-statement using context
>managers? Or that I use a context manager to address Martin's
>problem?
Yes. :) Both. Or neither. What I'm sugg
Martin v. Löwis wrote:
> Thomas Heller wrote:
>> Why does the ia64 debian buildbot now complain about unaligned accesses,
>> and how can we find out where they occur?
>
> I don't know why they started show up suddenly; on Debian-Itanium, it
> is a configuration option (even per process, through pr
On 4/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:05 PM 4/13/2006 -0600, Steven Bethard wrote:
> >On 4/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > Steven Bethard wrote:
> > > > I know 2.5's not out yet, but since I now have a PEP number, I'm going
> > > > to go ahead and p
On 4/13/06, Ian D. Bollinger <[EMAIL PROTECTED]> wrote:
> I guess I fail to see how this syntax is a significant improvement over
> metaclasses (though __metaclass__ = xyz may not be the most aesthetic
> construct.)
It doesn't seem strange to you to have to use a *class* statement and
a __meta*cla
Thomas Heller wrote:
> Why does the ia64 debian buildbot now complain about unaligned accesses,
> and how can we find out where they occur?
I don't know why they started show up suddenly; on Debian-Itanium, it
is a configuration option (even per process, through prctl(1)) whether
they just produce
I guess I fail to see how this syntax is a significant improvement over
metaclasses (though __metaclass__ = xyz may not be the most aesthetic
construct.)
-- Ian D. Bollinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailm
(Cc to python dev, as my question is really about 2.x)
On 4/13/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> ... the self in the signature (and the miscount of arguments
> in TypeError exceptions) ...
Even in the 2.x line, the TypeError messages should be improved.
>>> # No syntax errors w
On Wed, Apr 12, 2006 at 01:16:04AM -0400, Tim Peters wrote:
> 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 :-)
Not with -uall, yes. Witho
At 12:05 PM 4/13/2006 -0600, Steven Bethard wrote:
>On 4/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Steven Bethard wrote:
> > > I know 2.5's not out yet, but since I now have a PEP number, I'm going
> > > to go ahead and post this for discussion. Currently, the target
> > > version is
On 4/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > I know 2.5's not out yet, but since I now have a PEP number, I'm going
> > to go ahead and post this for discussion. Currently, the target
> > version is Python 2.6. You can also see the PEP at:
> > http://ww
Tim Peters wrote:
> Sorry, but it's horridly un-doctest-like to make inferences by magic.
> If you want to add an explicit ACCEPT_EXCEPTION_SUBCLASS doctest
> option, that's a different story. I would question the need, since
> I've never got close to needing it, and never heard anyone else bring
[Please let me know if this should go to the machine owner instead]
Why does the ia64 debian buildbot now complain about unaligned accesses,
and how can we find out where they occur?
http://www.python.org/dev/buildbot/trunk/ia64%20Debian%20unstable%20trunk/builds/123/step-test/0
Thanks,
Thomas
On 4/13/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > I know 2.5's not out yet, but since I now have a PEP number, I'm going
> > to go ahead and post this for discussion. Currently, the target
> > version is Python 2.6. You can also see the PEP at:
> > http://www.
[neal.norwitz]
>> Author: neal.norwitz
>> Date: Thu Apr 13 06:35:36 2006
>> New Revision: 45334
>>
>> Added:
>>python/trunk/Lib/test/leakers/test_gen1.py (contents, props changed)
>> Removed:
>>python/trunk/Lib/test/leakers/test_generator_cycle.py
>>python/trunk/Lib/test/leakers/test_
Building SVN trunk with --enable-shared has been broken on Mac OS X
Intel
since rev. 45232 a couple of days ago. I can't say if this is the case
anywhere else as well. What happens is simply that ld can't find the
file
to link the shared mods against.
//Simon
_
Steven Bethard wrote:
> I know 2.5's not out yet, but since I now have a PEP number, I'm going
> to go ahead and post this for discussion. Currently, the target
> version is Python 2.6. You can also see the PEP at:
> http://www.python.org/dev/peps/pep-0359/
>
> Thanks in advance for the feed
[Paul Moore]
>> Sorry, it's a trunk checkout, but I'm currently working on a machine
>> without svn access, so my checkout is from last night (before your
>> checkin). So that's the issue.
>>
>> Apologies - I should have checked the svn logs first.
[Martin v. Löwis]
> I find this kind of mistake (
Steven Bethard wrote:
> I know 2.5's not out yet, but since I now have a PEP number, I'm going
> to go ahead and post this for discussion. Currently, the target
> version is Python 2.6. You can also see the PEP at:
> http://www.python.org/dev/peps/pep-0359/
>
> Thanks in advance for the feed
Tim Peters wrote:
>> I'm not the one to decide, but at some time the traceback module should be
>> rewritten to match the interpreter behavior.
>
> No argument from me about that.
I also think the traceback module should be corrected, and the test
cases updated, despite the objections that it may
Tim Peters wrote:
> [Georg Brandl]
>> Well, it's tempting to let the buildbots run the tests for you
>> Honestly, I didn't realize that doctest relies on traceback. Running
>> the test suite takes over half an hour on this box, so I decided to
>> take a chance.
>
> Nobody ever expects that a chec
Paul Moore wrote:
> Sorry, it's a trunk checkout, but I'm currently working on a machine
> without svn access, so my checkout is from last night (before your
> checkin). So that's the issue.
>
> Apologies - I should have checked the svn logs first.
I find this kind of mistake (working on old sour
I know 2.5's not out yet, but since I now have a PEP number, I'm going
to go ahead and post this for discussion. Currently, the target
version is Python 2.6. You can also see the PEP at:
http://www.python.org/dev/peps/pep-0359/
Thanks in advance for the feedback!
PEP: 359
Title: The "make"
On 4/13/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Paul Moore]
> You didn't say from where, or when, you got the Python source code.
> Someone recently added a bare "import tty" to test_sundry on the
> trunk, without realizing that would cause test_sundry to get skipped
> on Windows. I repaired
[Paul Moore]
> I've just managed to get Python built using the free MS compiler and
> tools (yay! full instructions to follow somewhere - probably the wiki
> and maybe as a patch to PCBuild\readme.txt)
>
> There's one thing that puzzled me - test_sundry is marked as an
> "unexpected skip". As it im
[Georg Brandl]
> Well, it's tempting to let the buildbots run the tests for you
> Honestly, I didn't realize that doctest relies on traceback. Running
> the test suite takes over half an hour on this box, so I decided to
> take a chance.
Nobody ever expects that a checkin will break tests, so mer
I've just managed to get Python built using the free MS compiler and
tools (yay! full instructions to follow somewhere - probably the wiki
and maybe as a patch to PCBuild\readme.txt)
There's one thing that puzzled me - test_sundry is marked as an
"unexpected skip". As it imports tty, which imports
[Tim]
>> ...
>> doctest strives to be magic-free WYSIWYG. If someone _intends_
>> the module name to be optional in a doctest, they should explicitly
>> use doctest's ELLIPSIS option.
[Nick Coghlan]
> There's already a little bit of magic in the way doctest handles exceptions. I
> always use doct
> sorry if this came up before, but I tried searching the archives and
> found nothing. It would be really nice if new builtin truth functions
> in 2.5 took a predicate argument(defaults to bool), so one could
> write, for example:
>
> seq = [1,2,3,4,5]
> if any(seq, lambda x: x==5):
> ...
>
> w
On Wed, Apr 12, 2006 at 11:23:51PM -0400, Tim Peters wrote:
> Not the same thing, but I just added:
> http://wiki.python.org/moin/SimpleTodo
I added a list of the Demo directories so that people know which ones
need updating.
--amk
___
Python-Dev ma
[EMAIL PROTECTED] wrote:
> Jeremy> Looks good to me. Why don't you check it in.
>
> I did, but it broke the C build, so I reverted it and reopened the patch.
> I'll try to take a look at it more later today.
I took a different approach, introducing a second kind of sequence.
Since most acces
> "Jeremy" == Jeremy Hylton <[EMAIL PROTECTED]> writes:
Jeremy> Looks good to me. Why don't you check it in.
I did, but it broke the C build, so I reverted it and reopened the patch.
I'll try to take a look at it more later today.
Skip
___
Pyt
Neal Norwitz wrote:
> 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 u
Tim Peters wrote:
> [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 ma
Mikhail Glushenkov wrote:
> Hi,
>
> sorry if this came up before, but I tried searching the archives and
> found nothing. It would be really nice if new builtin truth functions
> in 2.5 took a predicate argument(defaults to bool), so one could
> write, for example:
>
> seq = [1,2,3,4,5]
> if any
Neal Norwitz wrote:
> I just grepped for INT_MAX and there's a ton of them still (well 83 in
> */*.c). Some aren't an issue like posixmodule.c, those are
> _SC_INT_MAX. marshal is probably ok, but all uses should be verified.
> Really all uses of {INT,LONG}_{MIN,MAX} should be verified and
> con
Hi,
sorry if this came up before, but I tried searching the archives and
found nothing. It would be really nice if new builtin truth functions
in 2.5 took a predicate argument(defaults to bool), so one could
write, for example:
seq = [1,2,3,4,5]
if any(seq, lambda x: x==5):
...
which is clearly
Tim Peters wrote:
> [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_onl
On 4/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> > 235:
> > assert(length > unicode->length = (int)length;
>
> Right: I just changed it. It may date back to a version of the patch
> where I only changed the signatures of the functions, but not the
> object layout.
I just gr
52 matches
Mail list logo
