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 Edds <[EMAIL PROTECTED]> added the comment:
Sorry about the delay with this. I've finally found some time to work on
this, so it should be completed within the next couple of days.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
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 Edds <[EMAIL PROTECTED]> added the comment:
What do you think would be the best way to implement a test for this? To
test it, I ran it on a known file that caused the old recursive method
to fail, but I don't know if it makes sense to include that with the
tests. I could always w
Nick Edds <[EMAIL PROTECTED]> added the comment:
I have the functionality for this working, and will post it tomorrow
when I complete its test suite.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
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 Edds <[EMAIL PROTECTED]> added the comment:
Here is a fixer and test suite for the UserDict. It doesn't do a very
good job handling imports with 'as' right now, but it's core
functionality appears to be working. If I get a chance I will improve
its handling of &
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 Edds <[EMAIL PROTECTED]> added the comment:
Could somebody else take a look at this and check in it if it looks
alright? I think that it works currently but I can't check it in...
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Nick Edds <[EMAIL PROTECTED]> added the comment:
Is there still any interest in this Collin? Is there anything else you
need me to do for it?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Nick Edds <[EMAIL PROTECTED]> added the comment:
The currently attached patch works in Python2.5 not Python2.6, so I will
update it for 2.6 when I get the chance. But as it is currently written,
the default behavior is not multiprocess. Instead, if you want
multiprocess, you specify ho
Nick Edds <[EMAIL PROTECTED]> added the comment:
I'll look in to it. Just give me a couple of days.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Nick Edds <[EMAIL PROTECTED]> added the comment:
The problem is that fix_imports doesn't look at matches that are nested
within matches. So the _winreg.OpenKey part gets fixed, but the
_winreg.HKEY_LOCAL_MACHINE does not because it is nested within the
other node. I didn't make
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 Edds <[EMAIL PROTECTED]> added the comment:
Here is a patch with a new test case. I don't know if we should apply it
until we've heard from Collin though. The old version of fix_imports
fails the new test, but this version, which allows matching of nodes
nested within mat
Nick Edds <[EMAIL PROTECTED]> added the comment:
I had very little experience with the processing module prior to the
creation of this patch, and because pool objects are listed last in the
documentation, I did not read about them because I saw a way to achieve
what I wanted using Proces
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.
Nick Coghlan added the comment:
Hmm, the problem here is we don't *know* the module filename until we get hold
of the loader for it (see _get_module_details() in runpy). And it is the
process of finding the loader for the __main__ module that does the initial
import of the package as a
Nick Coghlan added the comment:
I realised today that this behaviour is actually the case for any execution of
a module inside a package with -m (i.e. any __init__ modules execute before
sys.argv and __main__ are fully configured).
As I recall, I used a bit of a hack to get main.c to
Nick Coghlan added the comment:
I'm not sure simply changing the value is the right thing to do - with older
zlib versions (which do the wrong thing with 0), we definitely want that
exception to be triggered.
For newer versions, we want to check that passing in 0 worked as specified in
Nick Coghlan added the comment:
The "I'm not sure" in my comment really was a question, rather than a definite
direction to conditionally retain the old test.
I've actually looked at the relevant C code in the zlib module now, and I agree
with Antoine that the original su
Nick Coghlan added the comment:
This may be related to test_gdb problems I am seeing (test_gdb output attached).
gdb details:
GNU gdb (GDB) 7.0-ubuntu
This GDB was configured as "x86_64-linux-gnu".
After applying Dave's second patch, those original errors go away, but
Changes by Nick Coghlan :
Added file:
http://bugs.python.org/file16753/_svn_79729_plus_dm_patch2_test_gdb_errors_amd64_ubuntu_9.10.log
___
Python tracker
<http://bugs.python.org/issue8
Nick Coghlan added the comment:
Second error log attached (and the MIME type should finally be set properly to
let it display as a text file in the browser)
--
___
Python tracker
<http://bugs.python.org/issue8
Nick Coghlan added the comment:
I can reproduce this locally. I believe it is relevant that a simple "import
crash" (with crash.py as the directory) doesn't cause a problem - there must be
something higher in the import machinery which avoids the issue.
--
assigne
Nick Coghlan added the comment:
Ah, OK - the problem is confined solely to the wrapper for the Python imp
module function. The normal import machinery doesn't go through the wrapper and
hence doesn't have the problem.
The PyFile_FromFile logic is a little convoluted, but Flore
Nick Coghlan added the comment:
An interesting part of this story is *why* it doesn't crash in Py3k (despite
explicitly closing the file descriptor in the same way as 2.x closes the C file
pointer).
The reason is that PyFile_FromFd (the closest Py3k equivalent to
PyFile_FromFile)
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue8370>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Yep, this is the right sort of thing to kick in our direction.
There's a reasonable amount of implicit testing of import's level argument
through the relative import tests in test_import and test_runpy, but some
explicit tests of direct invocation
Nick Coghlan added the comment:
The corner case I was talking about was the one where you actually *want* the
old, more restrictive behaviour (i.e. you specifically want to receive
'x.y.Exception' and receiving 'a.b.Exception' instead should fail), but still
want to ignor
Nick Coghlan added the comment:
With a little more thought, I'm actually keen on including it as well (although
the docs still need a bit more tweaking). The 2.x/3.x compatibility point is a
good one.
If Benjamin OKs it, I'll include this in the list of things I want to get to
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue7490>
___
___
Python-bugs-list mailing list
Unsubscri
1001 - 1100 of 6501 matches
Mail list logo
