[ python-Bugs-1465093 ] Error with 2.5a1 MSI installer
Bugs item #1465093, was opened at 2006-04-05 17:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465093&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Martin v. Löwis (loewis) Summary: Error with 2.5a1 MSI installer Initial Comment: Installing 2.5a1 on Windows XP Pro SP2. I changed the install directory to D:\Apps\Python25, and selected "compile all modules" from the advanced options screen. Everything else is as standard. The install stopped with a message "There is a problem with ths Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor." This was right after the compile of all modules. There's plenty of free disk space on the machine. Rerunning without the "compile all modules" selection worked fine. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-07 12:03 Message: Logged In: YES user_id=21627 Thanks for the report. This is fixed in r43719. -- Comment By: Paul Moore (pmoore) Date: 2006-04-05 19:15 Message: Logged In: YES user_id=113328 Another data point - the pywin32 binary installer for 2.5 also fails, with an error saying that the preinstall script couldn't run. In both cases, it's an installer trying to run a Python script. I did a *very* quick test, and running scripts from the command line does work OK... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465093&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1463043 ] test_minidom.py fails for Python-2.4.3 on SUSE 9.3
Bugs item #1463043, was opened at 2006-04-02 15:03
Message generated for change (Comment added) made by rptownsend
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Martin v. Löwis (loewis)
Summary: test_minidom.py fails for Python-2.4.3 on SUSE 9.3
Initial Comment:
I built Python-2.4.3 from source on SUSE 9.3 and get
the following error for test_minidom.py
/usr/local/src/Python-2.4.3: ./python
Lib/test/test_minidom.py
Failed Test
Test Failed: testAltNewline
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 427, in
testAltNewline
confirm(domstr == str.replace("\n", "\r\n"))
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Failed testEncodings - encoding EURO SIGN
Test Failed: testEncodings
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 891, in
testEncodings
"testEncodings - encoding EURO SIGN")
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Failed After replaceChild()
Test Failed: testPatch1094164
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 1137, in
testPatch1094164
confirm(e.parentNode is elem, "After replaceChild()")
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Failed Test
Test Failed: testWriteXML
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 420, in
testWriteXML
confirm(str == domstr)
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Check for failures in these tests:
testAltNewline
testEncodings
testPatch1094164
testWriteXML
--
>Comment By: Richard Townsend (rptownsend)
Date: 2006-04-07 11:07
Message:
Logged In: YES
user_id=200117
I added a few print statements to the tests - see attached
file py_243.txt for the results while running on Python-
2.4.3
--
Comment By: Richard Townsend (rptownsend)
Date: 2006-04-06 13:31
Message:
Logged In: YES
user_id=200117
Interestingly, the error doesn't occur with Python-2.5a1
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-04 07:27
Message:
Logged In: YES
user_id=33168
Martin maintains PyXML AFAIK. Maybe he has some ideas. I
suspect this might be even worse in 2.5. Element Tree was
added and there was a name change. Some of those things
still need to be addressed.
--
Comment By: Richard Townsend (rptownsend)
Date: 2006-04-03 14:37
Message:
Logged In: YES
user_id=200117
Hi Neal,
I've just built 2.4.3 on a Red Hat Enterpeise Edition WS
V4.2 machine and this gives the same error.
I've had this vague feeling that I've seen something like
this before, but couldn't find anything when I searched the
tracker...
I've now realised that the error is due to a conflict with
PyXML-0.8.4 which was already installed on both machines.
If I rename the ../site_packages/_xmlplus directory to a
different name then the error goes away (on the Red Hat
machine at least, the SUSE machine is at home).
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-03 06:37
Message:
Logged In: YES
user_id=33168
Thanks for letting us know about where the regression
occurred. Can you do a little more debugging to try to find
the cause and some ideas about how to fix it?
I'm not sure that any developer runs on a system that
exhibits this error. So it will probably be very difficult
for us to figure it out since we can't reproduce it.
--
Comment By: Richard Townsend (rptownsend)
Date: 2006-04-02 15:28
Message:
Logged In: YES
user_id=200117
I've just retested with earlier versions.
No error with Python-2.4.1
Similar error with Python-2.4.2
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bu
[ python-Bugs-1465646 ] test_grp & test_pwd fail
Bugs item #1465646, was opened at 2006-04-06 12:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp & test_pwd fail Initial Comment: test_grp and test_pwd fail on PC running Red Hat Enterprise Edition V4.2 with Python-2.4.3 and Python- 2.5a1. See attached file for test error messages. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-07 12:13 Message: Logged In: YES user_id=21627 We should drop the tests in a selective manner. In this case, if -2 is in the password/group file, we should be able to find it: somebody might want to search by a gid value entered from a user, and that ought to work as well. rptownsend: could you investigate in more detail what's going on, on your system? -- Comment By: Walter Dörwald (doerwalter) Date: 2006-04-06 20:34 Message: Logged In: YES user_id=89016 I'm prepared to throw out the fancy tests from test_pwd.py and test_grp.py. They don't buy us much anyway and basically test more the OS then the Python modules. (For related bugs see #779218, #962226 and #775964.) -- Comment By: Matt Fleming (splitscreen) Date: 2006-04-06 17:48 Message: Logged In: YES user_id=1126061 AFAIK getgrgid() doesn't handle negative integers very well (I can't even add a group with a negative gid on my NetBSD machine). -- Comment By: Richard Townsend (rptownsend) Date: 2006-04-06 16:42 Message: Logged In: YES user_id=200117 The test workstation is getting its password and group info from NIS. The test workstation is running Red Hat Linux, but the NIS server is running HPUX 11i. I believe these are the entries causing the errors: lancaster:/etc > ypcat passwd | grep '-' nobody:*:-2:-2::/: lancaster:/etc > ypcat group | grep '-' nogroup:*:-2: -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 15:01 Message: Logged In: YES user_id=849994 Can you post the relevant part of /etc/passwd and /etc/group? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1462486 ] Scripts invoked by -m should trim exceptions
Feature Requests item #1462486, was opened at 2006-04-01 10:23
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Delaney (tcdelaney)
Assigned to: Nick Coghlan (ncoghlan)
Summary: Scripts invoked by -m should trim exceptions
Initial Comment:
Currently in 2.5, an exception thrown from a script invoked by -m
(runpy.run_module) will dump an exception like:
Traceback (most recent call last):
File "D:\Development\Python25\Lib\runpy.py", line 418, in run_module
filename, loader, alter_sys)
File "D:\Development\Python25\Lib\runpy.py", line 386, in _run_module_code
mod_name, mod_fname, mod_loader)
File "D:\Development\Python25\Lib\runpy.py", line 366, in _run_code
exec code in run_globals
File "D:\Development\modules\test25.py", line 53, in
raise GeneratorExit('body')
GeneratorExit: body
This should probably be trimmed to:
Traceback (most recent call last):
File "test25.py", line 53, in
raise GeneratorExit('body')
GeneratorExit: body
to match when a script is invoked by filename.
--
>Comment By: Nick Coghlan (ncoghlan)
Date: 2006-04-07 21:12
Message:
Logged In: YES
user_id=1038590
I'd forgotten about SF's current "no email when assigned a
bug" feature. . .
I'm inclined to agree with Guido that it could be tricky to
get rid of these without also masking legitimate traceback
info for import errors (e.g. if the PEP 302 emulation
machinery blows up rather than returning None the way it is
meant to when it can't find a loader for the module).
OTOH, I don't like the current output for an import errror,
either:
C:\>C:\python25\python.exe -m junk
Traceback (most recent call last):
File "C:\Python25\Lib\runpy.py", line 410, in run_module
raise ImportError("No module named " + mod_name)
ImportError: No module named junk
So I'll look into it - if it is suspected that runpy is at
fault for a problem with running a script, then there's two
easy ways to get the full traceback:
C:\>C:\python25\python.exe -m runpy junk
C:\>C:\python25\python.exe C:\Python25\Lib\runpy junk
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-06 10:45
Message:
Logged In: YES
user_id=6380
I'm not so sure. Who looks at the top of the traceback
anyway? And it might hide clues about problems caused by
runpy.py.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1432694 ] Implement preemptive threads in Python
Feature Requests item #1432694, was opened at 2006-02-16 18:11 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: None Status: Open Resolution: Invalid Priority: 5 Submitted By: Andrey Petrov (darkprokoba) Assigned to: Michael Hudson (mwh) Summary: Implement preemptive threads in Python Initial Comment: Cooperative threads have their uses but I find the lack of real native pre-emptive threads a major issue in a 21-st century language. We should consider the inertia of programmers from C++/Java/.NET background. They are used to and experienced in solving certain kind of problems with pre-emptive threads, and it's just too plain inconvenient to step back and try to cope with cooperative threads. The idea behind Python is that programming should not be a pain, right? This applies especially to GUI programs, where threads are used to perform time-consuming work in order to avoid the GUI from freezing (was I surprised the first time I tried this in Python!) Just look at some of the modern Python GUI applications, found in some recent Linux distributions. 99% of Fedora's configuration tools suffer extreme usability issues caused by their single-threadedness. I hate using yumex because the GUI is basically frozen for the half minute it takes to reload all repos I have configured on my machine!!! I know there might be a way to alleviate this particual class of problems by more careful cooperative thread programing... but I believe we need a more straightforward solution (i.e. preemptive threads) and not workarounds. I apologize if this issue has already been raised before. Cheers, darkprokoba -- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-07 21:28 Message: Logged In: YES user_id=1038590 One addition to Josiah's comments is that the previous attempts at free-threading failed to gain an appreciable performance benefit, as the gains from removing the global lock were lost in the subsequent need to add explicit synchronisation everywhere. Free threading is not a panacea. If Queue.Queue is used to pass data to worker threads, idle threads will not be consuming any GIL time. If there is OS level context-switch thrashing going on, then its time to look at using thread pools instead of a thread per task. Now, if you were to rephrase this request as "I want to be able to make the GUI thread higher priority than the worker threads so I can have a gazillion threads without hurting responsiveness of the main event loop so badly", that would be an entirely different story, and not a question I have seen asked recently (or at all, in fact). (Josiah's comments about any such thing being a couple of years away still hold, however - the multi-process support libraries are here and now, and scale a lot better than threads ever will, no matter what language you use) -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-02-22 18:35 Message: Logged In: YES user_id=341410 How many worker threads do you expect? If you work the sys.setcheckinterval() just right, you may be able to prioritize your threads... Any C library which does not acquire and release the GIL when it is supposed to is broken. Claiming that Python is broken in relation to C libraries being broken is misplaced blame. Python uses a GIL because it makes interaction with Python objects easier across threads. There have been previous failed efforts to make Python scalable across multiple processors; search for "python free threading" on google to see all of the relevant information about rewriting the Python interpreter with multiple processors in mind. Alternatively, you can always use one of the half-dozen parallel processing libraries for Python to distribute your work onto different processors, who all synchronize up with the main GUI process. Some are quite intuitive (check out Kamaelia), and will work today (any effort to get a 'free threading' idea into Python core will have to wait until at least Python 2.6, which is at least 2 years away). -- Comment By: Andrey Petrov (darkprokoba) Date: 2006-02-22 17:55 Message: Logged In: YES user_id=950037 > thread context switches happen at a regular > rate thanks for your response, but with enough worker threads it's still easy to starve the GUI thread. and the other problems of this model remain: 1) a stupid native module could forget to release the global interpreter lock and block on I/O, freezing the entire interpreter (i.e. GIL is a pain for native module writers) 2) poor C
[ python-Bugs-1466301 ] ImportError: Module _subprocess not found
Bugs item #1466301, was opened at 2006-04-07 14:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466301&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Africanis (africanis) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: Module _subprocess not found Initial Comment: I'm using Enthought Python 2.3.5 together with IPython and matplotlib on Windows XP SP2. I had problems importing pylab (in order actually to use matplotlib) until I changed the attached file (see from line 365). I have absolutely no idea what effect this will have on other modules (I'm fairly new to programming), but matplotlib seems to work okay now. Ignorance is bliss... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466301&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1433435 ] Use new expat version 2.0
Feature Requests item #1433435, was opened at 2006-02-17 10:16 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1433435&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wolfgang Langner (tds33) Assigned to: Nobody/Anonymous (nobody) Summary: Use new expat version 2.0 Initial Comment: New expat version 2.0 is released. This one schould be used in the next python release (2.5). I checked the repository and feature request and there is no note about usage of new expat versions. -- Comment By: iga Seilnacht (zseil) Date: 2006-04-07 15:26 Message: Logged In: YES user_id=1326842 There is a patch now: #1462338 upgrade pyexpat to expat 2.0.0 http://www.python.org/sf/1462338 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1433435&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465646 ] test_grp & test_pwd fail
Bugs item #1465646, was opened at 2006-04-06 11:57
Message generated for change (Comment added) made by rptownsend
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_grp & test_pwd fail
Initial Comment:
test_grp and test_pwd fail on PC running Red Hat
Enterprise Edition V4.2 with Python-2.4.3 and Python-
2.5a1.
See attached file for test error messages.
--
>Comment By: Richard Townsend (rptownsend)
Date: 2006-04-07 15:58
Message:
Logged In: YES
user_id=200117
When I run the following script on the workstation
import pwd, grp
entries = pwd.getpwall()
for e in entries:
if e[2] < 0:
print e
entries = grp.getgrall()
for e in entries:
if e[2] < 0:
print e
--
I get this output:
('nobody', '*', -2, -2, '', '/', '')
('nogroup', '*', -2, [])
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-07 11:13
Message:
Logged In: YES
user_id=21627
We should drop the tests in a selective manner. In this
case, if -2 is in the password/group file, we should be able
to find it: somebody might want to search by a gid value
entered from a user, and that ought to work as well.
rptownsend: could you investigate in more detail what's
going on, on your system?
--
Comment By: Walter Dörwald (doerwalter)
Date: 2006-04-06 19:34
Message:
Logged In: YES
user_id=89016
I'm prepared to throw out the fancy tests from test_pwd.py
and test_grp.py. They don't buy us much anyway and basically
test more the OS then the Python modules. (For related bugs
see #779218, #962226 and #775964.)
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-06 16:48
Message:
Logged In: YES
user_id=1126061
AFAIK getgrgid() doesn't handle negative integers very well
(I can't even add a group with a negative gid on my NetBSD
machine).
--
Comment By: Richard Townsend (rptownsend)
Date: 2006-04-06 15:42
Message:
Logged In: YES
user_id=200117
The test workstation is getting its password and group info
from NIS.
The test workstation is running Red Hat Linux, but the NIS
server is running HPUX 11i.
I believe these are the entries causing the errors:
lancaster:/etc > ypcat passwd | grep '-'
nobody:*:-2:-2::/:
lancaster:/etc > ypcat group | grep '-'
nogroup:*:-2:
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-06 14:01
Message:
Logged In: YES
user_id=849994
Can you post the relevant part of /etc/passwd and /etc/group?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1208730 ] expat binding for XML_ParserReset
Feature Requests item #1208730, was opened at 2005-05-25 22:37 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: expat binding for XML_ParserReset Initial Comment: XML_ParserReset is an expat parser method for resetting the parser to handle a new document. This keeps you from having to create a new parser for each document. -- Comment By: iga Seilnacht (zseil) Date: 2006-04-07 17:40 Message: Logged In: YES user_id=1326842 That is patch #1244208. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-01 05:44 Message: Logged In: YES user_id=33168 See patch #1208730. -- Comment By: John Eikenberry (zhar) Date: 2005-05-31 08:12 Message: Logged In: YES user_id=322022 Forgot to mention I made the patch against current CVS. -- Comment By: John Eikenberry (zhar) Date: 2005-05-31 08:10 Message: Logged In: YES user_id=322022 Ok. I gave it a whirl. The patch is attached. If you have a moment, could you please look over it and let me know if I made any mistakes. Its a forward diff as recommended by the guidelines. I tried to follow them as much as possible. Thanks. -- Comment By: Martin v. Löwis (loewis) Date: 2005-05-30 10:37 Message: Logged In: YES user_id=21627 Would you like to work on a patch for this feature? Exposing more methods from Expat is a good idea. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1190596 ] calendar._firstweekday is too hard-wired
Feature Requests item #1190596, was opened at 2005-04-27 00:10 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190596&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tres Seaver (tseaver) Assigned to: Raymond Hettinger (rhettinger) Summary: calendar._firstweekday is too hard-wired Initial Comment: Long-running applications which need to make use of the 'calendar' module may need to present calendars to different users using the users' preferred settings. Currently, the two functions which rely on the locale-specific setting are too inflexible: they assume that the module-level global should always govern. The attached patch adds defaulted arguments to these functions, and uses the module-level global only where the caller does not pass in a value. -- Comment By: iga Seilnacht (zseil) Date: 2006-04-07 18:24 Message: Logged In: YES user_id=1326842 I think that this request can now be closed, since an object oriented interface has been added in revision 43483 (see bug #947906). You can simply use multiple instances of Calendar class or its subclasses. -- Comment By: Tres Seaver (tseaver) Date: 2005-04-29 17:04 Message: Logged In: YES user_id=127625 I somehow dropped the test patch on the floor. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-29 16:44 Message: Logged In: YES user_id=80475 Okay, I've got it from here. -- Comment By: Tim Peters (tim_one) Date: 2005-04-29 16:32 Message: Logged In: YES user_id=31435 +1 from me. It's a very simple change, allowing callers to break dependence on a one-size-doesn't-fit-all global in a clear and thread-safe way. Doesn't break any existing code. Tiny slowdown in functions that aren't speed-critical anyway. The patch needs doc and test suite changes too, but what's here is fine by me so far as it goes. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-29 00:51 Message: Logged In: YES user_id=80475 Tim, I'm -0 on this one. Do you have an opinion? Essentially, the OP wants an alternate, thread-safe interface to specifying firstweekday on a per-call basis. It can already be done with a wrapper function and a lock, so it is just a convenience issue. -- Comment By: Tres Seaver (tseaver) Date: 2005-04-28 15:02 Message: Logged In: YES user_id=127625 WIth the patch, if you pass 'firstweekday' when calling 'monthcalendar' or 'weekheader', there is no race, and therefore no need to guard the global, because the global is ignored. Nothing else in the module depends on the value of that global except those two functions. I'm attaching a doctest which demonstrates the use case. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 14:36 Message: Logged In: YES user_id=80475 Write a simple wrapper to save and restore the global state: >>> def mymonthcalendar(year, month, first=None): if first is None: return monthcalendar(year, month) saved = firstweekday() setfirstweekday(first) rows = monthcalendar(year, month) setfirstweekday(saved) return rows That is essentially what the existing API is for. For a multi-threaded environment, you would need to add locks to th e critical section in the above code (the same would be true for your proposed patch). -- Comment By: Tres Seaver (tseaver) Date: 2005-04-28 14:24 Message: Logged In: YES user_id=127625 Different users of a long-running Python process may have different preferences for the first weekday; if the application tries to use the setfirstweekday() API for each of them, then they end up racing to set it. Making the option selectable per-call makes it side-effect free, and therefore more robust for multi-user applications. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 13:42 Message: Logged In: YES user_id=80475 I do not follow what can be done with your patch that cannot currently be done with setfirstweekday(). -- Comment By: Tres Seaver (tseaver) Date: 2005-04-28
[ python-Feature Requests-1190596 ] calendar._firstweekday is too hard-wired
Feature Requests item #1190596, was opened at 2005-04-27 00:10 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190596&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tres Seaver (tseaver) Assigned to: Raymond Hettinger (rhettinger) Summary: calendar._firstweekday is too hard-wired Initial Comment: Long-running applications which need to make use of the 'calendar' module may need to present calendars to different users using the users' preferred settings. Currently, the two functions which rely on the locale-specific setting are too inflexible: they assume that the module-level global should always govern. The attached patch adds defaulted arguments to these functions, and uses the module-level global only where the caller does not pass in a value. -- >Comment By: Walter Dörwald (doerwalter) Date: 2006-04-07 18:40 Message: Logged In: YES user_id=89016 Yes, with the new OO interface the examples from test_calendar.txt look like this: >>> import calendar >>> calendar.monthcalendar(2005, 4)[0] [0, 0, 0, 0, 1, 2, 3] >>> calendar.weekheader(1) 'M T W T F S S' >>> calendar.TextCalendar(0).monthdayscalendar(2005, 4)[0] [0, 0, 0, 0, 1, 2, 3] >>> calendar.TextCalendar(6).monthdayscalendar(2005, 4)[0] [0, 0, 0, 0, 0, 1, 2] >>> calendar.TextCalendar(0).formatweekheader(1) 'M T W T F S S' >>> calendar.TextCalendar(6).formatweekheader(1) 'S M T W T F S' Closing the feature request. -- Comment By: iga Seilnacht (zseil) Date: 2006-04-07 18:24 Message: Logged In: YES user_id=1326842 I think that this request can now be closed, since an object oriented interface has been added in revision 43483 (see bug #947906). You can simply use multiple instances of Calendar class or its subclasses. -- Comment By: Tres Seaver (tseaver) Date: 2005-04-29 17:04 Message: Logged In: YES user_id=127625 I somehow dropped the test patch on the floor. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-29 16:44 Message: Logged In: YES user_id=80475 Okay, I've got it from here. -- Comment By: Tim Peters (tim_one) Date: 2005-04-29 16:32 Message: Logged In: YES user_id=31435 +1 from me. It's a very simple change, allowing callers to break dependence on a one-size-doesn't-fit-all global in a clear and thread-safe way. Doesn't break any existing code. Tiny slowdown in functions that aren't speed-critical anyway. The patch needs doc and test suite changes too, but what's here is fine by me so far as it goes. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-29 00:51 Message: Logged In: YES user_id=80475 Tim, I'm -0 on this one. Do you have an opinion? Essentially, the OP wants an alternate, thread-safe interface to specifying firstweekday on a per-call basis. It can already be done with a wrapper function and a lock, so it is just a convenience issue. -- Comment By: Tres Seaver (tseaver) Date: 2005-04-28 15:02 Message: Logged In: YES user_id=127625 WIth the patch, if you pass 'firstweekday' when calling 'monthcalendar' or 'weekheader', there is no race, and therefore no need to guard the global, because the global is ignored. Nothing else in the module depends on the value of that global except those two functions. I'm attaching a doctest which demonstrates the use case. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 14:36 Message: Logged In: YES user_id=80475 Write a simple wrapper to save and restore the global state: >>> def mymonthcalendar(year, month, first=None): if first is None: return monthcalendar(year, month) saved = firstweekday() setfirstweekday(first) rows = monthcalendar(year, month) setfirstweekday(saved) return rows That is essentially what the existing API is for. For a multi-threaded environment, you would need to add locks to th e critical section in the above code (the same would be true for your proposed patch). -- Comment By: Tres Seaver (tseaver) Date: 2005-04-28 14:24 Message: Logged In: YES user_id=127625 Different users of a lo
[ python-Bugs-1464444 ] ctypes should be able to link with installed libffi
Bugs item #146, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). -- >Comment By: Thomas Heller (theller) Date: 2006-04-07 19:49 Message: Logged In: YES user_id=11105 I'm astonished how flexible the build-system is :-), once you leave Windows. setup.py needs a change, though, so that the _ctypes/libffi configure script is not run when not needed. One possible advange of Modules/Setup.local is that one can define additional compilation flags for ctypes - for example, if ctypes would support it, to enable/disable certain features (varargs function calls, for example). -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-06 23:46 Message: Logged In: YES user_id=21627 If this configuration needs an operator decision, I think this decision is best made in Modules/Setup.local. Anybody who wants to use the local libffi installation can do so, by writing a Setup.local that lists the source files, and gives -lffi as a library option. Setup.dist could provide a commented version of such a configuration. setup.py *should* then skip over building _ctypes, as it should find out that _ctypes was already built through Makefile. -- Comment By: Thomas Heller (theller) Date: 2006-04-06 22:02 Message: Logged In: YES user_id=11105 I do not really know. Maybe using distutils.sysconfig.get_config_var() ? A pragmatic approach would be to parse pyconfig.h itself in the setup script. -- Comment By: Matthias Klose (doko) Date: 2006-04-06 21:45 Message: Logged In: YES user_id=60903 maybe a configure switch --with-system-ffi could do it? How to pass this to the setup.py file? -- Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. -- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library buildable on hppa (or maybe this is just the failed (it's really a 32bit runtime, but hppa64-linux is detected). -- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Marti
[ python-Bugs-1466641 ] Bogus SyntaxError in listcomp
Bugs item #1466641, was opened at 2006-04-07 18:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466641&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Bogus SyntaxError in listcomp Initial Comment: The attached syn.py gives a SyntaxError in 2.5a1 and trunk. Works fine in earlier Pythons. Whittled down from real-life Zope3 source. def d(dir): return [fn for fn in os.listdir(dir) if fn if fn] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466641&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1039857 ] win32 silent installation: allow MAINDIR on command line
Feature Requests item #1039857, was opened at 2004-10-04 12:23 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1039857&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matteo Gallivanoni (sigmud) Assigned to: Nobody/Anonymous (nobody) Summary: win32 silent installation: allow MAINDIR on command line Initial Comment: This request is related to my (false) "Bugs item #1038410" since it is by design and it won't be fixed I thought I could be suggested as a new feature. Request: Add a command line switch to be able to specify python install directory in silent installation mode in other word it should be something like this: Python-X.Y.Z.exe /s /d MAINDIR=C:\some_dir\python BTW: IIRC the windows wise installer configuration file is not provided into python cvs source tree so I can only suggest this google-groups thread as a hint: Newsgroups:wise.wise7.general Subject: "Passing the path name to a silent install. How?" Data:2000/01/17 -- Comment By: iga Seilnacht (zseil) Date: 2006-04-08 03:35 Message: Logged In: YES user_id=1326842 Starting with Python 2.4 it is possible to specify a TARGETDIR parameter to the msi installer. See http://www.python.org/download/releases/2.4/msi/ for more details. This feature request should be closed as fixed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1039857&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1462352 ] socket.ssl won't work together with socket.settimeout on Win
Bugs item #1462352, was opened at 2006-03-31 14:11
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Georg Brandl (gbrandl)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.ssl won't work together with socket.settimeout on Win
Initial Comment:
Symptoms:
>>> import socket
>>> s = socket.socket()
>>> s.settimeout(30.0)
>>> s.connect(("gmail.org", 995))
>>> ss = socket.ssl(s)
Traceback (most recent call last):
File "", line 1, in ?
File "C:\python24\lib\socket.py", line 74, in ssl
return _realssl(sock, keyfile, certfile)
socket.sslerror: (2, 'The operation did not complete
(read)')
This does not occur on Unix, where
test_socket_ssl.test_timeout runs smoothly.
--
>Comment By: Tim Peters (tim_one)
Date: 2006-04-08 01:25
Message:
Logged In: YES
user_id=31435
I did a data breakpoint on the 8 bytes in the sock_timeout
member, and it never triggered: nothing stores anything
there to change 30.0 to 0.0.
Instead, socketmodule.c and _ssl.c have different views of
where the members of a PySocketSockObject live. WRT
socketmodule.c sock_settimeout's `s`, and _ssl.c
newPySSLObject's `Sock` (which are the same object in the
test case), the debugger agrees about the addresses at which
these members live:
&s->_ob_next0x0096c3e8
&s->_ob_prev0x0096c3ec
&s->ob_refcnt 0x0096c3f0
&s->ob_type 0x0096c3f4
&s->sock_fd 0x0096c3f8
&s->sock_family 0x0096c3fc
&s->sock_type 0x0096c400
&s->sock_proto 0x0096c404
&s->sock_addr 0x0096c408
&s->errorhandler 0x0096c488
But there's a radical disconnect about where it thinks
sock_timeout lives:
&s->sock_timeout0x0096c490
&Sock->sock_timeout 0x0096c48c
Indeed,
printf("%d\n", sizeof(PySocketSockObject));
displays different results:
socketmodule.c: 176
_ssl.c: 172
I'm unclear about why. Doing
printf("%d\n", sizeof(sock_addr_t));
prints 128 in both modules, so there's not an obvious
difference there.
--
Comment By: Tim Peters (tim_one)
Date: 2006-04-01 21:08
Message:
Logged In: YES
user_id=31435
BTW, does anyone understand why this part of my first
comment was true?:
"""
check_socket_and_wait_for_timeout() takes the "else if
(s->sock_timeout == 0.0)" path and and returns
SOCKET_IS_NONBLOCKING.
"""
How did s->sock_timeout become 0? s.settimeout(30.0) was
called, and the same s was passed to socket.ssl(). I don't
understand this at all:
>>> s.connect(("gmail.org", 995))
>>> s.gettimeout()
30.0
>>> s._sock
>>> s._sock.gettimeout()
30.0
>>> ss = socket.ssl(s)
but a breakpoint in newPySSLObject() right there shows that
Sock->sock_timeout is 0.0. HTF did that happen?
If I poke 30.0 (under the debugger) into Sock->sock_timeout
at the start of newPySSLObject(), the constructor finishes
unexceptionally.
--
Comment By: Tim Peters (tim_one)
Date: 2006-04-01 20:57
Message:
Logged In: YES
user_id=31435
gmail.com happened to respond when I tried it today, so I
can confirm (alas) that the patch at
http://pastebin.com/633224
made no difference to the outcome on Windows.
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-31 20:36
Message:
Logged In: YES
user_id=31435
Because the
s.connect(("gmail.org", 995))
line started timing out on all (non-Windows) buildbot slaves
some hours ago, causing all test runs to fail, I disabled
test_timeout on all boxes for now (on trunk & on 2.4 branch).
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-31 18:23
Message:
Logged In: YES
user_id=31435
Note that this is a problem in 2.4 and trunk.
The sample code worked fine earlier today if (and only if) I
left out the .settimeout() call.
Note that buildbot test runs are failing in trunk and 2.4
branch now on non-Windows boxes, because the
s.connect(("gmail.org", 995))
line is timing out (the new test is disabled on Windows, and
that's why the Windows buildbots are still passing). At the
moment, that's timing out on my Windows box too. We clearly
need a more reliable net address to connect to.
On Bug Day IRC, "arekm" last asked that I try this patch on
Windows:
http://pastebin.com/633224
Unfortunately, I haven't been able to get beyond the
s.connect(("gmail.org", 995)) line since then, so still
don't know whether that helps. Nothing else did ;-)
On Windows, in newPySSLObject(),
"ret = SSL_connect(self->ssl)
[ python-Bugs-1462352 ] socket.ssl won't work together with socket.settimeout on Win
Bugs item #1462352, was opened at 2006-03-31 14:11
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Georg Brandl (gbrandl)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.ssl won't work together with socket.settimeout on Win
Initial Comment:
Symptoms:
>>> import socket
>>> s = socket.socket()
>>> s.settimeout(30.0)
>>> s.connect(("gmail.org", 995))
>>> ss = socket.ssl(s)
Traceback (most recent call last):
File "", line 1, in ?
File "C:\python24\lib\socket.py", line 74, in ssl
return _realssl(sock, keyfile, certfile)
socket.sslerror: (2, 'The operation did not complete
(read)')
This does not occur on Unix, where
test_socket_ssl.test_timeout runs smoothly.
--
>Comment By: Tim Peters (tim_one)
Date: 2006-04-08 02:05
Message:
Logged In: YES
user_id=31435
As a sanity check on all those details, inside newPySSLObject()
*(double *)((char *)&Sock->sock_timeout + 4)
is in fact 30.0.
--
Comment By: Tim Peters (tim_one)
Date: 2006-04-08 01:25
Message:
Logged In: YES
user_id=31435
I did a data breakpoint on the 8 bytes in the sock_timeout
member, and it never triggered: nothing stores anything
there to change 30.0 to 0.0.
Instead, socketmodule.c and _ssl.c have different views of
where the members of a PySocketSockObject live. WRT
socketmodule.c sock_settimeout's `s`, and _ssl.c
newPySSLObject's `Sock` (which are the same object in the
test case), the debugger agrees about the addresses at which
these members live:
&s->_ob_next0x0096c3e8
&s->_ob_prev0x0096c3ec
&s->ob_refcnt 0x0096c3f0
&s->ob_type 0x0096c3f4
&s->sock_fd 0x0096c3f8
&s->sock_family 0x0096c3fc
&s->sock_type 0x0096c400
&s->sock_proto 0x0096c404
&s->sock_addr 0x0096c408
&s->errorhandler 0x0096c488
But there's a radical disconnect about where it thinks
sock_timeout lives:
&s->sock_timeout0x0096c490
&Sock->sock_timeout 0x0096c48c
Indeed,
printf("%d\n", sizeof(PySocketSockObject));
displays different results:
socketmodule.c: 176
_ssl.c: 172
I'm unclear about why. Doing
printf("%d\n", sizeof(sock_addr_t));
prints 128 in both modules, so there's not an obvious
difference there.
--
Comment By: Tim Peters (tim_one)
Date: 2006-04-01 21:08
Message:
Logged In: YES
user_id=31435
BTW, does anyone understand why this part of my first
comment was true?:
"""
check_socket_and_wait_for_timeout() takes the "else if
(s->sock_timeout == 0.0)" path and and returns
SOCKET_IS_NONBLOCKING.
"""
How did s->sock_timeout become 0? s.settimeout(30.0) was
called, and the same s was passed to socket.ssl(). I don't
understand this at all:
>>> s.connect(("gmail.org", 995))
>>> s.gettimeout()
30.0
>>> s._sock
>>> s._sock.gettimeout()
30.0
>>> ss = socket.ssl(s)
but a breakpoint in newPySSLObject() right there shows that
Sock->sock_timeout is 0.0. HTF did that happen?
If I poke 30.0 (under the debugger) into Sock->sock_timeout
at the start of newPySSLObject(), the constructor finishes
unexceptionally.
--
Comment By: Tim Peters (tim_one)
Date: 2006-04-01 20:57
Message:
Logged In: YES
user_id=31435
gmail.com happened to respond when I tried it today, so I
can confirm (alas) that the patch at
http://pastebin.com/633224
made no difference to the outcome on Windows.
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-31 20:36
Message:
Logged In: YES
user_id=31435
Because the
s.connect(("gmail.org", 995))
line started timing out on all (non-Windows) buildbot slaves
some hours ago, causing all test runs to fail, I disabled
test_timeout on all boxes for now (on trunk & on 2.4 branch).
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-31 18:23
Message:
Logged In: YES
user_id=31435
Note that this is a problem in 2.4 and trunk.
The sample code worked fine earlier today if (and only if) I
left out the .settimeout() call.
Note that buildbot test runs are failing in trunk and 2.4
branch now on non-Windows boxes, because the
s.connect(("gmail.org", 995))
line is timing out (the new test is disabled on Windows, and
that's why the Windows buildbots are still passing). At the
moment, that's timing out on my Windows box too. We clearly
need a more reliable net address to connect to.
On Bug Day IRC, "arekm" la
