Robert Kern added the comment:
This is on an Intel Core 2 Duo running OS X 10.5.6. __i386 is defined.
--
___
Python tracker
<http://bugs.python.org/issue4
Robert Kern added the comment:
John, -Z does not appear to help:
$ sudo dtrace -Z -n 'pid$target::PyEval_EvalFrameEx:entry' -c python
dtrace: description 'pid$target::PyEval_EvalFrameEx:entry' matched 0 probes
I'm not sure how that would help. If I'm readin
Robert Kern added the comment:
Skip> Perhaps not quite on-topic for this tracker item, but it bugs me
that the
Skip> mere compilation of a D script requires root privileges.
It doesn't. "dtrace -G" and "dtrace -h" (the only "mere compilation"
that dtrac
Robert Kern added the comment:
Ah, duh, of course. The problem here with PyEval_EvalFrameEx is that I
don't have ceval.o on the command line *at all* since OS X's dtrace
doesn't support -G. It doesn't appear to accept ceval.o with -h, either,
so I suppose that adding t
Robert Kern added the comment:
Hmm, wait a second. Never mind. The Solaris patches don't have ceval.o
on the line for compiling phelper.o, either.
If dtrace needs to resolve the symbol PyEval_EvalFrameEx in an object
file, how does it know to look in ceval.o for the phelper.d? WITH_DTRA
Robert Kern added the comment:
Is there any interest in my expanding the list of probes? Ruby has quite
a few more than function-entry and function-return, to give some
examples of what is possible:
http://dev.joyent.com/projects/ruby-dtrace/wiki/Ruby+DTrace+probes+and+arguments
I think that
Robert Kern added the comment:
We could probably merge Apple's and Sun's probes without too much
trouble. Apple simply extended function-entry to include the argcount in
addition to Sun's (filename, funcname, lineno) arguments. We could use
Apple's probe while retaining co
Robert Kern added the comment:
James McIlree from Apple has informed me on dtrace-discuss that ustack
helpers cannot currently be built on OS X. Bummer.
--
___
Python tracker
<http://bugs.python.org/issue4
Robert Kern added the comment:
Ah, I misread the Apple function-return probe code. Its extra argument
is the type name of the return object or "error" if an exception was
raised, not the returned object itself. Could be useful.
--
___
Pyth
Robert Collins added the comment:
On Sat, 2009-04-25 at 23:17 +, Michael Foord wrote:
> Michael Foord added the comment:
>
> Proper patch and proper issue this time! Not my evening.
>
> --
> Added file: http://bugs.python.org/file13787/unittest-no-exit.patch
D
New submission from Robert Schuppenies :
Running this code:
>>> import weakref
>>> class C: pass
...
>>> ws = weakref.WeakSet([C])
>>> if ws == 1:
... print(1)
...
gives me the following exception:
Traceback (most recent call last):
File "&quo
Robert Collins added the comment:
Maybe I'm missing something, but isn't the offset parameter just another
way of spelling
buffer(input, offset)?
I like the avoiding of copying, just wondering if having a magic
parameter to get a tuple is really better than (say)
re
Robert Schuppenies added the comment:
Here is a patch which will return False instead of TypeError. This is
the same behavior a normal set has. Two things though.
1. I don't know wether the 'import _abcoll' statement somehow influences
the bootstrap in one way or the other
Robert Collins added the comment:
Well, I think its relatively uncommon to be doing such a loop with a
static buffer anyway - often you'll instead be reading from disk or a
network stream; if we could make those cases simpler and avoid copying
that would be great.
Anyhow, no strong opi
Robert Schuppenies added the comment:
Sounds right to me. Here is another patch plus tests.
Going through the other tests, I adapted two more tests to actually test
WeakSet. Also, I found the following one and think it is a copy&paste
from test_set which is not useful for test_weakset. Sh
Changes by Robert Schuppenies :
Removed file: http://bugs.python.org/file13955/_weakrefset.patch
___
Python tracker
<http://bugs.python.org/issue5964>
___
___
Python-bug
Changes by Robert Schuppenies :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue5964>
___
___
Python-bugs-list mai
New submission from Robert Lehmann :
There are a few errors in the ctypes documentation covering function
calls using the example of `libc.printf`. It's basically just typos but
they are really confusing when trying to understand the examples.
Patch to trunk is attached. Corrections s
Robert Schuppenies added the comment:
The test passes on my machine, but a quick review would definitely be
nice :)
--
___
Python tracker
<http://bugs.python.org/issue5
Robert Schuppenies added the comment:
If that is the right behavior then yes. Is this documented somewhere?
--
___
Python tracker
<http://bugs.python.org/issue5
Robert Schuppenies added the comment:
I am now a bit confused about the semantics of __eq__ for WeakSets. Is a
WeakSet only equal to another WeakSet with the same elements or to any
iterable with the same elements, e.g. list? Because this is how I read
the current implementation. If it is the
Robert Schuppenies added the comment:
Maybe because I take the doc too specfic. It says "A rich comparison
method may return the singleton NotImplemented if it does not implement
the operation for a given pair of arguments."
I see the type check of the 'other' object as
Robert Schuppenies added the comment:
Fixed in r72751.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue5964>
___
___
Python-bugs-lis
Robert Cronk added the comment:
I have had this problem with 2.6.1 on windows from multiple _threads_
instead of multiple processes. Is that not supported either? If not,
what is the workaround for logging from multiple threads? Shouldn't it
be easy to use a semaphore within the lo
Robert Cronk added the comment:
I will go through the code and make sure I am not mistaken, but I do
believe I have a single process, multiple threads, and only one handler
for this file and I'm getting the same types of error messages shown on
this page. I'm probably doing somet
Robert Lehmann added the comment:
This only seems to be the case with the C implementation of json (_json).
>>> json.encoder.c_make_encoder = None
>>> json.dumps(OrderedDict(items))
'{"one": 1, "two": 2, "three": 3, "four":
Robert Cronk added the comment:
I have a small script that reproduces the problem. I couldn't
reproduce it until I added some os.system() calls in the threads that
were logging. Here's the output using python 2.6.1:
Traceback (most recent call last):
File "C:\Pytho
Robert Cronk added the comment:
P.S. The above script and failure is running on winxp sp3. Also, if
you comment out the two os.system() calls, it works just fine. They
seem like they should be unrelated to the logging though. You'll also
see some errors about access to the blah.txt
Robert Cronk added the comment:
>>> import sys
>>> print sys.version
2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit (Intel)]
I have seen this behavior in older versions as well. Interesting to
see it fai
Robert Cronk added the comment:
P.S. Frans - It's good to get these other data points from you. So
this is reproducible from another person and on different versions of
python AND on different platforms! I wasn't expecting that at all.
Thanks Frans.
Is there a way we can reope
Robert Cronk added the comment:
Thanks Lowell - good information. You have many more versions of
Python "laying around" than I do. ;)
--
___
Python tracker
<http://bugs.python.
Robert Cronk added the comment:
I just upgraded to 2.6.2 windows from python.org and it fails as well:
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32
I hope Vinay can track this down in case it's a race condition that's
just moving arou
Robert Cronk added the comment:
I didn't care about the os.system() call contention because that's what
caused the logging problem and that blah.txt file contention should not
cause logging to fail.
I also had the join calls originally but took them out to simplify the
code since
Robert Cronk added the comment:
Thanks Vinay. I ran the newest revised script with virus protection
turned off and got the same failures as before (see console output
below).
If you comment out the os.system() calls, everything works just fine.
Uncomment them and logging breaks.
The
Robert Cronk added the comment:
I'll thoroughly look through every piece of software that's running to
see if I can turn eveything off that might be causing the problem.
Were you able to reproduce the problem with my original script? I'm
sure you have all of your virus/searc
Robert Cronk added the comment:
I turned off anti-virus again as well as file indexing and google
desktop too and still got the errors when I disabled the locks around
the os.system() calls.
Vinay - when the locks aren't around the os.system() calls, do you get
the rotating log errors?
Robert Cronk added the comment:
Vinay - that's great news! Are you going to create a new bug for this issue
with a proper title? It would seem to me that the fix for this would be to put
locks internal to the os.system() call around where it spawns cmd so multiple
spawns don&#x
Robert Cronk added the comment:
I changed the script to use subprocess (attached file) and got the same
rollover errors as before. I had to change cd and del to be cd.bat and
del.bat which contained cd %1 and del %1 respectively since it appears
subprocess can't run internal commands
Robert Cronk added the comment:
Could this problem be associated with issue4749? It was found that
something goes wrong when two cmd children processes are spawned from
different threads, when the first exits, it is closing file handles
shared with the first (or something like that) and
Robert Cronk added the comment:
I found Issue1425127 which may be a different symptom of this core
problem. I suggested that we create a bug that documents the core
problem here as described by Vinay in msg89174 and links to these two
bugs (along with any others we find) as examples of the
Robert Cronk added the comment:
One more possibly related bug is issue2320 where subprocesses are
spawned from multiple threads. They found an interesting workaround
that I found seems to help our problem too: "on Windows, if close_fds
is true then no handles will be inherited by the
Robert Cronk added the comment:
Could this problem be associated with issue4749? It was found that
something goes wrong when two cmd children processes are spawned from
different threads, when the first exits, it is closing file handles
shared with the first (or something like that) and
Robert Pyle added the comment:
On Jul 8, 2010, at 6:52 PM, Mark Lawrence wrote:
>
> Mark Lawrence added the comment:
>
> Robert, could you provide a patch for this?
>
> --
> nosy: +BreamoreBoy
> stage: -> needs pa
Changes by Robert Cronk :
--
nosy: +rcronk
___
Python tracker
<http://bugs.python.org/issue1652>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Robert Buckley :
In both Python 2.7 and 3.1 the IDLE is unable to handle example 4.1 in the
tutorial (if statements). Works OK with the command line shell, but not the
IDLE shell.
--
messages: 112930
nosy: drbuckle
priority: normal
severity: normal
status: open
Robert Buckley added the comment:
See attached file
--
Added file: http://bugs.python.org/file18411/ISSUE_9519.rtf
___
Python tracker
<http://bugs.python.org/issue9
Robert Buckley added the comment:
Yes, thank you. Using BACKSPACE to unindent works when I am using an indented
block inside a first or subsequent indented block, e.g., inside a simple
funtion. That feature does not work, as illustrated in example 4.1, when using
IDLE.
--
status
Robert Buckley added the comment:
I can say that more clearly. The backspace feature for ending a block does not
work in IDLE when attempting to end a block that had no indentation. Example:
>>> if a < 4:
a = 0 # Assume this is end of the 'if' b
New submission from Robert Xiao:
bytes.fromhex ignores space characters now (yay!) but still barfs if fed
newlines or tabs:
>>> bytes.fromhex('ab\ncd')
Traceback (most recent call last):
File "", line 1, in
ValueError: non-hexadecimal number found i
Robert Xiao added the comment:
I used Py_ISSPACE, which uses the .strip() default charset - I think this is a
reasonable choice. We don't have to go crazy and support all the Unicode spaces.
--
___
Python tracker
<http://bugs.python.org/is
Robert Xiao added the comment:
Terry, can you elaborate what you mean by a tradeoff? I feel like such a patch
makes .fromhex more consistent with other string methods like .split() and
.strip() which implicitly consider all whitespace equivalent.
Martin, I've updated the patch to in
Robert Xiao added the comment:
Sorry, I should have clarified that these methods consider *ASCII whitespace*
equivalent - just like my proposed patch.
--
___
Python tracker
<http://bugs.python.org/issue28
Robert Xiao added the comment:
I see your point, Nick. Can I offer a counterpoint?
Most of the string parsers operate only on relatively short inputs, like
numbers. Numbers in particular are rarely written with inner spaces, so it
makes sense not to ignore internal whitespaces.
On the other
Robert Xiao added the comment:
OK, I've attached a new version of the patch with the requested documentation
changes (versionchanged and whatsnew).
--
Added file: http://bugs.python.org/file45966/fromhex.patch
___
Python tracker
Robert Xiao added the comment:
New patch with proper line lengths in documentation.
--
Added file: http://bugs.python.org/file45967/fromhex.patch
___
Python tracker
<http://bugs.python.org/issue28
Robert Collins added the comment:
A few thoughts;
usedforsecurity=xxx seems awkward: I wouldn't want, as a user of hashlib, to
have to put that in literally every use I make of it.
If I understand the situation correctly, the goal is for both linters, and at
runtime, identification o
Robert Collins added the comment:
@doug - I don't see how a separate fips module *wouldn't* solve it:
- code that uses md5 in security contexts wouldn't be able to call it from the
fips module, which is the needed outcome
- code that uses md5 and isn't fips compliant wou
Robert Collins added the comment:
Thanks for proposing this. I really don't want to add new assertions to
unittest, and I certainly don't want to add narrow usage ones like this, nor
ones that are confusingly named (this has nothing to do with files, but 'close'
is a verb
Robert Collins added the comment:
So its a feature of mock that it can mock a module that doesn't exist. And the
semantics of the import system are designed to be very cheap when a module is
already imported - so when 'patchbug.a' is in sys.modules, import will
correctly return
Robert Collins added the comment:
I'm fine with these as a mixin - they are all very generic and unambiguously
named. I'd marginally prefer the opt-in mixin over adding them to the base
class.
Ideally they'd be matchers, but since I haven't ported that upstream yet, th
Robert Collins added the comment:
Future direction: hamcrest style matchers. You can read more about them in the
context of unittest
https://rbtcollins.wordpress.com/2010/05/10/maintainable-pyunit-test-suites/
and http://testtools.readthedocs.io/en/latest/for-test-authors.html#matchers
Robert Haschke added the comment:
Uploaded a "hg diff" against the recent 2.7 branch of the source repo.
--
Added file: http://bugs.python.org/file43414/minidom.insertBefore.patch
___
Python tracker
<http://bugs.python.o
Robert Haschke added the comment:
I uploaded a simple example to illustrate the tremendous performance boost.
Obviously, the example exploits the caching improvement as much as possible:
The code assembles a XML document by inserting new nodes before the last one...
These are the timing
Robert Haschke added the comment:
Indeed there is a small slow down for insertion at the beginning.
However, this is simply due to the extra function _index() and thus linear in
the number of insertion operations.
My patch essentially boosts insertions before /any fixed/ node.
If this
Robert Haschke added the comment:
I don't see how to further minimize the checks - all of them are required. I
think, the most common uses cases to create a document are appendChild(), which
is not affected, and insertBefore() using the same refChild for a while. In
that case, the patch
Robert Collins added the comment:
There are two related things here.
Firstly, the generator's body will run without the patch (because the wrapping
function has
try:
return decorated(..)
finally:
unpwatch()
Secondly, the wrapping function is itself not a generator, and anything
Robert Collins added the comment:
Once fixed in CPython, we'll put the backport in mock, for folk using older
Python's.
--
versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.o
Robert Haschke added the comment:
Thank you very much for further improving the code. As I understand it, the
trick is to use temporary variables to minimize access time. Learned something
new.
I adapted your patch to python 2.7 again. Now, in python3, the new code is even
faster than the
Robert Collins added the comment:
Chris, I suggested altering assertAlmostEqual in
http://bugs.python.org/issue27198#msg267187 :) - I took your agreement with
that as a good thing and didn't reply because I had nothing more to add.
IMO the status of this issue is as you indicated: you n
Robert Collins added the comment:
hmm, can you give me a change to page this in? I'm pretty sure I saw breakage
in external libraries prompting me to add the test and fix. I'd rather not
recause that.
--
___
Python tracker
<http://bu
New submission from Robert Pierce:
cPickle fails on large objects, throwing a SystemError exception which is
cryptic.
The issue was fixed for pickle in python 3 back in 2011
(http://bugs.python.org/issue11564), but never addressed in 2.7. It seems to
be a recurring complaint (e.g., http
New submission from Robert Collins:
the docs (http://docs.python.org/3.x/library/io.html#io.FileIO) do not document
closefd, and AFAICT it isn't possible to tell if closefd is set after the
object is created. Specifically it does not show up in the repr().
>>> import sys
New submission from Robert Collins:
The io library rejects unbuffered text I/O, but this is not documented - and in
fact can be manually worked around:
binstdout = io.open(sys.stdout.fileno(), 'wt', 0)
sys.stdout = io.TextIOWrapper(binstdout, encoding=sys.stdout.encoding)
Robert Collins added the comment:
Huh, I didn't realise idna would retain data! But that will still be within the
TextIOWrapper itself, right?
And a stream opened 'wt' cannot be read from anyway, so the read1 limitation
New submission from Robert Tasarz:
Minimal example:
>>> import os
>>> somekey = 'random'
>>> try:
... os.environ[somekey]
... except KeyError as e:
... print(repr(e))
... somekey == e.args[0]
...
KeyError(b'random',)
False
Tested i
Changes by Robert Tasarz :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue17702>
___
___
Python-bugs-list mailing list
Unsubscri
Robert Collins added the comment:
FWIW I'd really like to be reducing the TestCase API not extending it -
particularly since there are lots of good convenient ways of doing this already
(not least mock.patch/mock.patch.object).
So I'm -0.5 on adding this, as I don't see it add
Robert Collins added the comment:
Closing as the fix to the test suite is applied.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
New submission from Robert Collins:
cpython.hg$ make patchcheck
./python ./Tools/scripts/patchcheck.py
Getting the list of files that have been added/changed ... 448 files
Fixing whitespace ... 0 files
Fixing C file whitespace ... 5 files:
Include/patchlevel.h
Modules/_ctypes/callbacks.c
Robert Collins added the comment:
FWIW testtools rejects test suites with duplicate test ids; I'm considering
adding that feature into unittest itself. We'd need an option to make it warn
rather than error I think, but if we did that we wouldn't need a separate
script at all.
Changes by Robert Collins :
Removed file: http://bugs.python.org/file36716/issue22457.diff
___
Python tracker
<http://bugs.python.org/issue22457>
___
___
Python-bug
Robert Collins added the comment:
Updated patch.
--
Added file: http://bugs.python.org/file36973/issue22457.patch
___
Python tracker
<http://bugs.python.org/issue22
Changes by Robert Collins :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue17401>
___
___
Python-bugs-list
Changes by Robert Collins :
Added file: http://bugs.python.org/file36974/issue7559.patch
___
Python tracker
<http://bugs.python.org/issue7559>
___
___
Python-bugs-list m
Robert Collins added the comment:
Patch polished up and updated - ready for review IMO.
--
___
Python tracker
<http://bugs.python.org/issue7559>
___
___
Python-bug
Robert Collins added the comment:
I think its worth a note that the stdio streams are constructed specially, even
with the repr improvements.
--
nosy: +rbcollins
___
Python tracker
<http://bugs.python.org/issue22
Robert Collins added the comment:
Yeah thats nicer. I'll apply that later unless you can.
--
___
Python tracker
<http://bugs.python.org/issue17401>
___
___
Robert Collins added the comment:
Showing it only when False would have higher cognitive load. Showing it always
is simple and clear.
--
___
Python tracker
<http://bugs.python.org/issue17
Robert Collins added the comment:
A few thoughts.
Adding a new public symbol seems inappropriate here: this is a performance
issue that is well predictable and we should cater for that (given difflibs
current performance).
I'll note in passing that both bzr and hg have much h
Robert Collins added the comment:
Just to note that unittest2 tip (unreleased)had michaels proposed fix, which is
different to that here. I'm going to back that out before doing a release,
because they should be harmonisious.
--
nosy: +rbco
Robert Collins added the comment:
My take on this, FWIW, is that any methods in the under-test API - setUp,
tearDown, test_* and anything registered via addCleanup should all support the
same protocol as much as possible, whatever it is.
That is, raising a skip in setUp should skip the test
Robert Collins added the comment:
I'd argue for
- An error - its not covered by the decorator.
- An error - the last two are not covered by the decorator.
- An error - the last two are not covered by the decorator.
- An error - the exception isn't a 'failure' [today - we
Robert Collins added the comment:
Oh, I got a profile from the test case for my own interest.
6615 seconds ..
some highlights that jumped out at me
200010.1270.000 6610.0250.330 difflib.py:868(compare)
which means we're basically using ndiff, which is cubic rather
Robert Collins added the comment:
Thanks for the review, updated patch here - I'll let this sit for a day or two
for more comments then commit it Monday.
--
Added file: http://bugs.python.org/file37002/issue7559.patch
___
Python tracker
Robert Collins added the comment:
I've updated the patch to try and address the niggling clarity issues from the
review. Please let me know what you think (and if I hear nothing I'll commit it
as-is since the review was still ok).
--
Added file: http://bugs.python.org
Robert Collins added the comment:
assertions in setUp are fine IMO. But here's the thing. WHat should this code
do?
class Demo(unittest.TestCase):
def setUp(self):
raise Exception('hi')
def test_normal(self):
# this should NOT be covered by
Robert Collins added the comment:
runTest is part of the current API. I think if we're going to hide it we should
do so as part of a deprecation path. (I'm +1 on hiding it).
--
___
Python tracker
<http://bugs.python.o
Changes by Robert Collins :
--
nosy: +rbcollins
___
Python tracker
<http://bugs.python.org/issue21820>
___
___
Python-bugs-list mailing list
Unsubscribe:
Robert Collins added the comment:
Constructing test case objects directly is part of the protocol, and its needed
for framework and extension authors.
I've seen folk use runTest, but rarely enough that I think we could deprecate
it. My argument is that while its supported we should be
New submission from Robert Collins:
found while backporting unittest fixes.
The current test fails like so:
==
FAIL: testAssertEqualSingleLine (unittest2.test.test_case.Test_TestCase
501 - 600 of 1080 matches
Mail list logo
