At the present time (Py2.4):
"""
Under Unix, if the environment variable BROWSER exists,
it is 
interpreted to override the platform default list of
browsers,...
"""
(extract from
Python-2.4/Doc/html/lib/module-webbrowser.html)

But, when the environment variable BROWSER is messed up,
there is no reason not to try the other detected
browser alternatives.

In this patch, if the BROWSER variable is Ok, than it
is respected.
Otherwise, the previously detected browsers are tryied
out as if
BROWSER variable never existed.

This does not break backward compatibility and adds
more chance
for webbrowser.open() to succeed.

This patch was made against CVS head 2005-03-20, and
aims to 2.5, but can safely be apllied to any 2.4.x bug
fix release.

Logged In: YES 
user_id=488897

I agree that this patch will improve chances that
webbrowser.open() will succeed. I'm a bit worried though
that if a user sets BROWSER incorrectly, it may cause some
confusion to see another browser opening. So we might some
some bug reports saying "webbrowser.py ignores BROWSER
variable" because a user set BROWSER incorrectly. One
solution might be to print some warning message if the
browser specified in BROWSER cannot be used.
(I'm just a patch reviewer, not an official Python
developer, so you don't need to take my comment to seriously
:-)).

Logged In: YES 
user_id=9057

Michiel de Hoon,

this patch is obsolete after the latest revision of patch
 [ 754022 ] Enhanced webbrowser.py, that integrates this
functionality and others in a single patch.

Moreover, if a user sets BROWSER incorrectly, to see another
browser opening will probably lead him to find that BROWSER
was set incorrectly.
IMO it is better to see a different browser opening than no
browser at all. But thank you for revising this patch.

Logged In: YES 
user_id=89016

If this patch is subsumed by 754022 can we close this one?

Logged In: YES 
user_id=9057

Closed because it is subsumed by 754022 

Python 2.4's compile.c contained a fix for large octal literals and 
int/long unification. 
 
This patch duplicates that fix in the ast-branch's ast.c 

Logged In: YES 
user_id=357491

Applied in rev. 1.1.2.56 .

Thanks, Nick.

Now we just need to get genexps working for test_grammar to get farther.  
=)

According to gettext(3), "LANGUAGE is assumed to
contain a colon separated list of  locale  names.". Fix
it by taking the string up to the first colon as
localename.

Logged In: YES 
user_id=60903

checked in as
  Lib/locale.py: 1.32 (HEAD)
  Lib/locale.py: 1.28.4.2 (2.4 branch)

locale.getdefaultencoding checks first LANGUAGE, then
the LC_* and LANG variables. Assume LANGUAGE is set to
en:de, and LANG to en_US.utf-8, then getdefaultencoding
returns the wrong encoding (ISO8859-1).

AFAIK, LANGUAGE is specific to gettext (GNU extension),
and IMO should not interfer with getting the correct
encoding.

This patch uses LANGUAGE as the choice with the lowest
priority, so the other variables to determine the
locale and encoding take precedence (LC_ALL, LC_CTYPE,
LANG).

There's another (minor) bug in the implementation:
LANGUAGE is honoured even if the default locale is "C".

Logged In: YES 
user_id=1188172

This file is one big patch for #1166938, #1166948 and #1166957.

Logged In: YES 
user_id=60903

checked in as
  Lib/locale.py: 1.32 (HEAD)
  Lib/locale.py: 1.28.4.2 (2.4 branch)

checked with glibc-2.3.2 on a Debian/sarge system. The
locale_alias and the encoding_alias tables map the
encoding from utf-8, utf8 to utf, which is not a valid
encoding, at least on this system.

LANG=de_DE.utf-8 python -c 'import locale;
locale.resetlocale()'
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "/usr/lib/python2.3/locale.py", line 391, in
resetlocale
    _setlocale(category,
_build_localename(getdefaultlocale()))
locale.Error: unsupported locale setting

Logged In: YES 
user_id=1188172

This file is one big patch for #1166938, #1166948 and #1166957.

Logged In: YES 
user_id=60903

already fixed on HEAD, rejected for the branch

Simple-minded fix to reflow when line doesn't contain a
' ' before the wrap column

Logged In: YES 
user_id=357491

I just raised max length to 80 in last commit.

Closed as out of date.

OS: linux

If you use tarfile.py to create a tarfile with a
symbolic link followed by a regular file, then use gnu
tar to list the contents you will see:

tar tvf archives/test1.my.tar
	lrwxrwxrwx andrew/dev        3 2005-03-20 16:00:35
barlink -> bar
	tar: Skipping to next header
	tar: Error exit delayed from previous errors

I have traced the problem down to the size field in the
tar header being set to the length of the link target
name, not zero as it should be.

I have put an extended description and proof of this at:

http://software.ellerton.net/supertar/README.txt
http://software.ellerton.net/supertar/PythonTarPatchProof.tar

The patch file attached fixes this by setting size == 0
if filetype == SYMLINK, and verified this works
perfectly on linux.

CAUTION: I don't know, though I can fairly safely
assume, that this will work also on other unix's.

(Shameless plug: this is where the supertar utility
is/will be: http://software.ellerton.net/supertar/ )

Logged In: YES 
user_id=642936

The size for a non-regular file is already set to zero but
at the wrong place. It is currently done in the add() method
and not in gettarinfo() as it should be. Since you use the
addfile() and gettarinfo() methods in your test script, you
get unwanted results.

I submitted patch #1168594 that fixes the whole problem in a
more generic way and is closely related to the fix for bug
#1031148 from last year.

Logged In: YES 
user_id=21627

Following gustaebel's recommendation, I reject this patch, and will accept 
1168594 instead.

Logged In: YES 
user_id=1046139

I don't mind which patch is accepted, so long as all uses
where a symlink is added results in the correct result, i.e.
size==0  :)

Logged In: YES 
user_id=21627

I have now committed #1168594, both for 2.4 and 2.5.

When doctest.py is ran without arguments, it runs its
own docs
through itself and crashes with:

bagira:~/python/dist/src/Lib> ../python doctest1.121.py
...............F
======================================================================
FAIL: Doctest: __main__.set_unittest_reportflags
----------------------------------------------------------------------
Traceback (most recent call last):
  File "doctest1.121.py", line 2152, in runTest
    raise
self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for
__main__.set_unittest_reportflags
  File "doctest1.121.py", line 2068, in
set_unittest_reportflags

----------------------------------------------------------------------
File "doctest1.121.py", line 2080, in
__main__.set_unittest_reportflags
Failed example:
    doctest._unittest_reportflags == (REPORT_NDIFF |
                                     
REPORT_ONLY_FIRST_FAILURE)
Expected:
    True
Got:
    False


----------------------------------------------------------------------
Ran 16 tests in 0.080s

FAILED (failures=1)

----------------------------------------------------------------------

The attached patch fixes the problem...

Logged In: YES 
user_id=488897

I tested this patch and found that it works OK. I'll write
to python-dev in support of this patch.
--Michiel.

Logged In: YES 
user_id=31435

Thanks!  Patch applied, Lib/doctest.py rev 1.122

Adds generator expression support to the AST branch. 
Support is sufficient to allow test_grammar to pass. 
 
Also eliminates the display of interim results within functions 
compiled at the interactive prompt, and the allocation of large 
amounts of memory when zero is passed to asdl_seq_new. 

Logged In: YES 
user_id=22785

This triggers an assert with a genexp in an argument because
the node is not a testlist_gexp, e.g. foo(i for i in
range(5)).  It's unclear what to do with foo(a = i for i in
range(5); see bug # 1167751

Logged In: YES 
user_id=1038590

I did wonder about that, but the assert wasn't triggering
for me. The offending line is REQ(n, testlist_gexpr) in
ast_for_genexp.

I'll setup a debug build to check all of the assertions
properly.

Logged In: YES 
user_id=1038590

I'm actually wondering if the grammar is entirely correct
here. Really, what is allowed for an argument is:

argument: test [gen_for | ('=' test)]

But that still permits generator expressions that are not
the sole argument. So I'd be tempted to move the 'gen_for'
up to the arglist level:

arglist: (test gen_for) | ((argument ',')* (argument [','] |
'*' test [',' '**' test] |  '**' test))
argument: test ['=' test]

As it is, I simply have a check in ast_gen_exp which imposes
the above rule (i.e. a generator expression as an argument
must be the sole argument, or parenthesised so that it
becomes a 'test' node in its own right)

Logged In: YES 
user_id=1038590

Updated patch ast_genexp_2.diff which correctly allows generator 
expressions to be part of a testlist_gexp node or an argument node. 
 
Removed old patch which failed for debug builds. 

Logged In: YES 
user_id=1038590

Correcting a previous comment: the check that ensures an 
unparenthesised generator expression is a sole argument is in 
ast_for_call. 

Logged In: YES 
user_id=1038590

I'm going to be out of the country until late next week, so
if you want to incorporate this (or parts of it) into the
PyCon AST sprint, please do. I'll be interested to see the
results of the sprint when I get back.

Logged In: YES 
user_id=357491

OK, I have applied the patch and tweaked it some, but I have
no committed yet because I can't run test_grammar to
completion yet; need to get to the other patches before I
can get that far.

Couple comments on the patch, though, Nick.  First, please
use unified diffs if you can.  I personally find them easier
to read and they are the agreed-upon standard for patches. 
Another is to please use PEP 7 as a coding guideline when
possible.  And if the surrounding code isn't huge and breaks
the coding standard please fix it.  I am going to go through
and fix all the code eventually during final code review,
but whatever can get done now would be great.

And now I see what you mean about the grammar for genexps. 
All of that duplicate work between listcomps and genexps
just because of some REQ() statements seems wasteful.

Thanks for the hard work on the AST branch so far!

Logged In: YES 
user_id=357491

OK, I went ahead and applied the patch realizing that if I
waited until test_grammar didn't segfault I would have one
massive commit and that would be bad.

So applied as rev. 1.1.2.12 for Python-ast.(c|h), 1.1.2.6
for asdl.c, 1.1.2.59 for ast.c, 2.247.2.3 for compile.c,
1.1.2.106 for newcompile.c, 2.10.8.32 for symtable.c,
1.1.2.11 for Python.asdl, 1.1.2.7 for asdl_c.py, and
1.1.2.14 for compile.txt .

I also went ahead and cleaned up all references to
GeneratorComp to be GeneratorExp instead.

Once again, thanks, Nick, for the patch!

This patch adds the generation of AST nodes for
decorators.  There is no compiler support for
decorators yet.  Note I also added support for ignoring
NULL's passed to the *_free functions generated by
asdl_c.py so that error handling is somewhat simplified.

Logged In: YES 
user_id=22785

This doesn't quite work.  I just realized when working on
the compiler portion that @foo is different than @foo().

Logged In: YES 
user_id=22785

New patch that handles @dottedname correctly and implements
bytecode generation.  The test_decorators test passes.

Logged In: YES 
user_id=35752

Thanks for the patch.  The only change I made was to change
// comments
to /* ... */ comments.

path for bug 1121494

for distutils.dir_utils.mkpath(name... function

changed name argument to support unicode

Logged In: YES 
user_id=21627

The patch is fine. I'll apply it after 2.4.1 is released.

Logged In: YES 
user_id=21627

Thanks for the patch. Committed as

NEWS 1.1347
dir_util.py 1.16
dir_util.py 1.15.2.1
NEWS 1.1193.2.83

The try_run function in command/config.py is used to
run a test program as part of configuring an extension
module with "python setup.py config" before running
"python setup.py build". When running the test program,
the current directory is not included in the program
name. So it attempts to run _configtest instead of
./_configtest. This works fine as long as the user has
the current directory in the path. If not, the attempt
to run _configtest fails. The patch adds the current
directory in front of _configtest, so that the program
runs even if the user does not have the current
directory in the path.

Phillip, any thoughts?

Sorry, I've never used the "config" command nor seen any code that does, nor any documentation for it.  I didn't even know it was actually usable.

The OP's rationale for the change sounds reasonable to me, but a quick skim of the module doesn't convince me that it'll fix the problem correctly, vs. e.g. using os.path.abspath().  One thing that bugs me is why the program's being created in the current directory instead of the build/ directory in the first place.  ISTM that there's a lot more that's broken here.   OTOH, I don't suppose the patch would make things any worse.  It would be nice if the original author of the module were around.

Closing based on PJE's comment.

This patch provides a better solution to the problem
discussed in item #1167128.

Logged In: YES 
user_id=21627

Can you please provide a test case for this bug?

Logged In: YES 
user_id=642936

Here it is. I hope it is sufficient.

Logged In: YES 
user_id=21627

Thanks for the fix and the test case, committed as

tarfile.py 1.32
test_tarfile.py 1.19
NEWS 1.1357
tarfile.py 1.21.2.5
test_tarfile.py 1.16.2.1
NEWS 1.1193.2.90

This is on Fedora Core 3.

RPM automatically gzips man pages after the %install
stage. So any generated file lists MUST substitute .gz
filenames for non-.gz filenames for man pages, or the
file check stage that happens just before writing the
RPM out, will fail.

Attached patch is a 'quick hack' using sed, to solve
this issue. Improvements welcome.