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 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 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 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
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
It turns out threading uses the odd "class-that-is-not-a-class" naming
scheme as well:
threading.Lock
threading.RLock
threading.Condition
threading.Semaphore
threading.BoundedSemaphore
threading.Event
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Patch added to tone down note regarding the PEP 8 compliant aliases that
have been added to the threading module.
Added file:
http://bugs.python.org/file11327/issue3352_tone_down_26_threading_doc
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
And one last patch to adjust the threading docs in Py3k to reflect the
fact that the 2.x API is still supported, even if it is no longer
documented.
Added file:
http://bugs.python.org/file11328/issue3352_update_30_threading_doc
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
Removed file:
http://bugs.python.org/file11324/issue3352_remove_threading_py3k_warnings.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Updated the 2.6 threading patch to also remove the warnings from the
methods that are being replaced by properties.
Added file:
http://bugs.python.org/file11329/issue3352_remove_threading_py3k_warning
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Given how long I've been using the threading module without realising it
does the same thing, I'm actually prepared to live with the wrapper
functions rather than messing with this so close to release.
As Fredrik noted in the p
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Regarding the factory functions that are named as if they were classes,
Fredrik noted on python-dev that the ones from the threading module are
explicitly documented as being factory functions, and the
multiprocessing API really just f
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Ben, if you get a chance to apply those patches, feel free, otherwise I
should be able to get to them this evening (my time - about 10 hours
from now).
___
Python tracker <[EMAIL PROTECTE
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Thanks!
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3352>
___
___
Python-bugs
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
2.6 fixed in r66144, merged to 3.0 in r66147
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Not so much "too complicated" as "potentially touches a lot of code and
not something I want to fiddle with this close to release".
As I noted on python-dev, it's actually a change that can easily be
handled thr
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Looks like we'll be living with the slowdown for 3.0, so marking this as
a high priority item for 3.1.
(Given that the API doesn't change, I wonder if this could be included
in a 3.0.1 release?)
--
priority: -> hig
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
This issue was missing a priority setting.
Alexander's range-sequence patch still applies cleanly to the Py3k
branch, and "make test" still runs correctly after applying it.
As Alexander notes above, range_contains doe
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
Removed file:
http://bugs.python.org/file11345/issue2690-range-sequence-ncoghlan.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
My initial patch had a few problems - I removed it and uploaded a
corrected version.
Added file:
http://bugs.python.org/file11346/issue2690-range-sequence-ncoghlan.diff
___
Python tracker <[EMAIL
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Good catch Antoine (I missed that in Alexander's patch) - working on
that now.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
v2 of my updated patch attached to fix the issue Antoine noted.
Also gets rid of some tab-instead-of-spaces indenting issues in the
file, and avoids hardcoding PyRange_Type when creating new instances.
However, the patch still has issu
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Given the problems with it, I'm dropping this to normal priority and
punting to 3.1.
(the release blocker status was just temporary to ensure we got a
decision on it before rc1 - it previously didn't have a priority set)
---
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Raymond Hettinger wrote:
> I think this should be deferred to Py3.1.
> This decision was not widely discussed and I think it likely that some
> users will
> be surprised and dismayed. The release
> candidate seems to
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Attached patch raises Py3k warnings rather than plain deprecation
warnings, so it looks good to me (some of the discussions on python-dev
gave the impression that may have been getting full deprecation
warnings, implying its potential r
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Patch looks good to me (I've only looked at the patch - not the other
possible misuses of PyByteArray_ that Amaury noted)
--
nosy: +ncoghlan
___
Python tracker <[EMAIL PRO
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I was actually pretty sure the intention was to add Py3k warnings, but
the exact phrase being used in the python-dev thread was "deprecation
warnings" which made folks a little nervous.
__
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Reopening this because I disagree with the fix - I would prefer to see
catch_warnings() reverted back to the API and implementation* it used
prior to the test_support->warnings migration.
That version had perfectly clear semantic
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
As far as the use cases go, it was moved out of test.test_support to
warnings SOLELY due to the requests from the twisted folks for
assistance in testing their generation of warnings. The fact that it is
also useful for suppressing warni
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
It turns out the warnings.catch_warnings version has re-entrancy issues
due to the fact that it can't use @contextmanager:
Python 2.6b3+ (trunk:66143M, Sep 2 2008, 20:04:43)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I also have to comment on the "makes the API simpler to use" note in the
checkin message. No, no it doesn't. See all those "warning[-1]" calls in
the current unit tests? They're all unhelpful, because if
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
assignee: -> ncoghlan
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3781>
___
___
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
test.test_support *is* a public API (it's even documented).
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
In working on the reversion patch, I just noticed that r66321 also
incorrectly removed a whole pile of w.reset() calls.
When using a single catch_warning() context to test two or more
operations which may raise the same warning, you
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I will put together two patches: one that reverts all the way back to
what we had in the betas, and another which just reverts the Python test
suite changes in the most recent checkin (instead modifying
test_support.catch_warning to u
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Fully reverting the relocation also required reverting r66197 (a belated
checkin of test_py3kwarn for the r66135 changes).
There was also a change to test_warnings that had to be reverted (it
appeared to have been mistakenly checked in a
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Reversion patch attached - it does indeed recreate some nasty
dependencies from the main areas of the standard library on to the
regression test suite. That's enough to kill the idea of a complete
reversion as far as I'm conc
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
No worries - the only reason I suggested full reversion at all is
because I had temporarily forgotten why the relocation had become so
necessary (i.e. we needed the feature ourselves in the main part of the
standard library to avoid em
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Not quite that basic for the warnings.catch_warnings() part. I plan to
leave the current warnings.catch_warnings() alone (aside from adding
some re-entrancy checks), and add back a
test.test_support.check_warnings() that uses a WarningsRe
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Cleanup patch now attached. Details of changes:
- warnings.catch_warnings() now has reentry guards (and associated
tests) to prevent silent errors when misused
- added back a test_support.check_warnings() convenience wrapper
(delibe
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Applied to trunk for 2.6 in r66386.
--
priority: release blocker -> deferred blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Blocked merge in the py3k branch since it requires some fiddling to
handle the change from test.test_support to test.support. I'll post a
new patch here for the py3k forward port when I can (I may not make it
before 3.0b4 though, so
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Setting this to a release blocker, because it is affecting Neal's
automated execution of the regression test suite with a debug build.
--
nosy: +ncoghlan
priority: -> release blocker
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Scratch that - it's more likely to be Neal's setup which is at fault,
which I will be questioning on python-dev shortly (there are 3 other
tests which are failing/getting skipped in Neal's regression test suite)
---
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
3.0 version of the patch attached (it turned that it wasn't so much
test_support itself that caused the forward port problems, as the fact
that most of the tests that use this feature in 2.x are testing
specifically for Py3k warni
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
keywords: +needs review
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3781>
___
__
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
This is the kind of project where the sandbox is useful - Facundo's
original decimal work was done there, as was the attempt at a complete
rewrite of the decimal module in C (which turned out to be a less than
optimal approach t
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Patch comments:
- the test suite section of the diff appears to have a number of changes
that are unrelated to this issue
- the purpose of the new do_not_close flag (i.e. avoiding the crash)
could use a comment at the point where
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
All of those explanations sound fair to me - with those questions
answered, the patch looks good to me.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
The 3.0 forward port of r66386 still needs a once over before being
committed (there were enough differences that I don't think the review
of the 2.6 version is enough to cover the 3.0 version as well).
Once that is done, then thi
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Looking at mp.synchronize, the whole module really does depend on a
working _multiprocessing.SemLock instance. If these platforms don't have
a native semaphore implementation, what is their basic inter-process
synchronisation primi
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Jesse, how much (if any) of the rest of the package will work without
the synchronize module? If it isn't a lot, then it may be a matter of
just making this a cleaner ImportError and an expected test suite skip
on OpenBSD
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Agreed - Jesse, can you work up a patch that generates a clean import
error when _multiprocessing.SemLock can't be defined (due to
HAVE_SEM_OPEN=0 or a single-threaded build), adds test_multiprocessing
to the expected skips for
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Could use confirmation from Damien and Andrew that they now see the
expected skips with the patch applied, but otherwise looks good to me.
___
Python tracker <[EMAIL PROTECTED]>
<http://
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Platform? It works fine for me (system python is 2.5, local python is
trunk - the tildes aren't actually in the printout, I subbed them in for
my home directory):
~/devel/python$ python -m site
sys.path = [
'~/devel/python
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Platform? It works fine for me (system python is 2.5, local python is
trunk - the tildes aren't actually in the printout, I subbed them in for
my home directory):
~/devel/python$ python -m site
sys.path = [
'~/devel/python
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4082>
___
___
Python-bugs-list mailing list
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4082>
___
___
Python-bugs-list mailing list
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4082>
___
___
Python-bugs-list mailing list
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Hmm, that makes for absolutely identical base systems except that mine
is i686 where yours is x86_64.
What do you see if you stick some debugging messages at module level in
site.py? (e.g. printing out __name__)
(I'll be going offl
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I'm setting up a 2.6 working area now - we'll see what's to be seen once
I have that up and running. None of the runpy or pkgutil stuff has been
touched in months though (since PEP 366 was implemented), so I'm a
litt
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Platform? It works fine for me (system python is 2.5, local python is
trunk - the tildes aren't actually in the printout, I subbed them in for
my home directory):
~/devel/python$ python -m site
sys.path = [
'~/devel/python
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
No joy. 32-bit Ubuntu here, and "./python -m site" works fine on the 2.6
branch, as does "python2.6 -m site" after a "make altinstall".
Is this an installation you built yourself
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Platform? It works fine for me (system python is 2.5, local python is
trunk - the tildes aren't actually in the printout, I subbed them in for
my home directory):
~/devel/python$ python -m site
sys.path = [
'~/devel/python
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
(Adding some additional details regarding the reasons why this became an
error again in 2.6)
The ImportError when attempting to execute a package was lost during the
conversion from the C-based implementation in 2.4 to the runpy module
New submission from Nick Coghlan :
As discussed recently on python-dev, issue 1739468 deserves a mention in the
What's New for the relevant Python releases.
--
assignee: ncoghlan
components: Documentation
keywords: easy
messages: 98420
nosy: akuchling, ncoghlan
priority: n
Nick Coghlan added the comment:
If I ever clear all the other issues off my list, I may get a chance to have a
closer look at this one :)
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue1681
Nick Coghlan added the comment:
Since import and direct execution will cope with files that don't end with a
blank line, changing the first argument to "source + '\n'" in the pkgutil
compile call seems like a reasonable workaround for the limitation in
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue6760>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file16098/subprocess.rst.patch
___
Python tracker
<http://bugs.python.org/issue6760>
___
___
Python-bug
Nick Coghlan added the comment:
Committed for 2.7 as r77959.
Still needs to be merged to the other branches.
--
resolution: -> accepted
status: open -> pending
___
Python tracker
<http://bugs.python.org/
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue4037>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
As RDM said, it is AMK's What's New that is missing a description of this new
feature. A lot of Python developers just read that document rather than
trawling through the whole NEWS file for each major release.
I actually thought I had got AMK t
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue2001>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Nick Coghlan :
A bug report for the incompatibility I was trying to explain on the checkins
list. The test_support module is the only part of the regression test suite
that is officially documented, so we can't go changing behaviour that is
visible to third parties at
Changes by Nick Coghlan :
--
title: Incompoatible change to test.test_support.check_warnings behaviour ->
Incompatible change to test.test_support.check_warnings behaviour
___
Python tracker
<http://bugs.python.org/iss
Nick Coghlan added the comment:
On a quick read through, the patch looks fine to me.
I actually agree it would be nice if we could keep the "quiet=True" default
(since it is a better match for the feature set we want in our own tests), but
I see the compatibility issue as a deal b
Nick Coghlan added the comment:
On a second look, there are a couple of things missing:
- the default value didn't actually get changed!
- we should add an explicit test that the no argument behaviour doesn't raise a
warning by default
Since we don't really have an existing tes
Nick Coghlan added the comment:
Ah, I didn't notice that there were already tests for this in test_warnings
(that's what I get for commenting late at night).
Updated patch looks good.
--
___
Python tracker
<http://bugs.python.
901 - 1000 of 6301 matches
Mail list logo
