Nick Edds <[EMAIL PROTECTED]> added the comment:
Here are the changes we talked about to fix_imports.py which remove the
functionality for members. This causes a substantial performance boost,
as fix_imports was the main bottleneck for 2to3.
Added file: http://bugs.python.org/fil
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 Edds <[EMAIL PROTECTED]> added the comment:
Here is a diff for the both the fix_imports changes which I corrected,
and the pytree changes. The pytree changes were a lot more significant
before the fix_imports change, but I think they are still a decent
improvement. I think I ha
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
New submission from Nick Edds <[EMAIL PROTECTED]>:
Here is my proposed fix_urllib. The transform function is massive
because there are a lot of cases, so maybe I should break it into
separate functions for each case, and it could maybe do with some more
documentation as well. I al
Nick Edds <[EMAIL PROTECTED]> added the comment:
I broke up transform into the logical pieces of it, so I think now the
code is a little bit more clear.
Added file: http://bugs.python.org/file10846/fix_urllib.diff
___
Python tracker <[EMAIL PROTECTE
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
Nick Edds <[EMAIL PROTECTED]> added the comment:
Fair enough. I guess that even though there's a little bit of a
performance improvement from this, it does hurt extensibility, so its
probably not a worthwhile change after all.
___
Python trac
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 Edds <[EMAIL PROTECTED]> added the comment:
Yeah that import_as_names definitely shouldn't be there. I don't know
what I was thinking at the time, but that should just be an any I
believe. I'll clean this up today or tomorrow, update fix_imports2 as
well, and try
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
New submission from Nick Edds <[EMAIL PROTECTED]>:
Here is an iterative replacement to _recursive_matches for Wildcard
Patterns. It's not really much faster now, although I think there is
some room to improve it. It's doesn't seem like the most elegant
solution, but it wo
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 Edds <[EMAIL PROTECTED]> added the comment:
I should be able to. What time would you need it by?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Nick Edds <[EMAIL PROTECTED]> added the comment:
I've got it finished, I just need to write some tests for it. It will
all be done later tonight.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Nick Edds <[EMAIL PROTECTED]> added the comment:
Here is a working version with tests. I believe it has all the desired
functionality, but correct me if I'm wrong Brett. Also, I did not model
MAPPING as suggested by Collin because order was important in generating
tests, so I didn&#x
Nick Edds <[EMAIL PROTECTED]> added the comment:
I can hopefully have it all fixed up by tonight or tomorrow.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Nick Edds <[EMAIL PROTECTED]> added the comment:
It should be done tonight, but probably not until around 11 central
time. Sorry for the delay.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Nick Edds <[EMAIL PROTECTED]> added the comment:
Sorry I couldn't have this done earlier today. I updated the test suite,
and this is now passing all tests. Collin, could you verify that is has
all the functionality you were expecting? If the member functionality
turns out to
Nick Edds <[EMAIL PROTECTED]> added the comment:
Just as an added note: with the new changes made to fix_imports, this is
now noticeably slower than the recursive approach, even after I made a
few optimizations like removing the unnecessary len() in the whil
Nick Edds <[EMAIL PROTECTED]> added the comment:
I believe the problem was that in the case of this fix, rather than
using set_prefix to give the new node the same prefix as before,
new.prefix = was used. Here is the one line fix which preserves the
prefix in the example
Nick Edds <[EMAIL PROTECTED]> added the comment:
This seems to have been the same problem that was causing whitespace to
get lost before some imports. I believe the fix_import change I provided
in that issue, issue 3334, also corrects this problem.
--
nosy:
Nick Edds <[EMAIL PROTECTED]> added the comment:
Yeah sorry. I can't commit changes, so I have the diff in the other
issue but it has not yet been committed. Here it is again for redundancy.
--
keywords: +patch
Added file: http://bugs.python.org/file10938/fix_
Nick Edds <[EMAIL PROTECTED]> added the comment:
My iterative pattern matching doesn't break on this file, but as
mentioned elsewhere, the iterative solution is slower. I'll work on
speeding it up, but I don't immediately see a good way to do so. Any
ideas would b
New submission from Nick Edds <[EMAIL PROTECTED]>:
Here is a working, multiprocess version of 2to3 with a few caveats.
First, you need to already have the processing module installed for this
to work. If we don't want to include processing in some way, I think I
can modify this to
Nick Edds <[EMAIL PROTECTED]> added the comment:
Here is a version that only imports processing if the multi-process
option is specified. I don't know if this is the most efficient way it
can be done, and I think there's a better way to do it, but this works.
Added file: http:/
Nick Edds <[EMAIL PROTECTED]> added the comment:
I don't think it would be hard to implement, I just need a good, fast
metric to determine if a file should be processed iteratively or
recursively. What do you think would be the best way to do this?
___
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.
New submission from Nick Edds <[EMAIL PROTECTED]>:
Here is a substantial improvement to the pattern for fix_imports. It
significantly reduces the size of the previous pattern and represents it
in a more reasonable way. It still passes all of the tests and it also
makes 2to3 roughly two to
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 Edds <[EMAIL PROTECTED]> added the comment:
Sounds good to me. I should have a chance to implement this and submit
it within the next couple of days.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
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
Nick Edds <[EMAIL PROTECTED]> added the comment:
Here is a patch that tries to use the faster recursive matching, but if
there is a RuntimeError, it will use the iterative matching. It passes
all the tests and works on the ssl.py file that were known to break the
recursive matching.
Adde
Nick Edds <[EMAIL PROTECTED]> added the comment:
If nobody else is interested in or currently in the process of making a
fixer for this, I can do it. I'm not sure if I completely understand the
changes I need to make though. Importing dl needs to be replaced by
importing ctypes, calls
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
The documentation and Py3k warning will be ready for the third beta next
week (the remaining part is a lot easier than the initial fix).
___
Python tracker <[EMAIL PROTECTED]>
<http://
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Py3k warnings for this have been checked in on the trunk as r65642.
There's an unfortunate problem with having to define a fixed stack level
for the warnings - for classes with a metaclass implemented in Python,
the warning message
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I still intend to do the necessary documentation updates for this, but
they're going to be delayed a bit since getting the warnings right took
much longer than I expected.
___
Python trac
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
numbers.Number change forward ported to Py3k in r65808
Docs updated for 2.6 and 3.0 in r65810 and r65811 respectively.
Which means I can finally close this one :)
--
resolution: -> fixed
status: open
New submission from Nick Coghlan <[EMAIL PROTECTED]>:
The package level imports from the new multiprocessing package exhibit
some very strange behaviour because they are actually functions
pretending to be classes:
Python 2.6b1+ (trunk:64945, Jul 14 2008, 20:00:46)
[GCC 4.1.3 20
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Setting to deferred blocker, since this really needs to be dealt with
for RC1 (probably too close to b3 to get it discussed and dealt with for
that).
--
priority: critical -> deferre
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I created issue 3589 to cover the problem I mentioned above with the
very misleading names for the package level functions in multiprocessing.
___
Python tracker <[EMAIL PROTECTED]>
<http://
Nick Edds <[EMAIL PROTECTED]> added the comment:
What's the current status of this? If nobody is working on it, I would
be willing to give it a shot. Can somebody just confirm that I have a
correct understanding of the problem.
UserDict.UserDict needs a deprecat
Nick Edds <[EMAIL PROTECTED]> added the comment:
Ahh right. I totally forgot that there was already a fix_dict.py that
took care of that.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
is_alive appears to be a potentially expensive check for the
multiprocessing side of things, which is why I'm inclined to leave it as
a method. "if t.is_alive():" actually reads better to me than
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
My preference actually isn't particularly strong either way, so I
suggest asking Barry for a casting vote.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Just saw a couple of docs checkins go by suggesting that the camelCase
names will be unavailable in 3.x. Remember that the intent *isn't* to
remove the old names from threading.py - we're just adding the PEP 8
names so that mul
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Note regarding those comments - only the exitcode one is something we
should try to get sorted for the beta. Backing out the deprecation
warnings and cleaning up the documentation can wait for the first
release can
Nick Edds <[EMAIL PROTECTED]> added the comment:
I've been thinking about this a bit, and I don't see how handling it
should be all that different from handling module renaming.
For import UserDict, we can just change UserDict to collections and deal
with UserDict.UserDict wi
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
If the object being wrapped isn't a plain vanilla function, then the
odds are *very* good that __doc__ cannot be copied to the new function
and still be correct. This is definitely the case for both modules and
partial objects.
So f
Nick Edds <[EMAIL PROTECTED]> added the comment:
How soon is this needed by? I probably won't have a chance to do it in
the next week, but it shouldn't take that long to make once I get a
chance to work on it.
___
Python tracker <[EMAI
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Reopening - still need to fix the Python level docs for hash() and
__hash__().
--
resolution: fixed ->
status: closed -> open
___
Python tracker <[EMAIL PROTECTED]>
<h
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Docs updated for 3.0 in r66084 (and I was right in thinking the
automatic merge didn't have a hope of getting this right - there were
conflicts all the way through the file).
Closing this issue after a mere 5 years and 9 months - a
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
__hash__() documentation fixed for 2.6 in r66085 and for 3.0 in r66086.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
New submission from Nick Coghlan <[EMAIL PROTECTED]>:
Two of the return paths from ABCMeta.__subclasscheck__ store the
subclass being checked in _abc_registry instead of _abc_cache.
The attached patch corrects the issue.
--
files: meta_subclass_fix.diff
keywords: needs review,
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
priority: critical -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I found further PEP 8 non-compliances in the multiprocessing API while
working on a patch for issue 3589, mainly in the area of function names
that start with a capital letter, making them look like classes when
they definitely are not.
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Patch attached that removes the misleading "convenience" functions,
replacing them with explicit imports of the appropriate names.
The patch also adds docstrings to some of the original class definitions
that were missing t
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Benjamin's patch was applied in r65982
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3352>
___
___
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Patch added that removes the incorrect Py3k warnings from the threading
module (also restores the methods to the same __name__ attributes as
they had in 2.5).
Added file:
http://bugs.python.org/fil
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Second patch added that removes the deprecation warnings from the Py3k
version of the threading module.
Added file:
http://bugs.python.org/file11326/issue3352_remove_threading_deprecation_warning
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
keywords: +needs review -patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3352>
___
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
assignee: jnoller ->
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3352>
___
___
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
keywords: +patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3352>
___
__
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Interesting - in some of the other work I was doing regarding the PEP 8
compliant alternative threading API, I noticed that the threading module
contains similar gems such as:
def Event(*args, **kwds):
return _Event(*args, **kwds)
U
901 - 1000 of 6501 matches
Mail list logo
