[ python-Bugs-1517990 ] IDLE on macosx keybindings need work

2006-07-06 Thread SourceForge.net
Bugs item #1517990, was opened at 2006-07-06 10: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=1517990&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: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE on macosx keybindings need work

Initial Comment:
There is a serious issue with the keybindings for IDLE on OSX: a lot of 
them don't work correctly. One example of a not-working key-binding is 
'CMD-W', this should close the current window but doesn't.  'CMD-N' does 
create a new window though, so at least some keybindings work.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517990&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1517993 ] IDLE: config-main.def contains windows-specific settings

2006-07-06 Thread SourceForge.net
Bugs item #1517993, was opened at 2006-07-06 10:29
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=1517993&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE: config-main.def contains windows-specific settings

Initial Comment:
The default values in config-main.def contain values that are specific for 
Windows. This means that the key-bindings for other platforms, such as 
OSX will be wrong (because config-main selects the windows keybindings 
as the default keybindings).

I've worked around this by copying a mac version of config-main.def over 
the installed version of config-main.def from Mac/IDLE/Makefile.in. That 
is obviously a crude hack, but I know of no better solution.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517993&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1517996 ] IDLE (macosx): Class and Path browsers show Tk menu

2006-07-06 Thread SourceForge.net
Bugs item #1517996, was opened at 2006-07-06 10:34
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=1517996&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE (macosx): Class and Path browsers show Tk menu

Initial Comment:
I've done some work on fixing the menus for IDLE before 2.5b1, but 
recently found more toplevel windows that don't have their own menu.

Both the Path Browser and Class Browser don't have a menubar of their 
own. The Tk implementation on MacOSX won't accept an empty menubar, 
but will replace that by a generic Tk menubar.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1518190 ] c_void_pointer should accept a long pointer > 0x7fffffff

2006-07-06 Thread SourceForge.net
Bugs item #1518190, was opened at 2006-07-06 16: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=1518190&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: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: c_void_pointer should accept a long pointer > 0x7fff

Initial Comment:
Mike Fletcher reported this problem:

http://tinyurl.com/esneq

Currently, the c_void_p constructor calls
PyLong_AsVoidPtr(value), in Modules/_ctypes/cfield.c,
near line 1491.

This call should be changed to use either
PyLong_AsUnsignedLongMask() or
PyLong_AsUnsignedLongLongMask() depending on
sizeof(void *), and cast the result to (void *).

This change would also make the c_void_p behaviour more
consistent with the other c_int, c_long and so on
constructors since all of them mask the value to the
number of bits they can accept.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518190&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1518190 ] c_void_pointer should accept a long pointer > 0x7fffffff

2006-07-06 Thread SourceForge.net
Bugs item #1518190, was opened at 2006-07-06 16:46
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518190&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: c_void_pointer should accept a long pointer > 0x7fff

Initial Comment:
Mike Fletcher reported this problem:

http://tinyurl.com/esneq

Currently, the c_void_p constructor calls
PyLong_AsVoidPtr(value), in Modules/_ctypes/cfield.c,
near line 1491.

This call should be changed to use either
PyLong_AsUnsignedLongMask() or
PyLong_AsUnsignedLongLongMask() depending on
sizeof(void *), and cast the result to (void *).

This change would also make the c_void_p behaviour more
consistent with the other c_int, c_long and so on
constructors since all of them mask the value to the
number of bits they can accept.

--

>Comment By: Thomas Heller (theller)
Date: 2006-07-06 19:03

Message:
Logged In: YES 
user_id=11105

Assigning to Neal for review (please).  The #if block is not
really needed imo, but I used it for clarity - it is copied
verbatim from Objects/longobject.c, which would throw
compile errors if the conditions are not fulfilled.

--

Comment By: Thomas Heller (theller)
Date: 2006-07-06 18:56

Message:
Logged In: YES 
user_id=11105

Attached a patch, with tests, that fixes this bug.
PyInt_AsUnsignedLongMask() and
PyInt_AsUnsignedLongLongMask() is what we need to use.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518190&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1515998 ] bdist_msi fails (egg-info)

2006-07-06 Thread SourceForge.net
Bugs item #1515998, was opened at 2006-07-02 22:44
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515998&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: Paul Moore (pmoore)
Assigned to: Martin v. Löwis (loewis)
Summary: bdist_msi fails (egg-info)

Initial Comment:
If I try to build a bdist_msi installer for a trivial
module, using Python 2.5b1, I get an error.

It looks like a problem with the interaction of the new
(in 2.5) egg-info stuff and the bdist_msi code - but I
have no further ideas.
Here is the setup.py

from distutils.core import setup
setup(
   name='test',
   version='1.0',
   py_modules=['test'],
)

And here is the build output:

>python setup.py bdist_msi
running bdist_msi
running build
running build_py
creating build
creating build\lib
copying test.py -> build\lib
installing to build\bdist.win32\msi
running install_lib
creating build\bdist.win32
creating build\bdist.win32\msi
creating build\bdist.win32\msi\Lib
creating build\bdist.win32\msi\Lib\site-packages
copying build\lib\test.py ->
build\bdist.win32\msi\Lib\site-packages
running install_egg_info
Writing
build\bdist.win32\msi\Lib\site-packages\test-1.0-py2.5.egg-info
creating dist
Traceback (most recent call last):
 File "setup.py", line 5, in 
   py_modules=['test'],
 File "D:\Apps\Python25\Lib\distutils\core.py", line
151, in setup
   dist.run_commands()
 File "D:\Apps\Python25\Lib\distutils\dist.py", line
974, in run_commands
   self.run_command(cmd)
 File "D:\Apps\Python25\Lib\distutils\dist.py", line
994, in run_command
   cmd_obj.run()
 File
"D:\Apps\Python25\Lib\distutils\command\bdist_msi.py",
line 235, in run
   self.add_files()
 File
"D:\Apps\Python25\Lib\distutils\command\bdist_msi.py", line
263, in add_files
   key = dir.add_file(file)
 File "D:\Apps\Python25\Lib\msilib\__init__.py", line
343, in add_file
   language, attributes, sequence)])
 File "D:\Apps\Python25\Lib\msilib\__init__.py", line
115, in add_data
   raise MSIError("Could not insert "+repr(values)+"
into "+table)
_msi.MSIError: Could not insert [(None, 'site_packages',
'TEST-1~1.EGG|test-1.0-py2.5.egg-info', 186L, None,
None, 512, 1)]
into File


--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-07-06 21:28

Message:
Logged In: YES 
user_id=21627

Thanks for the report. This is now fixed in r47280.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515998&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1518346 ] cookielib doku

2006-07-06 Thread SourceForge.net
Bugs item #1518346, was opened at 2006-07-06 21:31
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=1518346&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: cookielib doku

Initial Comment:
The cookielib doku says in 17.22
(http://docs.python.org/dev/lib/module-cookielib.html)
".. the max-age and port cookie-attributes introduced
with RFC 2109..."

The port cookie-attribute woth introduced with RFC
2965, not RFC 2109.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518346&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1518346 ] cookielib doku port cookie-attribute

2006-07-06 Thread SourceForge.net
Bugs item #1518346, was opened at 2006-07-06 21:31
Message generated for change (Settings changed) made by cito
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518346&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.5
Status: Open
Resolution: None
>Priority: 1
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
>Summary: cookielib doku port cookie-attribute

Initial Comment:
The cookielib doku says in 17.22
(http://docs.python.org/dev/lib/module-cookielib.html)
".. the max-age and port cookie-attributes introduced
with RFC 2109..."

The port cookie-attribute woth introduced with RFC
2965, not RFC 2109.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518346&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1518406 ] re '\' char interpretation problem

2006-07-06 Thread SourceForge.net
Bugs item #1518406, was opened at 2006-07-06 16: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=1518406&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ollie oldham (ooldham)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re '\' char interpretation problem

Initial Comment:
I've run across 2 problems having to do with '\' 
character problems with the re module.

Problem 1 does not match the re when it should have.
Problem 2 matches, when it should not have.

There is a short snippet of code attached that shows 
the problems I'm having, and the output as it occurs 
on my machine.

I'm running on Windows 2000
Python versions: 2.4b1 and 2.4.3c1 both act the same 
way.

Problem (1) : why does * work and not + ?
import re
rex = re.compile(r'[a-z]:\.*', re.IGNORECASE)
rey = re.compile(r'[a-z]:\.+', re.IGNORECASE)
path1 = r'D:\Logs'
print rex.match(path1) # Matches - as it should have.
print rey.match(path1) # FAILES to match - should have.

Problem 2) : match occurs on nonUncPath when it should 
not
import re
uncPath = r'\\someUNC\path'
nonUncPath = r'\nonUnc\path'
rew = re.compile('.+', re.IGNORECASE)
print rew.match(uncPath) # works as it should.
print rew.match(nonUncPath) # matches and it should 
NOT.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518406&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1518406 ] re '\' char interpretation problem

2006-07-06 Thread SourceForge.net
Bugs item #1518406, was opened at 2006-07-06 21:26
Message generated for change (Comment added) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518406&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.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: ollie oldham (ooldham)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re '\' char interpretation problem

Initial Comment:
I've run across 2 problems having to do with '\' 
character problems with the re module.

Problem 1 does not match the re when it should have.
Problem 2 matches, when it should not have.

There is a short snippet of code attached that shows 
the problems I'm having, and the output as it occurs 
on my machine.

I'm running on Windows 2000
Python versions: 2.4b1 and 2.4.3c1 both act the same 
way.

Problem (1) : why does * work and not + ?
import re
rex = re.compile(r'[a-z]:\.*', re.IGNORECASE)
rey = re.compile(r'[a-z]:\.+', re.IGNORECASE)
path1 = r'D:\Logs'
print rex.match(path1) # Matches - as it should have.
print rey.match(path1) # FAILES to match - should have.

Problem 2) : match occurs on nonUncPath when it should 
not
import re
uncPath = r'\\someUNC\path'
nonUncPath = r'\nonUnc\path'
rew = re.compile('.+', re.IGNORECASE)
print rew.match(uncPath) # works as it should.
print rew.match(nonUncPath) # matches and it should 
NOT.


--

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2006-07-06 21:36

Message:
Logged In: YES 
user_id=7887

1) r'[a-z]:\.+' should not match r'D:\Logs'. r'\.+' matches
one or more dots. There's no dot in this string.

2) '.+' is the equivalent of r'\\.+', and should match
anything that starts with a '\' and has at least one char
following it, which includes r'\nonUnc\path'.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518406&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1518406 ] re '\' char interpretation problem

2006-07-06 Thread SourceForge.net
Bugs item #1518406, was opened at 2006-07-06 16:26
Message generated for change (Comment added) made by ooldham
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518406&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.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: ollie oldham (ooldham)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re '\' char interpretation problem

Initial Comment:
I've run across 2 problems having to do with '\' 
character problems with the re module.

Problem 1 does not match the re when it should have.
Problem 2 matches, when it should not have.

There is a short snippet of code attached that shows 
the problems I'm having, and the output as it occurs 
on my machine.

I'm running on Windows 2000
Python versions: 2.4b1 and 2.4.3c1 both act the same 
way.

Problem (1) : why does * work and not + ?
import re
rex = re.compile(r'[a-z]:\.*', re.IGNORECASE)
rey = re.compile(r'[a-z]:\.+', re.IGNORECASE)
path1 = r'D:\Logs'
print rex.match(path1) # Matches - as it should have.
print rey.match(path1) # FAILES to match - should have.

Problem 2) : match occurs on nonUncPath when it should 
not
import re
uncPath = r'\\someUNC\path'
nonUncPath = r'\nonUnc\path'
rew = re.compile('.+', re.IGNORECASE)
print rew.match(uncPath) # works as it should.
print rew.match(nonUncPath) # matches and it should 
NOT.


--

>Comment By: ollie oldham (ooldham)
Date: 2006-07-06 17:46

Message:
Logged In: YES 
user_id=649833

I beg to differ on problem 1)

Since ‘r’ was used in the definition of both the re and 
path, the ‘.’ Char is not being escaped (not supposed to be 
anyway).
And even if it is, then rex=re.compile(‘[a-z]:\\.+’, 
re.IGNORECASE) should get me what I want (in textual form:: 
char a-z colon backslash with 1 or more trailing chars).
But that does not work either.

I beg to differ on item 2) as well:
Yes - '.+' is the equivalent of r'\\.+'
BUT I then read this as: 2 backslashes with 1 or more 
chars – NOT backslash with escaped ‘.’


--

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2006-07-06 16:36

Message:
Logged In: YES 
user_id=7887

1) r'[a-z]:\.+' should not match r'D:\Logs'. r'\.+' matches
one or more dots. There's no dot in this string.

2) '.+' is the equivalent of r'\\.+', and should match
anything that starts with a '\' and has at least one char
following it, which includes r'\nonUnc\path'.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518406&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1518406 ] re '\' char interpretation problem

2006-07-06 Thread SourceForge.net
Bugs item #1518406, was opened at 2006-07-06 21:26
Message generated for change (Comment added) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518406&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.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: ollie oldham (ooldham)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re '\' char interpretation problem

Initial Comment:
I've run across 2 problems having to do with '\' 
character problems with the re module.

Problem 1 does not match the re when it should have.
Problem 2 matches, when it should not have.

There is a short snippet of code attached that shows 
the problems I'm having, and the output as it occurs 
on my machine.

I'm running on Windows 2000
Python versions: 2.4b1 and 2.4.3c1 both act the same 
way.

Problem (1) : why does * work and not + ?
import re
rex = re.compile(r'[a-z]:\.*', re.IGNORECASE)
rey = re.compile(r'[a-z]:\.+', re.IGNORECASE)
path1 = r'D:\Logs'
print rex.match(path1) # Matches - as it should have.
print rey.match(path1) # FAILES to match - should have.

Problem 2) : match occurs on nonUncPath when it should 
not
import re
uncPath = r'\\someUNC\path'
nonUncPath = r'\nonUnc\path'
rew = re.compile('.+', re.IGNORECASE)
print rew.match(uncPath) # works as it should.
print rew.match(nonUncPath) # matches and it should 
NOT.


--

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2006-07-06 22:55

Message:
Logged In: YES 
user_id=7887

Please, use a single way to report issues. Do not message
*and* add a comment to the bug.

I think you're missing the behavior of r'' in Python. It
changes the way the Python interpreter parses the string,
not the way the regular expression compiler/interpreter
works. r'\.' is precisely the same as '\\.', and both of
them really describe the string |\.|.

  >>> r'\.' == '\\.'
  True

  >>> print r'\.'
  \.

Escaping a dot means a real dot. Please have a look at the
re module documentation and perhaps some general regular
expression info for more details.


--

Comment By: ollie oldham (ooldham)
Date: 2006-07-06 22:46

Message:
Logged In: YES 
user_id=649833

I beg to differ on problem 1)

Since ‘r’ was used in the definition of both the re and 
path, the ‘.’ Char is not being escaped (not supposed to be 
anyway).
And even if it is, then rex=re.compile(‘[a-z]:\\.+’, 
re.IGNORECASE) should get me what I want (in textual form:: 
char a-z colon backslash with 1 or more trailing chars).
But that does not work either.

I beg to differ on item 2) as well:
Yes - '.+' is the equivalent of r'\\.+'
BUT I then read this as: 2 backslashes with 1 or more 
chars – NOT backslash with escaped ‘.’


--

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2006-07-06 21:36

Message:
Logged In: YES 
user_id=7887

1) r'[a-z]:\.+' should not match r'D:\Logs'. r'\.+' matches
one or more dots. There's no dot in this string.

2) '.+' is the equivalent of r'\\.+', and should match
anything that starts with a '\' and has at least one char
following it, which includes r'\nonUnc\path'.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518406&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1518453 ] '\' problem in re.sub

2006-07-06 Thread SourceForge.net
Bugs item #1518453, was opened at 2006-07-06 20:03
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=1518453&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: ilan29 (ilan29)
Assigned to: Nobody/Anonymous (nobody)
Summary: '\' problem in re.sub

Initial Comment:
#! /usr/bin/env python
import re

# Pattern only to match character 'b'
p = re.compile('b')

# Replace 'b' with SINGLE literal backslash
print p.sub( '\\', 'b', 1 )


I'm running:
   Python 2.4.3 (#1, Jun 11 2006, 12:01:42) 
   [GCC 3.3.4 (pre 3.3.5 20040809)] on linux2

When starting the progam it raises:
sre_constants.error: bogus escape (end of line)


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518453&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1512604 ] Install on Windows Vista locks up

2006-07-06 Thread SourceForge.net
Bugs item #1512604, was opened at 2006-06-26 11:15
Message generated for change (Comment added) made by plathem
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512604&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Lucas (michael_lucas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install on Windows Vista locks up

Initial Comment:
I have had problems trying to install this version on 
Vista. When the install gets to the verifying disk 
space requirements the system locks up. It does not go 
any further. I have to cancel the instalation of 
python. The only way I have got around this is to 
install an older version of python (version 2.3.5) 
this version does work, but there are newer versions 
that I want to work with on my system. If anyone has a 
work around for this please contact me at 
[EMAIL PROTECTED]

--

Comment By: Pat Lathem (plathem)
Date: 2006-07-07 01:51

Message:
Logged In: YES 
user_id=661716

FWIW, this can be worked around by using the command-line
MSI installer:

msiexec /i python-2.4.3.msi TARGETDIR="C:\Program
Files\Python24"
ALLUSERS=1 /qb

Found that here:
http://mail.python.org/pipermail/python-list/2006-June/347402.html

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-06-29 18:48

Message:
Logged In: YES 
user_id=21627

I can confirm the problem, but I doubt I can do much about it.

In fact, I believe this is a bug in Vista/Windows Installer
4.0.  The installer GUI waits for the CostingComplete
property to be set, but this never happens.

If you are a beta tester, please make a bug report to Microsoft.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512604&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1512604 ] Install on Windows Vista locks up

2006-07-06 Thread SourceForge.net
Bugs item #1512604, was opened at 2006-06-26 13:15
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512604&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Lucas (michael_lucas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install on Windows Vista locks up

Initial Comment:
I have had problems trying to install this version on 
Vista. When the install gets to the verifying disk 
space requirements the system locks up. It does not go 
any further. I have to cancel the instalation of 
python. The only way I have got around this is to 
install an older version of python (version 2.3.5) 
this version does work, but there are newer versions 
that I want to work with on my system. If anyone has a 
work around for this please contact me at 
[EMAIL PROTECTED]

--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-07-07 07:08

Message:
Logged In: YES 
user_id=21627

That's actually no surprise: /qb disables the user
interface, so that the problematic interaction is skipped
entirely.

--

Comment By: Pat Lathem (plathem)
Date: 2006-07-07 03:51

Message:
Logged In: YES 
user_id=661716

FWIW, this can be worked around by using the command-line
MSI installer:

msiexec /i python-2.4.3.msi TARGETDIR="C:\Program
Files\Python24"
ALLUSERS=1 /qb

Found that here:
http://mail.python.org/pipermail/python-list/2006-June/347402.html

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-06-29 20:48

Message:
Logged In: YES 
user_id=21627

I can confirm the problem, but I doubt I can do much about it.

In fact, I believe this is a bug in Vista/Windows Installer
4.0.  The installer GUI waits for the CostingComplete
property to be set, but this never happens.

If you are a beta tester, please make a bug report to Microsoft.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512604&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com