[ python-Bugs-1213894 ] os.path.realpath() cannot handle symlinks
Bugs item #1213894, was opened at 2005-06-03 02:33
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: os.path.realpath() cannot handle symlinks
Initial Comment:
To reproduce:
Create a link, say to /tmp:
bagira:~/python> ls -l xxx
lrwxrwxrwx1 ilya ilya4 2005-06-02
17:09 xxx -> /tmp/
And now:
bagira:~/python> python2.4
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
Type "help", "copyright", "credits" or "license" for
more
information.
>>> import os.path
>>> os.path.realpath("xxx")
'/home/ilya/python/xxx'
I'd expect realpath() to return "/tmp"
Note: This bug was reported earlier (e.g bug 990669)
but it was closed as fixed
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 09:58
Message:
Logged In: YES
user_id=1188172
Confirmed. Only occurs when the symlink is the first
directory part of the argument. Attaching fix, assigning to
Raymond to check in.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202493 ] RE parser too loose with {m,n} construct
Bugs item #1202493, was opened at 2005-05-15 23:59
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: RE parser too loose with {m,n} construct
Initial Comment:
This seems wrong to me:
>>> re.match("(UNIX{})", "UNIX{}").groups()
('UNIX',)
With no numbers or commas, "{}" should not be considered
special in the pattern. The docs identify three numeric
repetition possibilities: {m}, {m,} and {m,n}. There's no
description of {} meaning anything. Either the docs should
say {} implies {1,1}, {} should have no special meaning, or
an exception should be raised during compilation of the
regular expression.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 10:01
Message:
Logged In: YES
user_id=1188172
I just realized that e.g. the string module uses unescaped
braces, so I think we should not become overly strict as it
would break much code...
Perhaps the original patch (sre-brace-diff) is better...
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-06-02 13:16
Message:
Logged In: YES
user_id=44345
In the absence of strong technical reasons, I'd vote to do what Perl
does. I believe the assumption all along has been that most people
coming to Python who already know how to use regular expressions are
Perl programmers. It wouldn't seem to make sense to throw little land
mines in their paths. I realize that explicit is better than implicit, but
practicality beats purity.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 23:32
Message:
Logged In: YES
user_id=1188172
Okay. Attaching patch which does that.
BTW, these things are currently allowed too (treated as
literals):
"{"
"{x"
"{x}"
"{x,y}"
"{1,x}"
etc.
The patch changes that, too.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 23:07
Message:
Logged In: YES
user_id=80475
I prefer Skip's third option, raising an exception during
compilation. This is an re syntax error. Treat it the same
way that we handle similar situations with regular Python:
>>> a[]
SyntaxError: invalid syntax
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 22:30
Message:
Logged In: YES
user_id=1188172
So, should a {} raise an error, or warn like in Ruby?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 22:25
Message:
Logged In: YES
user_id=80475
IMO, the simplest rule is that braces always be considered
special. This accommodates future extensions, simplifies
the re compiler, and makes it easier to know what needs to
be escaped.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 18:54
Message:
Logged In: YES
user_id=1188172
It's interesting what other RE implementations do with this
ambiguity:
Perl treats {} as literal in REs, as Skip proposes.
Ruby does, too, but issues a warning about } being unescaped.
GNU (e)grep v2.5.1 allows a bare {} only if it is at the
start of a RE, but matches it literally then.
GNU sed v4.1.4 does never allow it.
GNU awk v3.1.4 is gracious and acts like Perl.
Attached is a patch that fixes this behaviour in the
appearing "common sense".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1213894 ] os.path.realpath() cannot handle symlinks
Bugs item #1213894, was opened at 2005-06-03 02:33
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Raymond Hettinger (rhettinger)
Summary: os.path.realpath() cannot handle symlinks
Initial Comment:
To reproduce:
Create a link, say to /tmp:
bagira:~/python> ls -l xxx
lrwxrwxrwx1 ilya ilya4 2005-06-02
17:09 xxx -> /tmp/
And now:
bagira:~/python> python2.4
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
Type "help", "copyright", "credits" or "license" for
more
information.
>>> import os.path
>>> os.path.realpath("xxx")
'/home/ilya/python/xxx'
I'd expect realpath() to return "/tmp"
Note: This bug was reported earlier (e.g bug 990669)
but it was closed as fixed
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 10:17
Message:
Logged In: YES
user_id=1188172
Attaching new test case for this problem.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 09:58
Message:
Logged In: YES
user_id=1188172
Confirmed. Only occurs when the symlink is the first
directory part of the argument. Attaching fix, assigning to
Raymond to check in.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&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-1190033 ] The array module and the buffer interface
Feature Requests item #1190033, was opened at 2005-04-26 01:59
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&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: Rejected
Priority: 5
Submitted By: Josiah Carlson (josiahcarlson)
Assigned to: Nobody/Anonymous (nobody)
Summary: The array module and the buffer interface
Initial Comment:
It would be terribly convenient if array objects were
willing to take any object supporting the buffer
interface as initialization or extension via
a.fromstring().
They currently offer the buffer interface for other
objects to read/write once the array has been created,
but they do not accept buffers during creation or
extension (except for the typecode 'c').
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-03 05:52
Message:
Logged In: YES
user_id=80475
No need for a doc update either. The docs rarely make
promises about the substitutability of lookalike objects.
For instance, almost nothing that accepts a file argument
documents accepting StringIO objects or other lookalikes.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-06-03 01:50
Message:
Logged In: YES
user_id=341410
Sounds reasonable.
What about updating the documentation for array.fromstring()
to acknowledge that it accepts buffer objects, or do we call
it an 'undocumented and untested bonus feature'?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-03 01:42
Message:
Logged In: YES
user_id=80475
I recommend dropping this one and leaving the API alone.
The improvement would be so small that it isn't worth the
time to review it, test it, and introduce another version
incompatability (something that runs on Py2.5 that won't run
on Py2.4).
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-06-02 21:04
Message:
Logged In: YES
user_id=341410
I had assumed str(buf) copied the contents of the buffer,
but I was mistaken (read the source Josiah).
As I stated in my previous post, array.fromstring takes
buffer objects, so the documentation should be updated in
that case, which I can do if desired.
Honestly, I am also +0 on the patch. I think it is
convenient for completeness sake, but with array.fromstring,
and str(buf) being fast, it isn't necessary.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-02 20:12
Message:
Logged In: YES
user_id=80475
+0 It is not unreasonable to want to generalize the
interface. OTOH, the str() workaround is trivial and explicit:
>>> buf = buffer('abcdefghi', 1, 5)
>>> array('b', str(buf))
array('b', [98, 99, 100, 101, 102])
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-04-28 07:39
Message:
Logged In: YES
user_id=341410
I couldn't sleep, so I started working on it.
Note: a.fromstring(buf_obj) works in Python 2.3 and 2.4, it
just isn't documented, nor is it exposed via array_new.
I've got less than 20 lines of changes that seem to be
necessary for array(typecode, buf) to be supported,
including documentation and unittest updates. I'll sleep on
it (I'm getting tired) and upload it tomorrow.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-04-28 01:37
Message:
Logged In: YES
user_id=341410
Not right now, but I could probably have one for you
tomorrow. You want doc updates and tests too?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 00:20
Message:
Logged In: YES
user_id=80475
Do you have a patch?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1213894 ] os.path.realpath() cannot handle symlinks
Bugs item #1213894, was opened at 2005-06-02 19:33
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&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.4
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Ilya Sandler (isandler)
>Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: os.path.realpath() cannot handle symlinks
Initial Comment:
To reproduce:
Create a link, say to /tmp:
bagira:~/python> ls -l xxx
lrwxrwxrwx1 ilya ilya4 2005-06-02
17:09 xxx -> /tmp/
And now:
bagira:~/python> python2.4
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
Type "help", "copyright", "credits" or "license" for
more
information.
>>> import os.path
>>> os.path.realpath("xxx")
'/home/ilya/python/xxx'
I'd expect realpath() to return "/tmp"
Note: This bug was reported earlier (e.g bug 990669)
but it was closed as fixed
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-03 06:27
Message:
Logged In: YES
user_id=80475
Run the full testsuite, then
go ahead an apply the patch.
Be sure to add an entry to Misc/NEWS.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 03:17
Message:
Logged In: YES
user_id=1188172
Attaching new test case for this problem.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 02:58
Message:
Logged In: YES
user_id=1188172
Confirmed. Only occurs when the symlink is the first
directory part of the argument. Attaching fix, assigning to
Raymond to check in.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1205568 ] Compile fails on Darwin8 with --with-cxx=g++
Bugs item #1205568, was opened at 2005-05-20 07:05 Message generated for change (Comment added) made by rzigweid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205568&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Robert M. Zigweid (rzigweid) Assigned to: Nobody/Anonymous (nobody) Summary: Compile fails on Darwin8 with --with-cxx=g++ Initial Comment: As has been previously reported and fixed in some portions of the build process, building on Darwin 8 with gcc-4.0 requires some extra libraries to be passed. When --with-cxx=g++ is specified to configure, and possibly for other flags that make the build process be conscious of C++. Tail of error: gcc -u _PyMac_Error -o python.exe Modules/ccpython.o libpython2.4.a -ldl /usr/bin/ld: Undefined symbols: ___gxx_personality_v0 collect2: ld returned 1 exit status make: *** [python.exe] Error 1 Fix: Add -lSystem and -lSystemStubs for Darwin 8 to the linker where appropriate. I haven't identified all these spots though. -- >Comment By: Robert M. Zigweid (rzigweid) Date: 2005-06-03 07:56 Message: Logged In: YES user_id=554287 Firstly, exposing this bug, I discovred, also requires passing --with- pydebug=true. It's fine if you don't compile with pydebug. I'm sorry I did not mention/realize that initially. Secondly in response to loewis comment. It looks like linking with g++ instead of gcc as you eluded to takes care of the problem. Ilyria% gcc -u _PyMac_Error -o python.exe > Modules/ccpython.o > libpython2.4.a -ldl /usr/bin/ld: Undefined symbols: ___gxx_personality_v0 collect2: ld returned 1 exit status Ilyria ~/src/Python-2.4.1 05-06-03 7:53AM [gcc -u _PyMac_Error -o python.exe \nModules/ccpython.o \n libpython2.4.a -ldl] Ilyria% g++ -u _PyMac_Error -o python.exe Modules/ccpython.o libpython2.4.a -ldl Ilyria ~/src/Python-2.4.1 -- Comment By: Martin v. Löwis (loewis) Date: 2005-05-20 17:13 Message: Logged In: YES user_id=21627 Can you check whether just linking with g++ (instead of linking with gcc, and still not adding -lSystem) also solves the problem? configure is supposed to detect that g++ is needed for linking; if linking with g++ solves the problem, then configure.in must be enhanced to properly auto-detect this case. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205568&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1213894 ] os.path.realpath() cannot handle symlinks
Bugs item #1213894, was opened at 2005-06-03 02:33
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&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.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: os.path.realpath() cannot handle symlinks
Initial Comment:
To reproduce:
Create a link, say to /tmp:
bagira:~/python> ls -l xxx
lrwxrwxrwx1 ilya ilya4 2005-06-02
17:09 xxx -> /tmp/
And now:
bagira:~/python> python2.4
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
Type "help", "copyright", "credits" or "license" for
more
information.
>>> import os.path
>>> os.path.realpath("xxx")
'/home/ilya/python/xxx'
I'd expect realpath() to return "/tmp"
Note: This bug was reported earlier (e.g bug 990669)
but it was closed as fixed
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 16:32
Message:
Logged In: YES
user_id=1188172
Fixed, thanks for the report.
Lib/posixpath.py r1.74 r1.73.2.1
Lib/test/test_posixpath.py r1.13 r1.12.2.1
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-03 13:27
Message:
Logged In: YES
user_id=80475
Run the full testsuite, then
go ahead an apply the patch.
Be sure to add an entry to Misc/NEWS.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 10:17
Message:
Logged In: YES
user_id=1188172
Attaching new test case for this problem.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 09:58
Message:
Logged In: YES
user_id=1188172
Confirmed. Only occurs when the symlink is the first
directory part of the argument. Attaching fix, assigning to
Raymond to check in.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1212411 ] Incorrect result for regular expression - "|(hello)|(world)"
Bugs item #1212411, was opened at 2005-06-01 01:13
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&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: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Vijay Kumar (karamana)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Incorrect result for regular expression - "|(hello)|(world)"
Initial Comment:
The regular expression "|hello|world" incorrectly gives a
match, owing to the starting '|'. Below is a sample
program which highlights this. The correct result
behavior is to return None:
If the leading '|' is removed then the result is correct.
-
import re
m = re.search("|hello|world","This is a simple sentence")
print m
m2 = re.search("hello|world","This is a simple sentence")
print m2
output ---
<_sre.SRE_Match object at 0x00B71F70>
None
--
The first one is incorrect. Should have returned a None.
--
>Comment By: Tim Peters (tim_one)
Date: 2005-06-03 10:53
Message:
Logged In: YES
user_id=31435
I'm closing this as not-a-bug. The current behavior makes
sense, matches how other regexp packages work, and can't
be changed regardless without breaking existing code. Note
that
(mid|)night
isn't the same as
(mid)?night
in the case where "mid" doesn't match. That's one reason
the first form actually gets used (in the first form group 1
matches an empty string, in the second form group 1 doesn't
match at all).
As birkenfeld said, character classes are entirely different
gimmicks.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-02 02:49
Message:
Logged In: YES
user_id=1188172
Your example is wrong. "[]" is an error because it is an
empty character group.
"[|]" is a valid character group which matches the literal
"|", it is equivalent to r"\|". Between [ and ] most
character lose their special meaning.
I'm also in favour of the current behaviour, recommend closing.
--
Comment By: Vijay Kumar (karamana)
Date: 2005-06-01 18:59
Message:
Logged In: YES
user_id=404715
I think what you are saying is correct in terms of a formal
sense, but it makes sense to distinguish between a useful
match and an empty match. May be there can be an
additional method isEmptyMatch() in the match object which
can be used to detect this.
Also this one does not work: Gives a compile error
m = re.search("[]","This is a simple sentence")
print m
wherease this one returns None:
m = re.search("[|]","This is a simple sentence")
print m
So the empty match is not consistent :) (don't know if I
should wink )
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 17:39
Message:
Logged In: YES
user_id=80475
The current behavior best matches my expectations.
One other datapoint, AWK handles it the same way.
Recommend closing this as Invalid.
--
Comment By: Tim Peters (tim_one)
Date: 2005-06-01 01:19
Message:
Logged In: YES
user_id=31435
I expect you'll find that, e.g., Perl does the same thing:
a "missing" alternative is treated as an empty string, and an
empty string always matches. What basis do you have for
claiming it should not match (beyond just repeating that it
should not )?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202493 ] RE parser too loose with {m,n} construct
Bugs item #1202493, was opened at 2005-05-15 16:59
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: RE parser too loose with {m,n} construct
Initial Comment:
This seems wrong to me:
>>> re.match("(UNIX{})", "UNIX{}").groups()
('UNIX',)
With no numbers or commas, "{}" should not be considered
special in the pattern. The docs identify three numeric
repetition possibilities: {m}, {m,} and {m,n}. There's no
description of {} meaning anything. Either the docs should
say {} implies {1,1}, {} should have no special meaning, or
an exception should be raised during compilation of the
regular expression.
--
>Comment By: Skip Montanaro (montanaro)
Date: 2005-06-03 10:13
Message:
Logged In: YES
user_id=44345
Can you elaborate? I fail to see what the string module
has to do with the re module. Can you give an example
of code that would break?
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 03:01
Message:
Logged In: YES
user_id=1188172
I just realized that e.g. the string module uses unescaped
braces, so I think we should not become overly strict as it
would break much code...
Perhaps the original patch (sre-brace-diff) is better...
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-06-02 06:16
Message:
Logged In: YES
user_id=44345
In the absence of strong technical reasons, I'd vote to do what Perl
does. I believe the assumption all along has been that most people
coming to Python who already know how to use regular expressions are
Perl programmers. It wouldn't seem to make sense to throw little land
mines in their paths. I realize that explicit is better than implicit, but
practicality beats purity.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 16:32
Message:
Logged In: YES
user_id=1188172
Okay. Attaching patch which does that.
BTW, these things are currently allowed too (treated as
literals):
"{"
"{x"
"{x}"
"{x,y}"
"{1,x}"
etc.
The patch changes that, too.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 16:07
Message:
Logged In: YES
user_id=80475
I prefer Skip's third option, raising an exception during
compilation. This is an re syntax error. Treat it the same
way that we handle similar situations with regular Python:
>>> a[]
SyntaxError: invalid syntax
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 15:30
Message:
Logged In: YES
user_id=1188172
So, should a {} raise an error, or warn like in Ruby?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 15:25
Message:
Logged In: YES
user_id=80475
IMO, the simplest rule is that braces always be considered
special. This accommodates future extensions, simplifies
the re compiler, and makes it easier to know what needs to
be escaped.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 11:54
Message:
Logged In: YES
user_id=1188172
It's interesting what other RE implementations do with this
ambiguity:
Perl treats {} as literal in REs, as Skip proposes.
Ruby does, too, but issues a warning about } being unescaped.
GNU (e)grep v2.5.1 allows a bare {} only if it is at the
start of a RE, but matches it literally then.
GNU sed v4.1.4 does never allow it.
GNU awk v3.1.4 is gracious and acts like Perl.
Attached is a patch that fixes this behaviour in the
appearing "common sense".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202493 ] RE parser too loose with {m,n} construct
Bugs item #1202493, was opened at 2005-05-15 23:59
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: RE parser too loose with {m,n} construct
Initial Comment:
This seems wrong to me:
>>> re.match("(UNIX{})", "UNIX{}").groups()
('UNIX',)
With no numbers or commas, "{}" should not be considered
special in the pattern. The docs identify three numeric
repetition possibilities: {m}, {m,} and {m,n}. There's no
description of {} meaning anything. Either the docs should
say {} implies {1,1}, {} should have no special meaning, or
an exception should be raised during compilation of the
regular expression.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 20:00
Message:
Logged In: YES
user_id=1188172
Raymond said that braces should always be considered
special. This includes constructs like "{(?P.*)}"
which the string module uses, and which would be a syntax
error then.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-06-03 17:13
Message:
Logged In: YES
user_id=44345
Can you elaborate? I fail to see what the string module
has to do with the re module. Can you give an example
of code that would break?
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 10:01
Message:
Logged In: YES
user_id=1188172
I just realized that e.g. the string module uses unescaped
braces, so I think we should not become overly strict as it
would break much code...
Perhaps the original patch (sre-brace-diff) is better...
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-06-02 13:16
Message:
Logged In: YES
user_id=44345
In the absence of strong technical reasons, I'd vote to do what Perl
does. I believe the assumption all along has been that most people
coming to Python who already know how to use regular expressions are
Perl programmers. It wouldn't seem to make sense to throw little land
mines in their paths. I realize that explicit is better than implicit, but
practicality beats purity.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 23:32
Message:
Logged In: YES
user_id=1188172
Okay. Attaching patch which does that.
BTW, these things are currently allowed too (treated as
literals):
"{"
"{x"
"{x}"
"{x,y}"
"{1,x}"
etc.
The patch changes that, too.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 23:07
Message:
Logged In: YES
user_id=80475
I prefer Skip's third option, raising an exception during
compilation. This is an re syntax error. Treat it the same
way that we handle similar situations with regular Python:
>>> a[]
SyntaxError: invalid syntax
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 22:30
Message:
Logged In: YES
user_id=1188172
So, should a {} raise an error, or warn like in Ruby?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 22:25
Message:
Logged In: YES
user_id=80475
IMO, the simplest rule is that braces always be considered
special. This accommodates future extensions, simplifies
the re compiler, and makes it easier to know what needs to
be escaped.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 18:54
Message:
Logged In: YES
user_id=1188172
It's interesting what other RE implementations do with this
ambiguity:
Perl treats {} as literal in REs, as Skip proposes.
Ruby does, too, but issues a warning about } being unescaped.
GNU (e)grep v2.5.1 allows a bare {} only if it is at the
start of a RE, but matches it literally then.
GNU sed v4.1.4 does never allow it.
GNU awk v3.1.4 is gracious and acts like Perl.
Attached is a patch that fixes this behaviour in the
appearing "common sense".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mail
[ python-Bugs-1209447 ] os.path.join() fails if 2nd arg is a UNC path
Bugs item #1209447, was opened at 2005-05-26 22:45
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209447&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: 5
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.join() fails if 2nd arg is a UNC path
Initial Comment:
os.path.join('c:', r'\server\share') returns
c:\server\share rather than \server\share.
Interestingly os.path.join('c:a', r'\server\share')
returns r'\server\share'. IMHO, r'\server\share'
should be returned in all cases.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 20:09
Message:
Logged In: YES
user_id=1188172
I'd recommend not to change the behaviour, but add a note in
the docs that UNCs are not recognized as such in os.path.join.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-05-31 12:25
Message:
Logged In: YES
user_id=1188172
This is a difficult issue, since as far as I recall Windows
allows two or more backslashes in a row in the middle of
normal paths.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209447&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1194181 ] bz2.BZ2File doesn't handle modes correctly
Bugs item #1194181, was opened at 2005-05-03 04:39 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&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.4 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) >Assigned to: Raymond Hettinger (rhettinger) Summary: bz2.BZ2File doesn't handle modes correctly Initial Comment: I've noticed that if I specify a file mode of 'U' to bz2.BZ2File, it will erase my file. That's bad. Specifying 'rU' works as expected. Basically, it assumes that you want a writable file unless it sees an 'r' in the mode, or no mode is given. Ugh. I've attached a patch that fixes this on CVS HEAD, it looks like it should apply cleanly to 2.4 as well. This is a backport candidate if I've ever seen one. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 20:16 Message: Logged In: YES user_id=1188172 Okay to check in? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1205568 ] Compile fails on Darwin8 with --with-cxx=g++
Bugs item #1205568, was opened at 2005-05-20 13:05
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205568&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert M. Zigweid (rzigweid)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compile fails on Darwin8 with --with-cxx=g++
Initial Comment:
As has been previously reported and fixed in some portions of the build
process, building on Darwin 8 with gcc-4.0 requires some extra libraries to
be passed.
When --with-cxx=g++ is specified to configure, and possibly for other flags
that make the build process be conscious of C++.
Tail of error:
gcc -u _PyMac_Error -o python.exe Modules/ccpython.o
libpython2.4.a -ldl
/usr/bin/ld: Undefined symbols:
___gxx_personality_v0
collect2: ld returned 1 exit status
make: *** [python.exe] Error 1
Fix:
Add -lSystem and -lSystemStubs for Darwin 8 to the linker where
appropriate. I haven't identified all these spots though.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-06-03 20:18
Message:
Logged In: YES
user_id=21627
Ok. configure should have detected that you need g++ to
link. To do so, it compiles the program
void foo();int main(){foo();}void foo(){}
with g++ (g++ -c), then links the object file with gcc. If
that fails, it concludes that g++ is needed.
Can you please
a) confirm that this specific procedure indeed links
correctly, and
b) experiment to find out what changes to the program need
to be made so that it fails to link because of
___gxx_personality_v0
?
To analyse b), a number of issues have to be considered: it
may be that more include files are needed in the test
program, it may be that other compiler flags need to be
passed, and it may be that more code needs to be added. If
you cannot easily make the test case fail, please try to
reduce Modules/ccpython so that moves towards the test code.
--
Comment By: Robert M. Zigweid (rzigweid)
Date: 2005-06-03 13:56
Message:
Logged In: YES
user_id=554287
Firstly, exposing this bug, I discovred, also requires passing --with-
pydebug=true. It's fine if you don't compile with pydebug. I'm sorry I did
not
mention/realize that initially.
Secondly in response to loewis comment. It looks like linking with g++ instead
of gcc as you eluded to takes care of the problem.
Ilyria% gcc -u _PyMac_Error -o python.exe > Modules/ccpython.o
> libpython2.4.a -ldl
/usr/bin/ld: Undefined symbols:
___gxx_personality_v0
collect2: ld returned 1 exit status
Ilyria ~/src/Python-2.4.1 05-06-03 7:53AM
[gcc -u _PyMac_Error -o python.exe \nModules/ccpython.o \n
libpython2.4.a -ldl]
Ilyria% g++ -u _PyMac_Error -o python.exe Modules/ccpython.o
libpython2.4.a -ldl
Ilyria ~/src/Python-2.4.1
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-05-20 23:13
Message:
Logged In: YES
user_id=21627
Can you check whether just linking with g++ (instead of
linking with gcc, and still not adding -lSystem) also solves
the problem?
configure is supposed to detect that g++ is needed for
linking; if linking with g++ solves the problem, then
configure.in must be enhanced to properly auto-detect this case.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205568&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1194181 ] bz2.BZ2File doesn't handle modes correctly
Bugs item #1194181, was opened at 2005-05-02 22:39 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&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.4 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Raymond Hettinger (rhettinger) Summary: bz2.BZ2File doesn't handle modes correctly Initial Comment: I've noticed that if I specify a file mode of 'U' to bz2.BZ2File, it will erase my file. That's bad. Specifying 'rU' works as expected. Basically, it assumes that you want a writable file unless it sees an 'r' in the mode, or no mode is given. Ugh. I've attached a patch that fixes this on CVS HEAD, it looks like it should apply cleanly to 2.4 as well. This is a backport candidate if I've ever seen one. -- >Comment By: Bob Ippolito (etrepum) Date: 2005-06-03 14:23 Message: Logged In: YES user_id=139309 It should still be OK to check in. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 14:16 Message: Logged In: YES user_id=1188172 Okay to check in? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1190204 ] 3.29 site is confusing re site-packages on Windows
Bugs item #1190204, was opened at 2005-04-26 14:26 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190204&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: Kent Johnson (kjohnson) >Assigned to: Raymond Hettinger (rhettinger) Summary: 3.29 site is confusing re site-packages on Windows Initial Comment: Library Reference 3.29 site seems to say that site-packages is only searched on Unix and Mac. The relevant sentence is in the third paragraph: "For the tail part, it uses the empty string (on Windows) or it uses first lib/python2.4/site-packages and then lib/site-python (on Unixand Macintosh)." A clearer and more accurate wording would be "For the tail part, it uses the empty string and lib/site-python (on Windows) or it uses first lib/python2.4/site-packages and then lib/site-python (on Unixand Macintosh)." The relevant code is line 187 in site.py. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 20:24 Message: Logged In: YES user_id=1188172 Fix attached; okay to checkin? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190204&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202493 ] RE parser too loose with {m,n} construct
Bugs item #1202493, was opened at 2005-05-15 16:59
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: RE parser too loose with {m,n} construct
Initial Comment:
This seems wrong to me:
>>> re.match("(UNIX{})", "UNIX{}").groups()
('UNIX',)
With no numbers or commas, "{}" should not be considered
special in the pattern. The docs identify three numeric
repetition possibilities: {m}, {m,} and {m,n}. There's no
description of {} meaning anything. Either the docs should
say {} implies {1,1}, {} should have no special meaning, or
an exception should be raised during compilation of the
regular expression.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-03 13:46
Message:
Logged In: YES
user_id=80475
Hmm, it looks like they cannot be treated differently
without breaking backwards compatability.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 13:00
Message:
Logged In: YES
user_id=1188172
Raymond said that braces should always be considered
special. This includes constructs like "{(?P.*)}"
which the string module uses, and which would be a syntax
error then.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-06-03 10:13
Message:
Logged In: YES
user_id=44345
Can you elaborate? I fail to see what the string module
has to do with the re module. Can you give an example
of code that would break?
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 03:01
Message:
Logged In: YES
user_id=1188172
I just realized that e.g. the string module uses unescaped
braces, so I think we should not become overly strict as it
would break much code...
Perhaps the original patch (sre-brace-diff) is better...
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-06-02 06:16
Message:
Logged In: YES
user_id=44345
In the absence of strong technical reasons, I'd vote to do what Perl
does. I believe the assumption all along has been that most people
coming to Python who already know how to use regular expressions are
Perl programmers. It wouldn't seem to make sense to throw little land
mines in their paths. I realize that explicit is better than implicit, but
practicality beats purity.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 16:32
Message:
Logged In: YES
user_id=1188172
Okay. Attaching patch which does that.
BTW, these things are currently allowed too (treated as
literals):
"{"
"{x"
"{x}"
"{x,y}"
"{1,x}"
etc.
The patch changes that, too.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 16:07
Message:
Logged In: YES
user_id=80475
I prefer Skip's third option, raising an exception during
compilation. This is an re syntax error. Treat it the same
way that we handle similar situations with regular Python:
>>> a[]
SyntaxError: invalid syntax
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 15:30
Message:
Logged In: YES
user_id=1188172
So, should a {} raise an error, or warn like in Ruby?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 15:25
Message:
Logged In: YES
user_id=80475
IMO, the simplest rule is that braces always be considered
special. This accommodates future extensions, simplifies
the re compiler, and makes it easier to know what needs to
be escaped.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 11:54
Message:
Logged In: YES
user_id=1188172
It's interesting what other RE implementations do with this
ambiguity:
Perl treats {} as literal in REs, as Skip proposes.
Ruby does, too, but issues a warning about } being unescaped.
GNU (e)grep v2.5.1 allows a bare {} only if it is at the
start of a RE, but matches it literally then.
GNU sed v4.1.4 does never allow it.
GNU awk v3.1.4 is gracious and acts like Perl.
Attached is a patch that fixes this behaviour in the
appearing "common sense".
-
[ python-Bugs-1202493 ] RE parser too loose with {m,n} construct
Bugs item #1202493, was opened at 2005-05-15 23:59
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: RE parser too loose with {m,n} construct
Initial Comment:
This seems wrong to me:
>>> re.match("(UNIX{})", "UNIX{}").groups()
('UNIX',)
With no numbers or commas, "{}" should not be considered
special in the pattern. The docs identify three numeric
repetition possibilities: {m}, {m,} and {m,n}. There's no
description of {} meaning anything. Either the docs should
say {} implies {1,1}, {} should have no special meaning, or
an exception should be raised during compilation of the
regular expression.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 21:10
Message:
Logged In: YES
user_id=1188172
Then, I think, we should follow Perl's behaviour and treat
"{}" as a literal, just like every other brace construct
that isn't a repeat specifier.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-03 20:46
Message:
Logged In: YES
user_id=80475
Hmm, it looks like they cannot be treated differently
without breaking backwards compatability.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 20:00
Message:
Logged In: YES
user_id=1188172
Raymond said that braces should always be considered
special. This includes constructs like "{(?P.*)}"
which the string module uses, and which would be a syntax
error then.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-06-03 17:13
Message:
Logged In: YES
user_id=44345
Can you elaborate? I fail to see what the string module
has to do with the re module. Can you give an example
of code that would break?
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 10:01
Message:
Logged In: YES
user_id=1188172
I just realized that e.g. the string module uses unescaped
braces, so I think we should not become overly strict as it
would break much code...
Perhaps the original patch (sre-brace-diff) is better...
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-06-02 13:16
Message:
Logged In: YES
user_id=44345
In the absence of strong technical reasons, I'd vote to do what Perl
does. I believe the assumption all along has been that most people
coming to Python who already know how to use regular expressions are
Perl programmers. It wouldn't seem to make sense to throw little land
mines in their paths. I realize that explicit is better than implicit, but
practicality beats purity.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 23:32
Message:
Logged In: YES
user_id=1188172
Okay. Attaching patch which does that.
BTW, these things are currently allowed too (treated as
literals):
"{"
"{x"
"{x}"
"{x,y}"
"{1,x}"
etc.
The patch changes that, too.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 23:07
Message:
Logged In: YES
user_id=80475
I prefer Skip's third option, raising an exception during
compilation. This is an re syntax error. Treat it the same
way that we handle similar situations with regular Python:
>>> a[]
SyntaxError: invalid syntax
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 22:30
Message:
Logged In: YES
user_id=1188172
So, should a {} raise an error, or warn like in Ruby?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 22:25
Message:
Logged In: YES
user_id=80475
IMO, the simplest rule is that braces always be considered
special. This accommodates future extensions, simplifies
the re compiler, and makes it easier to know what needs to
be escaped.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 18:54
Message:
Logged In: YES
user_id=1188172
It's interesting what other RE implementations do with this
ambiguity:
Perl treats {} as literal in REs, as Skip proposes.
Ruby does, too, but issues
[ python-Bugs-1209447 ] os.path.join() fails if 2nd arg is a UNC path
Bugs item #1209447, was opened at 2005-05-26 20:45
Message generated for change (Comment added) made by jpe
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209447&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: 5
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.join() fails if 2nd arg is a UNC path
Initial Comment:
os.path.join('c:', r'\server\share') returns
c:\server\share rather than \server\share.
Interestingly os.path.join('c:a', r'\server\share')
returns r'\server\share'. IMHO, r'\server\share'
should be returned in all cases.
--
>Comment By: John Ehresman (jpe)
Date: 2005-06-03 19:34
Message:
Logged In: YES
user_id=22785
If the current behavior is kept, then os.path.join can't be
relied upon to return the 2nd (or 3rd+) argument if that
argument is an absolute path. This is one of the things I
rely on os.path.join to do and would need to write my own
version. Also, the behavior is quite different if the first
agument contains more than simply the drive letter.
I know this is a difficult issue and that is why I would
like to see it fixed in the standard library. My question
is whether there is a rationale for the current behavior.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-03 18:09
Message:
Logged In: YES
user_id=1188172
I'd recommend not to change the behaviour, but add a note in
the docs that UNCs are not recognized as such in os.path.join.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-05-31 10:25
Message:
Logged In: YES
user_id=1188172
This is a difficult issue, since as far as I recall Windows
allows two or more backslashes in a row in the middle of
normal paths.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209447&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1194181 ] bz2.BZ2File doesn't handle modes correctly
Bugs item #1194181, was opened at 2005-05-03 04:39 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&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.4 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Bob Ippolito (etrepum) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: bz2.BZ2File doesn't handle modes correctly Initial Comment: I've noticed that if I specify a file mode of 'U' to bz2.BZ2File, it will erase my file. That's bad. Specifying 'rU' works as expected. Basically, it assumes that you want a writable file unless it sees an 'r' in the mode, or no mode is given. Ugh. I've attached a patch that fixes this on CVS HEAD, it looks like it should apply cleanly to 2.4 as well. This is a backport candidate if I've ever seen one. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 21:47 Message: Logged In: YES user_id=1188172 Ok, checked in as Modules/bz2module.c r1.24 r1.23.2.1 Lib/test/test_bz2.py r1.17 r1.16.2.1 -- Comment By: Bob Ippolito (etrepum) Date: 2005-06-03 20:23 Message: Logged In: YES user_id=139309 It should still be OK to check in. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 20:16 Message: Logged In: YES user_id=1188172 Okay to check in? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1212900 ] Python segfaults on OpenBSD (tested 3.4 and 3.5)
Bugs item #1212900, was opened at 2005-06-01 19:33 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212900&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Fabien Devaux (fabinator) Assigned to: Nobody/Anonymous (nobody) Summary: Python segfaults on OpenBSD (tested 3.4 and 3.5) Initial Comment: Here is a minimal case, launch the server and then the client (change the server ip on the client source). Under NetBSD it works as expected, under OpenBSD I get a big segfault at the "ping" time... -- >Comment By: Martin v. Löwis (loewis) Date: 2005-06-03 21:49 Message: Logged In: YES user_id=21627 Looks like a stack overflow. What is the stack size limit in your account? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212900&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix
Bugs item #728515, was opened at 2003-04-27 19:44 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) Assigned to: Nobody/Anonymous (nobody) Summary: mmap's resize method resizes the file in win32 but not unix Initial Comment: In the resize method under win32 you have something like this: /* Move to the desired EOF position */ SetFilePointer (self->file_handle, new_size, NULL, FILE_BEGIN); /* Change the size of the file */ SetEndOfFile (self->file_handle); Which resizes the file Under Unix you need to call ftruncate(self->fileno, new_size) before calling remap() to make it do the same thing. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 22:12 Message: Logged In: YES user_id=1188172 This is not trivial since the filehandle can be closed at the time the ftruncate() would be necessary. The Windows specific code duplicates the filehandle upon mmap creation, perhaps the UNIX code should do this too? Then, the ftruncate call can be inserted. -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-31 01:51 Message: Logged In: YES user_id=752496 Reopened as posted that still is a bug. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 01:32 Message: Logged In: YES user_id=341410 The problem still persists in Python 2.3 and 2.4. A quick read of mmapmodule.c shows that ftruncate() is not being called within the non-windows portion of mmap_resize_method(). -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 20:59 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 18:55 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:36 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? Please make sure to include changes to the documentation and test suite. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&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-1212091 ] sets needs an 'arbitrary element' method
Feature Requests item #1212091, was opened at 2005-05-31 10:54 Message generated for change (Comment added) made by mkc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&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: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: sets needs an 'arbitrary element' method Initial Comment: It would be nice to have an "arbitrary element" method that would return some arbitrary element of a non-empty set (throwing an exception if the set is empty). Something like this >>> s = sets.Set([1,2,3]) >>> print s.element() 2 AFAIK, the current alternative would be to do something like this >>> print list(s)[0] which is somewhat expensive and unreadable. It'd be fine if the operator returned the same or a different element each time. Perhaps it'd be useful if it returned the same element each time for frozen sets. -- >Comment By: Mike Coleman (mkc) Date: 2005-06-03 15:45 Message: Logged In: YES user_id=555 I like rhettinger's "iter(s).next()" solution quite well, except that it's kind of an obscure way to say "give me an element of this set". I'm completely okay with the idea that the choose method may or may not return the same element each time--I just want a "for example" element. To my thinking, pop() isn't really a good solution because it treats sets and frozensets differently. Plus a pop()/add() cycle seems wasteful and confusing. One could argue that in the other place where pop() is available (lists), there is also a simple way to "peek" at what would be popped, which is kind of what we're talking about here. As for a use case, I'm not sure I have a great one. This came up when I was writing some union/find code. I was using sets to represent equivalence classes and I wanted to be able to grab a representative of a set (which would be any element of the set), given the set. I was surprised to find that there didn't seem to be a straightforward way to do this. I agree that I could just copy your 'choose' function into my code easily. There are several such functions that I already copy into pretty much every script I write these days (warn, error, and groupby, which probably do just what you think they do). If it's something that would be broadly useful, though, it seems like it'd be a lot more efficient for everyone to know the function by the same name (i.e., by having it be in the standard library). -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-31 11:54 Message: Logged In: YES user_id=80475 I had looked at putting in a choose() method but there were a shortage of use cases that were not better served by pop() or by iteration. Will leave this open as the request may yet prove its worth. To do so, I would need to see examples of practical code where choose() is a better choice than existing alternatives. For the record, here were some of the lines of thinking about choose(). * Given that any element could be returned, it was logical to return the first encountered. That led to the odd situation where the method would return the same value on every call (unless followed by a set mutation) making the method useless in a loop. * If needed, an efficient alternative is available: iter(s).next(). And here is a more readable, encapsulated version that a programmer could dash off in seconds: def choose(s, default=None): for elem in s: return elem return default * I had looked at a few textbook algorithms that were expressed in terms of choose(). Without exception, their Python code was better expressed using pop(), In a couple of cases, the pop() needed to be followed by an add() if the item was to be left in the set. Those two cases all had other set mutations occuring on each iteration (otherwise, the pop/add pair would always get the same element). -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 10:59 Message: Logged In: YES user_id=1188172 For mutable sets, I think that pop() is better suited. Do you have a use case of your proposal with frozensets? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix
Bugs item #728515, was opened at 2003-04-27 19:44 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) >Assigned to: Raymond Hettinger (rhettinger) Summary: mmap's resize method resizes the file in win32 but not unix Initial Comment: In the resize method under win32 you have something like this: /* Move to the desired EOF position */ SetFilePointer (self->file_handle, new_size, NULL, FILE_BEGIN); /* Change the size of the file */ SetEndOfFile (self->file_handle); Which resizes the file Under Unix you need to call ftruncate(self->fileno, new_size) before calling remap() to make it do the same thing. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 22:50 Message: Logged In: YES user_id=1188172 Attaching patch which duplicates the file handle under UNIX too (btw, the size() method was broken too), mimics Windows behaviour with resize(), adds a testcase for this and clarifies the docs. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 22:12 Message: Logged In: YES user_id=1188172 This is not trivial since the filehandle can be closed at the time the ftruncate() would be necessary. The Windows specific code duplicates the filehandle upon mmap creation, perhaps the UNIX code should do this too? Then, the ftruncate call can be inserted. -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-31 01:51 Message: Logged In: YES user_id=752496 Reopened as posted that still is a bug. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 01:32 Message: Logged In: YES user_id=341410 The problem still persists in Python 2.3 and 2.4. A quick read of mmapmodule.c shows that ftruncate() is not being called within the non-windows portion of mmap_resize_method(). -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 20:59 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 18:55 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:36 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? Please make sure to include changes to the documentation and test suite. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1212077 ] itertools.groupby ungraceful, un-Pythonic
Bugs item #1212077, was opened at 2005-05-31 10:34 Message generated for change (Comment added) made by mkc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212077&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.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: itertools.groupby ungraceful, un-Pythonic Initial Comment: The sharing of the result iterator by itertools.groupby leads to strange, arguably un-Pythonic behavior. For example, suppose we have a list of pairs that we're about to turn into a dict and we want to check first for duplicate keys. We might do something like this >>> [ (k,list(v)) for (k, v) in groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0]) ] [(1, [(1, 2), (1, 3)]), (2, [(2, 3)]), (3, [(3, 5)])] >>> [ (k,list(v)) for (k, v) in list(groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0])) ] [(1, []), (2, []), (3, [(3, 5)])] >>> [ (k,list(v)) for (k, v) in groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0]) if len(list(v)) > 1 ] [(1, [])] The first result looks good, but the second two silently produce what appear to be bizarre results. The second is understandable (sort of) if you know that the result iterator is shared, and the third I don't get at all. This silent failure seems very Perlish. At a minimum, if use is made of the "expired" result iterator, an exception should be thrown. This is a wonderfully useful function and ideally, there should be a version of groupby that behaves as a naive user would expect. -- >Comment By: Mike Coleman (mkc) Date: 2005-06-03 16:10 Message: Logged In: YES user_id=555 I didn't mean it as a rant. Sorry. I don't necessarily mind having an optimized version of groupby with sharp edges for the unawares, but it seems like a "friendly" version is actually at least as important and should therefore also be supplied. (Making an analogy with Lisp, having 'nconc' doesn't alleviate the need for an 'append'.) The friendly version of 'groupby' doesn't really have much to do with itertools--maybe it should be a basic builtin operator, like 'reduce'. With due respect, I don't think the examples I'm giving are at all cryptic or playing fast and loose with comprehension semantics. Rather, I'd argue that they demonstrate that the somewhat surprising semantics of itertools.groupby make it not entirely suitable for naive users. I'm really hoping for something here, as I've been copying a 'groupby' function (from the Python recipe collection) into my scripts now for quite a long time. I think this is a powerful and very much needed basic function, and I'd really like to see a broadly usable version of it incorporated. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-31 11:16 Message: Logged In: YES user_id=80475 Sorry, this is more of a rant than a bug report. The tool is functioning as designed and documented. The various design options were discussed on python-dev and this was what was settled on as the most useful, general purpose tool (eminently practical, but not idiotproof). Like other itertools, it can be used in a straight-forward manner or be used to write cryptic, mysterious code. In general, if you can't follow your own code (in situatations such as the above), a good first step is to unroll the list comprehension into a regular for-loop as that tends to make the assumptions and control flow more visible. Also, it can be taken as a hint that the itertool is not being used as intended. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212077&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1212900 ] Python segfaults on OpenBSD (tested 3.4 and 3.5)
Bugs item #1212900, was opened at 2005-06-01 17:33 Message generated for change (Comment added) made by fabinator You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212900&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Fabien Devaux (fabinator) Assigned to: Nobody/Anonymous (nobody) Summary: Python segfaults on OpenBSD (tested 3.4 and 3.5) Initial Comment: Here is a minimal case, launch the server and then the client (change the server ip on the client source). Under NetBSD it works as expected, under OpenBSD I get a big segfault at the "ping" time... -- >Comment By: Fabien Devaux (fabinator) Date: 2005-06-04 03:22 Message: Logged In: YES user_id=658447 ulimit -s returns "4096" with the limit set to 32000 I have the same error. -- Comment By: Martin v. Löwis (loewis) Date: 2005-06-03 19:49 Message: Logged In: YES user_id=21627 Looks like a stack overflow. What is the stack size limit in your account? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212900&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1214662 ] test_marshal.py discards marshal.load val
Bugs item #1214662, was opened at 2005-06-04 00:52 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=1214662&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: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: test_marshal.py discards marshal.load val Initial Comment: I'm working on making the marshal module work with any file-like object. It's proving a bit more difficult than I imagined it would be. At any rate, several of the various test_* methods are similar in structure to test_buffer: def test_buffer(self): for s in ["", "AndrË Previn", "abc", " "*1]: b = buffer(s) new = marshal.loads(marshal.dumps(b)) self.assertEqual(s, new) marshal.dump(b, file(test_support.TESTFN, "wb")) marshal.load(file(test_support.TESTFN, "rb")) self.assertEqual(s, new) os.unlink(test_support.TESTFN) I'm thinking that throwing away the result of marshal.load has to be an error (especially with the immediately following assert), and that it should really be: def test_buffer(self): for s in ["", "AndrË Previn", "abc", " "*1]: b = buffer(s) new = marshal.loads(marshal.dumps(b)) self.assertEqual(s, new) marshal.dump(b, file(test_support.TESTFN, "wb")) new = marshal.load(file(test_support.TESTFN, "rb")) self.assertEqual(s, new) os.unlink(test_support.TESTFN) Attached is a patch. I'd apply it but this apparent mistake is so pervasive that I thought it worth a double-check. Skip -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1214662&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
