= staticmethod(foo)
Which I find sad considering all the energy debating @decorators;)
In which context did you find a need for defining a static method and
calling it inside the class definition? I'm guessing that what you're
playing dubious scoping games.
--
--Guido van Rossum (home page
wrong, look at Java, where you
have bultin-array.length, String.length(), and Collection.size().
Give me len() any day. I believe Ruby has similar confusing diversity
for looping (each/forEach).
--
--Guido van Rossum (home page: http://www.python.org/~guido
compileFile(Lib/test/test_contextlib.py)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
is the same either way:
re.compile(pattern).match(line)
re.match(pattern, line)
:-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
, but the Python version thows an
exception. I think the Python API ought to be allowed to return any
long value and it's up to the C API to clip it.
Apart from that, I'm ready to accept the PEP. Other opinions?
--
--Guido van Rossum (home page: http://www.python.org/~guido
didn't have to twist my arm. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
won't get to this until Monday.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
which is
overwhelming but in the 2.4 docs for _future-_). In 2.5 it's already
fixed; perhaps the 2.5 docs could mention that this was accidentally
broken in 2.4.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
FWIW, coverity has been busy marketing this already:
http://www.pcpro.co.uk/news/84465/key-opensource-code-passes-muster.html
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
dict don't have some kind of generalization in common
-- perhaps a dict that takes a key function a la list.sort()?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
for item in items if item 3).next()
or alternatives that would break this into multiple statements.
Why is putting everything on a single line considered elegant?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido
aren't really trying, are you? What would the point be of
NAME = EXPR
while NAME:
BLOCK
del NAME
(Hint: while needs EXPR to be reevaluated each time through the loop.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
and class name with a dot in between; new-style
classes use the same format as their repr. Making exceptions new-style
classes is going to break a number of things; that's just inevitable.
--
--Guido van Rossum (home page: http://www.python.org/~guido
://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
On 3/7/06, Barry Warsaw [EMAIL PROTECTED] wrote:
On Tue, 2006-03-07 at 13:35 -0800, Guido van Rossum wrote:
IMO it shouldn't be fixed. Classic classes define their str to print
the module name and class name with a dot in between; new-style
classes use the same format as their repr. Making
I have a patch for this now -- python.org/sf/1445739.
Please review.
--Guido
On 3/3/06, Guido van Rossum [EMAIL PROTECTED] wrote:
A few days ago there were rumbling noises that requiring __exit__ to
re-raise the exception (as I amended PEP 343 at the time) could lead
to easily-missed bugs
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
We seem to have a consensus. Is anybody working on a patch yet?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
On 3/9/06, Greg Ewing [EMAIL PROTECTED] wrote:
BTW, are there any plans to make True and False hard
constants in 3.0 (like None is now)? Maybe also
others like Ellipsis, NotImplemented, etc.
I don't think we should make any of these keywords.
--
--Guido van Rossum (home page: http
On 3/10/06, Greg Ewing [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I don't think we should make any of these keywords.
Not even True and False? The only good reasons
I can see for anyone wanting to shadow these
are backwards compatibility ones.
Not even True and False.
I don't see
On 3/10/06, Neil Schemenauer [EMAIL PROTECTED] wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
Not even True and False.
I don't see why everything that doesn't make sense to be shadowed
ought to become a keyword. That way lies madness.
Have you considered whether P3K will disallow
competely off their keyboard. :D
Given how much Python is indebted to Lisp, digs at Lisp seem
particularly off-topic for this list.
Fully expecting this to bounce,
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing
/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
it.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
, a BS is about potentially blocking
new requests and a TaskQueue is about blocking other work until outstanding
requests are complete.
Raymond
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
time to start releasing and stop evolving for a few months...
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
and an undotted
__name__? ISTM that passing in the builtins dictionary as the globals
argument ought to do the trick.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
code is safe for use with absolute imports. So, the existing
approach might well be better than what I had in mind.
I think so. Import hooks requires a lot of careful work. Requiring
import hooks to be explicitly ported probably provides better
guarantees that they actually work.
--
--Guido van
OLBKMhOjd3OScyhypefruhXJJ8o1SvQn4eQeGacIsYaqbohs3OEEqv3RW5o1h3Qo
azV3CQn+2Fs=
=qcFp
-END PGP SIGNATURE-
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
to be that each use of 'as' is some
kind of assignment to the name after 'as' but the relationship with
the thing before 'as' is different in each case.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
that *have* static
methods) -- since those languages don't have the ability to call
methods (static or otherwise) at class definition time.
So perhaps you need to dig deeper to find out *why* this is a recurring issue.
--
--Guido van Rossum (home page: http://www.python.org/~guido
/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
it a bytes array (especially
since I expect it will start off as a subclass of the array.array
class). I'd still like the built-in name to be 'bytes'.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
got to think more about
the pros and cons of making GeneratorExit as special as
KeyboardInterrupt.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
point since so many
exceptions (user-defined or otherwise) aren't errors. Not to mention
the Warnings which sometimes can be raised as Errors (but without
changing their type).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
they aren't strictly necessary to resolve syntactic ambiguity.
In the style guide only, I hope. The parens that are mandatory in a
few places *are* necessary to resolve ambiguity.
This might be one of them.
No, the original proposal (which was already in PEP 3000 anyway) is fine.
--
--Guido van
, and if there's
general agreement on the hierarchy I proposed (so far so good :), then
I'd like to take a crack at implementing them.
-1. See my response in the other thread. The focus on 'Error' is
mistaken, and we have a large body of existing code that derives from
Exception.
--
--Guido van
is not to
split the list.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive
create that mailing list, please?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
upon checkin into
svn).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
)
Would that philosophy be extended to slicing operations, though?
That's a question I hadn't though about yet. I'm not sure I like it,
but it sure is consistent with other view APIs; like everywhere, if
you need a separate object, you can place a list() around it.
--
--Guido van Rossum (home page
there's an automatic no.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
that in practice is never triggered.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
On 3/24/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 02:36 PM 3/24/2006 -0800, Guido van Rossum wrote:
I think it's overkill to warn for any string exceptions thrown this
way. Since the only use case for using throw() is to pass an exception
you just caught, I don't see that putting
/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
On 3/24/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 03:04 PM 3/24/2006 -0800, Guido van Rossum wrote:
The current state is that it always allows them, right?
No. It doesn't allow them. Support for string exceptions was never
actually implemented; I'm trying to implement it now.
Oops, I
of reminding people not to
write g.throw(abc) seems artificial to me. I'd rather see less code,
meaning less maintenance, and no need to remove the check later (or
when I merge your changes into the p3yk branch).
--
--Guido van Rossum (home page: http://www.python.org/~guido
On 3/24/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 03:05 PM 3/24/2006 -0800, Guido van Rossum wrote:
Oops, that's definitely a bug. Please go ahead and fix in both places.
Will do.
(I'm still trying to fathom the other PEP 343 issue you brought up.)
Here's the paragraph I'm proposing
OK, I give up. I'm giving you a -1 on the test for a non-empty
traceback without explaining it further.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
On 3/24/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 03:50 PM 3/24/2006 -0800, Guido van Rossum wrote:
I'm not against recommending in the PEP that __exit__ shouldn't
re-raise but instead should return False to signal a re-raise, and
fixing any existing code that re-raises in __exit__
believe that the decision to derive an exception from
BaseException instead of Exception should not be taken lightly -- lest
we set the wrong example and render the nice feature we're trying to
create (that except Exceptiondoes the right thing almost all of the
time) useless.
--
--Guido van Rossum
through; the latter is not
raised by code at all but by the end user.
I don't think GeneratorExit qualifies.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
a home in
the documentation yet? I seem to recall some discussion about a decorator
library or functools or something of that sort.
Is the with statement documented yet?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
if you want me to take any particular action (even rejecting
something) please send me a separate email!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
On 3/27/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
When you assign a bug/patch to me, somehow SourceForge doesn't send me
an email. (Is this understood behavior? Can it be changed?)
I believe it broke at some point, I'm pretty certain it used to work.
More reason
in any particular case?
Shouldn't it be numpy's responsibility to implement both operations identically?
(It's a design bug in Python that the + operation has two
implementation slots. But it's difficult to fix that until Python
3000. It *will* be fixed there.)
--
--Guido van Rossum (home page
On 3/27/06, Travis E. Oliphant [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On 3/27/06, Travis Oliphant [EMAIL PROTECTED] wrote:
If you have Numeric or numpy installed try this:
#import Numeric as N
import numpy as N
a = range(10)
b = N.arange(10)
a.__iadd__(b)
print
be a good indication of feature(s) that IronPython is missing. ;)
Just curious (and lazy): what magic is the implementation using that
makes this work without a custom metaclass?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python
On 3/28/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 10:01 AM 3/28/2006 -0800, Guido van Rossum wrote:
OK, I'm convinced (mostly by the awful hackery that Phillip so proudly
exposed :-).
Just as a historical note, here's where you previously rejected the same
hackery as an argument
pronouncement, it's going to be no.
It's not worth the change (in docs, user habits, etc.) and there's
nothing particularly broken.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
somemodule as long as somemodule.py uses the if
__name__=='__main__' convention. What does your proposal add?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
Sorry, I meant python -m somemodule.
On 3/28/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 3/28/06, Charles Cazabon [EMAIL PROTECTED] wrote:
It might be worth instead adding an option flag to the executable that
implies
from the loaded module, run __main__() with sys.argv as its
OK. -1 on PEP 299 it is.
On 3/28/06, Charles Cazabon [EMAIL PROTECTED] wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
On 3/28/06, Charles Cazabon [EMAIL PROTECTED] wrote:
It might be worth instead adding an option flag to the executable that
implies
from the loaded module, run
Die, thread.
Do I personally have to go into svn and reject this PEP?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
to be
rebutted.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
the language. Sometimes I have strong feelings about
the library. This doesn't seem to be one of those cases though...
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
On 3/29/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Watch out for the parochialism! I like Python as much as the next guy
(probably more :-) but I'm sensitive to choosing the best solution.
you better make that good enough, or we'll be stuck with SF for an-
other
in the Windows
build is actually going to be a big plus (though not for me personally
:-).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
the process and meta
issues for Python 3000. (Yes, I know, I need to catch up with some
threads myself. Hopefully next week when I'm no longer a single
parent.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python
, although it would break
the conceptual notion that a += b is equivalent to
a = a + b when a can't be modified in-place.
No, it's not reasonable, because this would fail:
x = 5
x += 0.5
--
--Guido van Rossum (home page: http://www.python.org/~guido
So do I.
On 3/30/06, Bill Janssen [EMAIL PROTECTED] wrote:
I think sqlite is just fine.
I do, too.
Bill
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
) problem that only occurs when I run
test_tokenize.py directly -- the doctest for decistmt()
has-3.21716034272e-007 but (on my box) this outputs
-3.21716034272e-07. That doesn't seem to bother it when run via
regrtest.py. I'm not sure what's at fault here.
--
--Guido van Rossum (home page: http
the list and gmane?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
not part of the language spec! :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
rare. I think the extra required space for
all tuples isn't worth the potential savings for some cases.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
, whereas I think these should pass
through.
I see no reason for this with the current code. Perhaps a previous
version of contextlib.py had this problem?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python
Could one of the tracker admins add a Python-3000 group to the SF
trackers (while we're still using them :-)? This is so we can easily
move proposals between Python 3000 and Python 2.x status.
--
--Guido van Rossum (home page: http://www.python.org/~guido
, but will only call the
finalizer once. IOW if the resurrected object is GC'ed a second time,
its finalizer won't be called. This would require a bit __del__
already called on an object, but don't we have a whole word of
GC-related flags?
--
--Guido van Rossum (home page: http://www.python.org/~guido
in the PEP, assume it has been deferred until
2.6.
Also, now would be a good time to see if you have any bugs/patches
assigned to you: http://sourceforge.net/my/tracker.php
Cheers,
n
--
--Guido van Rossum (home page: http://www.python.org/~guido
the occasional idea first
brought up on python-dev that makes more sense to move to Python 3000,
or vice versa; let's all be mindful of such cases.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
On 4/2/06, Noam Raphael [EMAIL PROTECTED] wrote:
On 4/2/06, Guido van Rossum [EMAIL PROTECTED] wrote:
I tried the change, and it turned out that I had to change cPickle a
tiny bit: it uses a 2-tuple which is allocated when the module
initializes to lookup tuples in a dict. I changed
think of any
reason why it shouldn't work.
Agreed.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido
Sorry, I missed the fact that this was about nested classes.
Still, I don't think it's worth fixing.
--Guido
On 4/6/06, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I think it's fine as it is. I don't think making it walk the
inheritance tree is helpful; the output would
/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
: *** Deallocation of a pointer not malloced:
0x36b460; This could be a double free(), or free() called with the
middle of an allocated block; Try setting environment variable
MallocHelp to see tools to help debug
--
--Guido van Rossum (home page: http://www.python.org/~guido
,
and the memory can originally come from a lot of places).
Shouldn't it at least match call_readline() in Modules/readline.c,
which uses PyMem_Malloc()? Also, since it's really a char array, I
don't see the point of using something with Object in its name.
--
--Guido van Rossum (home page: http
on the code at the moment, I think reverting broken
patches that don't have trivial test fixes is the way to go. The
buildbot system is useless, otherwise.
That was the right thing to do (short of fixing all the missing tests,
which requires actual thinking :-).
--
--Guido van Rossum (home page
), showing the traceback is much more
natural than putting a try/except around the erroneous call.
So one person's ugly is another person's pretty.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
On 4/18/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
I think we should correct the PEP.
Yes please, go ahead.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido
facilities for such functionaliy.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
will maintain it (or if he
doesn't, I expect that he would gladly do so if you asked). This has
always been sufficient as a guarantee that a new module isn't
orphaned. Beyond that, this objection is FUD; the circumstances of the
original distutils aren't likely to be replicated here.
--
--Guido van Rossum
701 - 800 of 5880 matches
Mail list logo
