Changes by Brett Cannon <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11131/pep3120_test.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Brett Cannon <[EMAIL PROTECTED]> added the comment:
On the trunk with r66237 and 3.0 with r66238.
--
resolution: -> accepted
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Brett Cannon <[EMAIL PROTECTED]> added the comment:
And I forgot to mention that subclassing list is a new thing I tossed in
when I moved the code and tweaked the API so that's another reason that
using list's abilities was not pervasive.
__
Brett Cannon <[EMAIL PROTECTED]> added the comment:
The use of __getattr__ is a historical artifact. Originally there was no
way to record multiple warnings as the object returned by
catch_warnings() represented only a single instance of a warning. But
then the ability to record mu
Brett Cannon <[EMAIL PROTECTED]> added the comment:
On Sat, Sep 6, 2008 at 11:31 AM, Barry A. Warsaw <[EMAIL PROTECTED]> wrote:
>
> Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
>
> Sounds good. This needs to go into 2.6 and 3.0.
Oh, definitely.
> A
Changes by Brett Cannon <[EMAIL PROTECTED]>:
--
assignee: -> brett.cannon
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3781>
___
__
Brett Cannon <[EMAIL PROTECTED]> added the comment:
The new patch ditches the WarningsRecorder class and just returns a list
that is directly mutated. I also removed all uses of
test.test_support.catch_warning() and moved them over. Docs have been
thoroughly updated to give example usag
Changes by Brett Cannon <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11382/catch_warnings_atts.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Brett Cannon <[EMAIL PROTECTED]> added the comment:
On Mon, Sep 8, 2008 at 3:12 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
> Benjamin Peterson <[EMAIL PROTECTED]> added the comment:
>
> The patch mostly looks good. However, all the w[-1] logic looks rather
Brett Cannon <[EMAIL PROTECTED]> added the comment:
Covered by r66321 in the trunk. Now I just need to merge into 3.0.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Brett Cannon <[EMAIL PROTECTED]> added the comment:
r66322 has the fix in 3.0.
--
resolution: -> accepted
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
New submission from Brett Cannon <[EMAIL PROTECTED]>:
test_logging is leaving behind a file named 'test.blah' after every run.
--
assignee: vsajip
components: Tests
messages: 72818
nosy: brett.cannon, vsajip
priority: deferred blocker
severity: normal
status: open
tit
Brett Cannon <[EMAIL PROTECTED]> added the comment:
I can understand the amount of time it might take to revert this;
merging was horrendous and stuff was partially combined into single
patches as to get a review done for all related changes instead of doing
more atomic commits if a revi
Brett Cannon <[EMAIL PROTECTED]> added the comment:
On Tue, Sep 9, 2008 at 6:43 AM, Vinay Sajip <[EMAIL PROTECTED]> wrote:
>
> Vinay Sajip <[EMAIL PROTECTED]> added the comment:
>
> Fix checked into trunk - revision 66337.
>
Did
Brett Cannon <[EMAIL PROTECTED]> added the comment:
On Tue, Sep 9, 2008 at 3:00 PM, Vinay Sajip <[EMAIL PROTECTED]> wrote:
>
> Vinay Sajip <[EMAIL PROTECTED]> added the comment:
>
> Sorry, no - whoops. It was a minor test data change which introduced the
> prob
Brett Cannon <[EMAIL PROTECTED]> added the comment:
On Tue, Sep 9, 2008 at 3:13 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Nick Coghlan <[EMAIL PROTECTED]> added the comment:
>
> No worries - the only reason I suggested full reversion at all is
> because I
Brett Cannon <[EMAIL PROTECTED]> added the comment:
Since this is a 3.0 thing I am dropping it down to a deferred blocker.
--
nosy: +brett.cannon
priority: release blocker -> deferred blocker
___
Python tracker <[EMAIL PROTE
Brett Cannon <[EMAIL PROTECTED]> added the comment:
Since we are making 3.0 issues deferred blockers dropping the priority.
--
nosy: +brett.cannon
priority: release blocker -> deferred blocker
___
Python tracker <[EMAIL PROTE
Brett Cannon <[EMAIL PROTECTED]> added the comment:
Going with what Martin suggested, the attached patch reverts what
Christian did and adds an #ifdef sizeof(uint) <= sizeof(uint) around the
PY_SIZE_MAX check. Someone should obviously test on an AMD64 machine (I
have a Core 2 Mac, bu
Brett Cannon <[EMAIL PROTECTED]> added the comment:
Patch seems okay and passes regrtest, although I have to admit I am not
intimately familiar with sre or the new validator.
--
nosy: +brett.cannon
___
Python tracker <[EMAIL PROTECTE
Brett Cannon <[EMAIL PROTECTED]> added the comment:
Patch looks good to me and Martin's analysis of the test being useless
on a platform where size_t > uint_t makes sense.
--
keywords: -needs review
___
Python tracker <[EMAIL
Brett Cannon <[EMAIL PROTECTED]> added the comment:
Code looks good.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3781>
___
___
Python
Changes by Brett Cannon <[EMAIL PROTECTED]>:
--
keywords: +patch -needs review
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3781>
___
Brett Cannon <[EMAIL PROTECTED]> added the comment:
As Benjamin said, it's too late in the release cycle to change this.
Plus turtle is entirely Tk-dependent so putting in the package makes
sense to me. It also isn't important enough to be a top-level package.
Finally, I disagre
New submission from Brett Cannon <[EMAIL PROTECTED]>:
CVE-2008-2316
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2316) notes that
_hashopenssl.c has a potential integer overflow. Attached is the patch
sent to PSRT.
--
components: Extension Modules
files: CVE-200
Changes by Brett Cannon <[EMAIL PROTECTED]>:
--
resolution: -> fixed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2620>
___
___
New submission from Brett Cannon <[EMAIL PROTECTED]>:
http://psf.upfronthosting.co.za/roundup/security/issue2
--
components: Extension Modules
messages: 73355
nosy: brett.cannon
severity: normal
status: open
title: imageop issue
type: crash
versions: Pyth
Changes by Brett Cannon <[EMAIL PROTECTED]>:
--
priority: -> deferred blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3894>
___
_
New submission from Brett Cannon <[EMAIL PROTECTED]>:
http://psf.upfronthosting.co.za/roundup/security/issue3
--
components: Extension Modules
messages: 73356
nosy: brett.cannon
priority: deferred blocker
severity: normal
status: open
title: _lsprof issue
type: crash
versions:
Brett Cannon <[EMAIL PROTECTED]> added the comment:
The reason this happens is to support ``import pack.y``. When you
reference the module in this way it is accessing the 'y' attribute on
the 'pack' module. If import didn't set it this form of importing would
nev
Brett Cannon <[EMAIL PROTECTED]> added the comment:
Sorry about missing your work, Ralf. In the rush to getting a fix in for
2.6rc2 we went with the patch Apple sent to the security mailing list
when the CVE was reported to us.
And 2.5 has already been patched by r66497, so removing tha
Brett Cannon <[EMAIL PROTECTED]> added the comment:
If we think once can reliably add the directory based purely on whether
it starts with "build/lib.", and then potentially check for a suffix of
"-pydebug" if we are in a debug build, I will support adding this
Brett Cannon <[EMAIL PROTECTED]> added the comment:
On Thu, Sep 18, 2008 at 6:58 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
> Brett Cannon <[EMAIL PROTECTED]> added the comment:
>
> If we think once can reliably add the directory based purely on whether
> it s
Brett Cannon <[EMAIL PROTECTED]> added the comment:
Is this really meant to be for 3.1, or should this be a 3.0 blocker?
--
nosy: +brett.cannon
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Brett Cannon <[EMAIL PROTECTED]> added the comment:
I can't find the bug right now, but this has been brought up before.
Since it is only on posix systems and only when running in a code
checkout, no one has worried about it enough to change it. And I am not
sure if it is necess
Changes by Brett Cannon <[EMAIL PROTECTED]>:
--
assignee: -> brett.cannon
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3895>
___
__
Brett Cannon <[EMAIL PROTECTED]> added the comment:
2.6 is fixed in r66677 and 2.5 in r66678. 3.0 has not been applied yet
as test_cProfile is still currently listed as a broken test. So I am
blocking 66677 on py3k for now.
--
priority: release blocker -> deferred blocker
Brett Cannon <[EMAIL PROTECTED]> added the comment:
It looks like no one objected. Can you check this in, Bill?
--
nosy: +brett.cannon
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Brett Cannon <[EMAIL PROTECTED]> added the comment:
Well, even if 2.6 slipped (which it is looking probably won't happen),
how much time would you need to deal with this? Sounds like you just
won't be able to get to it even with an extra week. So that means
multiprocessing is ju
Changes by Brett Cannon <[EMAIL PROTECTED]>:
--
assignee: -> benjamin.peterson
nosy: +benjamin.peterson
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Brett Cannon <[EMAIL PROTECTED]> added the comment:
On Sun, Sep 28, 2008 at 7:56 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
> Benjamin Peterson <[EMAIL PROTECTED]> added the comment:
>
> Brett, are you looking for #58
Brett Cannon <[EMAIL PROTECTED]> added the comment:
On Mon, Sep 29, 2008 at 11:20 AM, Jesse Noller <[EMAIL PROTECTED]> wrote:
>
> Jesse Noller <[EMAIL PROTECTED]> added the comment:
>
> Hows this error look:
>
>>>> import multiprocessing
> Trace
Brett Cannon <[EMAIL PROTECTED]> added the comment:
Setting as a deferred blocker since this is a 3.0 thing and not a 2.6 thing.
--
nosy: +brett.cannon
priority: release blocker -> deferred blocker
___
Python tracker <[EMAIL PROTE
Brett Cannon <[EMAIL PROTECTED]> added the comment:
Amaury's fix works for me; since this is an edge case situation anyway,
I am not terribly worried about some fancy error message.
Fixed in r66700 for 2.6, r66701 for 2.5.
--
resolution: -> accepted
status:
Brett Cannon <[EMAIL PROTECTED]> added the comment:
See the fix in r66700 for the change to _lsprof.c to use.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Brett Cannon <[EMAIL PROTECTED]> added the comment:
Well, all of my modules are in a non-standard location and I have no
build issues on OS X 10.5. If you look at PyBuildExt.detect_modules()
you will see that the paths are at least added for the search path from
LDFLAGS and CP
New submission from Brett Cannon <[EMAIL PROTECTED]>:
PEP 101 says it would be nice to have a dependency graph that showed
what could and could not be done in parallel when cutting a release.
Should throw one together using OmniGraffle or Graphviz.
--
assignee: brett.cannon
me
Brett Cannon <[EMAIL PROTECTED]> added the comment:
On Thu, Oct 2, 2008 at 1:57 PM, Roumen Petrov <[EMAIL PROTECTED]> wrote:
>
> Roumen Petrov <[EMAIL PROTECTED]> added the comment:
>
> One of the problems that I see in that LDFLAGS is Makefile variable and
> Mak
Changes by Brett Cannon <[EMAIL PROTECTED]>:
--
status: closed -> open
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3758>
___
___
Brett Cannon <[EMAIL PROTECTED]> added the comment:
But why does iso-8859-1 need to be treated as a special case? UTF-8 is
special because it is the default encoding for source. But iso-8859-1
really shouldn't be special, IMO.
Your patch does exactly what happens lower when s
Brett Cannon <[EMAIL PROTECTED]> added the comment:
Sorry, I mis-spoke: your patch, Victor, doesn't change the state to
NORMAL. But my worry still stands; why does iso-8859-1 need to be
special-cased? It suggests to me that some more fundamental needs to be
dealt with instead of ju
Brett Cannon <[EMAIL PROTECTED]> added the comment:
Thanks for finding that, Victor! I will do a patch review when I have a
chance (it won't be until after the weekend).
--
assignee: -> brett.cannon
___
Python tracker <[EMAIL
Brett Cannon <[EMAIL PROTECTED]> added the comment:
2.7 through r66819, 2.6 through r66820, and 3.0 through r66821.
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Brett Cannon <[EMAIL PROTECTED]> added the comment:
So I tried the patch (I attached my version with different comments in
the header file and removed some redundant change in whitespacing), and
test_sys consistently fails for me:
test_current_frames (__main__.SysModuleTest)
Assertio
Changes by Brett Cannon <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file11722/alt_latin_1.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Brett Cannon <[EMAIL PROTECTED]> added the comment:
Yep, it passes for me now.
Martin, have any objection to this patch?
--
assignee: -> loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
New submission from Brett Hoerner <[EMAIL PROTECTED]>:
It would be great if the main Python distribution supported DTrace on
(Open)Solaris / FreeBSD / OS X.
I've attached a patch against 2.6 that instruments function calls. It's
from the ed scripts included in Apple's Pyth
Brett Cannon <[EMAIL PROTECTED]> added the comment:
At one point we were told Apple would try to backport their dtrace
instrumentation. I don't know what the status of that is, but it
obviously has not happened.
--
nosy: +brett.cannon
___
Changes by Brett Cannon :
--
nosy: -brett.cannon
___
Python tracker
<http://bugs.python.org/issue7092>
___
___
Python-bugs-list mailing list
Unsubscribe:
Brett Cannon added the comment:
On Tue, Feb 2, 2010 at 19:00, Benjamin Peterson wrote:
>
> Benjamin Peterson added the comment:
>
> Has enough time elapsed yet for py3k merging?
Sure. I will try to do it before or at PyCon.
--
___
Py
Brett Cannon added the comment:
I can't reproduce the failure as running test_multiprocessing and then
test_importlib does not show any left over stuff in the interpreter what would
lead to importlib being used for __import__. But as the IndexError part is a
valid issue I am renamin
Changes by Brett Cannon :
--
priority: -> low
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue7829>
___
___
Python-bugs-list
Brett Cannon added the comment:
OK, this ain't ever going to happen, so I am just going to close this issue.
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python
Brett Cannon added the comment:
In other words you want a way to limit what the context manager catches and
records while allowing all other warnings to propagate. That seems fine.
I didn't do much of a code review, but there is a grammatical error in the
docstring: change "a fi
Brett Cannon added the comment:
I don't know who is doing this, but from what I can tell it isn't
test_imoprtlib; running with -i shows __import__ to still be the built-in one
along with no new sys.path_hooks entries or stale entries in
sys.path_importer_cache. Same goes for
Changes by Brett Cannon :
--
assignee: -> brett.cannon
___
Python tracker
<http://bugs.python.org/issue7875>
___
___
Python-bugs-list mailing list
Unsubscri
Brett Cannon added the comment:
OK, I figured this one out. Someone is using importlib.import_module() which
uses importlib itself to do the import and not builtins.__import__. That has
the side-effect of importlib replacing all None entries in
sys.path_importer_cache with the finder that
Changes by Brett Cannon :
--
dependencies: +importlib not checking bytecode length
___
Python tracker
<http://bugs.python.org/issue7875>
___
___
Python-bugs-list m
Brett Cannon added the comment:
issue #7875 brought up the original failure that caused the creation of this
bug again and led to me finally diagnosing the problem.
--
___
Python tracker
<http://bugs.python.org/issue7
New submission from Brett Cannon :
The saved_test_environment context manager should check that sys.path_hooks,
sys.path_importer_cache, and __import__ have not changed.
The thing that is tricky, though, is that sys.path_importer_cache is
legitimately mutated by other tests simply because
Brett Cannon added the comment:
A quick check of things shows that a totally empty file, a missing timestamp,
or no marshalled code triggers the use of source. I still need to check what
happens when the magic number is truncated by a byte or so along with the
timestamp.
Any screw-up with
Brett Cannon added the comment:
So option 3 would marginalize __import__ testing as importlib's finders and
loaders as pulled from sys.path_importer_cache would be used over __import__'s
own implicit importers that it contains.
As for test.support.import_module being the culprit,
Brett Cannon added the comment:
Importlib actually already can do this: importlib.test.regrtest. It runs
regrtest after importlib has been set for __import__. It also skips tests known
to fail for stupid reasons (typically they don't expect __loader__ to be
defined). You can also ru
Brett Cannon added the comment:
So doing the import manually through __import__('os', globals(), locals(),
['walk'], 1) does not work. My guess is it has something to do with the
IMPORT_FROM opcode (or something related), but I don't have time
Brett Cannon added the comment:
Lib/_strptime.py itself should be thread-safe. I am guessing that it has
something to do with the way the C code in time.c imports _strptime.py. A
possible solution if it is the C code's import stuff is to create a time.py
that imports a _time.c, but tha
Brett Cannon added the comment:
That's a package decision by Ubuntu, not Python, and thus not a bug on our end.
Thanks for the report anyway.
--
nosy: +brett.cannon
resolution: -> invalid
status: open -> closed
___
Python tra
Brett Cannon added the comment:
Now that Dino has commit privileges and I just gave him the coordinator role,
he can do the commit himself. =) Went ahead and assigned this issue to him.
And Dino, it would be helpful if you changed your username on the tracker to
match your username on python
Brett Cannon added the comment:
So it isn't really unexpected as -Q uses DeprecationWarning which is being
silenced by default.
So either -Q has to turn DeprecationWarning back on or a new subclass of
DeprecationWarning (say IntegerDivisionWarning) needs to be introduced that -Q
use
Brett Cannon added the comment:
Posted to python-dev to solicit feedback on how to handle this.
--
stage: commit review -> needs patch
versions: -Python 3.2
___
Python tracker
<http://bugs.python.org/iss
Changes by Brett Cannon :
--
priority: -> low
stage: -> patch review
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue8100>
___
___
P
Changes by Brett Cannon :
--
priority: -> low
___
Python tracker
<http://bugs.python.org/issue8119>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Brett Cannon :
--
assignee: georg.brandl -> brett.cannon
___
Python tracker
<http://bugs.python.org/issue7997>
___
___
Python-bugs-list mai
Changes by Brett Cannon :
--
assignee: -> ronaldoussoren
components: +Macintosh -Build
nosy: +ronaldoussoren
priority: -> normal
stage: -> needs patch
___
Python tracker
<http://bugs.python.o
Brett Cannon added the comment:
So David's right that local commits are bad from a threading perspective. If
you happen to have an import trigger a thread which itself triggers an import
you will lock up the interpreter. Typically this is avoided by not importing
anything in a thread an
Brett Cannon added the comment:
You could break it out into a module, but that feels like overkill for some
minor code duplication that is not going to be a problem once we stop caring
about Python 2.x. I personally wouldn't bother going that far.
--
priority: normal -
Brett Cannon added the comment:
Trying to get this right is nasty as mixed filesystem stuff is always tricky,
especially since NFD is still UTF-8 as is NFC so sys.getdefaultencoding()
doesn't help.
Without some way to get that extra bit of info about what form of UTF-8
encoding is
Brett Cannon added the comment:
Patch works for me as well. Go ahead and commit it, Florent, with the comment
fix as a separate commit as Mark suggested.
--
assignee: brett.cannon -> flox
stage: patch review -> commit review
___
Python t
Brett Cannon added the comment:
Can't reproduce under OS X with Python 2.6.5. Closing as out of date.
--
nosy: +brett.cannon
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python
Brett Cannon added the comment:
Nick is right that importing package.__main__ requires importing
package.__init__ first.
But it sounds like Michael really just wants some way to know when runpy is
being used over something else. Could a special string token like "" or
"<
Brett Cannon added the comment:
While technically site.py could probably detect it is running in an interactive
session, changing this behaviour now would be backwards-incompatible and break
pre-existing code that relies on this behaviour (which has been around for a
long time
Brett Cannon added the comment:
I take the blame on documenting the handful of things in test.support; I
thought it was a good idea to expose the handful of things that had an actual
design to them. =)
But yes, we should probably shift to test.support to being private and simply
exposing
Brett Cannon added the comment:
Your assessment of what is going on, Andy, is correct; the peephole optimizer
for bytecode optimizes away the `if __debug__` section of the `if` statement
for .pyo files.
But that is actually a reasonable thing for the compiler to do as you are not
supposed
Changes by Brett Cannon :
--
nosy: -brett.cannon
___
Python tracker
<http://bugs.python.org/issue1722344>
___
___
Python-bugs-list mailing list
Unsubscribe:
Brett Cannon added the comment:
So technically Python does not know that some bytecode was compiled with
optimization flags on; that is simply not carried in the bytecode format. You
also cannot rely on file name extensions as the bytecode could have been
generated by an interpreter that
Brett Cannon added the comment:
First off, the 'as' clause is not influencing anything; simply try to assign
``t = a.b.t`` and you still get the error.
Second, you are trying to reference a.b in a.b.c through your a.b.t import
before a.b has finished importing. This is causing
Brett Cannon added the comment:
On Wed, Apr 14, 2010 at 18:35, R. David Murray wrote:
>
> R. David Murray added the comment:
>
> No, Brett said he thought it was not a bug. If Raymond disagrees, he'll
> say so. If I may attempt to channel Brett, I suspect his logic for
Brett Cannon added the comment:
If you want a justification, think of it as undefined behavior. When you use an
empty string in fromlist you are essentially simulating ``from pkg import``
which makes absolutely no sense, so no one has cared enough to try to fix this.
It's such a hack t
Brett Cannon added the comment:
On Thu, Apr 15, 2010 at 14:56, Ãric Araujo wrote:
That's fine with me if someone wrote a patch that did that.
--
title: __import__ with fromlist=[''] causes double initialization of modules ->
__import__ with fromlist
Brett Cannon added the comment:
Although now that I think about it, there is a slightly sticky situation of
someone using '' or some name with a slash for a key in __dict__. The usage in
fromlist would then be "reasonable", but the semantics would be somewhat odd as
fro
Brett Cannon added the comment:
Attached is a patch I wrote entirely independently of this issue (Mercurial's
test suite trigger it for me). I go further in terms of caching items than the
original patch as I still got failures even when I stored just a reference to
os (might be an
801 - 900 of 5934 matches
Mail list logo
