[issue1497] Patch to remove API to create new unbound methods

[Christian Heimes]

Christian Heimes added the comment:

The new patch adds new.boundcfunction as a replacement for
new.instancemethod(id, None, cls). I'm going to add docs if you like the
approach.

Added file: http://bugs.python.org/file8810/py3k_remove_newunbound2.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: Objects/classobject.c
===
--- Objects/classobject.c	(Revision 59184)
+++ Objects/classobject.c	(Arbeitskopie)
@@ -37,10 +37,9 @@
 }
 
 
-/* Method objects are used for two purposes:
+/* Method objects are used for one purposes:
(a) as bound instance methods (returned by instancename.methodname)
-   (b) as unbound methods (returned by ClassName.methodname)
-   In case (b), im_self is NULL
+   ClassName.methodname returns an ordinary function.
 */
 
 static PyMethodObject *free_list;
@@ -53,6 +52,10 @@
 		PyErr_BadInternalCall();
 		return NULL;
 	}
+	if (self == NULL) {
+		PyErr_BadInternalCall();
+		return NULL;
+	}
 	im = free_list;
 	if (im != NULL) {
 		free_list = (PyMethodObject *)(im->im_self);
@@ -86,7 +89,7 @@
 	{"im_func",	T_OBJECT,	OFF(im_func),	READONLY|RESTRICTED,
 	 "the function (or other callable) implementing a method"},
 	{"im_self",	T_OBJECT,	OFF(im_self),	READONLY|RESTRICTED,
-	 "the instance to which a method is bound; None for unbound methods"},
+	 "the instance to which a method is bound"},
 	{NULL}	/* Sentinel */
 };
 
@@ -162,11 +165,9 @@
 "first argument must be callable");
 		return NULL;
 	}
-	if (self == Py_None)
-		self = NULL;
-	if (self == NULL && classObj == NULL) {
+	if (self == NULL || self == Py_None) {
 		PyErr_SetString(PyExc_TypeError,
-			"unbound methods must have non-NULL im_class");
+			"unbound methods are not supported");
 		return NULL;
 	}
 
@@ -253,10 +254,10 @@
 			klassname = NULL;
 		}
 	}
-	if (self == NULL)
-		result = PyUnicode_FromFormat("",
-		  klassname, defname,
-		  funcname, defname);
+	if (self == NULL) {
+		PyErr_BadInternalCall();
+		return NULL;
+	}
 	else {
 		/* XXX Shouldn't use repr()/%R here! */
 		result = PyUnicode_FromFormat("",
@@ -296,88 +297,16 @@
 	return 0;
 }
 
-static void
-getclassname(PyObject *klass, char *buf, int bufsize)
-{
-	PyObject *name;
-
-	assert(bufsize > 1);
-	strcpy(buf, "?"); /* Default outcome */
-	if (klass == NULL)
-		return;
-	name = PyObject_GetAttrString(klass, "__name__");
-	if (name == NULL) {
-		/* This function cannot return an exception */
-		PyErr_Clear();
-		return;
-	}
-	if (PyUnicode_Check(name)) {
-		strncpy(buf, PyUnicode_AsString(name), bufsize);
-		buf[bufsize-1] = '\0';
-	}
-	Py_DECREF(name);
-}
-
-static void
-getinstclassname(PyObject *inst, char *buf, int bufsize)
-{
-	PyObject *klass;
-
-	if (inst == NULL) {
-		assert(bufsize > 0 && (size_t)bufsize > strlen("nothing"));
-		strcpy(buf, "nothing");
-		return;
-	}
-
-	klass = PyObject_GetAttrString(inst, "__class__");
-	if (klass == NULL) {
-		/* This function cannot return an exception */
-		PyErr_Clear();
-		klass = (PyObject *)(inst->ob_type);
-		Py_INCREF(klass);
-	}
-	getclassname(klass, buf, bufsize);
-	Py_XDECREF(klass);
-}
-
 static PyObject *
 method_call(PyObject *func, PyObject *arg, PyObject *kw)
 {
 	PyObject *self = PyMethod_GET_SELF(func);
-	PyObject *klass = PyMethod_GET_CLASS(func);
 	PyObject *result;
 
 	func = PyMethod_GET_FUNCTION(func);
 	if (self == NULL) {
-		/* Unbound methods must be called with an instance of
-		   the class (or a derived class) as first argument */
-		int ok;
-		if (PyTuple_Size(arg) >= 1)
-			self = PyTuple_GET_ITEM(arg, 0);
-		if (self == NULL)
-			ok = 0;
-		else {
-			ok = PyObject_IsInstance(self, klass);
-			if (ok < 0)
-return NULL;
-		}
-		if (!ok) {
-			char clsbuf[256];
-			char instbuf[256];
-			getclassname(klass, clsbuf, sizeof(clsbuf));
-			getinstclassname(self, instbuf, sizeof(instbuf));
-			PyErr_Format(PyExc_TypeError,
- "unbound method %s%s must be called with "
- "%s instance as first argument "
- "(got %s%s instead)",
- PyEval_GetFuncName(func),
- PyEval_GetFuncDesc(func),
- clsbuf,
- instbuf,
- self == NULL ? "" : " instance");
-			return NULL;
-		}
-		Py_INCREF(arg);
+		PyErr_BadInternalCall();
+		return NULL;
 	}
 	else {
 		Py_ssize_t argcount = PyTuple_Size(arg);
@@ -412,14 +341,8 @@
 	}
 	/* No, it is an unbound method */
 	if (PyMethod_GET_CLASS(meth) != NULL && cls != NULL) {
-		/* Do subclass test.  If it fails, return meth unchanged. */
-		int ok = PyObject_IsSubclass(cls, PyMethod_GET_CLASS(meth));
-		if (ok < 0)
-			return NULL;
-		if (!ok) {
-			Py_INCREF(meth);
-			return meth;
-		}
+		PyErr_BadInternalCall();
+		return NULL;
 	}
 	/* Bind it to obj */
 	return PyMethod_New(PyMethod_GET_FUNCTION(meth), obj, cls);
Index: Lib/new.py
==

[issue1225584] crash in gcmodule.c on python reinitialization

[Adam Olsen]

Changes by Adam Olsen:


--
nosy: +rhamphoryncus

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1498] Rename __builtins__ to __root_namespace__?

[Guido van Rossum]

New submission from Guido van Rossum:

In http://bugs.python.org/issue1774369 I mentioned that I wanted to
rename __builtins__ to __rootns__.  Though right now I think something
longer and less cryptic might be better.  The reason is to avoid for
once and for all the confusion between __builtin__, which is a module,
and __builtins__, a feature mainly used by sandboxing to pass the set of
builtins to be used via the global namespace.  This lay at the heart of
the referenced bug.

I'm still in favor of this but haven't had the time to investigate how
much work it would be.

--
messages: 57842
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Rename __builtins__ to __root_namespace__?
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1498] Rename __builtins__ to __root_namespace__?

[Christian Heimes]

Changes by Christian Heimes:


--
keywords: +py3k
nosy: +tiran

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1498] Rename __builtins__ to __root_namespace__?

[Christian Heimes]

Christian Heimes added the comment:

A simple replace with sed -i works just fine. Afterwards the code needs
only minor adjustments and cleanups.

find -name \*.py -or -name \*.c -or -name \*.h | xargs sed -i 
's/__builtins__/__root__/g'

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1498] Rename __builtins__ to __root_namespace__?

[Guido van Rossum]

Guido van Rossum added the comment:

OK, then we need to agree on a new name. I find __root__ too short,
__rootns__ too cryptic, and __root_namespace__ too long. :-) What else
have we got?

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1498] Rename __builtins__ to __root_namespace__?

[Christian Heimes]

Christian Heimes added the comment:

__origin__
__footing__
__radix__
__namespace__

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1497] Patch to remove API to create new unbound methods

[Georg Brandl]

Georg Brandl added the comment:

Note though that the "new" module was deprecated once...

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1497] Patch to remove API to create new unbound methods

[Guido van Rossum]

Guido van Rossum added the comment:

OK. Some code review comments:

- Please clean up the comment in classobject.c starting with "Method
objects are used for one purposes:" -- to begin with, "one purposes" is
ungrammatical.  Best to remove the (a) bullet and rephrase the whole
thing more like "Method objects are used for bound instance methods (...)"

- The error "unbound methods are not supported" sounds a bit strange;
better rephrase more positive as "self must not be None"

- There is still a comment left "No, it is an unbound method". Is this
code still reachable? I though all ways to set im_self to NULL/None are
blocked?

- Is bug 1202533 still worth testing for in test_descr.py?  I don't know
that using a lambda reproduces the error condition that once existed.


Functional suggestions:

- Do we really need im_class for anything any more?  ISTM that the one
place where it is still used (in method_repr), we could as well use the
class of im_self.  (And before you think of super() as a
counter-argument: super() passes the object's class in rather than the
class where the method is found (though this may be considered a bug).

- I think that, like func_code -> __code__, the im_xxx attributes should
be renamed __xxx__.

The 'new' module claims to exist solely for backwards compatibility.  If
that's true, why are we adding to it?  In any case, the
_BoundCFunction() class is redundant -- you can just use the "method"
type, which is easily accessed as any bound method's __class__
attribute.  And is there a use case for an *unbound* C function? If not,
you could replace boundcfunction() with just a call to the method type.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1498] Rename __builtins__ to __root_namespace__?

[Guido van Rossum]

Guido van Rossum added the comment:

Time for a quick poll on the list.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1496] add str.maketrans()

[Guido van Rossum]

Guido van Rossum added the comment:

BTW I'm okay with submitting this as is (plus docs and tests) and
tighten the spec later.

--
assignee: gvanrossum -> georg.brandl
keywords: +patch, py3k

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1499] failure behaviour of compile() is missing

[Achim Gaedke]

New submission from Achim Gaedke:

Regarding the compile() function in html/lib/built-in-funcs.html:
Please add a note about the exceptions raised by this function.

--
components: Documentation
messages: 57850
nosy: AchimGaedke
severity: minor
status: open
title: failure behaviour of compile() is missing
versions: Python 2.4, Python 2.5

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1348] httplib closes socket, then tries to read from it

[Bill Janssen]

Bill Janssen added the comment:

No, the close must be removed.  It's the wrong *way* to "transfer
responsibility".  Close means "close", not "I wash my hands of
responsibility here".  What's hidden here is that the open socket is
transferred to the response, which continues to use it.  In fact, the
close() should happen when the caller is finished with the response,
probably as effect of the GC of the "response" object.

On Nov 25, 2007 3:09 AM, vila <[EMAIL PROTECTED]> wrote:
>
> vila added the comment:
>
> The title of this bug is scary.
>
> httplib rightly close the socket because that's the way to transfer the
> responsibility of the close to the user of the HttpResponse object.
>
> The close MUST stays there.
>
> I do encounter a bug related to that close while trying to use the ssl
> module in python2.6.
>
> I'm willing to help fixing it but *this* bug may not be the right place
> to do so (even if related).
>
> I'm a bit lost on how to help right now since the involved changes seems
> to occur in both python3.0 and python2.6 and I'm currently targeting 2.4
> and 2.5.
>
> --
> nosy: +vila
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
>

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1500] Example using range doesn't give claimed results

[Steve Jones]

New submission from Steve Jones:

See for yourself, on
http://docs.python.org/tut/node6.html
*

>>> for n in range(2, 10):
... for x in range(2, n):
... if n % x == 0:
... print n, 'equals', x, '*', n/x
... break
... else:
... # loop fell through without finding a factor
... print n, 'is a prime number'
... 
2 is a prime number - this bit is wrong
3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8 equals 2 * 4
9 equals 3 * 3

--
components: Documentation
messages: 57852
nosy: basingwerk
severity: minor
status: open
title: Example using range doesn't give claimed results
type: behavior
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1348] httplib closes socket, then tries to read from it

[Guido van Rossum]

Guido van Rossum added the comment:

Bill, is there a code example that should work but breaks because of
that close()?  ATM, there doesn't seem to be anything in the tests that
breaks...

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1500] Example using range doesn't give claimed results

[Guido van Rossum]

Guido van Rossum added the comment:

2 *is* a prime number.

--
nosy: +gvanrossum
resolution:  -> invalid
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1501] 0 ** 0 documentation

[Jim Jewett]

New submission from Jim Jewett:

http://docs.python.org/lib/typesnumeric.html contains a table listing the 
mathematical operators.  Please add a note to the final row (x ** y meaning 
x to the power y) indicating that Python has chosen to define 0**0==1
Note 6:  Python defines 0**0 to be 1.  For background, please see http://
en.wikipedia.org/wiki/Exponentiation#Zero_to_the_zero_power

This doc change should have prevented issue 1461; I *think* there have been 
similar issues in the past.

--
components: Documentation
messages: 57855
nosy: jimjjewett
severity: minor
status: open
title: 0 ** 0 documentation
type: rfe
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear

[Guido van Rossum]

Guido van Rossum added the comment:

So is this a Mac-only issue?

And couldn't the GIL state cleanup also invoke user code, which might be
abused to create more threads, wreaking havoc that way?  I'm kind of
worried about putting this into 2.5.2 and breaking somebody's working
code (that's always worse than fixing somebody's broken code... :-).

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1501] 0 ** 0 documentation

[Guido van Rossum]

Guido van Rossum added the comment:

(Can you also submit a doc fix that would have prevented issue 1500? :-)

--
nosy: +gvanrossum
priority:  -> low

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1492] BaseHTTPServer hard-codes Content-Type for error messages

[Guido van Rossum]

Guido van Rossum added the comment:

I'm okay with adding this to 2.6 (and hence 3.0) but not with doing this
to 2.5.

--
nosy: +gvanrossum
priority:  -> low
resolution:  -> accepted
versions:  -Python 2.4, Python 2.5, Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1491] BaseHTTPServer incorrectly implements response code 100

[Guido van Rossum]

Guido van Rossum added the comment:

I'm not sure I understand why anyone would ever want to send a 100
response anyway.

If I were to add support for this, I'd probably refactor send_response()
so that there's a lower-level function send_response_only() that *only*
sends the response header and change send_response() to call that
followed by sending the headers. I'm not sure where the request logging
code should go but I suspect it should be in send_response(), not in
send_response_only().

Speaking of send_response(), I wonder if it is correct to send the
Server: and Date: headers when the request version is HTTP/0.9?

I don't think we should add the paranoid version to the code; in general
this code is not sufficiently aware of all the quirks of HTTP to prevent
nonsensical things from happening.

--
nosy: +gvanrossum
priority:  -> low
versions:  -Python 2.4, Python 2.5, Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue718532] inspect, class instances and __getattr__

[Guido van Rossum]

Guido van Rossum added the comment:

Obviously Ping isn't listening, so waiting for him is not productive. 
Looking at the issue more, I can't really see a bug in inspect -- it's
the class definitions that are broken.  So closing as "rejected".

> Due to this bug, 'pydoc modulename' is not working.

Can you be more specific? I can't reproduce this.


> And this case is also not working (same issue):
> 
> class X:
>   __bases__ = ()
> 
> x = X()

Again, this is just a malformed class.

--
assignee: ping -> 
priority: high -> normal
resolution:  -> rejected
status: open -> closed
versions:  -Python 2.4, Python 2.6, Python 3.0


Tracker <[EMAIL PROTECTED]>


___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1502] itertools should grow chunkify

[Chris Mellon]

New submission from Chris Mellon:

One of the most common requests in c.l.p and #python is a way to break
an iterable up into some particular size chunks. For example, "abcdef"
-> "ab", "cd", "ef". It's pretty easy to write one, but there are a few
subtleties to it (like if you want padding or partial results) and it's
so common that having it in the stdlib would be nice.

Attached is a patch which implements itertools.chunkify. It can
optionally discard, pad, or return any leftovers in the source iterable.
Tests and docstrings are included, but it needs to be documented in the
manual. One thing it does not do, but maybe it should, is guess what
type the yielded values should have based on the input sequence - it
always returns lists.

Patch is against trunk, r59186.

--
components: Library (Lib)
files: chunkify.patch
messages: 57861
nosy: arkanes
severity: normal
status: open
title: itertools should grow chunkify
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file8811/chunkify.patch

__
Tracker <[EMAIL PROTECTED]>

__

chunkify.patch
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1502] itertools should grow chunkify

[Raymond Hettinger]

Raymond Hettinger added the comment:

Sorry, this has been proposed and rejected previously.  One of the 
reasons was that the docs already have a C-speed recipe, grouper(), 
that shows how to do it with padding and it is even simpler to do it 
without padding using only zip() or izip().  Another was a lack of 
compelling use cases.  It was more fun to write and discuss than 
actually use in real code.

Also, I'm not happy with the given implementation.  The name is weak 
and the "partial" argument complexifies the function (its often better 
to have separate function than two combine two behaviors with a flag 
variable).

Even if cleaned-up and a use case or two is demonstrated, am not 
willing to clutter the module with more functions like this.

That being said, I do want to compliment the submission of a working 
patch with unittests.  Nice work.

--
assignee:  -> rhettinger
nosy: +rhettinger
resolution:  -> rejected
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1498] Rename __builtins__ to __root_namespace__?

[Raymond Hettinger]

Raymond Hettinger added the comment:

FWIW, I find __root__ to be just right.  It is not subject 
misspelling.  It is distinct enough to serve as a mental link to a 
specific concept.  The leading and trailing underscores cause just 
enough typing pain that I wouldn't want anything longer.

--
nosy: +rhettinger

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1503] test_xmlrpc is still flakey

[Guido van Rossum]

New submission from Guido van Rossum:

See e.g.:
http://www.python.org/dev/buildbot/3.0/ppc%20Debian%20unstable%203.0/builds/303/step-test/0

Note how it fails the first time and passes on the re-run.  I've seen
this before (just not on any of my own systems).  I've also seen it fail
twice (on buildbot machines).

--
messages: 57864
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: test_xmlrpc is still flakey
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear

[Ronald Oussoren]

Ronald Oussoren added the comment:

This is not a mac-specific issue, the script happens to be mac-specific 
because that's how I found the issue.

Amaury's patch adds a unittest that reproduces the problem in a 
platform-indepenent way using ctypes.

The _PyGILState_Fini function might cause user code to run as well, it 
removes the thread-local variable that contains the PyThreadState for 
threads, and that contains some Python objects that might contain 
arbitrary values (such as the last exception value). I guess that means 
that a variation on Amaury's patch would cause a patched interpreter to 
crash (create on instance of 'C' as an attribute on an exception, e.g. 
raise ValueError(C()) in the second thread). 

BTW. I would be very uncomfortable if my patch were applied without 
review from someone that knows his way around the threading code.  

BTW2. I have a workaround for my initial issue (the crash in 
threads.py): if I add an atexit handler that performs some cleanup in 
PyObjC the problem goes away.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com