Nick Coghlan added the comment:
Helps to add the patch rather than the whole file...
--
Added file: http://bugs.python.org/file20702/issue10971_temp_module_cleanup
___
Python tracker
<http://bugs.python.org/issue10
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file20701/test_zipimport_support.py
___
Python tracker
<http://bugs.python.org/issue10971>
___
___
Pytho
Nick Coghlan added the comment:
Fixed for 3.2 in r88368 (no backport needed, since the older test suites didn't
exhibit the original problem with the _ssl module reloading)
--
resolution: -> fixed
status: open -> closed
___
Python tra
Nick Coghlan added the comment:
(Georg reviewed the patch after I mentioned it to him on IRC)
--
___
Python tracker
<http://bugs.python.org/issue10971>
___
___
New submission from Nick Coghlan :
There are currently undocumented PyEval_Call* equivalents to a number of the
PyObject_Call* functions.
Since there are resources out there on the web that direct people to use the
currently undocumented PyEval functions, it would be good to document those
Nick Coghlan added the comment:
Removed the easy tag, since this may involve some python-dev discussion as to
where to put them in C API docs (they don't really fit in any of the current
sections).
Perhaps an "advanced APIs" section, for things that most C extension
Nick Coghlan added the comment:
It is, but keep issue 10181 in mind (since that may lead to some restructuring
of the memoryview code, potentially leading to a need to update your patch).
--
___
Python tracker
<http://bugs.python.org/issue5
Nick Coghlan added the comment:
I'm still not comfortable with a convention that relies on *clients* of the PEP
3118 API not mucking with the internals of the Py_buffer struct.
I'm *much* happier with the rule based on malloc/free semantics where the
*pointer* passed to PyObject
Nick Coghlan added the comment:
As far as the question of re-exporting the underlying view or not goes, I agree
having "memoryview(a)" potentially refer to different underlying memory from
"a" itself (because the source object has changed since the first view was
expor
Nick Coghlan added the comment:
I should note that the idea of using a Py_buffer's "internal" field as the
unique ID rather than the Py_buffer's address does have some merit, but I still
overall prefer a design that places fewer constrai
Nick Coghlan added the comment:
On Mon, Feb 14, 2011 at 8:33 AM, Antoine Pitrou wrote:
>> I'm still not comfortable with a convention that relies on *clients*
>> of the PEP 3118 API not mucking with the internals of the Py_buffer
>> struct.
>
> Which clients? Th
Nick Coghlan added the comment:
Another idea we may want to revisit is the PyManagedBuffer concept, which would
be a true PyObject that existed solely to simplify sharing of Py_buffer structs.
If memoryview used such an object internally, then copying and slicing would be
quite simple - just
Nick Coghlan added the comment:
OK, to summarise that revisit into a coherent proposal:
1. Add "PyManagedBuffer" as an even lower level wrapper around Py_buffer. The
only thing this would support is doing GetBuffer on construction and
ReleaseBuffer when destroyed (or when explicitl
Nick Coghlan added the comment:
On further reflection, I realised point 4 in that suggestion isn't reliable in
a formal sense. Consider:
with memoryview(a) as m:
m[:]
The slice won't reference the buffer again, but isn't guaranteed by the
language definition to ha
Nick Coghlan added the comment:
The managed buffer needs to be a separate object so that multiple memoryview
objects can share it. Essentially, we would end up with two APIs - the raw
Py_buffer API and the higher level PyManagedBuffer one.
C extensions would have the choice of using the low
Nick Coghlan added the comment:
If it helps, one way to think of it is that post-redesign, the PyManagedBuffer
would be the "real" API object, with Py_buffer merely a way for data exporters
to provide the information needed to initialise the managed buffer properly.
(That actua
Nick Coghlan added the comment:
On Sun, Feb 20, 2011 at 4:22 AM, Éric Araujo wrote:
> It appears that Misc/NEWS in 3.2 lists the new functions under the 3.1
> section, among other strange differences.
"new in 3.2" changes are relative to 3.1, while 2.7 is relative to
2.6. Th
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Note that this functionality is currently available as follows:
>>> from itertools import count
>>> list(zip(count(3), 'abcdefg')
[(3, 'a'), (4, 'b'), (5, 'c'), (6, 'd&#
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Mentioning the zip(count(start), itr) version in the enumerate() docs
may be a good idea though.
(And of course, in 2.x, it should be izip() rather than zip() to
preserve the memory efficiency of enu
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I've attached a sample ProxyBase class that delegates all of the special
methods handled by weakref.proxy (as well as the tp_oct and tp_hex
slots, which weakref.proxy ignores).
While there are other special methods in CPython (e.g
New submission from Nick Coghlan <[EMAIL PROTECTED]>:
The rich compare implementation for set objects raises TypeError
directly instead of returning NotImplemented to allow the other type
involved in the comparison a chance at handling the operation.
--
messages: 67152
nosy: nc
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Eh, never mind, raising the TypeError explicitly is necessary due to the
misbehaviour of the default comparisons in 2.x.
I'll work around the problem in my test case.
--
resolution: -> invalid
status:
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Attached a new version of the module, along with a unit test file. The
unit tests caught a bug in the __gt__ implementation. I've also changed
the name to ProxyMixin as suggested by Adam and switched to using a
normal __init__ method
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10390/test_typetools.py
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10385/typetools.py
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Added documentation, and assigned to Barry as release manager for 2.6/3.0.
Also bumped to 'release blocker' status because I think the loss of
classic classes transparent proxying capabilities is a fairly
substantial issue
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Also changed to a library issue instead of a docs issue.
--
components: +Library (Lib) -Documentation
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Correct, this isn't intended to be an all-singing, all-dancing proxy
implementation - it's meant to be a simple solution for local proxies
that want to change the behaviour of a few operations while leaving
other operations
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Specialised? What's specialised about it? It's designed to serve as a
replacement for the simple delegation use cases that are currently met
quite adequately by classic classes, since those are no longer
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
As to the rationale for having it in the standard library: it's because
of the coupling with the implementation of the type() builtin. If a new
slot is added to type() that the interpreter may access without
consulting __getattrib
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
The way to override _deref/_unwrap is to make _target a property on a
ProxyMixin subclass (which reminds me, I want to put in an explicit
test case to make sure that works as intended - I'll use the
weakref-proxy-in-Python as the
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10438/typetools.py
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10389/typetools.py
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10390/test_typetools.py
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10402/typetools.rst
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Updated test cases and documentation to cover use of a descriptor for
_target in a subclass, and uploaded most recent local copies of all 3 files.
--
keywords: +patch
versions: +Python 3.0 -Python 2.2.1, Python 2.2.2, Python
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10439/test_typetools.py
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.
New submission from Nick Coghlan <[EMAIL PROTECTED]>:
PEP 371 highlighted the non-PEP 8 compliant nature of the threading API.
Since part of that PEP involves updating the multiprocessing API to be
PEP 8 compliant before addition the standard library, the threading API
should also be upda
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I've attached the latest version of the module as an actual patch
against Python SVN.
It differs slightly from the last version uploaded as separate files, in
that in-place operations on a proxied object will no longer strip the
pr
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Note that I'll be offline for the next few days, so I want be able to
respond to any comments until some time next week.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
The code changes in the patch look pretty good to me (although you
probably want to actually use @wraps inside _old_api!)
There are obviously also documentation and test suite changes that will
be
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Ah, that would answer my #XXX comment regarding that in the patch.
Agreed, the best answer will be to factor out the _rewrap operation into
a new class method. (Next week though...)
___
Python t
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I'd still be inclined to put a @wraps(meth) decorator on the definition
of the wrapper function (and then override to the supplied name
afterwards) - remember that functools.wraps is a decorator factory
rather than a decorator its
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
As far as I am concerned, the implementation of PyObject_Unicode in
object.c has a bug in it: it should NEVER be retrieving __unicode__ from
the instance object. The implementation of PyObject_Format in abstract.c
shows the correct
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Here's the key difference with the way PyObject_Format looks up the
pseudo-slot method:
PyObject *method = _PyType_Lookup(Py_TYPE(obj),
str__format__);
_PyType_Loo
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Unfortunately, the standard library doesn't tend to do this kind of
delegation (aside from weakref.proxy, which implements the equivalent
code directly in C), so there isn't a lot of standard library code that
will benefit
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
bleh, "application independent decision" in my last post should read
"interpreter implementation dependent decision".
___
Python tracker <[EMAIL PROTECTED]>
<
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
and "__print__" was meant to be "__unicode__"...
___
Python tracker <[EMAIL PROTECTED]>
<
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
And (mainly for Barry's benefit) a quick recap of why I think this is
necessary for Python 3.0:
For performance or correctness reasons, the interpreter is permitted to
bypass the normal __getattribute__ when looking up special meth
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Minor cleanup of Simon's patch attached - aside from a couple of
unneeded whitespace changes, it all looks good to me.
Not checking it in yet, since it isn't critical for this week's beta
release - I'd prefer to lea
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
New patch (proxymixin.diff) uploaded that correctly delegates
__format__, as well as using an overridable return_inplace() method to
generate the inplace operation return values. The _target attribute has
also been made formally part
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Note that I don't make any promises about the correctness of the ReST
formatting in that latest patch - my Doc build is misbehaving at the
moment, and I haven't had a chance to look at what
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I'm not sure adding a dedicated method slot would be worth the hassle
involved - Py3k drop backs to just the tp_str slot anyway, and the only
thing you gain with a tp_unicode slot over _PyType_Lookup of a
__unicode__ attribute
New submission from Nick Coghlan <[EMAIL PROTECTED]>:
Pydoc doesn't display the standard special attributes for packages and
modules (__name__, __file__, __path__).
It shouldn't display PEP 361's new __package__ attribute either.
--
assignee: ncoghlan
components: L
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Amaury's patch doesn't currently remove the new-in-2.6 code that turns
"tp_hash = NULL" at the C level into "__hash__ = None" at the Python
level. I suspect that will prove to be a problem (and may be the c
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
The _new__/__init__ stuff showed up on my diff as well (obviously) -
that seemed to be doing a pretty good job of maintaining backwards
compatibility.
I'll dig into this further today and tomorrow - I'll probably start
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
assignee: -> ncoghlan
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2235>
___
___
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Well, I think I figured out why the __hash__ changes were backported
from Py3k: without them, the existence of object.__hash__ makes the
Hashable ABC completely useless (every newstyle class meets it).
I see two options here. Option 1
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Attached patch allows classes to explicitly block inheritance of
object.__hash__ by setting the tp_hash slot to Py_None or the __hash__
attribute to None.
This is similar to the approach used in Py3k, but allows __hash__ to be
inheri
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Unassigning for the moment - I'll take a look at adding the Py3k warning
back in at some point, but the main thing I would like now is a sanity
check from Guido or Barry (or anyone else happy to dig into the guts of
typeobject.c) tha
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Fixed for 2.6b2 in rev 64656 (will be ported to Py3k as part of the
normal merge process)
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PR
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Suggestion from GvR (one I like): instead of re-using Py_None, add a new
C function that is stored in the tp_hash slot as a sentinel instead of
the Py_None value used in the posted version of the patch. This will
avoid breaking code tha
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Unhashable types that implement an "I'm not hashable" __hash__ method
will indeed require modification in 2.6 in order to avoid incorrectly
passing an "isinstance(obj, collections.Hashable)" check (note that
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
As far as deque goes, the following behaviour on the trunk is the
problem I am trying to fix:
Python 2.6b1+ (trunk:64655, Jul 2 2008, 22:48:24)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help&q
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Hmm, setting an invalid value for __package__ will definitely break
relative imports (see PEP 361), but it probably shouldn't be breaking
absolute imports.
--
nosy: +ncoghlan
___
Pyt
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
One idea would be to change the import code to only produce a warning
for a missing __package__ entry instead of a SystemError (reserving the
SystemError for cases where the package name is derived from __name__
rather than being retrieve
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Attached updated patch which implements Guido's suggestion from above
(inheritance of __hash__ is blocked at the C level by setting the slot
to PyObject_HashNotImplemented and at the Python level by setting
__hash__ = None).
All
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Two failures in the -uall run (test_codecmaps_hk, test_linuxaudiodev).
However, I see those test failures even after reverting my changes, so
they aren't related to this.
___
Python tracker <[E
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Bumped priority - an existing module shouldn't crash in 2.6 just because
we started using __package__ as part of the import mechanism and that
module happens to already set an attribute by that name.
--
priority: -> r
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Adding this to my personal to-do list for the next beta release.
--
assignee: georg.brandl -> ncoghlan
priority: normal -> critical
___
Python tracker <[EMAIL PROTECTED]>
<h
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Adding to my personal to-do list for next beta.
--
assignee: twouters -> ncoghlan
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
The outcome of discussion of this issue on python-dev was that the
lookup methodology for the special methods needs to be better
documented, especially for those cases where the instance *must* be
bypassed in order to avoid metaclass con
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue643841>
___
___
Python-bugs-list mailing list
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I'm still seeing intermittent lockups on Ubuntu 7.10 - traceback on
ctrl-C is similar to that posted by Ismail above.
Since Jesse seems to be on top of this, I'll stick to using -x
test_multiprocessing for the moment.
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Bumping back to release blocker for beta 2 (Barry may choose to defer it
again, but it should at least be on his radar).
--
priority: critical -> release blocker
resolution: accepted ->
__
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Updated issue title to more accurately reflect scope of the problem.
--
title: test_multiprocessing hangs on OS X 10.5.3 -> test_multiprocessing hangs
intermittently on POSIX platforms
_
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I forgot to mention that I am seeing the intermittent hangs on the trunk
(2.6). I haven't been testing it on Py3k.
--
versions: +Python 2.6
___
Python tracker <[EMAIL PRO
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Fixed in 64791.
Blocked from being merged to Py3k (since there is no longer a
__unicode__ special method).
For MAL: the PyInstance_Check included in the patch for the benefit of
classic classes defined in Python code also covers all
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Given where we are in the release cycle, I've bumped the target releases
to 2.7/3.1. So Symbian are probably going to have to do something
port-specific anyway in order to get 2.6/3.0 up and running.
And in terms of hooking into t
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
A better option may be to append _tmp to the passed in token:
#define Py_CLEAR(op)\
do {\
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Fixed in r64915.
The end result is that the import system now only emits a RuntimeWarning
instead of raising SystemError if it can't find the parent module when
attempting to perform an absolute import (regardless of whether the
pa
New submission from Nick Coghlan <[EMAIL PROTECTED]>:
The "PEP 8 compliant" API for multiprocessing and threading needs to be
cleaned up before release as per the thread on python-dev. The release
manager gave approval for this change during that discussion [1].
Changes neede
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
At this stage I'm still inclined to skip the warnings completely - at
the very least, any eventual removals will go through a full deprecation
cycle in 2.7/3.1 before being removed in 2.8/3.2.
It's also much easier to b
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
There are both speed and correctness reasons for special methods being
looked up the way they are, so the behaviour isn't going to change.
Aside from providing additional details in the language reference on how
special methods ar
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Fixed for 2.6 in r64962 and the underlying PyObject_HashNotImplemented
mechanic forward ported to 3.0 in r64967.
Still need to update the C API documentation and the library reference,
as well as implement the Py3k warning in 2.6, but I
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Now, if someone was to provide a 2.7 rfe with associated patch that
implements this feature properly, and includes an explanation for why it
doesn't subtly break imports the way 2.5 does, that would be a
completely different sto
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
If I recall correctly (it's been a while), the breakages were tied in
with relative imports - probably something like explicit relative
imports not working at all, and implicit relative imports appearing to
work, but resulting i
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Like Raymond, I have issues with the idea of implicitly reading the
headers in __init__, but would be fine with the idea of a separate
method in 2.7/3.1.
As far as working around the absence of such a method goes, I personal
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
The problem actually has to do with trying to use update_wrapper on a
method instead of a function - bound and unbound methods don't have all
the same attributes that actual functions do.
>>> import functools
>>>
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
title: functools.update_wrapper bug -> Ignore missing attributes in
functools.update_wrapper
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Re-opened for consideration of GvR's suggestion.
--
resolution: wont fix ->
status: closed -> open
___
Python tracker <[EMAIL PROTECTED]>
<http:/
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I personally like the idea of making fieldnames a property - while
having merely reading an attribute cause disk I/O is slightly
questionable, it seems like a better option than returning a misleading
value for that property and also a
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I'll have a look at this in the next day or two.
--
nosy: +ncoghlan
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Skip's patch looks good to me (as Skip discovered, I left out the
necessary step of putting the first row back into an iterable before
invoking chain in my example code)
___
Python tracker <[E
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Guido, does that mean we can apply this patch to get the cleaner
list-like behaviour for 3.0, and then work on the sq_item/sq_len fixes
for 3.1 as a separate issue?
___
Python tracker <[EMAIL
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Attaching a documentation patch for the moment until I get some info
back from Georg as to why I can't build the docs locally.
Once I get my local doc build working again, I'll check the formatting
and check it in.
---
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
components: +Documentation -Library (Lib)
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Committed for 2.6 as r65487.
I also blocked the automatic merge to 3.0 since the references to
old-style classes don't make sense there.
___
Python tracker <[EMAIL PROTECTED]>
<ht
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I meant to say that I will be merging it manually to avoid bringing the
old-style class specific parts over (that's why I left the issue open
and assigned to me).
___
Python tracker <[EMAIL PRO
801 - 900 of 6301 matches
Mail list logo
