[issue3336] datetime weekday() function

Changes by Georg Brandl <[EMAIL PROTECTED]>: -- resolution: -> wont fix status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue2271] msi installs to the incorrect location (C drive)

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I'd be happy to provide any more information that can help get this > resolved. Contribution of a patch would be the best way to resolve this quickly. ___ Python tracker <[EMAIL PROTECTED]>

[issue3371] 2to3 fails in Python 2.6

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Reverting r64742 would have had the same effect (IMO, it shouldn't have been checked in in the first place, as it causes the test suite to fail). -- nosy: +loewis ___ Python tracker <[EMAIL PROTEC

[issue3371] 2to3 fails in Python 2.6

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: That revision caused the test suite to fail because it caused to be actually run. :) ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3362] locale.getpreferredencoding() gives bus error on Mac OS X 10.4.11 PPC

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: The Python debugger (pdb) won't help here; you'ld have to use the system debugger (gdb). Please add the line printf("The value of name is %p\n", name); printf("It points to '%s'\n", name); right before the call to CFStringGetCStringPtr

[issue3371] 2to3 fails in Python 2.6

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > That revision caused the test suite to fail because it caused to be > actually run. :) Right - but now you've disabled the test again, when the original introduction of the resource lib2to3 already had the (desirable) effect of disabling t

[issue3088] test_multiprocessing hangs intermittently on POSIX platforms

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment: Here's the 'make' output. What's strange is that moving _multiprocessing{_failed,}.so, the import works just fine. building '_multiprocessing' extension creating build/temp.linux-i686-3.0/home/barry/projects/python/python30/Modules/_multipr

[issue3371] 2to3 fails in Python 2.6

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: > IOW, this is a duplicate of issue2969. and so it is. Well, it's disabled now, so no point in arguing how. -- resolution: -> duplicate status: open -> closed ___ Python tracker <[EMAIL PROTEC

[issue2969] Test_imports fails in 2.6

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- priority: -> deferred blocker ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Pytho

[issue3338] cPickle segfault with deep recursion

Darryl Dixon <[EMAIL PROTECTED]> added the comment: Hmm, looks like this dup's 2702... Funny how two people find the same thing within a short window of each other *sighs* so looks like it's probably fixed. I'll test /trunk against the failing testcase below and make sure all is OK. D _

[issue3316] Proposal for fix_urllib

Nick Edds <[EMAIL PROTECTED]> added the comment: Here is a working version with tests. I believe it has all the desired functionality, but correct me if I'm wrong Brett. Also, I did not model MAPPING as suggested by Collin because order was important in generating tests, so I didn't think using a

[issue3373] sys recursion limit a lot shorter on trunk?

New submission from Darryl Dixon <[EMAIL PROTECTED]>: The system recursion limit seems to be wildly different in its behaviour on 2.6/trunk versus, for example, 2.5 or 2.4, EG: On Python 2.4: Python 2.4.3 (#1, Dec 11 2006, 11:38:52) [GCC 4.1.1 20061130 (Red Hat 4.1.1-43)] on linux2 Type "help",

[issue3338] cPickle segfault with deep recursion

Darryl Dixon <[EMAIL PROTECTED]> added the comment: No, I've just tested /trunk, including r64595, and the Segmentation fault is still present, eg: Python 2.6b1+ (trunk:64998, Jul 16 2008, 15:50:22) [GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2 Type "help", "copyright", "credits" or "licens

[issue3373] sys recursion limit a lot shorter on trunk?

Brett Cannon <[EMAIL PROTECTED]> added the comment: A lot of crashers were fixed for 2.6 where the recursion limit was not being used at all. That is probably what you are seeing. -- nosy: +brett.cannon ___ Python tracker <[EMAIL PROTECTED]>

[issue2702] pickling of large recursive structures crashes cPickle

Darryl Dixon <[EMAIL PROTECTED]> added the comment: Please check issue #3338 for a dup of this issue with a testcase that continues to fail after the application of r64595 -- nosy: +esrever_otua ___ Python tracker <[EMAIL PROTECTED]>

[issue3373] sys recursion limit a lot shorter on trunk?

Darryl Dixon <[EMAIL PROTECTED]> added the comment: Hmmm, I'm not certain I agree; on 2.4/2.5 doing rec(999) hits the recursion limit, as expected (makes sense that there would be an item or two on the stack prior to the immediate call to rec() ). This looks more like the interpreter is adding 4x

[issue3316] Proposal for fix_urllib

Brett Cannon <[EMAIL PROTECTED]> added the comment: I got your patch and it looks good overall. I made some style changes and upped the code reuse in some places. I am running the test suite now before I commit. -- status: open -> pending ___ Python t

[issue3359] add 'rbU' mode to open()

anatoly techtonik <[EMAIL PROTECTED]> added the comment: That's weird and the worst is that it is not documented. Manual says: "If Python is built without universal newline support a mode with 'U' is the same as normal text mode." but no information about what is "normal text mode" behaviour.

[issue3316] Proposal for fix_urllib

Brett Cannon <[EMAIL PROTECTED]> added the comment: r65002 has the patch. Thanks, Nick! -- resolution: -> accepted status: pending -> closed ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3373] sys recursion limit a lot shorter on trunk?

Brett Cannon <[EMAIL PROTECTED]> added the comment: Well, probably the best way to find out would be to run under gdb and see who is incrementing the recursion count. ___ Python tracker <[EMAIL PROTECTED]> ___

<    1   2