[ python-Feature Requests-1368091 ] shutils cannot copy owner
Feature Requests item #1368091, was opened at 2005-11-28 11:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1368091&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: Pierre Ossman (dr7eus) Assigned to: Nobody/Anonymous (nobody) Summary: shutils cannot copy owner Initial Comment: shutils is a nice wrapper for handling copying of files. But it currently falls short of being able to make an exact copy of a file. What is missing is the possibility to copy ownership of a file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1368091&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1366311 ] SRE engine do not release the GIL
Bugs item #1366311, was opened at 2005-11-25 13:57
Message generated for change (Comment added) made by eric_noyau
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366311&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: Eric Noyau (eric_noyau)
Assigned to: Nobody/Anonymous (nobody)
Summary: SRE engine do not release the GIL
Initial Comment:
In a multi-threaded program that does lots of regular
expression searching, some of them on very long strings
with complex regex we've noticed that everything stops
when a regular expression is searching.
One of the issue is that the re engine does not release
the interpreter lock while it is running. All the
other threads are therefore blocked for the entire time
it takes to do the regular expression search.
See the thread in python-dev about it:
http://mail.python.org/pipermail/python-dev/2005-November/058316.html
--
>Comment By: Eric Noyau (eric_noyau)
Date: 2005-11-28 14:11
Message:
Logged In: YES
user_id=1388768
Thanks for your comments. I've updated the patch to fix your
issues, but without introducing a per-state object lock.
What I did instead is to mark a state as not supporting
concurrency when a scanner object creates it. So the GIL
will not be released for scanners objects at all.
For consistency match also release the GIL now, if possible.
--
Comment By: Armin Rigo (arigo)
Date: 2005-11-25 21:38
Message:
Logged In: YES
user_id=4771
The patch looks good, but I wonder if it is safe. The SRE_STATE structure that
SRE_SEARCH_INNER uses is potentially visible to the application-level Python
code, via the (undocumented) scanner objects:
>>> r = re.compile(r"hello")
>>> s = r.scanner("big string in which to search")
>>> s.search()
<_sre.SRE_Match object at 0x12345678>
Each call to s.search() continues the previous search with the same SRE_STATE.
The problem with releasing the GIL as you do is that several threads could call
s.search() concurrently, which would most probably crash CPython.
This probably means that you need to add a lock in SRE_STATE and acquire it
while searching, to serialize its usage. Of course, we should then be careful
about what overhead this gives to applications that use regexps on a lot of
small strings...
Another note: for consistency, match() should also release the GIL if search()
does.
--
Comment By: Eric Noyau (eric_noyau)
Date: 2005-11-25 14:02
Message:
Logged In: YES
user_id=1388768
I'm attaching a diff to this bug that remove this limitation
if it sane to do so. If a search is done on a string or a
unicode object (which by definition are immutable) the GIL
is released and reacquired everytime a search is done.
I've tested this patch in both a simple tests (start a
thread with a greedy regex on a monstruous string and verify
that the othe python threads are still active) and by
running our internal application verifying that nothing is
blocking anymore.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366311&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1368312 ] fix for scheme identification in urllib2?
Bugs item #1368312, was opened at 2005-11-28 10:37
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=1368312&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: Ben Boals (bboals)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for scheme identification in urllib2?
Initial Comment:
I was looking at the following piece of code in urllib2
def http_error_auth_reqed(self, auth_header, host,
req, headers):
authreq = headers.get(auth_header, None)
if self.retried > 5:
# Don't fail endlessly - if we failed once,
we'll probably
# fail a second time. Hm. Unless the
Password Manager is
# prompting for the information. Crap. This
isn't great
# but it's better than the current 'repeat
until recursion
# depth exceeded' approach
raise HTTPError(req.get_full_url(), 401,
"digest auth failed",
headers, None)
else:
self.retried += 1
if authreq:
scheme = authreq.split()[0]
if scheme.lower() == 'digest':
return self.retry_http_digest_auth(req,
authreq)
else:
raise
ValueError("AbstractDigestAuthHandler doesn't know "
"about %s"%(scheme))
The particular thing that concerns me is scheme =
scheme = authreq.split()[0]
if scheme.lower() == 'digest':
Quite frequently, when there are multiple auth schemes
allowed, digest is NOT the first one in the list.
I would suggest substituting
schemes = authreq.lower().split(',')##a list of schemes
allowed, all lowercase
if('digest' in schemes):
and if needed, fixing the call to
retry_http_digest_auth so that the authreq passed is
valid (assuming for some reason it assumes the digest
is first)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368312&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1368368 ] prompt_user_passwd() in FancyURLopener
Bugs item #1368368, was opened at 2005-11-28 17:39
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=1368368&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Björn Lindqvist (sonderblade)
Assigned to: Nobody/Anonymous (nobody)
Summary: prompt_user_passwd() in FancyURLopener
Initial Comment:
Currently, urllib.urlopen() "kind of" handles HTTP
authentication. You simply write something like this:
urllib.urlopen("http://foo:[EMAIL PROTECTED]")
And it works like a charm. EXCEPT when the
username/password is wrong. Then you get the
FancyURLopener.prompt_user_passwd()-prompt asking you
for your username and password. I think that behaviour
is extremely illogical and annoying because it forces
you to add more code just to circumvent the odd default
behaviour.
I would be MUCH happer if, instead of the prompt, you
get an exception or the 401 Unauthorized error page
returned.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368368&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 04:25 Message generated for change (Comment added) made by loewis 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: Closed >Resolution: Fixed 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: Martin v. Löwis (loewis) Date: 2005-11-28 18:36 Message: Logged In: YES user_id=21627 This is now fixed with patch #1350409. -- Comment By: Atul Varma (varmaa) Date: 2005-11-18 17: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 09: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-02 00: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 22: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-1368481 ] python.dir still refers to python-whatsnew23
Bugs item #1368481, was opened at 2005-11-28 19:33 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=1368481&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Herzog (bernhard) Assigned to: Nobody/Anonymous (nobody) Summary: python.dir still refers to python-whatsnew23 Initial Comment: In the tarball with the GNU info version of the documentation, the file python.dir still refers to a node python-whatsnew23 which doesn't exist. It should be python-whatsnew24. This bug is also present in SVN in both release24-maint branch and trunk. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368481&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1368515 ] threading.Timer: Constructor does not handle args correctly
Bugs item #1368515, was opened at 2005-11-28 20:10
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=1368515&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: dominikush (dominikush)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Timer: Constructor does not handle args correctly
Initial Comment:
The constructor of threading.Timer does not correctly
handle arguments passed to it, see example given. I
noted the bug in Python 2.4.1 and checked it also for
Python 2.4.2:
>>> def test(*args,**kwds): print "test: args
=",args,"and kwds =",kwds
...
>>> import threading
>>> t = threading.Timer(2,test,"hello")
>>> t.start()
>>> test: args = ('h', 'e', 'l', 'l', 'o') and kwds = {}
Proposed bug fix in threading.Timer.__init__:
def __init__(self, interval, function, args=[],
kwargs={}): # bug
def __init__(self, interval, function, *args,
**kwargs):# correction
After proposed correction, rerun of test results in:
>>> t.start()
>>> test: args = ('hallo',) and kwds = {}
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368515&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1368768 ] clearing up dictionary keys/set member docs
Bugs item #1368768, was opened at 2005-11-28 19:40 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=1368768&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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: clearing up dictionary keys/set member docs Initial Comment: The documentation for dictionaries says "A dictionary's keys are almost arbitrary values. Only values containing lists, dictionaries or other mutable types (that are compared by value rather than by object identity) may not be used as keys." This is wrong. tuples are an immutable type, but not all tuples can be used as keys. The set documentation says "A set object is an unordered collection of immutable values.". This is also wrong - at least for common definitions of immutable. Immutability is a convenient way of dealing with builtin types, but is a red herring. It's whether or not the object has a hash value that matters, and it's the behavior of that hash value (coupled with comparison) that determine whether or not things behave as expected. The __hash__ documentation deals with these issues. I suggest replacing the current descriptions with one that references hashing, and a footnote pointing to the __hash__ docs for details: Any hashable object(1) can be used as a dictionary key/set element. Lists, sets and dicts are not hashable, and can not be used. Tuples can be used if all the things they contain are hashable. Instances of all other built-in types and most user-defined classes are hashable. (1) Objects for which the hash() function returns an appropriate value. See the __hash__ documentation for details. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368768&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1368827 ] bad external link in xmlrpc lib page
Bugs item #1368827, was opened at 2005-11-28 22:38 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=1368827&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: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: bad external link in xmlrpc lib page Initial Comment: This section of the current docs: 11.22 xmlrpclib -- XML-RPC client access http://docs.python.org/lib/module-xmlrpclib.html ... has the following bad link: http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html We could still list this useful external link in our docs: http://xmlrpc-c.sourceforge.net -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368827&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
