Nick Coghlan added the comment:
The patch does make a slight difference for me - I go from 14 failures down to
8 failures and 6 skipped.
The post-patch failures appear to be the same ones Martin is getting:
"test_gdb.get_stack_trace" is regularly failing due to t
Nick Coghlan added the comment:
Ah, yep - "rm python-gdb.py", "make" cleared up those remaining ".function"
failures. The makefile could probably use a Modules/Setup.dist vs Modules/Setup
style warning when libpython.py is newer than python-gdb.py to help preve
New submission from Nick Coghlan :
Remaining failure after resolution of issue8437:
==
FAIL: test_basic_command (test.test_gdb.PyBtTests)
Verify that the "py-bt" com
Nick Coghlan added the comment:
And Dave's comment from the other issue:
Reading the frame information seems to be highly sensitive to the optimization
level and the exact version of gcc for the build, and the exact version of gdb,
alas. I've been tracking a failure like t
Nick Coghlan added the comment:
Potentially relevant gcc and gdb version info:
~$ gcc --version
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY
Nick Coghlan added the comment:
Remaining problem recorded as issue 8482
--
components: +Library (Lib), Tests
keywords: +64bit -patch
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue8
Nick Coghlan added the comment:
(Oops, thought I had reverted those accidental edits by reloading the page. I
guess not)
--
keywords: +patch -64bit
___
Python tracker
<http://bugs.python.org/issue8
Nick Coghlan added the comment:
Thanks Victor.
The test actually runs fine under "./configure --with-pydebug", but reverting
to a plain "./configure" and rebuilding means I get the error again.
Definitely sounds like it could be due to the compiler failing to make
Nick Coghlan added the comment:
I'll weight for Dave to weigh in before I dig any further - the problem I am
seeing seems to have a lot in common with the issue he reported on 64-bit
Fedora, but I only followed about half of that bug discu
Changes by Nick Coghlan :
--
___
Python tracker
<http://bugs.python.org/issue8482>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/m
Nick Coghlan added the comment:
I'll wait for Dave to weigh in before I dig any further - the problem I am
seeing seems to have a lot in common with the issue he reported on 64-bit
Fedora, but I only followed about half of that bug discu
Nick Coghlan added the comment:
Thanks, I understood your summary significantly better than I did the bug
discussion :)
Any of your 3 options sounds reasonable to me (although i. sounds potentially
fragile in the face of different versions of gcc, so iii. might be necessary
anyway).
The
Nick Coghlan added the comment:
Committed for 2.7 in r80578
I'll forward port to 3.2 at some point after the next 2.7 beta is out.
--
resolution: -> accepted
stage: patch review -> committed/rejected
status: open -> pending
___
Nick Coghlan added the comment:
I think I'll concur with the "this is a mess" assessment.
Given that state of affairs, punting on this until 3.2 (at the earliest).
--
assignee: ncoghlan ->
versions: +Python 3.2 -Python 2.4, Python 2.7, Pyth
Nick Coghlan added the comment:
Committed for 2.7 in r80580 (as it turns out, the hack I remembered was
probably from the original pre-runpy 2.4 implementation and has since been
replaced by the proper runpy based system. This bug was likely just a lingering
remnant of that original hackish
Nick Coghlan added the comment:
Missed the boat for 2.7 I'm afraid. Definitely one to take another look at for
3.2 though.
--
assignee: ncoghlan ->
versions: -Python 2.7
___
Python tracker
<http://bugs.python.or
Nick Coghlan added the comment:
I'll have a closer look at this tomorrow with the aim of getting it into 2.7b2.
(I'm inclined to agree with jd that this is just a bug in the existing
implementation, hence the change in the issue type)
--
type: feature request -> beha
Changes by Nick Coghlan :
--
versions: +Python 3.2 -Python 3.0
___
Python tracker
<http://bugs.python.org/issue5251>
___
___
Python-bugs-list mailing list
Unsub
Nick Coghlan added the comment:
OK, reassessing with brain fully engaged this time: the current patch is
incorrect, and this request is more complicated than one might initially think
:)
It appears that since the patch was originally tried out only on Windows, a
Modules/Setup based system
Changes by Nick Coghlan :
--
stage: needs patch ->
___
Python tracker
<http://bugs.python.org/issue1644818>
___
___
Python-bugs-list mailing list
Unsubscri
Nick Coghlan added the comment:
Unassigning - this idea needs a lot more specification work to be done before
actually implementing it becomes a good idea.
(e.g. IronPython and Jython should be looked at to see how they handle the
naming schemes in the standard libraries for their respective
Nick Coghlan added the comment:
I haven't looked at this in a while, but I do remember it was hard to get
working at all without a ridiculous number of false alarms - type
initialisation isn't the most straightforward thing in the world.
Agreed the warning for __cmp__ should just g
Nick Coghlan added the comment:
(Not sure how relevant my second last paragraph is - I meant to take that out
after noticing the MRO details).
--
___
Python tracker
<http://bugs.python.org/issue8
New submission from Nick Coghlan :
As noted in the comments for issue 2831, the enumerate docstring doesn't cover
the feature added by that patch.
--
components: Interpreter Core
keywords: easy
messages: 105144
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
s
Nick Coghlan added the comment:
Created issue 8635 for the incomplete docstring
--
___
Python tracker
<http://bugs.python.org/issue2831>
___
___
Python-bug
Nick Coghlan added the comment:
I agree with Michael - one test that covers multiple settings can easily be
done by collecting results within the test itself and then checking at the end
that no failures were detected (e.g. I've done this myself with a test that
needed to be run ag
Nick Coghlan added the comment:
No, I'm saying I don't see summarising the parameterised tests separately from
the overall test run as a particularly important feature, since you can test
multiple parameters in a single test manually now.
The important part is for the framework to
Nick Coghlan added the comment:
I forgot to update the special _run_module_as_main variant when I
modified run_module. I'll modify the patch to fix that and to test '-m'
explicitly in test_cmd_line_script.
__
Tracker <[EMAIL PROTECTED]>
&l
Changes by Nick Coghlan:
Removed file: http://bugs.python.org/file8794/pep_366_v1.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1487>
__
___
Python-bugs-
Nick Coghlan added the comment:
Posted v2 of the patch, which fixes the problem Guido noted, and
improved the tests to make sure __package__ is being set correctly.
There's also now an explicit test for using -m on a module inside a
package (which proved harder to write than I expected
Nick Coghlan added the comment:
Checked in as rev 59288.
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1487>
__
___
P
Nick Coghlan added the comment:
PEP 366 has been implemented for 2.6, which fixes this bug. The fix
turned out to be quite invasive (hence the PEP), so it won't be
backported to 2.5.
--
resolution: -> fixed
status: open -> closed
type:
Nick Coghlan added the comment:
This has been implemented for 2.6
--
priority: high -> normal
resolution: later -> fixed
status: open -> closed
type: -> rfe
versions: +Python 2.6 -Python 2.5
_
Tracker <[EMAIL PROTECTED]>
<h
Nick Coghlan added the comment:
I should have known that fiddling with import.c couldn't possibly go as
smoothly as it had been ;)
The problem actually turned out to be fairly shallow - the merge picked
up a lot of calls to the PyString_* interfaces from the 2.x import
implementation. Repl
Nick Coghlan added the comment:
In what sense is this being flagged as easy? All the runpy code knows at
this point is that it asked the import system for the __main__ module's
code object and didn't get one. __main__ always exists, so the module is
definitely able to be found - w
Nick Coghlan added the comment:
I removed the easy tag. I'll try to come up with some ideas for making
the error message more helpful without making it misleading.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Nick Coghlan added the comment:
Very nice solution Amaury. As far as I can tell, this should be
backported to 2.5 as well.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Nick Coghlan added the comment:
Marking this as Won't Fix.
I'd suggest looking at the _ast module
(http://docs.python.org/dev/library/_ast.html) as a reference rather
than the compiler module. The maintenance on the latter has been sketchy
at best, and as you note, it is scheduled
Nick Coghlan added the comment:
I don't have any objection in principle, but I would like to see the
updated rules based on the 2.6 and 3.0 Grammar files (they should only
be minor variants of what you have already done for 2.5)
__
Tracker <[EMAIL P
Nick Coghlan added the comment:
Sorry, I misread slightly (or else just got confused as to which of the
3 Grammar files I was looking at on my local machine). What you've
posted already is indeed the relevant change for 2.6 - it's only 3.0
that is slightly different because it
Changes by Nick Coghlan:
--
assignee: -> ncoghlan
nosy: +ncoghlan
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2021>
__
___
Python-bugs-li
Nick Coghlan added the comment:
Perhaps the best we can do is a warning from the DictMixin constructor
in 2.6 when the -3 flag is specified?
--
nosy: +ncoghlan
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Nick Coghlan added the comment:
I thought WINVER defaulted to something like 0x0400 (i.e. you can't use
things specifically defined for even Win2k without setting it, let alone
things first defined for XP).
I know I had to force it to 0x0500 recently for a non-Python project to
get acce
Nick Coghlan added the comment:
I've changed the issue type from rfe to behaviour. NamedTemporaryFile
actually provides __enter__ and __exit__ methods in 2.5, they just don't
work (it tries to use the methods from the underlying file object
directly which turns out to be a doomed exer
Changes by Nick Coghlan:
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1706>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mai
Nick Coghlan added the comment:
I just checked the current PC/pyconfig.h: with the current settings in
that file, the core is already limited to using NT4 compatible Win32 API
calls. Unless the specific source file takes steps to override it (i.e.
setting WINVER before including python.h), no
Nick Coghlan added the comment:
Given that whether or not Py_BUILD_CORE is defined flips the direction
of the DLL exports/import for the main python DLL, I don't see how it
could be defined for the separately compiled extension modules like
_tkinter, _sqlite3, _ctypes, _socket, _ssl, etc
Nick Coghlan added the comment:
Backported to 2.5 in r60728
P.S. To elaborate a bit more on why converting NamedTemporaryFile to
subclass file would be a much bigger deal than it is to just fix its
__enter__ and __exit__ methods:
- converts from old-style to new-style class
- imposes the
Nick Coghlan added the comment:
The wrapper approach has the virtue of providing easy access to the
underlying file object and its methods. That actually gets a bit more
difficult when you switch to a subclassing approach (you need to either
explicitly qualify the methods or play around with
Nick Coghlan added the comment:
Thanks for adding the class methods back Mark.
On the constructor front, we got a fair payoff in the early Decimal days
just by reordering the type checks in the constructor. Other than that,
I'd have to dig into the code a bit more to offer any u
Nick Coghlan added the comment:
I mentioned my dislike of the classmethod->staticmethod change on the
python-checkins list, but given the lack of response there, I figure I
should bring it up here. It is well established that the way to
implement an alternate constructor in Python is to writ
Nick Coghlan added the comment:
The test suite is run via test/regrtest.py. If you aren't on windows,
'make test' works as well.
For myself, I tend to just run "./python -m test.regrtest" in the
directory where I built Python.
-
Nick Coghlan added the comment:
We don't want to restore Python 2.5 behaviour - directories containing a
__main__.py file are meant to be executable in 2.6. With your proposed
change test_cmd_line_script will fail its directory execution tests
(since those rely on the default importer to
Nick Coghlan added the comment:
I've checked in friendlier error messages as r60955
Examples (paths somewhat redacted):
$ ./python bob
./python: can't open file 'bob': [Errno 2] No such file or directory
$ ./python .
/devel/python/python: can't find '__main__.py
Nick Coghlan added the comment:
If main.c doesn't handle sys.exit() correctly for code run via
RunMainFromImporter, then that's a problem with the main function - it
will happen regardless of whether it is runpy.py or application code
that calls sys.exit. But as far as I can tell, it
Nick Coghlan added the comment:
Interesting - I'll try to find the time to take a look at this. (I also
added PJE to the nosy list - hopefully he will get a chance to look at it)
--
nosy: +ncoghlan, pje
__
Tracker <[EMAIL PROTECTED
Nick Coghlan added the comment:
The mutation of sys.path is deliberate - the use case is to allow the
interpreter to execute a zipfile directly and have access to all of the
Python modules and packages bundled along with __main__.py. Supporting
execution of directories as well makes it much
Nick Coghlan added the comment:
Updated issue title to reflect what was actually implemented
--
title: Add a -z interpreter flag to execute a zip file -> Allow interpreter to
execute a zip file
_
Tracker <[EMAIL PROTECTED]>
<http://bug
Changes by Nick Coghlan:
Removed file: http://bugs.python.org/file8767/runmain_with_tests.diff
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1739468>
_
__
Nick Coghlan added the comment:
Reopening - I disagree with the assertion that this isn't expected to work.
--
nosy: +ncoghlan
resolution: fixed ->
status: closed -> open
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Nick Coghlan added the comment:
Hmm, I can't reproduce any failure using the supplied zip file, even if
I increase the number of threads to 382 (if I set it any higher,
start_new_thread starts to fail). That's with both 2.5.1 and 2.6 SVN.
I'll try again with the original tkinte
Nick Coghlan added the comment:
Nope, can't reproduce it with the original tkinter/urllib script either
(again, Ubuntu's 2.5.1 release and SVN 2.6, with the thread count set at
350).
Could it be a windows specific problem? Or require a non-hyperth
Nick Coghlan added the comment:
Ah, never mind - just needed to run the test a few more times to get it
to fail.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Nick Coghlan added the comment:
Ahah, found the real restrictions - while it turns out the OP's
demonstration code is indeed broken, I think the warning Georg added to
the docs based on Christian's comment above is *far* too strong (hence
my somewhat annoyed message on the checkins lis
Nick Coghlan added the comment:
Correction to previous comment: you can't safely perform imports from
daemon threads at all, as you have to set their daemon status before you
start them.
So, to be able to safely import from a thread other than the main thread:
- it must be created b
Nick Coghlan added the comment:
And one other restriction: the thread performing the import must not be
spawned as a side effect of importing a module (as this will deadlock
the interpreter)
The effect of disobeying the two restrictions in my previous comment
will be intermittent crashes at
Nick Coghlan added the comment:
(oh, one thing - the 'crashes' mentioned in my proposed wording are due
to explicit calls to PyErr_FatalError rather than a segfault or anything
like that. The one specifically reported by the OP is due to sys.modules
being gone by the time an import is
Nick Coghlan added the comment:
Proposed wording for a warning pointing that threads and imports can get
you in trouble. It might be better to squirrel off into a new subsection
on threaded imports, rather than giving it too much prominence (since
the recommended approach to creating subthreads
Nick Coghlan added the comment:
The mail.python.org link I posted previously is broken. Here's an
updated link to the relevant c.l.p. thread:
http://mail.python.org/pipermail/python-list/2005-February/310020.html
>From my point of view, I still think it's an excellent idea and woul
Nick Coghlan added the comment:
A closer approximation of what the with statement is doing would be:
exit = lock.release()
lock.acquire()
try:
pass
finally:
exit()
The problem with trying to store the result of the retrieval of __exit__
on the stack is that we need to leave the context
Nick Coghlan added the comment:
Scratch the parentheses on that first line of sample code in my previous
comment (isn't copy and paste wonderful?)
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Nick Coghlan added the comment:
Patch applied cleanly for me and all tests pass.
It also looked good on a visual scan over the diff text.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Nick Coghlan added the comment:
I went ahead and committed the change to the bytecode generation as r61290.
The deficiencies in the lock implementation should probably be raised as
a separate issue, so I'm closing this one.
--
resolution: -> accepted
status: open -
New submission from Nick Coghlan <[EMAIL PROTECTED]>:
The ability to execute zip files and directories containing a
__main__.py file needs to be covered in the documentation of the command
line options.
--
assignee: ncoghlan
components: Documentation
keywords: easy
messages: 6341
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
To clarify the intent of the section of PEP 302 Paul quoted: the
*module* object gets reused, but the contents of mod.__dict__ are
clobbered and the module code re-executed.
So it's the same module object, but with brand new conten
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
The patch actually isn't all that complicated - the main structural
change to make it possible to process the strings correctly is
converting the parser functions to have treat the flags argument as an
I/O variable, rather than ju
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I have a couple of use cases for bytes-as-ASCII-text -> int, one of
which also touches on floats. The other numeric types also accepting
bytes as representing ASCII encoded strings would then follow from a
consistency of behaviour
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Hmm, I forgot there wasn't currently a direct path back from int ->
bytes. I think your numbers *do* show that we need to do something about
the performance of the Python 3.0 version of decimal. A 25% increase in
runtime i
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Agreed - I've been convinced that the right thing to do is reject bytes
in int() and float() as well.
If we decide we still want to support a fast-path conversion it should
be via separate methods (e.g an int.from_ascii class me
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
The 2.6 and 3.0 documentation has already been updated appropriately.
The forward compatible way to handle this is to inherit from object and
override the special methods explicitly in the 2.x version (Yes this can
make writing proxy o
New submission from Nick Guenther <[EMAIL PROTECTED]>:
I think I've found a bug in python's list comprehension parser. Observe:
>>> [e for i in j in ['a','b','c']]
Traceback (most recent call last):
File "", line 1, in
NameErro
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Agreed that section of the docs should be more explicit in pointing out
that __getattr__ and __getattribute__ won't work for proxying special
methods for new-style classes.
It's also true that there are quite a few speci
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I've started a discussion on the Py3k development list regarding the
possibility of adding a new method to type to aid in converting proxy
classes from classic- to new-style.
Tracker <[E
Nick Guenther <[EMAIL PROTECTED]> added the comment:
Oh, okay. That's really confusing because I expect "in" to always return
a bool, but in the spirit of python there's no reason it should I guess.
__
Tracker <[EMAIL PROTECTED]>
&
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Running the interactive interpreter like that places the current
directory on sys.path, so it *is* doing an absolute import of your
pseudo email package. (If it didn't do that, your test would fail at the
"import foo" lin
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I spent an enlightening evening browsing through the source code for
weakref.proxy. The way that code works is to define every slot,
delegating to the proxied object to handle each call (wrapping and
unwrapping the proxied object as
New submission from Nick Coghlan <[EMAIL PROTECTED]>:
>From the discussion of issue 643841:
>>> class Demo:
... def __index__(self):
... return 1
...
>>> a = Demo()
>>> b = weakref.proxy(a)
>>> operator.index(a)
1
>>> operator.index(b
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
priority: -> normal
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2592>
__
___
Python-b
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Marking as easy - it should be possible to just look at what the code in
Objects\weakref.c is already doing for slots like tp_len and tp_int and
do the same thing for tp_index.
--
keywords:
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Georg Brandl applied Santiago's patch in rev. 54329, 54330
--
resolution: -> fixed
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bu
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
As of 2.5.1, a missing trailing newline no longer causes a Syntax Error,
making the second part of the caveat in the documentation unnecessary.
Changing to a documentation bug applicable to 2.5+.
--
assignee: -> geo
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I think the lowered priority got lost somewhere along the line.
--
priority: normal -> low
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyth
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Using relative imports within smtplib wouldn't have made any difference
in this case. Your dummy email package was the first one encountered on
sys.path, so the "import email.smtplib" line (which does an "import
emai
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
This is actually a pretty tough problem - fixing it would involve some
fairly subtle changes to the way imports from packages are handled.
Given that I'm of the opinion that permitting circular imports in a code
base is an extraord
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I should be able to review/commit this for the next alpha (looking into
it right now).
--
assignee: -> ncoghlan
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Test file added in rev 62351 (forgot to svn add it the first time around)
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Commited as rev 62350
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Yeah, it's actually still blowing up for me to. I have no idea what I
actually tested when I thought it was working in 2.6/3.0 - I must have
managed to sneak an extra carriage return into the test string. So
reverting back to mark
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Given that range() produced a list in the 2.x series (hence limited to
available memory), and xrange() uses int internally for its values (and
hence couldn't even cope with short ranges with values greater than
sys.maxint).
So my pr
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
It also isn't what range() and xrange() are used for now in 2.x. range()
returns an actual list, hence is limited to sequences that fit in a
reasonable amount of memory, and xrange() doesn't support values greater
than sys.maxi
1101 - 1200 of 6501 matches
Mail list logo
