[Python-Dev] Feature Request: Py_NewInterpreter to create separate GIL (branch)

[Robert]

Talin wrote:

>>/ I don't know how you define simple. In order to be able to have
/>>/ separate GILs  you have to remove *all* sharing of objects between
/>>/ interpreters. And all other data structures, too. It would probably
/>>/ kill performance too, because currently obmalloc relies on the GIL.
/
> Nitpick: You have to remove all sharing of *mutable* objects. One day, 
> when we get "pure" GC with no refcounting, that will be a meaningful 
> distinction. :)

Is it mad?:

It could be a distinction now: immutables/singletons refcount could be held 
~fix around MAXINT easily (by a loose periodic GC scheme, or by Py_INC/DEFREF 
to be like { if ob.refcount!=MAXINT ... )

dicty things like Exception.x=5 could either be disabled or 
Exception.refcount=MAXINT/.__dict__=lockingdict ... or exceptions could be 
doubled as they don't have to cross the bridge (weren't they in an ordinary 
python module once ?).

obmalloc.c/LOCK() could be something fast like:

_retry:
  __asm   LOCK INC malloc_lock
  if (malloc_lock!=1) { LOCK DEC malloc_lock; /*yield();*/ goto _retry; }

To know the final speed costs ( 
http://groups.google.de/group/comp.lang.python/msg/01cef42159fd1712 ) would 
require an experiment.
Cheap signal processors (<1%) don't need to be supported for free threading 
interpreters.

Builtin/Extension modules global __dict__ to become a lockingdict. 

Yet a speedy LOCK INC lock method may possibly lead to general free threading 
threads (for most CPUs) at all. Almost all Python objects have 
static/uncritical attributes/require only few locks.
A full blown LOCK INC lock method on dict & list accesses, (avoidable for 
fastlocals?) & defaulty Py_INC/DECREF (as far as there is still refcounting in 
Py3K).
Py_FASTINCREF could be fast for known immutables (mainly Py_None) with MAXINT 
method, and for fresh creations etc.

PyThreadState_GET(): A ts(PyThread_get_thread_ident())/*TlsGetValue() would 
become necessary. Is there a fast thread_ID register in todays CPU's?*


Robert


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of pairing_heap.py?

[Paul Chiusano]

> It is not required.  If you are careful, you can implement a pairing
> heap with a structure combining a dictionary and list.

That's interesting. Can you give an overview of how you can do that? I
can't really picture it. You can support all the pairing heap
operations with the same complexity guarantees? Do you mean a linked
list here or an array?

Paul

On 11/4/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Paul Chiusano schrieb:
> > > To support this, the insert method needs to return a reference to an
> > > object which I can then pass to adjust_key() and delete() methods.
> > > It's extremely difficult to have this functionality with array-based
> > > heaps because the index of an item in the array changes as items are
> > > inserted and removed.
> >
> > I see.
>
> It is not required.  If you are careful, you can implement a pairing
> heap with a structure combining a dictionary and list.  It requires that
> all values be unique and hashable, but it is possible (I developed one
> for a commercial project).
>
> If other people find the need for it, I could rewrite it (can't release
> the closed source).  It would use far less memory than the pairing heap
> implementation provided in the sandbox, and could be converted to C if
> desired and/or required.  On the other hand, I've found the pure Python
> version to be fast enough for most things I've needed it for.
>
>  - Josiah
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r52692 - in python/trunk: Lib/mailbox.py Misc/NEWS

[Anthony Baxter]

On Friday 10 November 2006 13:45, A.M. Kuchling wrote:
> OK, I'll backport it; thanks!
>
> (It's not fixing a frequent data-loss problem -- the patch just
> assures that when flush() or close() returns, data is more likely to
> have been written to disk and be safe after a subsequent system
> crash.)

Sure - it's a potential bug waiting to happen, though. And it's not a fun 
one :) 

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r52692 - in python/trunk: Lib/mailbox.py Misc/NEWS

[A.M. Kuchling]

On Fri, Nov 10, 2006 at 11:56:25AM +1100, Anthony Baxter wrote:
> Looking at the patch, the functions are pretty clearly internal 
> implementation 
> details. I'm happy for it to go into release25-maint (particularly because 
> the consequences of the bug are so dire).

OK, I'll backport it; thanks!

(It's not fixing a frequent data-loss problem -- the patch just
assures that when flush() or close() returns, data is more likely to
have been written to disk and be safe after a subsequent system
crash.)

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r52692 - in python/trunk: Lib/mailbox.py Misc/NEWS

[Anthony Baxter]

On Friday 10 November 2006 01:01, A.M. Kuchling wrote:
> On Thu, Nov 09, 2006 at 02:51:15PM +0100, andrew.kuchling wrote:
> > Author: andrew.kuchling
> > Date: Thu Nov  9 14:51:14 2006
> > New Revision: 52692
> >
> > [Patch #1514544 by David Watson] use fsync() to ensure data is really on
> > disk
>
> Should I backport this change to 2.5.1?  Con: The patch adds two new
> internal functions, _sync_flush() and _sync_close(), so it's an
> internal API change.  Pro: it's a patch that should reduce chances of
> data loss, which is important to people processing mailboxes.
>
> Because it fixes a small chance of potential data loss and the new
> functions are prefixed with _, my personal inclination would be to
> backport this change.

Looking at the patch, the functions are pretty clearly internal implementation 
details. I'm happy for it to go into release25-maint (particularly because 
the consequences of the bug are so dire).

Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using SCons for cross-compilation

[Samuele Pedroni]

Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Nov 9, 2006, at 2:15 PM, [EMAIL PROTECTED] wrote:
>
>   
>> Martin> In any case, the patch being contributed uses SCons. If  
>> people
>> Martin> think this is unmaintainable, this is a reason to  
>> reject the
>> Martin> patch.
>>
>> Could SCons replace distutils?
>> 
>
> I'm not so sure.  I love SCons, but it has some unpythonic aspects to  
> it, which (IMO) make sense as a standalone build tool, but not so  
> much as a standard library module.  I'd probably want to see some of  
> those things improved if we were to use it to replace distutils.
>
>   
in PyPy we explored at some point using SCons instead of abusing 
distutils for our building needs,
it seems to have a library part but a lot of its high-level dependency 
logic seems to be coded
in what is its main invocation script logic in a monolithic way and with 
a lot of global state.
We didn't feel like trying to untangle that or explore more.
> There does seem to be overlap between the two tools though, and it  
> might make for an interesting sprint/project to find and refactor the  
> commonality.
>
> - -Barry
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.5 (Darwin)
>
> iQCVAwUBRVObXHEjvBPtnXfVAQIhQQP/esS6o+7NX/JenJcuEdvb7rWIVxRgzVEh
> rfZGSOO2mp6b0PgrvXjAnZQHYJFpQO5JXpWJVqLBPxbucbBwvWaA0+tgTrpnBpj9
> Cs/vwlMsmk55CwSYjvl7eM0uW9aIuT9QcZxuf4j+T7dzQOL0LL2Id4/876Azcfo0
> 7A0dtc2oJ+U=
> =H1w2
> -END PGP SIGNATURE-
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/pedronis%40strakt.com
>   

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using SCons for cross-compilation

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Nov 9, 2006, at 2:15 PM, [EMAIL PROTECTED] wrote:

>
> Martin> In any case, the patch being contributed uses SCons. If  
> people
> Martin> think this is unmaintainable, this is a reason to  
> reject the
> Martin> patch.
>
> Could SCons replace distutils?

I'm not so sure.  I love SCons, but it has some unpythonic aspects to  
it, which (IMO) make sense as a standalone build tool, but not so  
much as a standard library module.  I'd probably want to see some of  
those things improved if we were to use it to replace distutils.

There does seem to be overlap between the two tools though, and it  
might make for an interesting sprint/project to find and refactor the  
commonality.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRVObXHEjvBPtnXfVAQIhQQP/esS6o+7NX/JenJcuEdvb7rWIVxRgzVEh
rfZGSOO2mp6b0PgrvXjAnZQHYJFpQO5JXpWJVqLBPxbucbBwvWaA0+tgTrpnBpj9
Cs/vwlMsmk55CwSYjvl7eM0uW9aIuT9QcZxuf4j+T7dzQOL0LL2Id4/876Azcfo0
7A0dtc2oJ+U=
=H1w2
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using SCons for cross-compilation

[Martin v. Löwis]

[EMAIL PROTECTED] schrieb:
> Someone (I don't know who) submitted a patch to use SCons for building
> modules in cross-compilation contexts.  Either the author tried to shoehorn
> this into distutils and failed or never tried (maybe because using SCons for
> such takss is much easier - who knows?).  I assume that if the patch is
> accepted that SCons would have to be bundled with Python.

I don't see that as a requirement. People cross-compiling Python could
be required to install SCons - they are used to install all kinds of
things for a cross-compilation environment.

In particular, to run SCons, they need a host python. The just-built
python is unsuitable, as it only runs on the target.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using SCons for cross-compilation

[Martin v. Löwis]

David Boddie schrieb:
> It seems that Martin's patch solves some problems I encountered more cleanly
> (in certain respects) than the solutions I came up with. Here are some
> issues I encountered (from memory):

Just let me point out that it is not my patch:

http://python.org/sf/841454

was contributed by Andreas Ames. I performed triage on it (as it is
about to reach its 3rd anniversary), and view SCons usage as the biggest
obstacle.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using SCons for cross-compilation

[skip]

>> Could SCons replace distutils?

Chris> If SCons replaced Distutils would SCons have to become part of
Chris> Python?  Is SCons ready for that?  What do you do about the
Chris> existing body 3rd party extensions that are already using
Chris> Distutils?

Sorry, my question was ambiguous.  Let me rephrase it: Could SCons replace
distutils as the way to build extension modules delivered with Python
proper?

In answer to your quesions:

 * Yes, I believe so.

 * I have no idea what SCons is ready for.

 * I assume distutils would continue to ship with Python, so existing
   distutils-based setup.py install scripts should continue to work.

Someone (I don't know who) submitted a patch to use SCons for building
modules in cross-compilation contexts.  Either the author tried to shoehorn
this into distutils and failed or never tried (maybe because using SCons for
such takss is much easier - who knows?).  I assume that if the patch is
accepted that SCons would have to be bundled with Python.  I don't see that
as a big problem as long as there's someone to support it and it meets the
basic requirements for inclusion (significant user base, documentation, test
cases, release form).  Given that SCons can apparently be coaxed into
cross-compiling extension modules, I presume it should be relatively simple
to do the same in a normal compilation environment.  If that's the case,
then why use distutils to build Python's core extension modules at all?

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using SCons for cross-compilation

[Martin v. Löwis]

Chris Lambacher schrieb:
> I think a better question is what about Distutils hinders cross-compiler
> scenarios and how to we fix those deficiencies?

It's primarily the lack of contributions. Somebody would have to define
a cross-compilation scenario (where "use Cygwin on Linux" is one that
might be available to many people), and try to make it work.

I believe it wouldn't work out of the box because distutils issues
the wrong commands with the wrong command line options. But I don't
know for sure; I haven't tried myself.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using SCons for cross-compilation

[Chris Lambacher]

On Thu, Nov 09, 2006 at 01:15:15PM -0600, [EMAIL PROTECTED] wrote:
> 
> Martin> In any case, the patch being contributed uses SCons. If people
> Martin> think this is unmaintainable, this is a reason to reject the
> Martin> patch.
> 
> Could SCons replace distutils?
If SCons replaced Distutils would SCons have to become part of Python?  Is
SCons ready for that?  What do you do about the existing body 3rd party
extensions that are already using Distutils?  

Think of the resistance to the, relatively minor, that Setuptools made to the
way Distutils works.

I think a better question is what about Distutils hinders cross-compiler
scenarios and how to we fix those deficiencies?

-Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using SCons for cross-compilation

[skip]

Martin> In any case, the patch being contributed uses SCons. If people
Martin> think this is unmaintainable, this is a reason to reject the
Martin> patch.

Could SCons replace distutils?

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using SCons for cross-compilation

[Martin v. Löwis]

Anthony Baxter schrieb:
> So we'd now have 3 places to update when things change (setup.py, PCbuild 
> area, SCons)? How does this deal with the problems that autoconf has with 
> cross-compilation? It would seem to me that just fixing the extension module 
> building is a tiny part of the problem... or am I missing something?

I'm not quite sure. I believe distutils is too smart to support
cross-compilation. It has its own notion of where to look for
header files and how to invoke the compiler; these builtin
assumptions break for cross-compilation.

In any case, the patch being contributed uses SCons. If people
think this is unmaintainable, this is a reason to reject the
patch.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r52692 - in python/trunk:Lib/mailbox.py Misc/NEWS

[Terry Reedy]

"A.M. Kuchling" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> On Thu, Nov 09, 2006 at 02:51:15PM +0100, andrew.kuchling wrote:
>> Author: andrew.kuchling
>> Date: Thu Nov  9 14:51:14 2006
>> New Revision: 52692
>>
>> [Patch #1514544 by David Watson] use fsync() to ensure data is really on 
>> disk
>
> Should I backport this change to 2.5.1?  Con: The patch adds two new
> internal functions, _sync_flush() and _sync_close(), so it's an
> internal API change.  Pro: it's a patch that should reduce chances of
> data loss, which is important to people processing mailboxes.

I am not familiar with the context but I would naively think of data loss 
as a bug.

The new functions' code could be preceded by a comment that they were added 
in 2.5.1 for internal use only and that external use would make code 
incompatible with 2.5 -- and of course, not documented elsewhere.

tjr



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using SCons for cross-compilation

[Chris Lambacher]

On Thu, Nov 09, 2006 at 04:42:48PM +0100, David Boddie wrote:
> On Thu Nov 9 07:45:30 CET 2006, Anthony Baxter wrote:
> 
> > On Thursday 09 November 2006 16:30, Martin v. Löwis wrote:
> > > Patch #841454 takes a stab at cross-compilation
> > > (for MingW32 on a Linux system, in this case),
> > > and proposes to use SCons instead of setup.py
> > > to compile extension modules. Usage of SCons
> > > would be restricted to cross-compilation (for
> > > the moment).
> > >
> > > What do you think?
> > 
> > So we'd now have 3 places to update when things change (setup.py, PCbuild 
> > area, SCons)? How does this deal with the problems that autoconf has with 
> > cross-compilation? It would seem to me that just fixing the extension 
> > module 
> > building is a tiny part of the problem... or am I missing something?
> 
> I've been working on adding cross-compiling support to Python's build system,
> too, though I've had the luxury of building on Linux for a target platform
> that also runs Linux. Since the build system originally came from the GCC
> project, it shouldn't surprise anyone that there's already a certain level
> of support for cross-compilation built in. Simply setting the --build and
> --host options is a good start, for example.
> 
> It seems that Martin's patch solves some problems I encountered more cleanly
> (in certain respects) than the solutions I came up with. Here are some
> issues I encountered (from memory):
> 
>  * The current system assumes that Parser/pgen will be built using the
>compiler being used for the rest of the build. This obviously isn't
>going to work when the executable is meant for the target platform.
>At the same time, the object files for pgen need to be compiled for
>the interpreter for the target platform.
> 
>  * The newly-compiled interpreter is used to compile the standard library,
>run tests and execute the setup.py file. Some of these things should
>be done by the interpreter, but it won't work on the host platform.
>On the other hand, the setup.py script should be run by the host's
>Python interpreter, but using information about the target interpreter's
>configuration.
> 
>  * There are various extensions defined in the setup.py file that are
>found and erroneously included if you execute it using the host's
>interpreter. Ideally, it would be possible to use the target's
>configuration to disable extensions, but a more configurable build
>process would also be welcome.
> 
This pretty much covers the difficulties I encountered.  For what it's worth,
my experiences with Python 2.5 are documented here:


I am also interested in pursuing solutions that make it easier to both build
python and third party extensions in cross compile environment.

> I'll try to look at Martin's patch at some point. I hope these observations
> and suggestions help explain the current issues with the build system when
> cross-compiling.
> 
> David
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/chris%40kateandchris.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Using SCons for cross-compilation

[David Boddie]

On Thu Nov 9 07:45:30 CET 2006, Anthony Baxter wrote:

> On Thursday 09 November 2006 16:30, Martin v. Löwis wrote:
> > Patch #841454 takes a stab at cross-compilation
> > (for MingW32 on a Linux system, in this case),
> > and proposes to use SCons instead of setup.py
> > to compile extension modules. Usage of SCons
> > would be restricted to cross-compilation (for
> > the moment).
> >
> > What do you think?
> 
> So we'd now have 3 places to update when things change (setup.py, PCbuild 
> area, SCons)? How does this deal with the problems that autoconf has with 
> cross-compilation? It would seem to me that just fixing the extension module 
> building is a tiny part of the problem... or am I missing something?

I've been working on adding cross-compiling support to Python's build system,
too, though I've had the luxury of building on Linux for a target platform
that also runs Linux. Since the build system originally came from the GCC
project, it shouldn't surprise anyone that there's already a certain level
of support for cross-compilation built in. Simply setting the --build and
--host options is a good start, for example.

It seems that Martin's patch solves some problems I encountered more cleanly
(in certain respects) than the solutions I came up with. Here are some
issues I encountered (from memory):

 * The current system assumes that Parser/pgen will be built using the
   compiler being used for the rest of the build. This obviously isn't
   going to work when the executable is meant for the target platform.
   At the same time, the object files for pgen need to be compiled for
   the interpreter for the target platform.

 * The newly-compiled interpreter is used to compile the standard library,
   run tests and execute the setup.py file. Some of these things should
   be done by the interpreter, but it won't work on the host platform.
   On the other hand, the setup.py script should be run by the host's
   Python interpreter, but using information about the target interpreter's
   configuration.

 * There are various extensions defined in the setup.py file that are
   found and erroneously included if you execute it using the host's
   interpreter. Ideally, it would be possible to use the target's
   configuration to disable extensions, but a more configurable build
   process would also be welcome.

I'll try to look at Martin's patch at some point. I hope these observations
and suggestions help explain the current issues with the build system when
cross-compiling.

David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using SCons for cross-compilation

[skip]

Anthony> So we'd now have 3 places to update when things change
Anthony> (setup.py, PCbuild area, SCons)? 

Four.  You forgot Modules/Setup...

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r52692 - in python/trunk: Lib/mailbox.py Misc/NEWS

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Nov 9, 2006, at 9:01 AM, A.M. Kuchling wrote:

> Should I backport this change to 2.5.1?  Con: The patch adds two new
> internal functions, _sync_flush() and _sync_close(), so it's an
> internal API change.  Pro: it's a patch that should reduce chances of
> data loss, which is important to people processing mailboxes.
>
> Because it fixes a small chance of potential data loss and the new
> functions are prefixed with _, my personal inclination would be to
> backport this change.

I agree.  _ is a hint as to its non-publicness and I don't have a  
problem in principle adding such methods.  In this particular case,  
it seems the patch improves reliability, so +1.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRVNEL3EjvBPtnXfVAQIb0QP+Nmd6XPKQeeXaHrAG/fAFjrVHFn4SFkhH
PtJqnLVOAQeSDonDdBQKluypGdWktcpGM/r1mz51cpJhxytYnAbwqeu1LyWJ/maX
ABxG6zrkd7YCjZ5VyK2VQNs2dSLVWYYH24V/xwP5E5D2sEQ80sII3mnydSO+KLVI
HBg9jztsc70=
=Sj0Q
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r52692 - in python/trunk: Lib/mailbox.py Misc/NEWS

[A.M. Kuchling]

On Thu, Nov 09, 2006 at 02:51:15PM +0100, andrew.kuchling wrote:
> Author: andrew.kuchling
> Date: Thu Nov  9 14:51:14 2006
> New Revision: 52692
> 
> [Patch #1514544 by David Watson] use fsync() to ensure data is really on disk

Should I backport this change to 2.5.1?  Con: The patch adds two new
internal functions, _sync_flush() and _sync_close(), so it's an
internal API change.  Pro: it's a patch that should reduce chances of
data loss, which is important to people processing mailboxes.

Because it fixes a small chance of potential data loss and the new
functions are prefixed with _, my personal inclination would be to
backport this change.

Comments?  Anthony, do you want to pronounce on this issue?

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com