[issue2610] string representation of range

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > In a world where ints and long ints have been unified the existence of > this error seems like a bug. > > I think the right thing would be to fix range_item and range_length so > they do not use Py_ssize_t for the length of the range. B

[issue992389] attribute error after non-from import

Torsten Bronger <[EMAIL PROTECTED]> added the comment: I have a very similar issue (maybe the same?) at the moment. Assume the follwing package structure: main.py package/ __init__.py [empty] moduleX.py moduleY.py main.py says: from package import moduleX moduleX.py says:

[issue2611] Extend buildbot web interface to allow for forced tests to be run on a slave in verbose mode.

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I think this will be fairly difficult to set up. If the clean buildstep had been executed, you would have to rerun configure and compile before you can run any tests. Also, how would you communicate what specific test you want to run? A "bui

[issue2604] doctest.DocTestCase fails when run repeatedly

James Henstridge <[EMAIL PROTECTED]> added the comment: Is repeating a test with the same TestCase instance ever safe? It'd be better to create a new instance and run that. If any of the variables in test.globs are changed by the test (e.g. appending to a list), then rerunning the test will not

[issue2612] file.tell() returns Long usually, Int if subclassed

Darryl Dixon <[EMAIL PROTECTED]> added the comment: Thanks Benjamin, that is a very interesting feature that I can't find documented anywhere. Is there perhaps a documentation bug that can arise from this? There are various places where the differences between old and new-style classes are docume

[issue2612] file.tell() returns Long usually, Int if subclassed

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: This is because y is a new-style class (because file is) and z is not. If the return type of new-style classe's len is not an int, Python tries to convert it, which is why that works for the first example. However, that conversion doesn't h

[issue2607] why is (default)dict so slow on tuples???

Andreas Eisele <[EMAIL PROTECTED]> added the comment: Sorry for not giving a good example in the first place. The problem seems to appear only in the presence of sufficiently many distinct tuples. Then I see performance that looks rather like O(n*n) Here is an example that shows the problem: >>>

[issue2612] file.tell() returns Long usually, Int if subclassed

New submission from Darryl Dixon <[EMAIL PROTECTED]>: Compare: >>> class y(file): ... def __init__(self, name): ... file.__init__(self, name) ... def __len__(self): ... self.seek(0, 2) ... return self.tell() ... >>> n = y('/tmp/longfile') >>> len(n) 364773376

[issue2610] string representation of range

Brad Miller <[EMAIL PROTECTED]> added the comment: Thanks for all of the help. Using range_item certainly simplified my job. Although I more than made up for it with all of the decref and error checking calls. One side effect of using range_item is that str(range(...)) is now subject to the

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Here is a new patch, all tests pass. - no warning for classic classes - added tests for -3 warnings I had to add two TPSLOT entries to the slodefs list; can you please check that this is correct (I wanted to reset tp_hash to NULL when _

[issue2611] Extend buildbot web interface to allow for forced tests to be run on a slave in verbose mode.

New submission from Trent Nelson <[EMAIL PROTECTED]>: It'd be nice if there was a facility to force a particular test to be re-run in verbose mode with the most recent build via the buildbot web interface. It would allow us to get a bit more information about what's going on when the buildbot

[issue2240] setitimer, getitimer wrapper

Changes by Trent Nelson <[EMAIL PROTECTED]>: -- nosy: +Trent.Nelson __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubsc

[issue2440] Issues with getargs_n() and PyNumber_Index.

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Thanks for fixing that. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Uns

[issue2440] Issues with getargs_n() and PyNumber_Index.

Trent Nelson <[EMAIL PROTECTED]> added the comment: Eek, so it does, thanks. Applied the following patch on a bunch of 32- bit/x64 systems, testing now, so far everything looks good... Index: abstract.c === --- abstract.c (revisio

[issue2256] Install failure of 2.6a1 on Windows XP without VS8 installed

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bug

[issue2440] Issues with getargs_n() and PyNumber_Index.

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Trent, that commit broke several tests (test_builtin for one) that relied on a floats not being interpreted as longs. -- nosy: +benjamin.peterson __ Tracker <[EMAIL PROTECTED]>

[issue2256] Install failure of 2.6a1 on Windows XP without VS8 installed

Jim Kleckner <[EMAIL PROTECTED]> added the comment: I hadn't seen any comment here that I should try it again until your question (that was why the ping). I did try it again and my application worked. Thanks! __ Tracker <[EMAIL PROTECTED]>

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Thanks for your quick answer. I'd like to know what can we do to push > this patch into upstream. Does the fact that the patch is posted in a > bug report (and not in a developer's mailing list) is slowing down the > reviewing process? No,

[issue1649238] potential clash with C++ in ceval.h

Changes by A.M. Kuchling <[EMAIL PROTECTED]>: -- keywords: +easy _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-list mailing list U

[issue2610] string representation of range

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I use Python in my CS1 and CS2 curriculum and I have a question. At this point, I would have almost stopped reading - the tracker is not a place for questions. I read on and then noticed that you have a patch also, not just a question :-)

[issue2610] string representation of range

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Thanks for the patch! You can avoid the compiler warning by casting to reprfunc like this: (reprfunc)range_str /* tp_str */ Also, some of the whitespace needs reformating. Please put a space between the parameters passed a function, and r

[issue2221] Py30a3: eval in threaded code raises SystemError

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: I think this is good enough: you should not invoke python code with a pending exception set (PyErr_Occurred()). __ Tracker <[EMAIL PROTECTED]> __

[issue2603] Make range __eq__ work

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Including __hash__ in this patch. Alexander, thanks; that could worked perfectly. Added file: http://bugs.python.org/file10001/range_eq3.patch __ Tracker <[EMAIL PROTECTED]>

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

Sérgio Durigan Júnior <[EMAIL PROTECTED]> added the comment: Hi Martin, Thanks for your quick answer. I'd like to know what can we do to push this patch into upstream. Does the fact that the patch is posted in a bug report (and not in a developer's mailing list) is slowing down the reviewing pro

[issue2610] string representation of range

New submission from Brad Miller <[EMAIL PROTECTED]>: I use Python in my CS1 and CS2 curriculum and I have a question. As I've been using the Python 3.0 alphas one of the things that I am bothered by is that I cannot see the sequence produced by range without introducing students to the list() fun

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Thu, Apr 10, 2008 at 3:48 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: Maybe as the first step we could get rid of the size sign abuse in long integer objects. I would suggest reserving a bit in the first (or last) digit to carry

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: asserts nuked. r62271 and r62272 __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing

[issue2607] why is (default)dict so slow on tuples???

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: Questions about relative performance should be directed to comp.lang.python. Since no bug or suspect behavior was reported, closing as not-a-bug. -- nosy: +rhettinger status: open -> closed __ Tra

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Please do get rid of the asserts. Regarding signed sizes, it's a historic accident (copied from Unix system calls which tended to use plain ints or longs in the olden days), but it may not be impossible to fix -- we've fixed other things th

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: The asserts can go. I left them in figuring a crashing interpreter on a debug build in someones sandbox or on a buildbox would get more attention than a SystemError being raised. I doubt that is a worthy assumption on my part. Both a cras

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I'd like to know the status of this issue. I'm having the same problems > here with PPC64, and the patch that Bob Atkins has sent works fine for > me too. Would you intend to apply this patch in upstream? > > Thanks in advance. It's diffi

[issue2607] why is (default)dict so slow on tuples???

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file/a.py __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list

[issue2607] why is (default)dict so slow on tuples???

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I cannot reproduce this. The attached script for me gives for 1M iterations a total time of 0.8s, on 3.2GHz Pentium 4. -- nosy: +loewis resolution: -> works for me __ Tracker <[EMAIL PROTECTED]>

[issue2606] trace module crashes due to using wrong sort idiom

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I've further simplified the code by eliminating the local variables, and committed that as r62270. -- nosy: +loewis resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]>

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

Sérgio Durigan Júnior <[EMAIL PROTECTED]> added the comment: Hi, I'd like to know the status of this issue. I'm having the same problems here with PPC64, and the patch that Bob Atkins has sent works fine for me too. Would you intend to apply this patch in upstream? Thanks in advance. -

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Greg, any reason why you kept the assert()? IMO having the ValueError even in debug mode is better. __ Tracker <[EMAIL PROTECTED]> __ __

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Justin Ferguson <[EMAIL PROTECTED]> added the comment: The use of signed integers in Python is (imho) the single largest threat to the security of the interpreter. I'm probably preaching to the choir there though. I really dislike have to return values and indicate error in the return value, it

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Changes by David Remahl <[EMAIL PROTECTED]>: -- nosy: +chmod007 __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe

[issue2587] PyString_FromStringAndSize() to be considered unsafe

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Wed, Apr 9, 2008 at 8:18 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > [*sigh* i wish we didn't use a signed size type all over the place] > > What would you use for error returns then? > res == (size_t)-1 or res == 0 && Py

[issue2586] Integer signedness bugs in zlib modules

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Thu, Apr 10, 2008 at 1:17 PM, David Remahl <[EMAIL PROTECTED]> wrote: > I submit that a check for negative values (non-assert-based) should be > added to PyString_FromStringAndSize(). See issue2587 and r62262. ___

[issue2586] Integer signedness bugs in zlib modules

David Remahl <[EMAIL PROTECTED]> added the comment: I submit that a check for negative values (non-assert-based) should be added to PyString_FromStringAndSize(). This API is called from many, many places, and in several cases the operand could probably be negative. It should raise an overflow

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Let's try to have this resolved before the next release. Also let's try not to accidentally merge the 2.6 changes related to this issue into 3.0. :-) -- priority: high -> release blocker __ Tracker

[issue2609] Tests fail if ./@test is not writeable

New submission from Alexander Belopolsky <[EMAIL PROTECTED]>: If @test file is not writable in the current directory, test_support.TESTFN is changed to '/tmp/@test', but several tests fail if TESTFN is an absolute path: $ mkdir @test $ make test .. 4 tests failed: test_import test_site test_

[issue2608] manpages for sphinx-build & sphinx-quickstart

Changes by Mikhail Gusarov <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file9998/sphinx-quickstart.1 __ Tracker <[EMAIL PROTECTED]> __ ___ Py

[issue2608] manpages for sphinx-build & sphinx-quickstart

New submission from Mikhail Gusarov <[EMAIL PROTECTED]>: I just created manpages for sphinx-build and sphinx-quickstart as a part of Sphinx debianization. Feel free to use/change/improve - I'm releasing them under BSD license, matching rest of Sphinx. -- assignee: georg.brandl compone

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Note: some more tests also fail: test_descr, test_quopri, test_set __ Tracker <[EMAIL PROTECTED]> __ ___

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Hi Amaury, thanks for your work on this. I applied your patch and looked at the code but there seem to be some issues left still. (1) I don't think you need to add a warning to classic classes that define __eq__ without __hash__ -- these ar

[issue2607] why is (default)dict so slow on tuples???

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: My guess is that this is due to the fact that strings cache their hash values while tuples don't. IIRC, caching tuple's hash values has been proposed and rejected some time ago. Furthermore, dict lookups are heavily optimized for the c

[issue2440] Issues with getargs_n() and PyNumber_Index.

Trent Nelson <[EMAIL PROTECTED]> added the comment: Committed patch in r62269. I'll raise a separate tracker issue for PyLong_AsSsize_t as it isn't related to this issue. -- assignee: -> Trent.Nelson keywords: +64bit resolution: -> fixed status: open -> closed title: Issues with geta

[issue2606] trace module crashes due to using wrong sort idiom

Guilherme Polo <[EMAIL PROTECTED]> added the comment: I've changed them to sorted(obj.keys()) -- keywords: +patch nosy: +gpolo Added file: http://bugs.python.org/file9996/issue_2606.diff __ Tracker <[EMAIL PROTECTED]> __

[issue2607] why is (default)dict so slow on tuples???

New submission from Andreas Eisele <[EMAIL PROTECTED]>: I need to count pairs of strings, and I use a defaultdict in a construct like count[a,b] += 1 I am able to count 50K items per second on a very fast machine, which is way too slow for my application. If I count complete strings like cou

[issue1297] pyconfig.h not compatible with MS VC++ Express Edition

Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: On Apr 9, 2008, at 3:07 PM, Martin v. Löwis wrote: > Fred, can you remember what the rationale was? No; sorry. I didn't even remember that I'd ever built Python on Windows. Some things I've blocked out. __

[issue2603] Make range __eq__ work

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Thu, Apr 10, 2008 at 3:16 AM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote: > > And, a __hash__ method should be added. > See issue2268 for a slice.__hash__ implementation which should work for range as well.

[issue1049] socket.socket.getsockname() has inconsistent UNIX/Windows behavior

Changes by Trent Nelson <[EMAIL PROTECTED]>: -- nosy: +Trent.Nelson __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubsc

[issue2606] trace module crashes due to using wrong sort idiom

New submission from Mark Summerfield <[EMAIL PROTECTED]>: In Py30a4's trace.py there is this: calls = self.calledfuncs.keys() calls.sort() which causes: AttributeError: 'dict_keys' object has no attribute 'sort' There are two other occurrences of this idiom in trace.py (just search

[issue2605] Descriptor instance attributes not interpreted consistently

New submission from Piet Delport <[EMAIL PROTECTED]>: Short version: __get__/__set__/__delete__ attributes on descriptor objects (as opposed to their types) are treated inconsistently as part of the descriptor protocol: the documentation and support code includes them; the core implementation

[issue2603] Make range __eq__ work

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: And, a __hash__ method should be added. -- nosy: +amaury.forgeotdarc __ Tracker <[EMAIL PROTECTED]> __ _