Re: [Python-Dev] Pre-PEP: Redesigning extension modules

On 25 August 2013 14:12, PJ Eby wrote: > That is to say, in the pure PEP 302 world, there is no special status > for "reload" that is different from "load" -- the *only* thing that's > different is that there is already a module object to use, and there > is *no guarantee that it's a module object

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

On Fri, Aug 23, 2013 at 4:50 AM, Stefan Behnel wrote: > Reloading and Sub-Interpreters > == > > To "reload" an extension module, the module create function is executed > again and returns a new module type. This type is then instantiated as by > the original module load

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On Sat, Aug 24, 2013 at 5:55 PM, Stephen J. Turnbull wrote: > Eli Bendersky writes: > > > I'm strongly opposed to reverting [the change to ElementTree] > > because it cleaned up messy code duplication and actually make the > > code size smaller. While I agree that the API of incremental parsing

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

Eli Bendersky writes: > I'm strongly opposed to reverting [the change to ElementTree] > because it cleaned up messy code duplication and actually make the > code size smaller. While I agree that the API of incremental parsing > should be given another look, IncrementalParser can also be seen a

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On Sat, Aug 24, 2013 at 7:33 AM, Nick Coghlan wrote: > On 25 August 2013 00:26, Nick Coghlan wrote: > > On 25 August 2013 00:13, Antoine Pitrou wrote: > >> On Sun, 25 Aug 2013 00:03:01 +1000 > >> Nick Coghlan wrote: > >>> If Stefan's "please revert this" as lxml.etree maintainer isn't > >>> en

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

On 25 Aug 2013 01:44, "Stefan Behnel" wrote: > > Nick Coghlan, 24.08.2013 16:22: > > On 24 August 2013 23:19, Stefan Behnel wrote: > >> Nick Coghlan, 24.08.2013 13:36: > >>> On 24 August 2013 15:51, Nick Coghlan wrote: > My current plan is to create an experimental prototype of this > ap

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

On 25 Aug 2013 05:19, "Benjamin Peterson" wrote: > > 2013/8/24 Terry Reedy : > > On 8/24/2013 8:51 AM, Stefan Behnel wrote: > >> > >> Antoine Pitrou, 24.08.2013 13:53: > >>> > >>> This would also imply extension module have to be subclasses of the > >>> built-in module type. They can't be arbitrar

Re: [Python-Dev] Status of 3.2 in Hg repository?

Am 24.08.2013 22:38, schrieb Tim Peters: > [Tim, wondering why the 3.2 branch isn't "inactive"] > > [Georg Brandl] >> FWIW I have no real objections, I just don't see the gain. > > I'm glad it's OK! Especially because it's already been done ;-) > > Two gains: > > 1. "hg branches" output now ma

Re: [Python-Dev] Status of 3.2 in Hg repository?

[Tim, wondering why the 3.2 branch isn't "inactive"] [Georg Brandl] > FWIW I have no real objections, I just don't see the gain. I'm glad it's OK! Especially because it's already been done ;-) Two gains: 1. "hg branches" output now matches what the developer docs imply it should be. It didn't

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

2013/8/24 Terry Reedy : > On 8/24/2013 8:51 AM, Stefan Behnel wrote: >> >> Antoine Pitrou, 24.08.2013 13:53: >>> >>> This would also imply extension module have to be subclasses of the >>> built-in module type. They can't be arbitrary objects like Stefan >>> proposed. I'm not sure what the latter e

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

On 8/24/2013 8:51 AM, Stefan Behnel wrote: Antoine Pitrou, 24.08.2013 13:53: This would also imply extension module have to be subclasses of the built-in module type. They can't be arbitrary objects like Stefan proposed. I'm not sure what the latter enables, but it would probably make things mor

Re: [Python-Dev] Status of 3.2 in Hg repository?

Am 21.08.2013 21:26, schrieb Brett Cannon: > > > > On Wed, Aug 21, 2013 at 2:22 PM, Tim Peters > wrote: > > [Tim, wondering why the 3.2 branch isn't "inactive"] > >> ... > >> So let's try a different question ;-) Would anyone _object_ to > >> compl

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On 8/24/2013 10:03 AM, Nick Coghlan wrote: I have not used ET or equivalent, but I do have opinions on function names. Looking at the current documentation of ElementTree sets of alarm bells on that front, as it contains the following method descriptions for XMLParser: close() Fi

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

Nick Coghlan, 24.08.2013 16:22: > On 24 August 2013 23:19, Stefan Behnel wrote: >> Nick Coghlan, 24.08.2013 13:36: >>> On 24 August 2013 15:51, Nick Coghlan wrote: My current plan is to create an experimental prototype of this approach this weekend. That will include stdlib test cases, so

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On Sat, Aug 24, 2013 at 7:33 AM, Nick Coghlan wrote: > On 25 August 2013 00:26, Nick Coghlan wrote: > > On 25 August 2013 00:13, Antoine Pitrou wrote: > >> On Sun, 25 Aug 2013 00:03:01 +1000 > >> Nick Coghlan wrote: > >>> If Stefan's "please revert this" as lxml.etree maintainer isn't > >>> en

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On 25 August 2013 00:26, Nick Coghlan wrote: > On 25 August 2013 00:13, Antoine Pitrou wrote: >> On Sun, 25 Aug 2013 00:03:01 +1000 >> Nick Coghlan wrote: >>> If Stefan's "please revert this" as lxml.etree maintainer isn't >>> enough, then I'm happy to add a "please revert this" as a core >>> co

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On 25 August 2013 00:13, Antoine Pitrou wrote: > On Sun, 25 Aug 2013 00:03:01 +1000 > Nick Coghlan wrote: >> If Stefan's "please revert this" as lxml.etree maintainer isn't >> enough, then I'm happy to add a "please revert this" as a core >> committer that is confused about how and when the new t

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

On 24 August 2013 23:19, Stefan Behnel wrote: > Nick Coghlan, 24.08.2013 13:36: >> On 24 August 2013 15:51, Nick Coghlan wrote: >>> My current plan is to create an experimental prototype of this >>> approach this weekend. That will include stdlib test cases, so it will >>> also show how it looks f

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On Sun, 25 Aug 2013 00:03:01 +1000 Nick Coghlan wrote: > If Stefan's "please revert this" as lxml.etree maintainer isn't > enough, then I'm happy to add a "please revert this" as a core > committer that is confused about how and when the new tulip-inspired > incremental parsing API should be used

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On 24 August 2013 20:58, Antoine Pitrou wrote: > Someone can take the whole thing over if they want to, change the API > and make it more shiny or different, tweak the implementation to suit > it better to their own aesthetic sensibilities, but please don't revert > an useful feature unless it's b

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

Nick Coghlan, 24.08.2013 13:36: > On 24 August 2013 15:51, Nick Coghlan wrote: >> My current plan is to create an experimental prototype of this >> approach this weekend. That will include stdlib test cases, so it will >> also show how it looks from the extension developer's point of view. > > I p

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On Sat, 24 Aug 2013 14:53:13 +0200, Antoine Pitrou wrote: > On Sat, 24 Aug 2013 14:46:32 +0200 > Stefan Behnel wrote: > > > > As I said, the only reason why the current implementation is there is > > "because it's there". > > No. It works, it's functional, it fills an use case, and it doesn't s

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

Antoine Pitrou, 24.08.2013 14:53: > it doesn't seem to have any concrete issues. I don't consider closing your eyes and ignoring the obvious a good strategy for software design. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.pyth

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

Antoine Pitrou, 24.08.2013 15:00: > On Sat, 24 Aug 2013 14:51:42 +0200 > Stefan Behnel wrote: >> Antoine Pitrou, 24.08.2013 13:53: >>> This would also imply extension module have to be subclasses of the >>> built-in module type. They can't be arbitrary objects like Stefan >>> proposed. I'm not sure

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

On Sat, 24 Aug 2013 14:51:42 +0200 Stefan Behnel wrote: > Antoine Pitrou, 24.08.2013 13:53: > > This would also imply extension module have to be subclasses of the > > built-in module type. They can't be arbitrary objects like Stefan > > proposed. I'm not sure what the latter enables, but it would

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On Sat, 24 Aug 2013 14:46:32 +0200 Stefan Behnel wrote: > > As I said, the only reason why the current implementation is there is > "because it's there". No. It works, it's functional, it fills an use case, and it doesn't seem to have any concrete issues. Get over it, Stefan, and stop trolling

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

Antoine Pitrou, 24.08.2013 13:53: > This would also imply extension module have to be subclasses of the > built-in module type. They can't be arbitrary objects like Stefan > proposed. I'm not sure what the latter enables, but it would probably > make things more difficult internally. My line of th

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

Antoine Pitrou, 24.08.2013 12:58: > By the way, just know that Stefan tried to provide a patch that would > better suit his API desires, and failed because ElementTree's current > implementation makes it difficult to do so. Absolutely. I agree that your current implementation is a hack that works

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

On Sat, 24 Aug 2013 21:36:51 +1000 Nick Coghlan wrote: > On 24 August 2013 15:51, Nick Coghlan wrote: > > My current plan is to create an experimental prototype of this > > approach this weekend. That will include stdlib test cases, so it will > > also show how it looks from the extension develop

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

On 24 August 2013 15:51, Nick Coghlan wrote: > My current plan is to create an experimental prototype of this > approach this weekend. That will include stdlib test cases, so it will > also show how it looks from the extension developer's point of view. I prototyped as much as I could without PEP

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On Sat, 24 Aug 2013 15:57:50 +1000 Nick Coghlan wrote: > On 24 August 2013 15:32, Stefan Behnel wrote: > > So, to put it more nicely, I think this feature was added without the > > amount of review that it needs, and now that I've given it that review, I'm > > asking for removal of the feature an