date:20090609


Martin v. Löwis  added the comment:

Steven Bethard wrote:
> In particular, the
> optparse extension API is horribly designed, and exposes so many
> internals of optparse that it's nearly impossible to add any new
> features to optparse without breaking this.

It would be useful if several people could confirm that argparse
is *not* horribly designed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6250] Python compiles dead code


Raymond Hettinger  added the comment:

We've rejected dead-code elimination in the past (too much effort for
nearly zero benefit).  Will take a look at your patch though.

--
assignee:  -> rhettinger
nosy: +rhettinger
priority:  -> low
type:  -> performance

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6249] Error Prompt

2009-06-09 Thread Georg Brandl


Georg Brandl  added the comment:

Please consult a Python mailing list or newsgroup to learn how to use
the command box.  This is not a Python bug.

--
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4749] Issue with RotatingFileHandler logging handler on Windows


Vinay Sajip  added the comment:

The problem may occur just because of the way file handles work with
child processes. I'm not sure if it's a bug, or even if it's specific to
Python, so I'm not going to raise another issue. It's worth searching to
see if there's an existing issue about it, though.

Anyone can raise a new bug; you just log in and click on "Create New"
under "Issues" in the menu on the left of the page. I would suggest that
you research the issue first to see if it's previously been raised on
this tracker, or in c.l.py, or on the wider Internet.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6250] Python compiles dead code

2009-06-09 Thread James Abbatiello


New submission from James Abbatiello :

Python currently emits bytecode for code that is unreachable (e.g.
following a return statement).  This doesn't hurt anything but it takes
up space doing nothing.

This patch attempts to avoid generating any bytecode in this situation.
 There's an optional warning, enabled with the -r command line switch,
which notifies you if any unreachable code is found.  Running
regrtest.py with this switch produces a bit of noise but also revealed
issue6227 which looks like a real bug.

--
components: Interpreter Core
files: deadcode.patch
keywords: patch
messages: 89183
nosy: abbeyj, collinwinter, jyasskin, pitrou
severity: normal
status: open
title: Python compiles dead code
versions: Python 2.7
Added file: http://bugs.python.org/file14252/deadcode.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6247] should we include argparse

2009-06-09 Thread Steven Bethard


Steven Bethard  added the comment:

I'm happy to contribute argparse to the standard library and volunteer
to maintain it.

For what it's worth, I don't agree that there are already too many
argument parsing libraries in the standard library. I do agree that
there are already too many *option* parsing libraries. But both getopt
and optparse don't know how to parse positional arguments at all. For
example, if your program usage looks like:

prog eggs [spam] [baz [baz [...]]]

then getopt and optparse are worthless to you - they'll just return
sys.argv[1:] since there are no options. The argparse module, on the
other hand, can correctly parse out "eggs", "spam" and the "baz" list
into appropriate attributes (in addition to doing all the other stuff
that optparse does).

I also don't think there's much of a chance of optparse ever growing
most of the argparse features. When I started argpasre, my goal was
exactly that - to keep the module fully backwards compatible with
optparse and just to add the missing features. The optparse code just
wasn't written in a way that allowed me to do that. In particular, the
optparse extension API is horribly designed, and exposes so many
internals of optparse that it's nearly impossible to add any new
features to optparse without breaking this.

--
nosy: +bethard

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5437] Singleton MemoryError can hold traceback data and locals indefinitely


Alexandre Vassalotti  added the comment:

Honestly, I don't think it is a big issue. MemoryErrors are rare and
typically cause the interpreter to shutdown.

By the way, do you think the static PyExc_RecursionErrorInst object is
affected by this bug?

--
nosy: +alexandre.vassalotti

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1032] Improve the hackish runtime_library_dirs support for gcc


Changes by Alexandre Vassalotti :


--
resolution:  -> duplicate
status: open -> closed
superseder:  -> GCC detection for runtime_library_dirs when ccache is used

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4749] Issue with RotatingFileHandler logging handler on Windows


Robert Cronk  added the comment:

Vinay - that's great news!  Are you going to create a new bug for this issue 
with a proper title?  It would seem to me that the fix for this would be to put 
locks internal to the os.system() call around where it spawns cmd so multiple 
spawns don't occur simultaneously.

Is the proper procedure at this point to open a new bug with a more correct 
title that points back to this bug for reference?  Can you do that Vinay?  I 
don't know if I have the authority (nor experience with the bug tracking 
system) to do that.  Thanks.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1254718] GCC detection for runtime_library_dirs when ccache is used


Raymond Hettinger  added the comment:

FWIW, min() can usually be substituted for any().

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1254718] GCC detection for runtime_library_dirs when ccache is used

2009-06-09 Thread Seo Sanghyeon


Seo Sanghyeon  added the comment:

any() built-in is new in 2.5. PEP 291 specifies 2.3 compatibility for
distutils. (tarek: Why?) The original patch used str.find because
backward-compatibility requirement used to be stricter.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6249] Error Prompt

2009-06-09 Thread SonMarvin


New submission from SonMarvin :

When I open a Python File Prompt closes it quickly.My friends do not
have this problem. Now reinstall, download older versions and the
problem continued.

--
components: Windows
messages: 89177
nosy: SonMarvin
severity: normal
status: open
title: Error Prompt
versions: Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1254718] GCC detection for runtime_library_dirs when ccache is used

2009-06-09 Thread Jason Kankiewicz


Jason Kankiewicz  added the comment:

I've updated my patch to resemble the patch from issue1032 and also
because profiling showed that using str.__contains__ is more efficient
than using str.find.

--
Added file: http://bugs.python.org/file14251/distutils-rpath-gcc_and_icc.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1254718] GCC detection for runtime_library_dirs when ccache is used

2009-06-09 Thread Jason Kankiewicz


Changes by Jason Kankiewicz :


Removed file: http://bugs.python.org/file14250/distutils-rpath-gcc_and_icc.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1254718] GCC detection for runtime_library_dirs when ccache is used

2009-06-09 Thread Jason Kankiewicz


Jason Kankiewicz  added the comment:

I've attached a patch, based on the original, that will fix distutils
for both GCC and ICC.

--
nosy: +jkankiewicz
Added file: http://bugs.python.org/file14250/distutils-rpath-gcc_and_icc.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4749] Issue with RotatingFileHandler logging handler on Windows


Changes by Vinay Sajip :


--
resolution:  -> invalid
status: open -> closed
Added file: http://bugs.python.org/file14249/python-io-capture.log

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4749] Issue with RotatingFileHandler logging handler on Windows


Changes by Vinay Sajip :


Added file: http://bugs.python.org/file14248/thredio.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4749] Issue with RotatingFileHandler logging handler on Windows


Vinay Sajip  added the comment:

I've just run a test several times - it's your original script with
joins added at the end. I kept the acquire_lock and release_lock calls
but made them only do anything if a constant USE_LOCK was True. I set
this to False, so that no locking is actually occurring.

My earlier tests had run with Windows indexing not turned off properly
(there's an option to turn off for all subfolders which I mistakenly
didn't select, so that I had only turned it off on the root folder).
Now, I've turned off search indexing for the entire volume, as well as
the anti-virus, and re-run the tests. I also found that the TortoiseSVN
Windows shell extension sometimes scans files if you are working inside
a directory which is part of an SVN checkout, so I was careful to work
outside any SVN tree.

I also ran SysInternals filemon. I attach the log: it appears to show
that a SHARING VIOLATION (the WindowsError 32) is occurring specifically
because of interaction with a spawned os.system child process. However,
this does not appear to be logging-specific: my conjecture is that when
the cmd.exe is spawned, it inherits file handles from the parent process
(the Python process which is doing the logging). When cmd.exe exits, it
closes all its open file handles, thereby pulling the rug out from under
the Python process.

To confirm this, I created another script, thredio.py, which does not
use logging but does the equivalent I/O operations (including using a
threading lock around them to serialise access from the threads - but
there is no locking around the os.system() calls).

Guess what - the same error occurs. Here's the extract from the console
output:

Exception in thread Thread-10:
Traceback (most recent call last):
  File "C:\Python\lib\threading.py", line 488, in __bootstrap_inner
self.run()
  File "C:\temp\thredio.py", line 28, in run
os.rename('logthred.log', dfn)
WindowsError: [Error 32] The process cannot access the file because it
is being used by another process

So, I submit that this is not a logging issue, and am closing this issue.

--
Added file: http://bugs.python.org/file14247/python-logging-capture.log

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6201] test_winreg fails


Amaury Forgeot d'Arc  added the comment:

Fixed with r73325.
2.7 really introduces an incompatibility here; I added an entry in the 
whatsnew file.

--
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4749] Issue with RotatingFileHandler logging handler on Windows


Robert Cronk  added the comment:

I turned off anti-virus again as well as file indexing and google 
desktop too and still got the errors when I disabled the locks around 
the os.system() calls.

Vinay - when the locks aren't around the os.system() calls, do you get 
the rotating log errors?

I'm still confused at how the os.system calls could be affecting the 
logging at all.  The os.system calls aren't touching the log files.  
Why would it cause them to fail when the os.system calls fail?  It 
seems that when the os.system calls succeed (because of the locks) then 
the logging succeeds but when the os.system calls fail (because the 
locks are disabled), then logging fails.  If, as you suggest, this is a 
race condition that is being exposed by the os.system calls failing 
because they don't have locks around them, then that would be the 
perfect situation (if you can reproduce it) to debug it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2919] Merge profile/cProfile in 3.0


Alexandre Vassalotti  added the comment:

Jean Brouwers wrote:
> All tests passed after regenerating the expected results

The tests for profile are output test. If you regenerate them, they pass
for sure.

Merging cProfile/profile will require a lot more work than just renaming
the module. The designs of cProfile and profile are significantly
different. So a successful merge will require settling one profiler
design (cProfile is the better designed one, IMHO) and rewrite the other
one to match the chosen design.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6136] Make logging configuration files easier to use

Vinay Sajip added the comment:

"It was met by deafening silence though."

Give it time - it's only been a few days. For some reason, Google Groups
doesn't show your post in the first page of results when I search for
logging configuration by date (i.e. most recent on top):

http://groups.google.com/group/comp.lang.python/search?q=logging+configuration&start=0&scoring=d

The same problem if I search for "logging configuration" the phrase -
again, it doesn't show up.

However, if after a while there's still not much response, it would
indicate that this is not perhaps such an important issue for the
community as you feel it is. This doesn't stop you from rolling your own
format, but gives less justification for adding a patch to the core stdlib.

"[log4py's] configuration file scaled down much more
gracefully for simple usage, mostly because it didn't expose its
internal design like the logging one does. It had only loggers instead
of loggers/handlers/formatters."

Yes - Python logging is more complex because that's what's useful for
developers. It's not really intended for end-users to change - in fact
once something is in production, typically only levels need to change.
This is surely editable by end users even with the existing config file
format, as long as they're not too fazed by the other stuff which they
don't need to touch. If they are - then a much simpler,
application-specific, end-user friendly format seems more in order.

"But log4py is discontinued now as a project and I can't face
maintaining my own copy of it any more."

What's to maintain? Python logging has been pretty stable now for a long
time, and log4py being simpler shouldn't need any particular maintenance
(since it has worked for you in the past).

"I'm getting the feeling you're just trying to fob me off here. You
dismiss the threads I found as being 'mostly about other things' or 'not
mentioning specifics'. That may be so, but the fact is, in those threads
you have five other people expressing in one way or another that the
configuration file is too complex - and I'm sure I could find more if
you really want. If you prefer to ignore them and me there's not much
point in discussing further."

I'm not trying to fob you off - I just stated what I found about those
posts. The complaints you refer to were not specific enough to suggest
improvements, and anyone can write comments about how crufty they think
something is - it doesn't exactly tell the maintainer which direction
they would like to go in. I'm not saying that applies to anything you
personally have said - I'm referring to the comments in those posts you
referred to. All of us in open source development have to balance a
number of different issues and we all have different agendas and
priorities. My position is that the logging configuration system, while
not perfect, works and is used by quite a lot of people without
problems. It's just not high on my list of priorities to tinker with the
format, because the feedback I've had in the past is that those people
who care a lot about configuration will roll their own anyway. I'm never
going to be able to please them all, so why not focus my energies elsewhere?

"I'm not demanding that you do this work. I'm simply trying to raise the
issue and asking you to consider accepting such a patch if I or somebody
else produce it."

As I've said before, I've accepted numerous patches from numerous people
in the past. You can confirm this from SVN where commit messages
generally refer to issue numbers on this tracker. Clearly I can't make
promises in advance to accept any future patch, but I've indicated where
I'd set the bar (backward compatibility, doc changes, test changes) for
a patch to be considered.

___
Python tracker

___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5924] When setting complete PYTHONPATH on Python 3.x, paths in the PYTHONPATH are ignored


Changes by Amaury Forgeot d'Arc :


--
resolution: accepted -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5924] When setting complete PYTHONPATH on Python 3.x, paths in the PYTHONPATH are ignored


Amaury Forgeot d'Arc  added the comment:

Fixed in r73322 (py3k) and r73323 (3.0)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6247] should we include argparse


Martin v. Löwis  added the comment:

> Since they are missing in optparse, and since it doesn't look like
> argparse will be included, should I open new bugs for those features
> against optparse ?

I think chances are very low that any such bug report would be reacted
on within the next decade.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6215] Backport the IO lib to trunk


Alexandre Vassalotti  added the comment:

> Not sure, I don't think any of these modules are built-in.

Ah true. Although there are built-in in py3k, you are right that it
doesn't make sense to make the trunk versions built-in.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5924] When setting complete PYTHONPATH on Python 3.x, paths in the PYTHONPATH are ignored


Martin v. Löwis  added the comment:

The patch looks right to me, please apply.

--
assignee:  -> amaury.forgeotdarc
resolution:  -> accepted

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6215] Backport the IO lib to trunk


Antoine Pitrou  added the comment:

> I think the build configuration for _io on Windows is missing.

Yes.

> Modules/Setup.dist probably needs to be updated too.

Not sure, I don't think any of these modules are built-in.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6245] Add "intel" universal architecture on OSX


Martin v. Löwis  added the comment:

> FWIW,
> it's the --with-universal-archs option that he said wasn't 100% usable,
> not the binaries.

Ah, ok. That clarifies it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6215] Backport the IO lib to trunk


Alexandre Vassalotti  added the comment:

I think the build configuration for _io on Windows is missing.
Modules/Setup.dist probably needs to be updated too.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6242] Fix reference leak in io.StringIO


Alexandre Vassalotti  added the comment:

> Why do you need all this? Isn't it enough to take a weakref and check
> the callback is triggered?

No, because you would need a weak reference to the instance's __dict__,
which is unavailable for io.StringIO.

Anyway, here's a simplified patch without the fun experimental code. :-)

--
Added file: http://bugs.python.org/file14246/fix_refleak_stringio-3.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6136] Make logging configuration files easier to use

2009-06-09 Thread Geoffrey Bache


Geoffrey Bache  added the comment:

My comp.lang.python thread is here:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/a0c35c3c9ad210a4

It was met by deafening silence though.

I don't see why a simple format would need to be customer-specific.
log4py's isn't/wasn't and that worked just fine. It did support logging
to more than files but its configuration file scaled down much more
gracefully for simple usage, mostly because it didn't expose its
internal design like the logging one does. It had only loggers instead
of loggers/handlers/formatters.

But log4py is discontinued now as a project and I can't face maintaining
my own copy of it any more.

I'm getting the feeling you're just trying to fob me off here. You
dismiss the threads I found as being "mostly about other things" or "not
mentioning specifics". That may be so, but the fact is, in those threads
you have five other people expressing in one way or another that the
configuration file is too complex - and I'm sure I could find more if
you really want. If you prefer to ignore them and me there's not much
point in discussing further.

I'm not demanding that you do this work. I'm simply trying to raise the
issue and asking you to consider accepting such a patch if I or somebody
else produce it.

--
status: pending -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6137] Make pickle generated by Python 3.x compatible with 2.x and vice-versa.


Raymond Hettinger  added the comment:

Thanks for taking a look and opining.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6137] Make pickle generated by Python 3.x compatible with 2.x and vice-versa.

2009-06-09 Thread Guido van Rossum


Guido van Rossum  added the comment:

On Tue, Jun 9, 2009 at 12:16 PM, Antoine Pitrou wrote:
>
> Antoine Pitrou  added the comment:
>
>> Ah. How about only doing back-translation when protocol=2 (or lower)
>> is explicitly selected?
>
> Well, this is exactly what is implemented!

Ah, I missed that. Fine then!

>> I don't much like that 3.0 will be to read pickles written by 3.1 with
>> the default protocol (i.e. 3),
>
> I suppose you meant to say "will be unable",

Indeed.

> but it isn't, since
> protocol 3 pickles are not affected at all by this patch.

Good.

So I'm okay with the status quo -- too bad 3.0 can't read those
pickles, but that's the deal with abandoning 3.0...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6137] Make pickle generated by Python 3.x compatible with 2.x and vice-versa.


Antoine Pitrou  added the comment:

> Ah. How about only doing back-translation when protocol=2 (or lower)
> is explicitly selected?

Well, this is exactly what is implemented!

> I don't much like that 3.0 will be to read pickles written by 3.1 with
> the default protocol (i.e. 3),

I suppose you meant to say "will be unable", but it isn't, since
protocol 3 pickles are not affected at all by this patch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6137] Make pickle generated by Python 3.x compatible with 2.x and vice-versa.

2009-06-09 Thread Guido van Rossum


Guido van Rossum  added the comment:

Ah. How about only doing back-translation when protocol=2 (or lower)
is explicitly selected?

I don't much like that 3.0 will be to read pickles written by 3.1 with
the default protocol (i.e. 3), but I don't mind breaking protocol 2,
since that's most likely (as you say) intended for Python 2. So the
default for fix_imports would be None, and the __init__ would check if
it's None, and then set it to (protocol <= 2).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6137] Make pickle generated by Python 3.x compatible with 2.x and vice-versa.


Raymond Hettinger  added the comment:

I vaguely remember you rejecting a proposal along these lines when Brett
was doing the library renaming.  

The patch (as applied) turns on the renaming automatically when used
with protocol 2 (i.e. all object names are stored with their 2.x names,
not their new names).   Hagen points out that 3.1 proto 2 pickles can't
be read by 3.0.  I would think that the back-translation should be
disabled by default or else we're going to live with the 2.x names for a
very long time.

I don't care much one way or the other.  Just thought you should see it
before it got released and set in stone.  It's not too late for a one
line change, setting the fix_imports default from True to False.

FWIW, the argument for leaving the default as True is the theory that
anyone using protocol 2 is likely doing so to exchange data with 2.x.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4749] Issue with RotatingFileHandler logging handler on Windows


Robert Cronk  added the comment:

I'll thoroughly look through every piece of software that's running to 
see if I can turn eveything off that might be causing the problem.

Were you able to reproduce the problem with my original script?  I'm 
sure you have all of your virus/searching/etc. stuff turned off, so if 
it reproduced for you, then those things aren't the problem.

Question: If you take my original script and add joins at the end so 
it's proper and modify nothing else about it, does it show the rollover 
error?

If so, then I think that is where we need to start since you then have 
a simple test that manifests the problem without virus scanners (etc.) 
that might taint the issue.  Then you can chase this without having to 
assume what my system has running on it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6137] Make pickle generated by Python 3.x compatible with 2.x and vice-versa.

2009-06-09 Thread Guido van Rossum


Guido van Rossum  added the comment:

I'm not on IRC. What exactly is your question for me? What is Raymond's 
view?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6137] Make pickle generated by Python 3.x compatible with 2.x and vice-versa.


Antoine Pitrou  added the comment:

Guido, Raymond suggested we ask your input on this one, although it's
obviously a bit late (the patch has been committed).

--
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6248] TCP Sockets not closed by TCPServer and StreamRequestHandler

2009-06-09 Thread Kristján Valur Jónsson


New submission from Kristján Valur Jónsson :

When an error occurs in a StreamRequestHandler, its wfile and rfile 
members are not closed.  This causes the underlaying socket to stay 
alive and and it is therefore not closed, even when the SocketServer 
closes it in server.close_request().  This means that a client will not 
know that there is no one listening on the other end.

This is due to incorrect error handling semantics in BaseRequestHandler.

This patch fixes the error handling in BaseRequestHandler, ensuring that 
request.finish() is called when request.setup() has completed.

I also add an explicit socket.shutdown() in TCPServer.close_request() to 
make sure that at least a half-close occurs even in the face of socket 
reference leaks.

--
components: Library (Lib)
files: socketserver.patch
keywords: needs review, patch, patch
messages: 89152
nosy: krisvale
severity: normal
status: open
title: TCP Sockets not closed by TCPServer and StreamRequestHandler
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14245/socketserver.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4749] Issue with RotatingFileHandler logging handler on Windows


Vinay Sajip  added the comment:

Debugging threading problems is never as simple as it seems. I don't
believe logging is breaking because of some interaction with the system
calls - rather, the presence of the system calls is changing the
real-time characteristics of the system and exposing the failure.

This problem is not directly related to logging - for example, see

http://groups.google.com/group/comp.lang.python/browse_thread/thread/98fa9592e7c47130/d5642964c573dfc0#d5642964c573dfc0

I will look to see if I can find what the exact problem is. Did you turn
off Windows search indexing for the volume before running the test, in
addition to turning off the anti-virus? It looks as if something else is
opening the file (which, in our test, will have been very recently
written to when the error occurs) and the suspicion must fall on
anti-virus or search indexing or some other file watching software (e.g.
backup software which is configured to monitor all file changes and
refresh the backup copy in pseudo-real-time).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4749] Issue with RotatingFileHandler logging handler on Windows


Robert Cronk  added the comment:

Thanks Vinay.  I ran the newest revised script with virus protection 
turned off and got the same failures as before (see console output 
below).

If you comment out the os.system() calls, everything works just fine.  
Uncomment them and logging breaks.

The os.system() calls shouldn't break logging, especially since they 
are accessing a completely unrelated file - not the log file.

If you could go back to my original script that fails for you, you 
should be able to chase down why these unrelated os.system() calls are 
breaking logging.  Feel free to add the joins and replace the tabs if 
you want to, but don't put locks around the os.system() calls because 
that just makes the problem go away and leaves us with nothing to do.  
Does that make sense?  Regardless of what the os.system() calls are 
doing, they shouldn't break logging in any way whatsoever.  So if my 
original script breaks for you, please use that broken state to debug 
the problem and find out why an os.system() call is breaking logging.

---

C:\logthred>revised.py
Traceback (most recent call last):
  File "C:\Python26\lib\logging\handlers.py", line 72, in emit
self.doRollover()
  File "C:\Python26\lib\logging\handlers.py", line 129, in doRollover
os.rename(self.baseFilename, dfn)
WindowsError: [Error 32] The process cannot access the file because it 
is being
used by another process
2009-06-09 09:54:47,828 DEBUG3704 This is log message 0 from thread-
00 and I
 think this should be a little longer, so I'll add some more data here 
because p
erhaps the size of the individual log message is a factor.  Who knows 
for sure u
ntil this simple test fails.
Traceback (most recent call last):
  File "C:\Python26\lib\logging\handlers.py", line 71, in emit
if self.shouldRollover(record):
  File "C:\Python26\lib\logging\handlers.py", line 145, in 
shouldRollover
self.stream.seek(0, 2)  #due to non-posix-compliant Windows feature
ValueError: I/O operation on closed file
2009-06-09 09:54:47,967 DEBUG9052 This is log message 0 from thread-
01 and I
 think this should be a little longer, so I'll add some more data here 
because p
erhaps the size of the individual log message is a factor.  Who knows 
for sure u
ntil this simple test fails.
Traceback (most recent call last):
  File "C:\Python26\lib\logging\handlers.py", line 71, in emit
if self.shouldRollover(record):
  File "C:\Python26\lib\logging\handlers.py", line 145, in 
shouldRollover
self.stream.seek(0, 2)  #due to non-posix-compliant Windows feature
ValueError: I/O operation on closed file
2009-06-09 09:54:48,062 DEBUG7480 This is log message 0 from thread-
02 and I
 think this should be a little longer, so I'll add some more data here 
because p
erhaps the size of the individual log message is a factor.  Who knows 
for sure u
ntil this simple test fails.
Traceback (most recent call last):
  File "C:\Python26\lib\logging\handlers.py", line 71, in emit
if self.shouldRollover(record):
  File "C:\Python26\lib\logging\handlers.py", line 145, in 
shouldRollover
self.stream.seek(0, 2)  #due to non-posix-compliant Windows feature
ValueError: I/O operation on closed file
.
.
.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6195] Serious regression in doctest in Py3.1rc1

2009-06-09 Thread Lisandro Dalcin


Lisandro Dalcin  added the comment:

I've tested latest David's patch against Cython test suite (doctests
living in extension modules), and all is working as expected.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6247] should we include argparse

2009-06-09 Thread Ritesh Raj Sarraf


Ritesh Raj Sarraf  added the comment:

Thanks for the link. As a user, I see many of the features that argparse
brings, to be helpful.

Since they are missing in optparse, and since it doesn't look like
argparse will be included, should I open new bugs for those features
against optparse ?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6096] SimpleXMLRPCServer not suitable for HTTP/1.1 keep-alive

2009-06-09 Thread Kristján Valur Jónsson


Kristján Valur Jónsson  added the comment:

Here is a better patch.
Remove the individual flush() operations from the implementation classes, 
rather do it in the BaseHTTPRequestHandler().  This allows any request 
handler to be write buffered.

--
Added file: http://bugs.python.org/file14244/xmlsrv.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6247] should we include argparse

2009-06-09 Thread Benjamin Peterson


Changes by Benjamin Peterson :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6247] should we include argparse

2009-06-09 Thread Senthil


Senthil  added the comment:

I hope you read this thread which discusses the same issue.

* http://mail.python.org/pipermail/python-list/2007-January/592646.html

MvL,effbot and jjlee had shared their views to the original author of
argparse module. It did not go anywhere from there.

I see that this issue might be rejected unless followed the steps as
mentioned in that mail thread.

--
nosy: +orsenthil

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6198] test_float fails on Windows

2009-06-09 Thread Eric Smith


Eric Smith  added the comment:

In r73314, I restored the one test erroneously removed ("%#.0f 1.5 -> 2.").

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6006] ffi.c compile failures on AIX 5.3 with xlc


Antoine Pitrou  added the comment:

AIX doesn't seem listed in the platforms supported by libffi.
http://sourceware.org/libffi/ suggests you send platform test results to
libffi-disc...@sourceware.org

On the other hand, perhaps the libffi version which comes with Python is
outdated.

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6242] Fix reference leak in io.StringIO


Antoine Pitrou  added the comment:

Why do you need all this? Isn't it enough to take a weakref and check
the callback is triggered?
(besides, we should avoid tests which only work in debug mode)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6203] 3.x locale does not default to C, contrary to the documentation and to 2.x behavior


Changes by Antoine Pitrou :


--
assignee:  -> georg.brandl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5924] When setting complete PYTHONPATH on Python 3.x, paths in the PYTHONPATH are ignored


Amaury Forgeot d'Arc  added the comment:

Here is a patch: fix+test.

I left the initial code, #ifdef'd for PC platforms different than
MS_WINDOWS. Just in case someone wants to port py3k to OS/2...

--
keywords: +patch
Added file: http://bugs.python.org/file14243/large_pythonpath.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6245] Add "intel" universal architecture on OSX

2009-06-09 Thread John Szakmeister


John Szakmeister  added the comment:

I think Ronald is trying to say that a 10.6 SDK is likely not to support
building 64-bit binaries at all for the PPC (since there won't be 64-bit
versions of the supporting libraries).  So you need this patch, if
you're going to build against it.  I don't think he's trying to claim
that fat binaries won't run if there is 64-bit PPC code in them.  FWIW,
it's the --with-universal-archs option that he said wasn't 100% usable,
not the binaries.

--
nosy: +jszakmeister

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5623] test_fdopen fails with vs2005, release build on Windows 2000

2009-06-09 Thread Kristján Valur Jónsson


Kristján Valur Jónsson  added the comment:

Closing this defect, as the issues seems worked around on our end.

Btw, here is the issue on Microsoft's end.  They've marked it as "won't 
fix".
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?
FeedbackID=409955&wa=wsignin1.0

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6006] ffi.c compile failures on AIX 5.3 with xlc

2009-06-09 Thread rubisher


rubisher  added the comment:

Just to mention the same issue for Python-2.6.2 and gcc-4.2.0 on aix 
5.3 too.

--
nosy: +rubisher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6247] should we include argparse

2009-06-09 Thread Ritesh Raj Sarraf


Ritesh Raj Sarraf  added the comment:

>From the author, Steven Berthard:

Sorry about the delay - conferences and moving means that I haven't
had as much time for argparse as I'd like. Basically, the way things
get into the Python standard library is if a large enough community
requests it. I'm happy to contribute (and support) it if there's
enough demand, though since Python 3.1b1 is already out, the earliest
releases that might include it would be Python 2.7 and 3.2.



>From the conversation I have had with the author, he does seem to be
interested in it. I'll ask the author to respond to this bug report.

--
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5623] test_fdopen fails with vs2005, release build on Windows 2000


Martin v. Löwis  added the comment:

Why is this still open?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6203] 3.x locale does not default to C, contrary to the documentation and to 2.x behavior