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

[rubisher]

rubisher  added the comment:

Having a look at


gcc libffi is wel available for Aix, though?

That said, I just need python for bzr and associated tools to maintain 
localy a small number of script, so imho I would be able survive 
without ffi support in python (even _ctype?).

Any idea how to remove this support at build from src time: I have a 
look at ./configure --help and even try to change some other 
compilation option like -O2 (in place of default -O3) but nothing 
seems to be helpfull.

Tx for additional advise.

--

___
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

[Ritesh Raj Sarraf]

Ritesh Raj Sarraf  added the comment:

I'm not sure about the design part, but as a user, I find both to have very
similar interfaces.

argparse is better because it handles nargs=*. This has long been
asked in optparse. Positional arguments is something I wanted recently,
and argparse makes it very easy to use that too.

--

___
Python tracker 

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

[issue6251] c++ extension module implementation guide/example in extending/embedding documentation

[John O'Driscoll]

New submission from John O'Driscoll :

feature: extension module C++ howto/example in extending-embedding/c-api
documentation


why:The embedding/extension documentation states that module
implementation in c++ is possible, without providing any guidance beyond
this. Coders more familiar/comfortable with c++ than c, writing c++ code
to expose in python, might want to create the actual python class/module
implementations in c++ classes or structs. A basic guide can help
prevent wastage of energy reinventing the wheel, and also serve as a
guide to safe/preferred style. The method outlined here can be a
starting point in finding out what that style is. 
Also it seems, to my eyes at least, a little easier to 'visualise' and
apply than the equivalent in plain C (the Noddy module etc), a bit more
'systematic', and easier to understand the relation between c and python
objects. So after some trial and error, discovering the pitfalls, I am
finding it easy to create useful python classes with this recipe. Others
might also find it useful, even if only as a stimulus to find a Better Way.

Python is an object-oriented language noted for its clarity, so an
allegedly simple and clear OO implementation strategy for module classes
should be examined.


what:   I've written a module currently called 'cpeepee', containing a
basic python class ,(struct TestRealDestructor in C++,
'cpeepee.destructo' in python). It has been tested with python-2.5 and
g++-4.2 on ubuntu-'hardy heron' and python-2.5/g++-3.4 on FreeBSD-6.4. 

The c++ struct inherits from PyObject.(You could also inherit from
PyVarObject or other more specialised types). The most important
non-feature of this class is that it is not virtual, has no virtual
destructor or functions(in member objects virtual destructors and the
rest are OK however). Therefore the packing of ob_refcnt and friends is
correct, and casting to/from PyObject is safe(-and otherwise is not -
the PyObject* cast from such a type with virtual destructor is offset by
the size of a pointer -the vptr?-, but when python casts back to the
type - from void* or so?- the offset is not removed, leading to mayhem).

[You could also not inherit, simply put the PyObject_HEAD macro as the
first entry in the struct - could be a class also, as long as the
PyObject members(ob_refcnt, ob_type ... )were public - You would have to
write a new macro to fill in those members in the constructor's
initialiser list, but that doesn't look too hard. As it is the inherited
classes use a function and some macros (almost identical to
PyObject_HEAD_INIT(typo) ) to fill in the PyObject parent. Again, vfuncs
are out]

The destructo method and member tables are static members of
TestRealDestructor, as is its type object.(Other optional tables etc
should also be static members if provided - makes for a simple
consistent setup)
The objects constructor is called from
TestRealDestructor::type.tp_new() and passed the args and kwds arguments
it is passed, using placement new with memory obtained from
tp_alloc()(see TestRealDestructor::create() ). Being able to properly
call an object's constructor was the real motivation for writing the
code this derives from. Using C style one is stuck casting a char* to
your type and then filling its fields by hook or crook.
 
On error, either you could throw a c++ exception in constructor to catch
in tp_new, and convert to a python exception, or simply throw the python
exception in the constructor, and then check if PyErr_Occurred() in
tp_new() - the approach with destructo.

Since tp_new and the constructor take care of object creation, this
leaves tp_init not doing much at all. It could be used for extra checks,
or printing funky messages about preserved ham

Functions to be exposed in python API as class member functions should
static members of the class, and to do the work they call ordinary
member functions of the class object passed into the static function .
You could use global static functions(with the first arg
TestRealDestructor* say, rather than PyObject*), but that's less clear,
less systematic, less OO.

Everything can be placed in a namespace to avoid any pollution of global
namespace.

I've worked out the bugs that were obvious to me, so it should compile
and run as is, without error messages. The one compile warning I don't
know how to banish comes from the offsetof macro when setting member
offsets in the member table(as copied from the c example) - however the
object whose offset is so established works fine from python, so I think
it's a spurious warning. 

If you find any issues with my approach, I'm happy to work through them,
or if you know what to do then make whatever changes you think required.

I'm happy to put any code or words I contribute on this topic to go
under python's copyright as long as I'm credited somehow(however you
normally do that). Whatever, I'm happy to contribute to such a great
project as python

sincerely

John O'Driscoll

-

[issue6232] Improve test coverage of ElementTree and cElementTree

[Jeremy Thurgood]

Changes by Jeremy Thurgood :


--
nosy: +jerith

___
Python tracker 

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

[issue6252] logging midnigh rotation

[Turnaev Evgeny]

New submission from Turnaev Evgeny :

i have a very basic setup of logging in a long running daemon app..
I use TimedRotatingFileHandler with rotating at midnight.
The bug:
The last open logging file was for 2009-05-25..
app was running without logging anything for about a week or more.
After a week past something happened and daemon started to log messages,
but.. for each new message logging system creates new file.
In other words.. suppose we was idle since 2009-05-25, now it is 
2009-06-10 and we want to log 10 messages.. 
current opened file is for 2009-05-25.. so when a first messages
arrives into logging system current must be closed. and a new file must 
be opened where all 10 messages should be..
but instead logging system will log each subsequent message in files 
2009-05-26, 2009-05-27, 2009-05-28..(in fact it will log in file 
without a date and then when nect message arives rename current to 
2009-05-26, 2009-05-27, 2009-05-28.. but is still the same) and so on, 
one message per file.. i think until it reaches current date.
It is a logic error.


my logging setup looks like this:
-
import logging
from logging import debug,warning,info,error,critical
from logging.handlers import TimedRotatingFileHandler

log_path = '/var/log/cherry/smsd_reg'
log_level = logging.DEBUG

basic_log_handler = TimedRotatingFileHandler(log_path + "/
app_log_smsd_reg_server",'midnight',1)
basic_log_handler.setLevel(log_level)
basic_log_formatter = logging.Formatter('%(asctime)s pid: %(process)d, 
%(levelname)s %(message)s')
basic_log_handler.setFormatter(basic_log_formatter)
logging.getLogger('').addHandler(basic_log_handler)
logging.getLogger('').setLevel(log_level)



system info:
Python 2.5.1
FreeBSD 6.2-RELEASE-p7 FreeBSD 6.2-RELEASE-p7

--
components: Extension Modules
messages: 89191
nosy: SanityIO
severity: normal
status: open
title: logging midnigh rotation
type: behavior
versions: Python 2.5

___
Python tracker 

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

[issue5331] multiprocessing hangs when Pool used within Process

[Gabriel de Perthuis]

Gabriel de Perthuis  added the comment:

Apparently the pool workers die all at once, just after the pool creates
them and before the pool is used.
I added a few lines to multiprocessing/pool.py to get the stack and the
exception backtrace.

except (EOFError, IOError):
import traceback
debug(traceback.format_exc())
debug(''.join(traceback.format_stack()))
debug('worker got EOFError or IOError -- exiting')
break


INFO::Rule dispatcher::multiprocessing::child process calling self.run()
DEBUG::Rule dispatcher::multiprocessing::created semlock with handle
3082559488
DEBUG::Rule dispatcher::multiprocessing::created semlock with handle
3082104832
DEBUG::Rule dispatcher::multiprocessing::created semlock with handle
3081826304
DEBUG::Rule dispatcher::multiprocessing::created semlock with handle
3081822208
INFO::PoolWorker-3:1::multiprocessing::child process calling self.run()
DEBUG::PoolWorker-3:1::multiprocessing::Traceback (most recent call last):
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/pool.py",
line 57, in worker
task = get()
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/queues.py",
line 339, in get
return recv()
IOError: [Errno 9] Bad file descriptor

DEBUG::PoolWorker-3:1::multiprocessing::  File
"/home/who/var/co/git-svn/what-base/correlator/bin/correlator", line 30,
in 
what.corr.actors.main.main()
  File
"/home/who/var/co/git-svn/what-base/correlator/lib/what/corr/actors/main.py",
line 47, in main
rrp.start()
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/process.py",
line 109, in start
self._popen = Popen(self)
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/forking.py",
line 99, in __init__
code = process_obj._bootstrap()
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/process.py",
line 236, in _bootstrap
self.run()
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/process.py",
line 93, in run
self._target(*self._args, **self._kwargs)
  File
"/home/who/var/co/git-svn/what-base/correlator/lib/what/corr/actors/rule_dispatcher.py",
line 26, in main
initargs=(manager.agg_msgs_queue, ))
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/__init__.py",
line 232, in Pool
return Pool(processes, initializer, initargs)
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/pool.py",
line 107, in __init__
w.start()
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/process.py",
line 109, in start
self._popen = Popen(self)
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/forking.py",
line 99, in __init__
code = process_obj._bootstrap()
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/process.py",
line 236, in _bootstrap
self.run()
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/process.py",
line 93, in run
self._target(*self._args, **self._kwargs)
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/pool.py",
line 61, in worker
debug(''.join(traceback.format_stack()))

DEBUG::PoolWorker-3:1::multiprocessing::worker got EOFError or IOError
-- exiting
INFO::PoolWorker-3:1::multiprocessing::process shutting down
DEBUG::PoolWorker-3:1::multiprocessing::running all "atexit" finalizers
with priority >= 0

--
nosy: +onyxg7

___
Python tracker 

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

[issue6251] c++ extension module implementation guide/example in extending/embedding documentation

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Did you take a look at Boost.Python?
This is a much more natural (from C++ point of view) way to create
Python types. All boilerplate code comes from template techniques
(creation/destruction, static methods...)

The tutorial is interesting:
http://www.boost.org/doc/libs/release/libs/python/doc/tutorial/doc/html/python/exposing.html

IOW, I suggest to just add a reference to the boost::python library

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue6252] logging midnight rotation

[Vinay Sajip]

Changes by Vinay Sajip :


--
assignee:  -> vsajip
nosy: +vsajip
title: logging midnigh rotation -> logging midnight rotation

___
Python tracker 

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

[issue6251] c++ extension module implementation guide/example in extending/embedding documentation

[Skip Montanaro]

Changes by Skip Montanaro :


--
nosy: +skip.montanaro

___
Python tracker 

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

[issue5331] multiprocessing hangs when Pool used within Process

[OG7]

OG7  added the comment:

It seems the root cause is at http://bugs.python.org/issue5155 .
A workaround is to use a duplex Pipe in SimpleQueue.

--

___
Python tracker 

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

[issue5313] multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()

[OG7]

OG7  added the comment:

Using sys.stdin.close() fixes issues 5155 and 5331.

--
nosy: +OG7

___
Python tracker 

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

[issue5155] Multiprocessing.Queue created by sub-process fails when used in sub-sub-process ("bad file descriptor" in q.get())

[OG7]

OG7  added the comment:

Issue 5313 seems to be the culprit.

--
nosy: +OG7

___
Python tracker 

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

[issue5201] Using LDFLAGS='-rpath=\$$LIB:/some/other/path' ./configure breaks the build

[Floris Bruynooghe]

Floris Bruynooghe  added the comment:

Hi

What's the status of this?  I haven't seen a commit message regarding this.

Cheers

--

___
Python tracker 

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

[issue5313] multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()

[Graham Dumpleton]

Graham Dumpleton  added the comment:

Worth noting is that Python documentation in:

http://docs.python.org/library/stdtypes.html

says:

"""
file.fileno()
Return the integer “file descriptor” that is used by the underlying 
implementation to request I/O operations from the operating system. This 
can be useful for other, lower level interfaces that use file 
descriptors, such as the fcntl module or os.read() and friends.

Note File-like objects which do not have a real file descriptor should 
not provide this method!
"""

So, if sys.stdin is replaced with a file like object, then the code 
should not be assuming that fileno() even exists.

At the moment the code doesn't check for AttributeError which is what is 
going to be raised for trying to access non existent fileno() method.

"""
>>> import StringIO
>>> s=StringIO.StringIO("xxx")
>>> s.fileno()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: StringIO instance has no attribute 'fileno'
"""

Thus error propagates. The better check though would be to use:

def _bootstrap(self):
   
if sys.stdin is not None and hasattr(sys.stdin, "fileno"):
try:
os.close(sys.stdin.fileno())
except (OSError, ValueError):
pass

That is, only actually call fileno() if it is present.

This would solve the problem for the original reported issue by making 
it actually adhere to what Python documentation says about existence of 
fileno().

This change wouldn't necessarily solve other peoples related issues 
though.

--

___
Python tracker 

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

[issue5313] multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()

[Pablo Torres Navarrete]

Pablo Torres Navarrete  added the comment:

Wouldn't it be more pythonic to just try sys.stdin.fileno() and catch 
the AtributeError too?

def _bootstrap(self):
   
try:
os.close(sys.stdin.fileno())
except AtributeError:
sys.stdin.close()
except (OSError, ValueError):
pass

--
nosy: +ptn

___
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

[Steven Bethard]

Steven Bethard  added the comment:

On Tue, Jun 9, 2009 at 11:45 PM, Martin v. Löwis wrote:
> It would be useful if several people could confirm that argparse
> is *not* horribly designed.

A totally reasonable request. Anyone willing to evaluate this can take
a look at:

http://argparse.googlecode.com/svn/trunk/argparse.py

It also may help to look at the extensive test suite:

http://argparse.googlecode.com/svn/trunk/test/test_argparse.py

If anyone has specific questions about how something works or how to
extend argparse with new functionality, I'm happy to answer those
questions.

--

___
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

[Lowell Alleman]

Lowell Alleman  added the comment:

I must say that Vinay's findings are most interesting.  Thanks Vinay
for tracking this down!

Just a thought, but has anybody tried this using the subprocess
module?  I've glanced through subprocess.py and it certainly does not
use os.system().  Instead it uses CreateProcess() on windows and
os.execvp*() on all other platforms.  It also appears to go to great
effort to properly deal with file handles, so I'm wondering if that
would resolve this issue.  (The current 2.6 docs, state that the
subprocess "module is preferable" over the os.system() call, and that
"All of the popen*() functions are obsolete. Use the subprocess
module.")

I'm quite curious to see if my ConcurrentLogHandler will fare any
better with this scenario.  I would really like for it to be able to
handle this scenario, since it's design goals are to be resilient to
this type of thing.  But I'm relying on the threading system and locks
too, so it's hard to say what will happen.

Robert, I agree that submitting a new bug on this would be a good idea
if none currently exists.  I also think it would be good to to put a
warning in the docs about this scenario if there is nothing that can
be done to correct the situation.  Even it if is not Python-specific
thing, I think it is good to let people know about gotchas whenever
possible.

--

___
Python tracker 

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

[issue6253] optparse.OptionParser.get_usage uses wrong formatter

[Jan Pobrislo]

New submission from Jan Pobrislo :

When using OptionParser.format_help(formatter), the formatter parameter
should be used to format all of the help message. This is not the case
for usage message, as the method get_usage() is not passed the formatter
and always uses self.formatter. I'm using python-2.6.2-r1.

--
components: Extension Modules
files: fix_optparse_usage_formatter.diff
keywords: patch
messages: 89202
nosy: ccx
severity: normal
status: open
title: optparse.OptionParser.get_usage uses wrong formatter
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14254/fix_optparse_usage_formatter.diff

___
Python tracker 

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

[issue6253] optparse.OptionParser.get_usage uses wrong formatter

[Jan Pobrislo]

Changes by Jan Pobrislo :


Added file: http://bugs.python.org/file14255/fix_optparse_usage_formatter.diff

___
Python tracker 

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

[issue6253] optparse.OptionParser.get_usage uses wrong formatter

[Jan Pobrislo]

Changes by Jan Pobrislo :


Removed file: http://bugs.python.org/file14254/fix_optparse_usage_formatter.diff

___
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

[Eric Smith]

Eric Smith  added the comment:

I'll take a look at it. I've been meaning to use argparse, anyway.

--
nosy: +eric.smith

___
Python tracker 

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

[issue6253] optparse.OptionParser.get_usage uses wrong formatter

[Jan Pobrislo]

Jan Pobrislo  added the comment:

On second thought method name starting with get_ doesn't signify any
formatting, so it might be better to either:

1) Move call to formatter.format_usage from get_usage directly to
format_help.

2) Create method format_usage in OptionParser and call it from there.

--
Added file: http://bugs.python.org/file14256/fix_optparse_usage_formatter2.diff

___
Python tracker 

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

[issue5313] multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()

[OG7]

OG7  added the comment:

Closing the stdin fd without closing the stdin file is very dangerous.
It means that stdin will now access some random resource, for example, a
pipe created with os.pipe().

Closing stdin is useful to let the parent be alone in reading from it.
It can be achieved by replacing stdin by open('/dev/null'). The original
stdin can be closed or left to be garbage collected.

The "double flush" case is impossible to handle in general. It's the
libc's responsibility for standard file objects and sockets. But it
can't be helped (except by putting a warning in the documentation) if
someone combines multiprocessing with non-fork-safe code that keeps its
own buffers and doesn't check for a pid change.

So that code in _bootstrap should be:
sys.stdin.close()
sys.stdin = open(os.devnull)

--

___
Python tracker 

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

[issue6253] optparse.OptionParser.get_usage uses wrong formatter

[Jan Pobrislo]

Changes by Jan Pobrislo :


Removed file: 
http://bugs.python.org/file14256/fix_optparse_usage_formatter2.diff

___
Python tracker 

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

[issue6253] optparse.OptionParser.get_usage uses wrong formatter

[Jan Pobrislo]

Changes by Jan Pobrislo :


Added file: http://bugs.python.org/file14257/fix_optparse_usage_formatter2.diff

___
Python tracker 

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

[issue6254] tarfile unnecessarily requires seekable files

[Michael K Johnson]

New submission from Michael K Johnson :

In python 2.6 (not 2.4, haven't checked 2.5), the __init__() method of
the TarFile class calls the tell() method on the tar file, which doesn't
work if you are reading from standard input or writing to standard
output, two very reasonable things to do with a tar file.

While there are cases where it is logical to seek within a tar file,
supporting those cases should not preclude the normal design case for
tar archives of streaming reads/writes, including tar files being
streamed between processes via pipes.  If the tell() method is not
implemented for the file object, then the seek() method of TarFile (and
any other methods that can be implemented only for seekable files) can
raise a reasonable exception.  Note that this also means that the next()
method should not need to seek() for non-seekable files; it should
assume that it is at the correct block and read from there.

--
components: Library (Lib)
messages: 89206
nosy: johnsonm
severity: normal
status: open
title: tarfile unnecessarily requires seekable files
type: behavior
versions: Python 2.6

___
Python tracker 

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

[issue6252] logging midnight rotation

[Vinay Sajip]

Vinay Sajip  added the comment:

I'm unable to reproduce this problem with Python 2.5.2 on either Windows
XP or Ubuntu Hardy.

I used a test script (httpd.py, attached). This sets up an HTTP server
which you can use to trigger logging events.

I created a time simulator to allow testing in a timely way. This
monkey-patches the binding for the time module in logging and
logging.handlers to return either the real time or the simulated time.
Once you have started the server (just run the script), you can trigger
a logging event by running

wget -o /dev/null http://localhost:9022/

and you can initiate simulated timing by running

wget -o /dev/null http://localhost:9022/s

The simulated time is set to the next midnight, to facilitate rollover.
I then ran

wget -o /dev/null http://localhost:9022/

three times, then

wget -o /dev/null http://localhost:9022/s

once, then

wget -o /dev/null http://localhost:9022/

again three times. The only files created were:

vi...@zeta-hardy:~$ ls -l  httpd.log*
-rw-r--r-- 1 vinay vinay 192 2009-06-10 16:46 httpd.log
-rw-r--r-- 1 vinay vinay 256 2009-06-10 16:46 httpd.log.2009-06-10

which is as expected, and the contents are:

vi...@zeta-hardy:~$ cat httpd.log.2009-06-10 
2009-06-10 16:46:22,999 pid: 512 DEBUG - OK 2009-06-10 16:46:22
2009-06-10 16:46:23,765 pid: 512 DEBUG - OK 2009-06-10 16:46:23
2009-06-10 16:46:24,406 pid: 512 DEBUG - OK 2009-06-10 16:46:24
2009-06-10 16:46:25,974 pid: 512 DEBUG - OK 2009-06-10 16:46:25

and

vi...@zeta-hardy:~$ cat httpd.log
2009-06-11 00:00:01,260 pid: 512 DEBUG - OK 2009-06-11 00:00:01
2009-06-11 00:00:01,923 pid: 512 DEBUG - OK 2009-06-11 00:00:01
2009-06-11 00:00:02,547 pid: 512 DEBUG - OK 2009-06-11 00:00:02

which is again as expected.

Please try out the test script in your environment and feed back the
results you get.

--
resolution:  -> works for me
status: open -> pending
Added file: http://bugs.python.org/file14258/httpd.py

___
Python tracker 

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

[issue6255] PyInt_FromSize_t is undocumented.

[Naoki INADA]

New submission from Naoki INADA :

PyInt_FromSize_t() is not in Python/C API document.
People seeing document may be not able to find how to make int from 
unsigned long.

--
assignee: georg.brandl
components: Documentation
messages: 89208
nosy: georg.brandl, naoki
severity: normal
status: open
title: PyInt_FromSize_t is undocumented.
versions: Python 2.6, Python 2.7

___
Python tracker 

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

[issue6256] Wrong stacklevel in warning for contextlib.nested

[Hagen Fürstenau]

New submission from Hagen Fürstenau :

This leads to unhelpful warnings:

>>> with contextlib.nested(open("x", "w")) as f: pass
... 
/usr/local/lib/python3.1/contextlib.py:17: DeprecationWarning:
With-statements now directly support multiple context managers
  return next(self.gen)

Patch is attached.

--
components: Library (Lib)
files: warning_stacklevel.patch
keywords: patch
messages: 89209
nosy: hagen
severity: normal
status: open
title: Wrong stacklevel in warning for contextlib.nested
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14259/warning_stacklevel.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

[Robert Cronk]

Robert Cronk  added the comment:

I changed the script to use subprocess (attached file) and got the same 
rollover errors as before.  I had to change cd and del to be cd.bat and 
del.bat which contained cd %1 and del %1 respectively since it appears 
subprocess can't run internal commands like cd and del (unless you 
specify shell = True, which I thought might defeat the purpose of the 
test).

I will search around for this bug to see if it's already been entered.  
If the python developers decide not to fix this by wrapping os.system 
(and I guess subprocess.Popen too) with locks to prevent this error, 
then I agree that it should at least be well documented.

--
Added file: http://bugs.python.org/file14260/subprclg.py

___
Python tracker 

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

[issue6256] Wrong stacklevel in warning for contextlib.nested

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Fixed.  r7 and r73334

--
assignee:  -> rhettinger
nosy: +rhettinger
resolution:  -> accepted
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]

Vinay Sajip  added the comment:

You may want to re-test with Popen(..., close_fds=True) with the latest
Python 2.6. From the latest docs:

http://docs.python.org/library/subprocess.html

"If close_fds is true, all file descriptors except 0, 1 and 2 will be
closed before the child process is executed. (Unix only). Or, on
Windows, if close_fds is true then no handles will be inherited by the
child process. Note that on Windows, you cannot set close_fds to true
and also redirect the standard handles by setting stdin, stdout or stderr."

In Python 2.5, you can't use close_fds on Windows. In the 2.5
documentation (ActivePython 2.5.2.2) the above paragraph ends with
"(Unix only)."

--

___
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

[Collin Winter]

Collin Winter  added the comment:

As another data point, Unladen Swallow had to take explicit steps to
deal with this dead code when compiling bytecode to machine code. Since
Python's compiler isn't smart enough to ignore code following a "return"
or "raise" in the same suite, support for that had to percolate into our
compiler.

For me, it's cleanliness issue, not a performance issue. That certainly
lowers the priority, though.

The warning James is adding for dead code detection may also be useful;
it looks to have already found one bug in the stdlib.

--

___
Python tracker 

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

[issue1425127] os.remove OSError: [Errno 13] Permission denied

[Robert Cronk]

Robert Cronk  added the comment:

Could this problem be associated with issue4749?  It was found that 
something goes wrong when two cmd children processes are spawned from 
different threads, when the first exits, it is closing file handles 
shared with the first (or something like that) and it's causing a 
problem with logging in issue4749.  That bug has been closed since it's 
not a problem with logging so I'm searching for other similar bugs to 
see if we can create a new bug that documents the cause and link to 
these other bugs that are all showing different symptoms of the bug.  
Thoughts?

--
nosy: +rcronk

___
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]

Robert Cronk  added the comment:

I found Issue1425127 which may be a different symptom of this core 
problem.  I suggested that we create a bug that documents the core 
problem here as described by Vinay in msg89174 and links to these two 
bugs (along with any others we find) as examples of the types of 
symptoms that can come from this bug.  At that point, the merits of 
working around this bug in python versus documenting the problem for 
python users to work around it can be discussed and a decision can be 
made.  Thoughts?

--

___
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]

Raymond Hettinger  added the comment:

It looks like the patch is extensive and well thought out.  I look
forward to going through it in detail.

--

___
Python tracker 

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

[issue6257] Idle terminates on source save while debugging

[Andy Harrington]

New submission from Andy Harrington :

When I am running the idle debugger, and change something in a source
file and save it, the save works but idle immediately closes. 

I can see the debugger not liking it, but it would be much better if
just the debugger stopped, not the whole idle environment.

I'm running XP professional, Python 3.0.1

--
messages: 89217
nosy: andyharrington
severity: normal
status: open
title: Idle terminates on source save while debugging
type: crash
versions: Python 3.0

___
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]

Robert Cronk  added the comment:

One more possibly related bug is issue2320 where subprocesses are 
spawned from multiple threads.  They found an interesting workaround 
that I found seems to help our problem too: "on Windows, if close_fds 
is true then no handles will be inherited by the child process."  So if 
I change the subprocess.Popen lines in my most recently uploaded script 
to:

rc = subprocess.Popen('cd.bat . > blah.txt', close_fds=True).wait()
rc = subprocess.Popen('del.bat blah.txt', close_fds=True).wait()

The rollover logging failure goes away.  Does os.system have a similar 
option?  If not, then that would mean I'd have to convert all os.system 
calls to subprocess.Popen and add the close_fds=True parameter to it.  
The problem with this is that "Note that on Windows, you cannot set 
close_fds to true and also redirect the standard handles by setting 
stdin, stdout or stderr" and I am using both stdin and stdout on my 
main subprocess.Popen call and I have a couple of os.system calls as 
well.  Thoughts?

--

___
Python tracker 

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

[issue2320] Race condition in subprocess using stdin

[Robert Cronk]

Robert Cronk  added the comment:

Could this problem be associated with issue4749?  It was found that 
something goes wrong when two cmd children processes are spawned from 
different threads, when the first exits, it is closing file handles 
shared with the first (or something like that) and it's causing a 
problem with logging in issue4749.  That bug has been closed since it's 
not a problem with logging itself so I'm searching for other similar 
bugs to see if we can create a new bug that documents the cause and 
link to these other bugs that are all showing different symptoms of the 
bug.  Thoughts?

--
nosy: +rcronk

___
Python tracker 

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

[issue1069410] import on Windows: please call SetErrorMode first

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

i.e., fixed in r60221

--
nosy: +srid

___
Python tracker 

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

[issue6258] distributions built with bdist_msi on 64-bit Windows fail to install correctly

[Jason R. Coombs]

New submission from Jason R. Coombs :

It appears as if bdist_msi isn't properly tagging 64-bit binary builds.

When launching an .msi built by Python 2.6.2 using bdist_msi, such as
numpy found here
(https://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103),
it improperly detects the location of Python (which it gets from the
registry).  If the 32-bit Python 2.6 is also installed, it finds that
version.  If 32-bit Python 2.6 is not installed, it fails to find the
Python installation.  Even if the proper 64-bit Python 2.6 location is
selected, the files are not installed to the Python 2.6 site-packages. 
Furthermore, the registry Uninstall information is stored in the
Wow6432Node.

bdist_wininst executables appear to detect 64-bit Python and install
correctly.

I will attempt to recreate this problem with a minimal project and clean
64-bit Vista or Windows 7 machine at a later date.

--
assignee: tarek
components: Distutils
messages: 89221
nosy: jaraco, tarek
severity: normal
status: open
title: distributions built with bdist_msi on 64-bit Windows fail to install 
correctly
versions: Python 2.6

___
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

[Jason Kankiewicz]

Jason Kankiewicz  added the comment:

Seo, This ticket specifies Python-2.6 as the only version so using "any"
didn't seem to be a problem. 
I was not aware of PEP 291 until you mentioned it and, in order to
maintain compatibility with Python-2.3, the generator expression would
have to be dispensed with as well.

Raymond, I would prefer to substitute "max" for "any" in this case as it
seems to be more straightforward. There's no performance benefit to
using "min" as both "min" and "max" are O(n), no?

--
Added file: http://bugs.python.org/file14261/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

[Raymond Hettinger]

Raymond Hettinger  added the comment:

min() is a substitute for all() and
max() is a substitute for any().

They are O(n) but do not have the early
out behavior of any() and all().

--

___
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]

Changes by Raymond Hettinger :


--

___
Python tracker 

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

[issue6254] tarfile unnecessarily requires seekable files

[Lars Gustäbel]

Lars Gustäbel  added the comment:

If I am not mistaken the functionality you look for is the streaming
mode of tarfile.open():

tar = tarfile.open(fileobj=sys.stdin, mode="r|*")

Does this solve your problem?

--
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

___
Python tracker 

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

[issue6259] ctypes pointer arithmetic

[Thomas Heller]

New submission from Thomas Heller :

This patch implements some pointer arithmetic operations for ctypes.

--
files: ctypes-pointerarith.patch
keywords: patch
messages: 89225
nosy: theller
severity: normal
status: open
title: ctypes pointer arithmetic
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14262/ctypes-pointerarith.patch

___
Python tracker 

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

[issue6259] ctypes pointer arithmetic

[Thomas Heller]

Changes by Thomas Heller :


--
assignee:  -> theller
components: +ctypes
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

[issue6259] ctypes pointer arithmetic

[Mark Dickinson]

Changes by Mark Dickinson :


--
nosy: +marketdickinson

___
Python tracker 

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

[issue6254] tarfile unnecessarily requires seekable files

[Michael K Johnson]

Michael K Johnson  added the comment:

We are doing output, and mode='w|' works.  We were using
tarfile.TarFile, not realizing that the default constructor was an
unsupported and deprecated interface (!?!)

--
status: open -> closed

___
Python tracker 

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

[issue6260] os.utime should allow None values for ATIME or MTIME

[James]

New submission from James :

Hi, in using os.utime, it's nice that you can specify `None' for the
second argument. However it would be even `nicer' to be able to specify
None for either (or potentially both) values for the argument in the
tuple. to emulate this, i've been using os.stat to read the value
beforehand, and just use os.utime with the new value, and the old one
pulled from stat()

HTH, _J

example:
os.utime('/dev/pts/1', None) WORKS
os.utime('/dev/pts/1') SHOULD WORK (allow second argument to default to
None)
os.utime('/dev/pts/1', (time.time(), None)) SHOULD WORK
os.utime('/dev/pts/1', (None, None)) SHOULD WORK
os.utime('/dev/pts/1', (None, time.time())) I GUESS SHOULD WORK

ps: if this is a feature you'd agree with, let me know any maybe i can
*try* to write a patch?

--
components: IO
messages: 89227
nosy: purpleidea
severity: normal
status: open
title: os.utime should allow None values for ATIME or MTIME
type: feature request
versions: Python 2.5

___
Python tracker 

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

[issue6255] PyInt_FromSize_t is undocumented.

[Mark Dickinson]

Mark Dickinson  added the comment:

It seems to me that PyInt_FromSize_t() wouldn't be the right way to create a 
Python 
int from a C unsigned long anyway, since there's no guarantee that C's unsigned 
long and size_t have the same precision.

(I'm not disputing that PyInt_FromSize_t should be documented, by the way.)

Maybe a PyInt_FromUnsignedLong method would be useful?  It would be trivial to 
implement.

--
nosy: +marketdickinson

___
Python tracker 

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

[issue6258] distributions built with bdist_msi on 64-bit Windows fail to install correctly

[Jason R. Coombs]

Jason R. Coombs  added the comment:

Indeed, I confirmed that using the simple example from the distutils manual 
(http://docs.python.org/distutils/introduction.html#a-simple-example) on a 
clean install of Python 2.6.2, bdist_msi exhibits the behavior previously 
described.

I suspect that the TargetPlatform property needs to be set (based on what I 
read here: http://msdn.microsoft.com/en-us/library/cd7a85k9(VS.80).aspx ).

--
title: distributions built with bdist_msi on 64-bit Windows fail to install 
correctly -> distributions built with bdist_msi on 64-bit Windows fail  to 
install correctly

___
Python tracker 

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

[issue6258] distributions built with bdist_msi on 64-bit Windows fail to install correctly

[Jason R. Coombs]

Jason R. Coombs  added the comment:

Based on the MSDN article and what I read in a blog entry
(http://blogs.msdn.com/heaths/archive/2005/10/24/windows-installer-on-64-bit-platforms.aspx),
I thought that the enclosed patch might work around the issue... and
while it does set the template property to x64, the undesirable behavior
persists.

Index: Lib/msilib/__init__.py
===
--- Lib/msilib/__init__.py  (revision 73295)
+++ Lib/msilib/__init__.py  (working copy)
@@ -3,8 +3,11 @@
 # Licensed to PSF under a Contributor Agreement.
 from _msi import *
 import os, string, re
+import sys

-Win64=0
+Intel64=0
+AMD64 = 'AMD64' in sys.version
+Win64 = Intel64 or AMD64

 # Partially taken from Wine
 datasizemask=  0x00ff
@@ -145,8 +148,10 @@
 si.SetProperty(PID_TITLE, "Installation Database")
 si.SetProperty(PID_SUBJECT, ProductName)
 si.SetProperty(PID_AUTHOR, Manufacturer)
-if Win64:
+if Intel64:
 si.SetProperty(PID_TEMPLATE, "Intel64;1033")
+elif AMD64:
+si.SetProperty(PID_TEMPLATE, "x64;1033")
 else:
 si.SetProperty(PID_TEMPLATE, "Intel;1033")
 si.SetProperty(PID_REVNUMBER, gen_uuid())

--
components: +Windows

___
Python tracker 

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

[issue6258] distributions built with bdist_msi on 64-bit Windows fail to install correctly

[Jason R. Coombs]

Jason R. Coombs  added the comment:

I'm adding Martin to this as he appears to be the author of msilib.  If
it's inappropriate for me to do this, I apologize.  Just let me know and
I won't do it again.

--
nosy: +loewis

___
Python tracker 

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

[issue6261] Clarify behaviour of random.uniform

[Mark Dickinson]

New submission from Mark Dickinson :

The documentation for random.uniform() was recently updated to reflect 
the fact that it's possible for random.uniform(a, b) to produce the 
value b;  see issue 4979.

In a recent c.l.p. thread, Robert Kern suggested that 'it 
might be confusing to a user why random.random() returns values in a 
half-open interval while random.uniform() claims a closed interval';  
the thread itself confirms this potential for confusion.  See

http://mail.python.org/pipermail/python-list/2009-June/715851.html

Suggested extra wording for random.uniform, from Robert Kern:

"Due to floating point arithmetic, for some values of a and b, b may or 
may not be one of the possible generated results."

--
assignee: georg.brandl
components: Documentation
messages: 89232
nosy: georg.brandl, marketdickinson
severity: normal
status: open
title: Clarify behaviour of random.uniform
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

___
Python tracker 

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

[issue6261] Clarify behaviour of random.uniform

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee: georg.brandl -> rhettinger
nosy: +rhettinger
priority:  -> low

___
Python tracker 

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

[issue6261] Clarify behaviour of random.uniform

[Mark Dickinson]

Mark Dickinson  added the comment:

Regardless of whether the extra wording is added or not, the docstring for 
random.uniform should probably be changed to match the online 
documentation.  It currently says:

"""Get a random number in the range [a, b)."""

That should probably be:

"""Get a random number in the range [a, b]."""

--

___
Python tracker 

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

[issue6261] Clarify behaviour of random.uniform

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Right.

--

___
Python tracker 

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

[issue6255] PyInt_FromSize_t is undocumented.

[Naoki INADA]

Naoki INADA  added the comment:

You're right. PyInt_FromSize_t() isn't safe for unsigned long.

> Maybe a PyInt_FromUnsignedLong method would be useful?  It would be 
trivial to 
> implement.

I hope that all of py3k's PyInt_From** are in Python 2.x.
It makes maintaining extension module for both of Py2.x and Py3k a bit 
easier.

--

___
Python tracker 

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

[issue6252] logging midnight rotation

[Turnaev Evgeny]

Turnaev Evgeny  added the comment:

I am sorry for my poor english. You must be misunderstood me.
I attached a file try it like this:

wget -o /dev/null http://localhost:9022/

then 5-7 times
wget -o /dev/null http://localhost:9022/s

then 4-5 times 
wget -o /dev/null http://localhost:9022/

i bet this error persists in 3.1

--
status: pending -> open
Added file: http://bugs.python.org/file14263/httpd.py

___
Python tracker 

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

[issue6251] c++ extension module implementation guide/example in extending/embedding documentation

[John O'Driscoll]

John O'Driscoll  added the comment:

I'm aware of Boost without being familiar. I should find out more. I 
don't have any reason to think it might not be the better approach.

I guess when I wrote this I was thinking in terms of minimising 
dependencies: writing a program that depended only on the standard 
libraries of c/c++ and python. In that context, if Boost-python were to 
become a part of a stdlib, there'd be no need at all for this. Are there 
any plans afoot?

Also, if dependencies are not a problem for your project, Boost might be 
the way to go. I won't indulge in any polemic one way or the other. I 
just thought a DIY primer might be useful in some contexts. Whether the 
official docs is the place for it I don't know.

John O'Driscoll

--

___
Python tracker 

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