[ python-Bugs-1357604 ] os.path.makedirs DOES handle UNC paths
Bugs item #1357604, was opened at 2005-11-15 21:40 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357604&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: Documentation Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: j vickroy (jvickroy) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.makedirs DOES handle UNC paths Initial Comment: File: http://www.python.org/doc/current/lib/os-file-dir.html Paragraph: """ makedirs( path[, mode]) Recursive directory creation function. Like mkdir(), but makes all intermediate-level directories needed to contain the leaf directory. Throws an error exception if the leaf directory already exists or cannot be created. The default mode is 0777 (octal). This function does not properly handle UNC paths (only relevant on Windows systems; Universal Naming Convention paths are those that use the `\host\path' syntax). New in version 1.5.2. """ I just os.path.makedirs(...) with a UNC path and it DID create the desired folder on the specified host. The "in development" documentation is the same as the above documentation. I did not see any reference to this in the existing documentation bug reports. My particulars ... Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Windows XP-pro (all latest patches) -- Comment By: Peter van Kampen (pterk) Date: 2005-11-18 12:41 Message: Logged In: YES user_id=174455 I looks like the os.path (see ntpath.py) module has been updated to deal with UNC-paths somewhere between the 2.2.3 and 2.3.5 releases. Confirmed to work with python 2.3.5 and 2.4.1. It does NOT work in python 2.2.3. I have submitted a patch (http://sourceforge.net/tracker/index.php?func=detail&aid=1359879&group_id=5470&atid=305470) that removes the comment. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357604&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1360200 ] bdist_rpm still can't handle dashes in versions
Bugs item #1360200, was opened at 2005-11-18 10: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=1360200&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: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: jared jennings (sarynx) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_rpm still can't handle dashes in versions Initial Comment: I tried to use Python 2.4.2 to create a bdist_rpm of setuptools, whose version string was 0.6a9dev-r41475. The distutils/command/bdist_rpm module's _make_spec_file method mangled the version to 0.6a9dev_r41475 (line 370). Then when the spec file was being built by rpmbuild, it looked for the sdist named setuptools-0.6a9dev_r41475.tar.gz, which didn't exist: it was called setuptools-0.6a9dev-r41475.tar.gz (note dash). So you have to mangle the version to make rpm happy - but you can't expect the sdist to have the mangled version as part of its name. I looked at the nightly Python source as of 17 Nov 2005 and saw that this bug still exists in the development version of Python. A patch is attached which fixed this bug for me. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1360200&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1360221 ] telnetlib expect() and read_until() do not time out properly
Bugs item #1360221, was opened at 2005-11-18 15:58 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=1360221&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: Duncan Grisby (dgrisby) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib expect() and read_until() do not time out properly Initial Comment: In telnetlib, expect() and read_until() take a timeout argument. Unfortunately, the timeout is applied to each individual socket read(), rather than applying a deadline to the entire expect / read_until operation. The result of this is that if a server trickles non-matching data to the client, the expect() or read_until() never times out. In the case of expect(), it keeps building a larger and larger string of data to match with the regular expressions, leading to the eventual death of the process due to memory exhaustion. I have attached a patch that means the timeouts occur properly, and also adds a timeout to the initial open()'s connect() call. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1360221&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1167262 ] Fails assertion in winsig.c under VC 8.0
Bugs item #1167262, was opened at 2005-03-21 03:25 Message generated for change (Comment added) made by varmaa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Timothy Fitz (timothyfitz) Assigned to: Nobody/Anonymous (nobody) Summary: Fails assertion in winsig.c under VC 8.0 Initial Comment: In 2.4 and current cvs initsignal in signalmodule.c calls PyOS_getsig which calls signal with an invalid signal number. Under VC 7.1 (and 7.0, and probably before) this would return SIG_ERR however under VC 8.0 (beta) this causes an assertion failure. -- Comment By: Atul Varma (varmaa) Date: 2005-11-18 16:10 Message: Logged In: YES user_id=863202 Just wanted to mention that the Visual Studio 2005 products were officially launched on November 7th, 2005, and this same problem occurs when compiling the Python 2.4 source using Visual C++ 2005 Express Edition. -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-12 07:54 Message: Logged In: YES user_id=21627 See #1311784 for more discussion of this problem. -- Comment By: Martin v. Löwis (loewis) Date: 2005-04-01 22:02 Message: Logged In: YES user_id=21627 C99 7.14.1.1/p8 specifies # If the request can be honored, the signal function # returns the value of func for the most recent successful # call to signal for the specified signal sig. Otherwise, a # value of SIG_ERR is returned and a positive value is stored # in errno. So it seems to me that VC8 is in error: the request cannot be "honored", so it should return SIG_ERR. Until/if VC8 is released with that bug, I would like to take no action here. When it is released, we still might consider to ignore it until say, 8.1 comes along and fixes the bug. -- Comment By: Michael Hudson (mwh) Date: 2005-03-27 20:59 Message: Logged In: YES user_id=6656 Ew. My first thought is, is that allowed by ANSI C? I'd guess it's undefined behaviour. It still seems excessively unfriendly -- have you reported this to MS? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs
Bugs item #1338995, was opened at 2005-10-27 03:08
Message generated for change (Comment added) made by phd
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Couch (gregcouch)
Assigned to: Nobody/Anonymous (nobody)
Summary: CVS webbrowser.py (1.40) bugs
Initial Comment:
There are two calls to _safequote that are only made on
darwin, aka, Mac OS X. That function is missing.
And the UnixBrowser is missing an & in the "simpler
command" and thus causes python to hang until the
browser is exited (if it wasn't running already).
--
Comment By: Oleg Broytmann (phd)
Date: 2005-11-18 23:36
Message:
Logged In: YES
user_id=4799
So it seems the new webbrowser.py is too new. May I suggest
to rename the new module and doc to webbrowser2.py, and
restore the old version of the module and the doc?
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-11-15 07:08
Message:
Logged In: YES
user_id=44345
(Reopening. The webbrowser module still appears broken to me.)
I'm new to this thread, but webbrowser.open() in current SVN
(revision 41445) seems broken to me. This simple statement:
webbrowser.open("somefile.html")
returns True but fails to open the page in my currently running
instance of Safari. Dropping back to Python 2.4.1, it works fine.
I know webbrowser was a huge hack, but at least it appeared to do
basic stuff fine. It would appear that's no longer the case.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-11-10 00:43
Message:
Logged In: YES
user_id=1188172
Fixed in Revision 41419.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-11-01 01:01
Message:
Logged In: YES
user_id=131838
Breaking applications that use webbrowser does not help
application writers. It would be much more useful to me, as
an application writer, if the webbrowser module gave an
error saying it couldn't contact a web browser, rather than
the new behavior of hanging my application. You have yet to
address this common use case.
Running the webbrowser in the background is a contract that
the webbrowser module can't break and still be called the
webbrowser module. I agree that the 2.4.2 version is a
practical hack that should be fixed, but the CVS webbrower
almost fixes it while breaking existing applications. Since
adding an & is so bad (the web browser is already confirmed
to exist and to be executable), the CVS webbrower could be
changed to use the subprocess module instead of os.system,
and the original webbrowser contract could be preserved.
The wrong display or wrong xhost/xauth permissions are not a
problem because the python GUI application that calls
webbrowser would have failed to start up in the first place
if those problems existed. Starting the web browser in the
background only needs to confirm that the web browser
actually started up.
--
Comment By: Oleg Broytmann (phd)
Date: 2005-10-31 16:11
Message:
Logged In: YES
user_id=4799
Yes, I want.
Current practice of running a browser in the background by
default is deadly broken. The old code of webbrowser.py is
full of dirty hacks. Look at Netscape._remote(). It tries to
start a browser to send a remote command; if that fails it
tries to start the browser in the background, waits an
arbitrary number of seconds (why this? why not less? why not
more?) and without testing if the browser in the background
was started it retries sending the remote command. You can
never know if the browser was started and if the command was
sent becuase .open() does not return a result code.
At the global level the bug is that webbrowser.py doesn't
tri all browsers in the tryorder - it only concentrates on
the first it found in PATH. What if the brwoser cannot be
started (damaged disk image; wrong DISAPLY; wrong
xhost/xauth permissions)?
My patched webbrowser.py is much safer. It runs all browsers
in the tryorder until it finds one that can be started. One
doesn't need to wait a random number of seconds, too little
for slow systems, too many for fast. .open() returns a
success/fail status (on systems where it is possible to
obtain one).
The framework still alows you to shoot yourself in the foot,
but you must do it explicitly. Either run
os.system("shotgun-browser &")
yourself or register your own ShotgunBrowser. Thus the new
framework is safe by default but still flexible.
---
