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

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

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

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

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

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 >

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

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

Re: [Python-Dev] Python CFG Basic blocks

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

[Python-Dev] Python CFG Basic blocks

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 =

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

[Python-Dev] Supporting native backup facility of SQLite

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

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

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? > >

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

On Mon, Jul 11, 2016 at 4:25 PM, Ethan Furman wrote: > On 07/10/2016 08:32 PM, 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

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

On 07/10/2016 08:32 PM, 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