Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules

[Paul Moore]

On 12 July 2016 at 06:21, Nick Coghlan  wrote:
> Based on this discussion, I've come to the conclusion that there are
> only two cases where I'd like PEP 399 to document pre-emptive answers
> to "What counts as sufficiently compatible?" question

This sounds reasonable to me (particularly as it says that
implementations "should" do this rather than "must"). I think it would
be useful to see some explanation of *why* this is important included
as well, capturing the situation that prompted this thread, plus a
reminder that the *documented* API remains paramount but that we
prefer to avoid unexpected surprises for people working from
introspection where possible (hence these new recommendations).

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

[Python-Dev] [RELEASE] Python 3.6.0a3 is now available

[Ned Deily]

On behalf of the Python development community and the Python 3.6 release
team, I'm happy to announce the availability of Python 3.6.0a3.
3.6.0a3 is the third of four planned alpha releases of Python 3.6,
the next major release of Python.  During the alpha phase, Python 3.6
remains under heavy development: additional features will be added
and existing features may be modified or deleted.  Please keep in mind
that this is a preview release and its use is not recommended for
production environments.

You can find Python 3.6.0a3 here:

https://www.python.org/downloads/release/python-360a3/ 

The next release of Python 3.6 will be 3.6.0a4, currently scheduled for
2016-08-15.

--Ned

--
  Ned Deily
  n...@python.org -- []

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

Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules

[Nick Coghlan]

On 12 July 2016 at 02:05, Paul Moore  wrote:
> However, I don't think we can assume it'll be possible to make a
> high-level ruling on *every* possible situation. I don't think that's
> reasonable - there needs to be some level of judgement applied. The
> *documented* API is definitive, both implementations must follow the
> documented API - but if the documentation is silent or ambiguous, I
> don't think we should feel under undue pressure to replicate every
> behaviour of the CPython implementation - if we take that view, then
> we're back to implementation-defined semantics. Outside of documented
> behaviour, I don't think mandating compatibility without qualification
> is helpful.
>
> It's worth having guidelines on what implementers should be ensuring
> match between C and pure-Python implementation - and even more so
> having reminders about common pitfalls and places where extra work is
> needed to get the same behaviour - but I'd be concerned if the rules
> became dogma rather than guidance. We need to be prepared to trust the
> judgement of the core devs in this matter.

Based on this discussion, I've come to the conclusion that there are
only two cases where I'd like PEP 399 to document pre-emptive answers
to "What counts as sufficiently compatible?" question:

1. If an existing C API implementation is a public custom type, a
subsequently added Python fallback should also be a custom type, not a
closure or other non-type object that differs from the C
implementation in regards to subclassing and pickling support.
2. If an existing Python API implementation returns a closure, a
subsequently added accelerated version should either also return a
closure (e.g. if the accelerator is implemented in a language with
closure support, like Cython) or else be implemented as a factory
function returning an instance of a non-public type.

The first case is the one that applies to functools.partial:
preserving consistency in subclassing and pickling behaviour was
considered optional, even though it required disabling some of the
existing tests for the C version when testing the pure Python version.

The second case is, as far as I know, currently hypothetical, but
should make it clearer that it's important to watch out for
inadvertently *expanding* the inferred public API when implementing a
C accelerator - regardless of whether the C version or the Python
version is written first, we want to avoid the situation where the C
version implements a superset of the Python one, and folks mistakenly
consider that to be the supported cross-implementation definition of
the API.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] devguide: Star self as idlelib expert. Mark other 2 as inactive.

[Martin Panter]

On 12 July 2016 at 04:14, Martin Panter  wrote:
> On 12 July 2016 at 03:47, terry.reedy  wrote:
>> https://hg.python.org/devguide/rev/cc1c0dd798e7
>
> Terry it looks like you accidentally added Christian back (undoing
> )

Sorry, you can ignore that, I see you already reverted it :)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] devguide: Star self as idlelib expert. Mark other 2 as inactive.

[Martin Panter]

On 12 July 2016 at 03:47, terry.reedy  wrote:
> https://hg.python.org/devguide/rev/cc1c0dd798e7

Terry it looks like you accidentally added Christian back (undoing
)

> -xml.parsers.expat
> -xml.sax
> +xml.parsers.expat christian.heimes
> +xml.sax   christian.heimes
>  xml.sax.handler
>  xml.sax.saxutils
>  xml.sax.xmlreader
> @@ -319,7 +319,7 @@
>  bytecodebenjamin.peterson, pitrou, georg.brandl, yselivanov
>  context managersncoghlan
>  coverity scan   christian.heimes, brett.cannon, twouters
> -cryptographygregory.p.smith, dstufft
> +cryptographychristian.heimes, gregory.p.smith, dstufft
>  data formatsmark.dickinson, georg.brandl
>  databaselemburg
>  devguidencoghlan, eric.araujo, ezio.melotti, willingc
> @@ -341,7 +341,7 @@
>  georg.brandl
>  str.format  eric.smith
>  testing michael.foord, pitrou, ezio.melotti
> -test coverage   giampaolo.rodola
> +test coverage   giampaolo.rodola, christian.heimes
>  threads pitrou
>  time and dates  lemburg, belopolsky
>  unicode lemburg, ezio.melotti, haypo, benjamin.peterson, pitrou
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python CFG Basic blocks

[Brett Cannon]

On Mon, 11 Jul 2016 at 14:02 Obiesie ike-nwosu via Python-Dev <
python-dev@python.org> wrote:

> Hi,
>
> I am looking into how the python compiler generates basic blocks during
> the CFG generation process and my expectations from CFG theory seems to be
> at odds with how the python compiler actually generates its CFG. Take the
> following code snippet for example:
>
> def median(pool):
> copy = sorted(pool)
> size = len(copy)
> if size % 2 == 1:
> return copy[(size - 1) / 2]
> else:
> return (copy[size/2 - 1] + copy[size/2]) / 2
>
> From my understanding of basic blocks in compilers, the above code snippet
> should have at least 3 basic blocks as follows:
> 1. Block 1 - all instructions up to and including those for the if test.
> 2. Block 2 - all instructions for the if body i.e the first return
> statement.
> 3. Block 3 - instructions for the else block i.e. the second return
> statement.
>
> My understanding of the the section on Control flow Graphs in the “Design
> of the CPython Compiler” also alludes to this -
>
>
> As an example, consider an ‘if’ statement with an ‘else’ block. The guard
> on the ‘if’ is a basic block which is pointed to by the basic block
> containing the code leading to the ‘if’ statement. The ‘if’ statement block
> contains jumps (which are exit points) to the true body of the ‘if’ and the
> ‘else’ body (which may be NULL), each of which are their own basic blocks.
> Both of those blocks in turn point to the basic block representing the code
> following the entire ‘if’ statement.
>
>
> The CPython compiler however seems to generate 2 basic blocks for the
> above snippets -
> 1. Block 1 - all instructions up to and including the if statement and the
> body of the if statement (the first return statement in this case)
> 2. Block 2 - instructions for the else block (the second return statement)
>
> Is there any reason for this or have I somehow missed something in the CFG
> generation process?
>

I have not looked at the code or the CFGs that are generated from your
example code, but my guess is it's two blocks instead of three is because
two block is all that's necessary to generate jump targets (since there's
only one jump in that function). Since Python doesn't have block-level
scope there's no need to generate a separate block in the `if` statement.
And since the `if` statement will have a jump to the `else` block and
otherwise fall through then there's only a need to have the block that
starts the function and then the second block that the `if` jump goes to
and that's it.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python CFG Basic blocks

[Obiesie ike-nwosu via Python-Dev]

Hi,

I am looking into how the python compiler generates basic blocks during the CFG 
generation process and my expectations from CFG theory seems to be at odds with 
how the python compiler actually generates its CFG. Take the following code 
snippet for example:

def median(pool):
copy = sorted(pool)
size = len(copy)
if size % 2 == 1:
return copy[(size - 1) / 2]
else:
return (copy[size/2 - 1] + copy[size/2]) / 2

From my understanding of basic blocks in compilers, the above code snippet 
should have at least 3 basic blocks as follows:
1. Block 1 - all instructions up to and including those for the if test.
2. Block 2 - all instructions for the if body i.e the first return 
statement.
3. Block 3 - instructions for the else block i.e. the second return 
statement.

My understanding of the the section on Control flow Graphs in the “Design of 
the CPython Compiler” also alludes to this - 
 
>> As an example, consider an ‘if’ statement with an ‘else’ block. The guard on 
>> the ‘if’ is a basic block which is pointed to by the basic block containing 
>> the code leading to the ‘if’ statement. The ‘if’ statement block contains 
>> jumps (which are exit points) to the true body of the ‘if’ and the ‘else’ 
>> body (which may be NULL), each of which are their own basic blocks. Both of 
>> those blocks in turn point to the basic block representing the code 
>> following the entire ‘if’ statement.


The CPython compiler however seems to generate 2 basic blocks for the above 
snippets - 
1. Block 1 - all instructions up to and including the if statement and 
the body of the if statement (the first return statement in this case)
2. Block 2 - instructions for the else block (the second return 
statement)

Is there any reason for this or have I somehow missed something in the CFG 
generation process?

Regards,

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

Re: [Python-Dev] Supporting native backup facility of SQLite

[Lele Gaifax]

Paul Moore  writes:

>> Original questions still hold, though.
>
> Indeed - I don't see any reason why exposing the backup API through
> the sdlib module would be unacceptable (there's plenty of
> sqlite-specific functionality in there already, it's not as if there's
> a need to limit the module to just the DB-API interface). If you were
> interested in doing that, I'd suggest opening a tracker issue with a
> patch.

Excellent, will do that, thank you for the encouragement!

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it  | -- Fortunato Depero, 1929.

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

Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules

[Brett Cannon]

On Mon, 11 Jul 2016 at 09:06 Paul Moore  wrote:

> On 11 July 2016 at 14:11, Steven D'Aprano  wrote:
> > But generalising this to all possibly mismatches between a C class
> > implementation and a Python function implementation doesn't necessarily
> > follow. Raymond's general point about simplicity versus feature creep
> > still stands, even if in this case adding pickling is useful.
>
> On the specific case that started this thread, I think it's fair to
> say that when people see "object" in the documentation, they think in
> terms of "class instance", so an implementation that uses a closure
> instead of the standard (C implementation) approach is going to trip
> people up. So it would seem OK to me to say that both implementations
> should implement something described as an "object" in the same way
> (class, closure, or whatever else) - *unless* the documentation is
> explicit (for example by using a term like "opaque object" or
> "internal object") that the implementation details of the object are
> not public. (An alternative resolution to the original issue would
> hence be to update the documentation to make it explicit that the
> partial object's implementation is undefined, and cannot be relied on
> by user code).
>
> However, I don't think we can assume it'll be possible to make a
> high-level ruling on *every* possible situation. I don't think that's
> reasonable - there needs to be some level of judgement applied. The
> *documented* API is definitive, both implementations must follow the
> documented API - but if the documentation is silent or ambiguous, I
> don't think we should feel under undue pressure to replicate every
> behaviour of the CPython implementation - if we take that view, then
> we're back to implementation-defined semantics. Outside of documented
> behaviour, I don't think mandating compatibility without qualification
> is helpful.
>
> It's worth having guidelines on what implementers should be ensuring
> match between C and pure-Python implementation - and even more so
> having reminders about common pitfalls and places where extra work is
> needed to get the same behaviour - but I'd be concerned if the rules
> became dogma rather than guidance. We need to be prepared to trust the
> judgement of the core devs in this matter.
>

The other thing to consider is that CPython isn't the only interpreter that
might implement accelerated versions of modules in the stdlib. Those
implementations could have their own needs, etc. that won't necessarily
align with CPython's needs at the C level. And if we actually start
managing the stdlib as its own project then this will just become more
apparently as a separate stdlib repo could empower other implementations to
more easily send contributions upstream.

IOW we need to be careful to not make this too CPython-specific.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Supporting native backup facility of SQLite

[Paul Moore]

On 11 July 2016 at 16:59, Lele Gaifax  wrote:
> Paul Moore  writes:
>
>> There's also apsw (https://github.com/rogerbinns/apsw), which appears
>> to support backup - http://rogerbinns.github.io/apsw/backup.html.
>
> Thank you, will have a look: not sure it fits my need, because the application
> is currently based on Python's sqlite module (thru SQLAlchemy), and it seems
> I'd have to open another APSW connection just to make the backup...
>
> Original questions still hold, though.

Indeed - I don't see any reason why exposing the backup API through
the sdlib module would be unacceptable (there's plenty of
sqlite-specific functionality in there already, it's not as if there's
a need to limit the module to just the DB-API interface). If you were
interested in doing that, I'd suggest opening a tracker issue with a
patch.

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

Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules

[Paul Moore]

On 11 July 2016 at 14:11, Steven D'Aprano  wrote:
> But generalising this to all possibly mismatches between a C class
> implementation and a Python function implementation doesn't necessarily
> follow. Raymond's general point about simplicity versus feature creep
> still stands, even if in this case adding pickling is useful.

On the specific case that started this thread, I think it's fair to
say that when people see "object" in the documentation, they think in
terms of "class instance", so an implementation that uses a closure
instead of the standard (C implementation) approach is going to trip
people up. So it would seem OK to me to say that both implementations
should implement something described as an "object" in the same way
(class, closure, or whatever else) - *unless* the documentation is
explicit (for example by using a term like "opaque object" or
"internal object") that the implementation details of the object are
not public. (An alternative resolution to the original issue would
hence be to update the documentation to make it explicit that the
partial object's implementation is undefined, and cannot be relied on
by user code).

However, I don't think we can assume it'll be possible to make a
high-level ruling on *every* possible situation. I don't think that's
reasonable - there needs to be some level of judgement applied. The
*documented* API is definitive, both implementations must follow the
documented API - but if the documentation is silent or ambiguous, I
don't think we should feel under undue pressure to replicate every
behaviour of the CPython implementation - if we take that view, then
we're back to implementation-defined semantics. Outside of documented
behaviour, I don't think mandating compatibility without qualification
is helpful.

It's worth having guidelines on what implementers should be ensuring
match between C and pure-Python implementation - and even more so
having reminders about common pitfalls and places where extra work is
needed to get the same behaviour - but I'd be concerned if the rules
became dogma rather than guidance. We need to be prepared to trust the
judgement of the core devs in this matter.

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

Re: [Python-Dev] Supporting native backup facility of SQLite

[Lele Gaifax]

Paul Moore  writes:

> There's also apsw (https://github.com/rogerbinns/apsw), which appears
> to support backup - http://rogerbinns.github.io/apsw/backup.html.

Thank you, will have a look: not sure it fits my need, because the application
is currently based on Python's sqlite module (thru SQLAlchemy), and it seems
I'd have to open another APSW connection just to make the backup...

Original questions still hold, though.

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it  | -- Fortunato Depero, 1929.

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

Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules

[Nick Coghlan]

On 11 July 2016 at 23:11, Steven D'Aprano  wrote:
> If a core developer wishes to extend the API of partial objects to
> include such things as subclassing, isinstance tests, pickling etc, then
> it is reasonable to insist that both the C and the Python implementation
> both support the same API and both use a class. But at the moment I
> don't think any of those things are promised or supported[1], except by
> accident, so removing the discrepency between them is not a bug fix, but
> adding new features.

functools.partial was originally C only [1], then pickling support was
added [2], then a custom __repr__ was added [3], and only then was a
Python fallback added [4].

When [4] was implemented as a closure rather than as a custom
callable, the test cases for the pure Python version needed to be
customised to skip the custom __repr__ and pickling support tests
added by [2] and [3].

Emanuel's patch eliminates the special casing of the Python version in
the test suite by replacing the closure with a custom callable that
also implements the custom __repr__ and pickling support, and also
adds the test case needed to ensure subclasses of the Python version
work as expected (previously that test case was simply omitted, since
subclassing the Python version wasn't supported).

[1] https://www.python.org/dev/peps/pep-0309/
[2] https://hg.python.org/cpython/rev/184ca6293218
[3] https://hg.python.org/cpython/rev/2baad8bd0b4f
[4] https://hg.python.org/cpython/rev/fcfaca024160

> The more I think about it, the more I feel that it is *unreasonable* to
> mandate that devs must ensure that alternate implementations mirror each
> others *unsupported and accidental features*. Mirror the supported API?
> Absolutely! But not accidental features.

The pickling and custom __repr__ on functools.partial weren't
accidental features - they were features deliberately added to the C
version before the Python version was implemented that were
nevertheless originally deemed not part of the standard library
definition.

The fact the incomplete implementation was simpler and easier to read
was then used as an argument against providing a more complete
fallback implementation of the original API.

> (Aside: why can't closures be pickled?)

Functions and classes are deserialised based on their name, but just
the name isn't sufficient to deserialise a closure - you also need the
information about the cell references and their contents. However, the
internal mechanics of the way closures work in practice aren't
standardised at the language level, which means there isn't an
implementation independent way to represent them as a pickle (that's
not to say such a scheme couldn't be created - it just hasn't been
done to date).

> [1] If I'm wrong about this, and these features are supported, then
> Emanuel has found a hole in the functools test suite and a weakness in
> our testing: it's too hard to ensure that *both* the Python and C code
> is tested.

There's no hole, as the test suite was structured to special case the
Python fallback and only test the affected features for the C version.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules

[Emanuel Barry]

Hello,

> From: Steven D'Aprano
> Sent: Monday, July 11, 2016 9:11 AM
> 
> This isn't an actual problem that occurred in real code, it's a
> theoretical issue that Emanuel discovered, and by his own admission
> feels that he was doing something dubious ("It may not be the best idea
> to subclass something that is meant to be final" -- ya think?). Raymond
> Hettinger makes some good points about the costs of feature creep needed
> to support these accidental implementation features, and is against it.

Yes, this hasn't actually happened; hypothetic bugs make for the best
discussions though ;)

> But on the other hand, Serhiy also makes some good points about the
> usefulness of pickling partial objects. So as far as this *specific*
> issue goes, perhaps it is justified to make sure the Python
> implementation supports pickling.
> 
> But generalising this to all possibly mismatches between a C class
> implementation and a Python function implementation doesn't necessarily
> follow. Raymond's general point about simplicity versus feature creep
> still stands, even if in this case adding pickling is useful.

I'm not sure about feature creep in this particular case; pickling for
instance is no accident, even if it's not documented. Is there a particular
stance on non-accidental, undocumented features (if that makes any sense)?

> [1] If I'm wrong about this, and these features are supported, then
> Emanuel has found a hole in the functools test suite and a weakness in
> our testing: it's too hard to ensure that *both* the Python and C code
> is tested.

As far as tests go, there's a large common set of tests for either version
(which is the entirety of the Python version's tests), and the C version
extends those with the tests for repr(), pickling and copying, and does all
the tests again for a subclass. This probably doesn't mean much as far as
guaranteed API is concerned, but it does mean that it's (at least
internally) supported.

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

Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules

[Steven D'Aprano]

On Mon, Jul 11, 2016 at 01:32:32PM +1000, Chris Angelico wrote:
> On Mon, Jul 11, 2016 at 1:26 PM, Steven D'Aprano  wrote:
> > (1) How much extra effort are we going to *mandate* that core devs put
> > in to hide the differences between C and Python code, for the benefit of
> > a small minority that will notice them?
> >
> 
> The subject line is raising one specific difference: the use of a
> function in one version and a class in the other. I think it's not
> unreasonable to stipulate one specific incompatibility that mustn't be
> permitted.

Not so fast. Have you read the bug tracker issue that started this?

There are certain things, such as functools.partial() objects, which are 
most naturally implemented as a closure (i.e. a function) in Python, and 
as a class in C. Whether partial() happens to be a class or a function 
is an implementation detail. There are advantages to being able to write 
the simplest code that works, and prohibiting that mismatch means that 
you cannot do that.

If a core developer wishes to extend the API of partial objects to 
include such things as subclassing, isinstance tests, pickling etc, then 
it is reasonable to insist that both the C and the Python implementation 
both support the same API and both use a class. But at the moment I 
don't think any of those things are promised or supported[1], except by 
accident, so removing the discrepency between them is not a bug fix, but 
adding new features.

The more I think about it, the more I feel that it is *unreasonable* to 
mandate that devs must ensure that alternate implementations mirror each 
others *unsupported and accidental features*. Mirror the supported API? 
Absolutely! But not accidental features.

I think its worth reading the issue on the tracker:

http://bugs.python.org/issue27137

This isn't an actual problem that occurred in real code, it's a 
theoretical issue that Emanuel discovered, and by his own admission 
feels that he was doing something dubious ("It may not be the best idea 
to subclass something that is meant to be final" -- ya think?). Raymond 
Hettinger makes some good points about the costs of feature creep needed 
to support these accidental implementation features, and is against it.

But on the other hand, Serhiy also makes some good points about the 
usefulness of pickling partial objects. So as far as this *specific* 
issue goes, perhaps it is justified to make sure the Python 
implementation supports pickling.

(Aside: why can't closures be pickled?)

But generalising this to all possibly mismatches between a C class 
implementation and a Python function implementation doesn't necessarily 
follow. Raymond's general point about simplicity versus feature creep 
still stands, even if in this case adding pickling is useful.



[1] If I'm wrong about this, and these features are supported, then 
Emanuel has found a hole in the functools test suite and a weakness in 
our testing: it's too hard to ensure that *both* the Python and C code 
is tested.


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

Re: [Python-Dev] Supporting native backup facility of SQLite

[Paul Moore]

On 11 July 2016 at 10:51, Lele Gaifax  wrote:
> as I'm going to have a need to use the native `online backup API`__ provided
> by SQLite, I looked around for existing solutions and found `sqlitebck`__.
>
> I somewhat dislike the approach taken by that 3rd party module, and I wonder
> if the API should/could be exposed by the standard library sqlite module
> instead.
>
> Another option would be using ctypes, but as I never used it, I dunno how easy
> it is to maintain compatibility between different OSes...

There's also apsw (https://github.com/rogerbinns/apsw), which appears
to support backup - http://rogerbinns.github.io/apsw/backup.html.

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

[Python-Dev] Supporting native backup facility of SQLite

[Lele Gaifax]

Hi all,

as I'm going to have a need to use the native `online backup API`__ provided
by SQLite, I looked around for existing solutions and found `sqlitebck`__.

I somewhat dislike the approach taken by that 3rd party module, and I wonder
if the API should/could be exposed by the standard library sqlite module
instead.

Another option would be using ctypes, but as I never used it, I dunno how easy
it is to maintain compatibility between different OSes...

What do you think?

Thanks&bye, lele.

__ https://www.sqlite.org/backup.html
__ https://github.com/husio/python-sqlite3-backup 
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it  | -- Fortunato Depero, 1929.

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

Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules

[Nick Coghlan]

On 11 July 2016 at 13:26, Steven D'Aprano  wrote:
> My two core questions are:
>
> (1) How much extra effort are we going to *mandate* that core devs put
> in to hide the differences between C and Python code, for the benefit of
> a small minority that will notice them?
>
> (2) When should that effort be done? Upfront, or when and as problems
> are reported or noticed?
>
> My preference for answers will be, (1) not much, and (2) when problems
> are reported. In other words, close to the status quo.

I think it's still OK to defer fixing discrepancies between the
alternate implementations until people explicitly report a problem,
which I guess means the policy update that I'd be looking for is that
in cases where the C version currently implements a superset of the
Python version's behaviour, the recommended policy be to accept
patches to align the two even if:

- it makes the Python version more complex and hence harder to read
- it makes the Python version slower on CPython (and likely other
runtimes without even a method JIT)

Replacing a closure with a custom callable (as with the
functools.partial patch) is a case where both of those objections
legitimately apply, hence making the right thing to do less than
obvious given the current wording of PEP 399 - it isn't clear whether
those simplicity focused considerations should trump the cross-runtime
compatibility ones.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com