[ python-Bugs-1708326 ] find_module doc ambiguity
Bugs item #1708326, was opened at 2007-04-26 15:18
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1708326&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
Private: No
Submitted By: Andrew McNabb (amcnabb)
Assigned to: Nobody/Anonymous (nobody)
Summary: find_module doc ambiguity
Initial Comment:
The doc string for find_module doesn't make it clear that you can do:
stats_path = imp.find_module('scipy/stats')
It makes it sound like you would have to do:
scipy_path = imp.find_module('scipy')[1]
stats_path = imp.find_module('scipy', stats_path)[1]
However, the shorter snippet seems to work just fine.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2007-05-01 09:48
Message:
Logged In: YES
user_id=764593
Originator: NO
Are you sure it works the same? I would expect that
(1) The longer form first finds a module (or package) named scipy, then
finds the (sub-)module stats within it. The shortcut form might not
provide enough of the scipy context. (Whether this actually matters
probably depends on what stats does, how much it depends on the rest of
scipy, and what you need it for.)
(2) The longer form would work using python abstractions, while the short
form would depend on how files happened to be stored on your machine. Your
storage format is fairly common, but not guaranteed. For example, would
the short form work on windows, where directory slashes (sometimes) need to
go the other direction? Would it work if scipy were in a zipfile egg?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1708326&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1693753 ] Portability issue: os.rename behaves differently on win32
Bugs item #1693753, was opened at 2007-04-03 18:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693753&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: Platform-specific >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: cs_ (cs_) Assigned to: Nobody/Anonymous (nobody) Summary: Portability issue: os.rename behaves differently on win32 Initial Comment: os.rename(src, dst) fails on Windows if dst already exist and regular file. On Unixes, it does not fail, and silently overwrites dst. It's better to use MoveFileEx(src, dst, MOVEFILE_REPLACE_EXISTING) when moving regular files under Win32 to make it behave consistent way. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-05-01 17:02 Message: Logged In: YES user_id=21627 Originator: NO This change would be an incompatible change; see the discussion of the proposed patch. Closing this report as "won't fix". -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-04-23 00:48 Message: Logged In: YES user_id=984087 Originator: NO I submitted a patch for this (1704547) -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-04-12 18:35 Message: Logged In: YES user_id=984087 Originator: NO From MSDN document and googling, it does look like MOVEFILE_REPLACE_EXISTING guarantees atomicity for rename operation. I will see if I can come up with a patch (I will first need to learn building python on windows). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693753&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1709284 ] test_1686475 fails because pagefile.sys does not exist
Bugs item #1709284, was opened at 2007-04-28 16:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1709284&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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Calvin Spealman (ironfroggy) Assigned to: Nobody/Anonymous (nobody) Summary: test_1686475 fails because pagefile.sys does not exist Initial Comment: The file pagefile.sys is used as a test on stat'ing an open file, because previously we could rely on windows using it. It does not exist in newer versions, so the test fails. The attached patch uses a temporary file instead. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-05-01 17:04 Message: Logged In: YES user_id=21627 Originator: NO As discussed on python-dev: this patch is incorrect. -- Comment By: Calvin Spealman (ironfroggy) Date: 2007-04-28 20:32 Message: Logged In: YES user_id=112166 Originator: YES File Added: os_open_stat.patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1709284&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-1708652 ] Exact matching
Feature Requests item #1708652, was opened at 2007-04-27 13:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1708652&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: Regular Expressions >Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tom Lynn (tlynn) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Exact matching Initial Comment: I'd like to see a regexp.exact() method on regexp objects, equivalent to regexp.search(r'\A%s\Z' % pattern, ...), for parsing binary formats. It's probably not worth disturbing the current library interface for, but maybe in Py3k? -- >Comment By: Martin v. Löwis (loewis) Date: 2007-05-01 17:42 Message: Logged In: YES user_id=21627 Originator: NO Moving to the feature requests tracker. Notice that in Py3k, the string type will be a Unicode type, so it's not clear to me that regular expressions on binary data will still be supported. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1708652&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1710703 ] zipfile.ZipFile behavior inconsistent.
Bugs item #1710703, was opened at 2007-05-01 11:43 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=1710703&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 Private: No Submitted By: Mark Flacy (markaflacy) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile.ZipFile behavior inconsistent. Initial Comment: In short, ZipFile() will not write the Central Directory entry unless you have added a file to it. That makes it impossible to create a valid empty zip archive. In one of my applications, I have the need to extract a partial set of information from one zip file and insert it into another. There are valid use cases where the source zip archive will not have any of the files which I am looking for. In Python 2.4, I would end up with an empty file which was considered to be a valid empty zip archive. In Python 2.5, an empty file is not considered a valid zip archive. One would reasonably expect that creating a new ZipFile(mode="r") and successfully closing it without writing any entries would result in a valid zip archive that could be re-opened later without throwing an exception. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710703&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1710718 ] Ctrl+Shift block marking by words
Bugs item #1710718, was opened at 2007-05-01 17:26 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=1710718&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: IDLE Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: zorkin (zorkin) Assigned to: Nobody/Anonymous (nobody) Summary: Ctrl+Shift block marking by words Initial Comment: When I mark a block with ctrl+shift pressed, pressing the right arrow with cursor before the last word on the line marks this word plus whitespace till the first word on next line. I think this behaviour is wrong - it should stop at the end of line. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710718&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1710718 ] Ctrl+Shift block marking by words
Bugs item #1710718, was opened at 2007-05-01 17:26 Message generated for change (Comment added) made by zorkin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710718&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: IDLE Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: zorkin (zorkin) Assigned to: Nobody/Anonymous (nobody) Summary: Ctrl+Shift block marking by words Initial Comment: When I mark a block with ctrl+shift pressed, pressing the right arrow with cursor before the last word on the line marks this word plus whitespace till the first word on next line. I think this behaviour is wrong - it should stop at the end of line. -- >Comment By: zorkin (zorkin) Date: 2007-05-01 17:39 Message: Logged In: YES user_id=1741501 Originator: YES And another thing: if the cursor is at the start of line and I press ctrl + right, it moves to the start of the second word, not the first one, like it should. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710718&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1707768 ] os.path.normpath changes path (chops of trailing slash)
Bugs item #1707768, was opened at 2007-04-26 01:44
Message generated for change (Comment added) made by iszegedi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707768&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
Private: No
Submitted By: Robert Siemer (siemer)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.normpath changes path (chops of trailing slash)
Initial Comment:
Hello everybody!
>>> os.path.normpath('/etc/passwd')
'/etc/passwd'
I don't know any environment at all where
a) '/etc/passwd/'
b) '/etc/passwd'
are treated the same. It clearly does not apply for the path part of http urls
(this is left as an exercise for the reader).
But it also does not apply for (e.g.) Linux either:
an open() on path a) return ENOTDIR while it succeeds with b).
(assuming /etc/passwd is a file)
This is definitively not a documentation bug, as "normpath" should normalize a
path and not fuck it up.
Robert
--
Comment By: Istvan Szegedi (iszegedi)
Date: 2007-05-01 20:05
Message:
Logged In: YES
user_id=1772412
Originator: NO
I must admit that josm's comments make sense: in fact, I quickly tried out
how mkdir command from a bash shell would behave and it does the same:
# mkdir hello
# rmdir hello/.
Invalid argument
whereas
# rmdir hello/
works fine. I also wrote a small C program using mkdir() and rmdir()
functions and they behave exactly the same as mkdir/rmdir from bash (well,
no real suprise).
My suggestion to get the original issue fixed was based on POSIX standard
and apparently the Linux commands are not fully POSIX compliant, either...
Or do I misunderstand the quotes from the standard? Anyway, it is pretty
easy to modify my fix to be inline with Linux commands and C functions -
everything could be the same, apart from the last line where I added "/."
-- this should be only "/". So the entire function could look like this:
-- clip --
def normpath(path):
"""Normalize path, eliminating double slashes, etc."""
if path == '':
return '.'
initial_slashes = path.startswith('/')
# The next two lines were added by iszegedi
path = path.rstrip()
trailing_slash = path.endswith('/')
# POSIX allows one or two initial slashes, but treats three or more
# as single slash.
if (initial_slashes and
path.startswith('//') and not path.startswith('///')):
initial_slashes = 2
comps = path.split('/')
new_comps = []
for comp in comps:
if comp in ('', '.'):
continue
if (comp != '..' or (not initial_slashes and not new_comps) or
(new_comps and new_comps[-1] == '..')):
new_comps.append(comp)
elif new_comps:
new_comps.pop()
comps = new_comps
path = '/'.join(comps)
if initial_slashes:
path = '/'*initial_slashes + path
# The next two lines were added by iszegedi
if trailing_slash:
path = path + '/'
return path or '.'
-- clip --
Nevertheless, I would really appreciate to receive some comments from
POSIX gurus, how they see this problem.
--
Comment By: jos (josm)
Date: 2007-04-30 08:48
Message:
Logged In: YES
user_id=1776568
Originator: NO
I think we should be careful enough to tackle on this.
iszegedi's patch seems to work correctly,
but XBD's spec itself has some defect.
http://www.opengroup.org/austin/mailarchives/ag-review/msg01722.html
What do you think of the follow behavior?
>>> os.mkdir('dir/')
>>> os.mkdir('dir2/')
>>> os.rmdir(os.path.normpath('dir'))
>>> os.rmdir(os.path.normpath('dir2/'))
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 22] Invalid argument: 'dir2/.'
--
Comment By: Istvan Szegedi (iszegedi)
Date: 2007-04-28 22:27
Message:
Logged In: YES
user_id=1772412
Originator: NO
Here is what Posix standard says about pathnames:
"Base Definitions volume of IEEE Std 1003.1-2001, Section 3.266,
Pathname.
A character string that is used to identify a file. In the context of IEEE
Std 1003.1-2001, a pathname consists of, at most, {PATH_MAX} bytes,
including the terminating null byte. It has an optional beginning slash,
followed by zero or more filenames separated by slashes. A pathname may
optionally contain one or more trailing slashes. Multiple successive
slashes are considered to be the same as one slash."
And in the details:
"A pathname that contains at least one non-slash character and that ends
with one or more trailing slashes shall be resolved as if a single dot
character ( '.' ) were appended to the pathname."
[ python-Bugs-1708326 ] imp.find_module doc ambiguity
Bugs item #1708326, was opened at 2007-04-26 12:18
Message generated for change (Settings changed) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1708326&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
Private: No
Submitted By: Andrew McNabb (amcnabb)
Assigned to: Nobody/Anonymous (nobody)
>Summary: imp.find_module doc ambiguity
Initial Comment:
The doc string for find_module doesn't make it clear that you can do:
stats_path = imp.find_module('scipy/stats')
It makes it sound like you would have to do:
scipy_path = imp.find_module('scipy')[1]
stats_path = imp.find_module('scipy', stats_path)[1]
However, the shorter snippet seems to work just fine.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2007-05-01 06:48
Message:
Logged In: YES
user_id=764593
Originator: NO
Are you sure it works the same? I would expect that
(1) The longer form first finds a module (or package) named scipy, then
finds the (sub-)module stats within it. The shortcut form might not
provide enough of the scipy context. (Whether this actually matters
probably depends on what stats does, how much it depends on the rest of
scipy, and what you need it for.)
(2) The longer form would work using python abstractions, while the short
form would depend on how files happened to be stored on your machine. Your
storage format is fairly common, but not guaranteed. For example, would
the short form work on windows, where directory slashes (sometimes) need to
go the other direction? Would it work if scipy were in a zipfile egg?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1708326&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1708326 ] imp.find_module doc ambiguity
Bugs item #1708326, was opened at 2007-04-26 13:18
Message generated for change (Comment added) made by amcnabb
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1708326&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
Private: No
Submitted By: Andrew McNabb (amcnabb)
Assigned to: Nobody/Anonymous (nobody)
Summary: imp.find_module doc ambiguity
Initial Comment:
The doc string for find_module doesn't make it clear that you can do:
stats_path = imp.find_module('scipy/stats')
It makes it sound like you would have to do:
scipy_path = imp.find_module('scipy')[1]
stats_path = imp.find_module('scipy', stats_path)[1]
However, the shorter snippet seems to work just fine.
--
>Comment By: Andrew McNabb (amcnabb)
Date: 2007-05-01 12:57
Message:
Logged In: YES
user_id=1234027
Originator: YES
Given the issues you brought up, I guess I'm surprised that the shortcut
form is accepted, since it seems that it would often do the wrong thing.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2007-05-01 07:48
Message:
Logged In: YES
user_id=764593
Originator: NO
Are you sure it works the same? I would expect that
(1) The longer form first finds a module (or package) named scipy, then
finds the (sub-)module stats within it. The shortcut form might not
provide enough of the scipy context. (Whether this actually matters
probably depends on what stats does, how much it depends on the rest of
scipy, and what you need it for.)
(2) The longer form would work using python abstractions, while the short
form would depend on how files happened to be stored on your machine. Your
storage format is fairly common, but not guaranteed. For example, would
the short form work on windows, where directory slashes (sometimes) need to
go the other direction? Would it work if scipy were in a zipfile egg?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1708326&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1710802 ] subprocess must escape redirection characters under win32
Bugs item #1710802, was opened at 2007-05-01 22:46
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=1710802&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
Private: No
Submitted By: Patrick Mézard (pmezard)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess must escape redirection characters under win32
Initial Comment:
Hello,
For some reason, subprocess.Popen arguments are not processed correctly when
one of them contains a redirection character ("<>&|") when calling a batch file.
Unittest and patch are attached below. Here are the steps to reproduce it:
callee.py
"""
import sys
print sys.argv
"""
callee.bat
"""
python callee.py %*
"""
caller.py
"""
import subprocess
args = [
'ab',
'a|b',
'a&b',
]
for arg in args:
subprocess.check_call(['callee.bat', arg])
"""
Then:
"""
>python caller.py
The system cannot find the file specified.
Traceback (most recent call last):
File "caller.py", line 22, in
subprocess.check_call(['callee.bat', arg])
File "C:\Python251\lib\subprocess.py", line 461, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['callee.bat', 'a>>
"""
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710802&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1710802 ] subprocess must escape redirection characters under win32
Bugs item #1710802, was opened at 2007-05-01 22:46
Message generated for change (Comment added) made by pmezard
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710802&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
Private: No
Submitted By: Patrick Mézard (pmezard)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess must escape redirection characters under win32
Initial Comment:
Hello,
For some reason, subprocess.Popen arguments are not processed correctly when
one of them contains a redirection character ("<>&|") when calling a batch file.
Unittest and patch are attached below. Here are the steps to reproduce it:
callee.py
"""
import sys
print sys.argv
"""
callee.bat
"""
python callee.py %*
"""
caller.py
"""
import subprocess
args = [
'ab',
'a|b',
'a&b',
]
for arg in args:
subprocess.check_call(['callee.bat', arg])
"""
Then:
"""
>python caller.py
The system cannot find the file specified.
Traceback (most recent call last):
File "caller.py", line 22, in
subprocess.check_call(['callee.bat', arg])
File "C:\Python251\lib\subprocess.py", line 461, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['callee.bat', 'a>>
"""
--
>Comment By: Patrick Mézard (pmezard)
Date: 2007-05-01 22:47
Message:
Logged In: YES
user_id=1660346
Originator: YES
File Added: fix_subp
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710802&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1710703 ] zipfile.ZipFile behavior inconsistent.
Bugs item #1710703, was opened at 2007-05-01 09:43 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710703&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 Private: No Submitted By: Mark Flacy (markaflacy) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile.ZipFile behavior inconsistent. Initial Comment: In short, ZipFile() will not write the Central Directory entry unless you have added a file to it. That makes it impossible to create a valid empty zip archive. In one of my applications, I have the need to extract a partial set of information from one zip file and insert it into another. There are valid use cases where the source zip archive will not have any of the files which I am looking for. In Python 2.4, I would end up with an empty file which was considered to be a valid empty zip archive. In Python 2.5, an empty file is not considered a valid zip archive. One would reasonably expect that creating a new ZipFile(mode="r") and successfully closing it without writing any entries would result in a valid zip archive that could be re-opened later without throwing an exception. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-01 23:06 Message: Logged In: YES user_id=33168 Originator: NO Mark, can you create a patch for zipfile to make it do what you want? Do the docs mention anything about this either way? Perhaps the docs also need updating? I don't know about what happened here, but I'm guessing there was some bug fix. This change could have been intentional or not. I patch will help us figure out what went wrong and how to proceed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710703&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1710718 ] Ctrl+Shift block marking by words
Bugs item #1710718, was opened at 2007-05-01 10:26 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710718&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: IDLE Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: zorkin (zorkin) >Assigned to: Kurt B. Kaiser (kbk) Summary: Ctrl+Shift block marking by words Initial Comment: When I mark a block with ctrl+shift pressed, pressing the right arrow with cursor before the last word on the line marks this word plus whitespace till the first word on next line. I think this behaviour is wrong - it should stop at the end of line. -- Comment By: zorkin (zorkin) Date: 2007-05-01 10:39 Message: Logged In: YES user_id=1741501 Originator: YES And another thing: if the cursor is at the start of line and I press ctrl + right, it moves to the start of the second word, not the first one, like it should. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710718&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1710802 ] subprocess must escape redirection characters under win32
Bugs item #1710802, was opened at 2007-05-01 13:46
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710802&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
Private: No
Submitted By: Patrick Mézard (pmezard)
>Assigned to: Peter Åstrand (astrand)
Summary: subprocess must escape redirection characters under win32
Initial Comment:
Hello,
For some reason, subprocess.Popen arguments are not processed correctly when
one of them contains a redirection character ("<>&|") when calling a batch file.
Unittest and patch are attached below. Here are the steps to reproduce it:
callee.py
"""
import sys
print sys.argv
"""
callee.bat
"""
python callee.py %*
"""
caller.py
"""
import subprocess
args = [
'ab',
'a|b',
'a&b',
]
for arg in args:
subprocess.check_call(['callee.bat', arg])
"""
Then:
"""
>python caller.py
The system cannot find the file specified.
Traceback (most recent call last):
File "caller.py", line 22, in
subprocess.check_call(['callee.bat', arg])
File "C:\Python251\lib\subprocess.py", line 461, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['callee.bat', 'a>>
"""
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-01 23:38
Message:
Logged In: YES
user_id=33168
Originator: NO
Peter, can you take a look at this?
--
Comment By: Patrick Mézard (pmezard)
Date: 2007-05-01 13:47
Message:
Logged In: YES
user_id=1660346
Originator: YES
File Added: fix_subp
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710802&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
