Re: [Python-Dev] Missing operator.call

On Wed, Feb 4, 2009 at 10:43, Steven Bethard wrote: > On Wed, Feb 4, 2009 at 10:25 AM, Brett Cannon wrote: >> On Wed, Feb 4, 2009 at 05:35, Hrvoje Niksic wrote: >>> Andrew Bennetts wrote: >>>> >>>> A patch to add operator.caller(*args, **kwargs) may be

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

On Thu, Aug 11, 2011 at 00:02, Antoine Pitrou wrote: > Le Thu, 11 Aug 2011 03:34:37 +0200, > brian.curtin a écrit : > > http://hg.python.org/cpython/rev/77a65b078852 > > changeset: 71809:77a65b078852 > > parent: 71803:1b4fae183da3 > > user:Brian Curtin > > date:Wed Aug 10

Re: [Python-Dev] Backporting howto/pyporting to 2.7

Probably mostly hassle of maintaining changes between the two versions, but the doc will probably get more exposure that way. I say if you want to spearhead the backport, go for it. On Fri, Aug 12, 2011 at 09:51, Éric Araujo wrote: > Hi everyone, > > I think it would be useful to have the “Porti

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

On Sun, Aug 14, 2011 at 19:36, Benjamin Peterson wrote: > 2011/8/14 Brett Cannon : > > > > > > On Thu, Aug 11, 2011 at 00:02, Antoine Pitrou > wrote: > >> > >> Le Thu, 11 Aug 2011 03:34:37 +0200, > >> brian.curtin a écrit : > >> >

Re: [Python-Dev] Latest draft of PEP 399 (Pure Python/C Accelerator Module Compatibility Requirements)

meone). On Sun, Jul 17, 2011 at 17:16, Brett Cannon wrote: > While at a mini-PyPy sprint w/ Alex Gaynor of PyPy and Phil Jenvey of > Jython, I decided to finally put the time in to update this PEP yet again. > > The biggest changes is that the 100% branch coverage requirement has bee

Re: [Python-Dev] Planned PEP status changes

On Tue, Aug 23, 2011 at 19:42, Nick Coghlan wrote: > Unless I hear any objections, I plan to adjust the current PEP > statuses as follows some time this weekend: > > Move from Accepted to Finished: > >    389  argparse - New Command Line Parsing Module              Bethard >    391  Dictionary-Bas

Re: [Python-Dev] What it takes to change a single keyword.

Please file a bug about the dead links so we can fix/remove them. On Wed, Oct 5, 2011 at 13:29, Francisco Martin Brugue < francisco.mar...@web.de> wrote: > Just Info on the links: > > > http://docs.python.org/**devguide/compiler.htmlprovides > inf

Re: [Python-Dev] Deprecation policy

On Mon, Oct 24, 2011 at 06:17, Antoine Pitrou wrote: > On Mon, 24 Oct 2011 15:58:11 +0300 > Ezio Melotti wrote: >> >> I suggest to follow the following process: >>    1) deprecate something and add a DeprecationWarning; >>    2) decide how long the deprecation should last; >>    3) use the deprec

Re: [Python-Dev] Code cleanups in stable branches?

On Mon, Oct 31, 2011 at 13:24, Nick Coghlan wrote: > Removing dead code and bypassing redundant code are both reasonable bug > fixes. The kind of change to be avoided is gratuitous replacement of older > idioms with newer ones. > > What Nick said as I was in the middle of typing when he sent this

Re: [Python-Dev] Unexpected behaviour in compileall

On Wed, Nov 2, 2011 at 09:13, Vinay Sajip wrote: > Charles-François Natali free.fr> writes: > > > It's a consequence of http://hg.python.org/cpython/rev/740baff4f169. > > I'll fix that. > > Should a new issue be opened (or #13303 re-opened) pending this fix? > Re-open the issue. > > Regards,

Re: [Python-Dev] documenting the Hg commit message hooks in the devguide

On Fri, Nov 11, 2011 at 11:24, Eli Bendersky wrote: > Hi, > > Our Hg repo has some useful hooks on commit messages that allow to > specify which issue to notify for commits, and which issue to close. > AFAIU, it's currently documented only in the code of the hook > (http://hg.python.org/hooks/fil

Re: [Python-Dev] PyPy 1.7 - widening the sweet spot

On Thu, Nov 24, 2011 at 07:46, Nick Coghlan wrote: > On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski > wrote: > > The problem is not with maintaining the modified directory. The > > problem was always things like changing interface between the C > > version and the Python version or introdu

Re: [Python-Dev] PyPy 1.7 - widening the sweet spot

On Fri, Nov 25, 2011 at 12:37, Antoine Pitrou wrote: > On Fri, 25 Nov 2011 12:37:59 -0500 > Brett Cannon wrote: > > On Thu, Nov 24, 2011 at 07:46, Nick Coghlan wrote: > > > > > On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski > > > > wrote: > >

Re: [Python-Dev] [Python-checkins] peps: Bring the Python 3.3 feature list up to date.

Is the change to the pyc format big enough news to go into the release PEP? Or should that just be a "What's New" topic? On Fri, Jan 13, 2012 at 15:18, georg.brandl wrote: > http://hg.python.org/peps/rev/ea3ffa3611e5 > changeset: 4012:ea3ffa3611e5 > user:Georg Brandl > date:Fri

Re: [Python-Dev] Daily reference leaks (12de1ad1cee8): sum=6024

On Wed, Jan 18, 2012 at 10:56, Antoine Pitrou wrote: > On Thu, 19 Jan 2012 01:06:07 +1000 > Nick Coghlan wrote: > > On Wed, Jan 18, 2012 at 2:31 PM, wrote: > > > results for 12de1ad1cee8 on branch "default" > > > > > > > > > test_capi leaked [2008,

Re: [Python-Dev] Daily reference leaks (12de1ad1cee8): sum=6024

On Wed, Jan 18, 2012 at 11:27, Antoine Pitrou wrote: > On Wed, 18 Jan 2012 11:14:50 -0500 > Brett Cannon wrote: > > > On Wed, Jan 18, 2012 at 10:56, Antoine Pitrou > wrote: > > > > > On Thu, 19 Jan 2012 01:06:07 +1000 > > > Nick Coghlan wrote: > &

Re: [Python-Dev] PEP 407 / splitting the stdlib

On Wed, Jan 18, 2012 at 09:08, Nick Coghlan wrote: > On Wed, Jan 18, 2012 at 10:30 PM, Antoine Pitrou > wrote: > > Splitting the stdlib: > > - requires someone to do the splitting (highly non-trivial given the > > interactions of some modules with interpreter details or low-level C > > code) > >

Re: [Python-Dev] Counting collisions for the win

On Fri, Jan 20, 2012 at 13:15, Guido van Rossum wrote: > On Fri, Jan 20, 2012 at 5:10 AM, Barry Warsaw wrote: > >> On Jan 20, 2012, at 01:50 PM, Victor Stinner wrote: >> >> >Counting collision doesn't solve this case, but it doesn't make the >> >situation worse than before. Raising quickly an ex

[Python-Dev] Sprinting at PyCon US

I went ahead and signed us up as usual: https://us.pycon.org/2012/community/sprints/projects/ . I listed myself as the leader, but I will only be at the sprints one full day and whatever part of Tuesday I can fit in before flying out to Toronto (which is probably not much thanks to the timezone di

Re: [Python-Dev] devguide: Use -j0 to maximimze parallel execution.

On Tue, Jan 24, 2012 at 13:52, Georg Brandl wrote: > Am 24.01.2012 18:58, schrieb brett.cannon: > > http://hg.python.org/devguide/rev/a34e4a6b89dc > > changeset: 489:a34e4a6b89dc > > user:Brett Cannon > > date:Tue Jan 24 12:58:01 2012 -0500 &g

Re: [Python-Dev] plugging the hash attack

On Fri, Jan 27, 2012 at 21:33, Benjamin Peterson wrote: > 2012/1/27 Steven D'Aprano : > > Benjamin Peterson wrote: > >> > >> Hello everyone, > >> In effort to get a fix out before Perl 6 goes mainstream, Barry and I > >> have decided to pronounce on what we want for our stable releases. > >> What

Re: [Python-Dev] [Python-checkins] cpython: Issue #8828: Add new function os.replace(), for cross-platform renaming with

Should this end up being used in importlib through _os? On Mon, Jan 30, 2012 at 16:11, antoine.pitrou wrote: > http://hg.python.org/cpython/rev/80ddbd87 > changeset: 74689:80ddbd87 > user:Antoine Pitrou > date:Mon Jan 30 22:08:52 2012 +0100 > summary: > Issue #8828: Ad

Re: [Python-Dev] cdecimal (Was: Store timestamps as decimal.Decimal objects)

On Tue, Jan 31, 2012 at 06:47, Paul Moore wrote: > On 31 January 2012 11:11, Nick Coghlan wrote: > > although decimal.Decimal is also a contender if backed up by > > Stefan's C implementation. > > As you mention this, and given the ongoing thread about __preview__ > and "nearly ready for stdlib"

Re: [Python-Dev] [Python-checkins] cpython (3.2): remove unused import

I'm going to assume pylint or pyflakes would throw too many warnings on the stdlib, but would it be worth someone's time to write a simple unused import checker to run over the stdlib on occasion? I bet even one that did nothing more than a regex search for matched import statements would be good e

[Python-Dev] need help with frozen module/marshal/gc issue involving sub-interpreters for importlib bootstrapping

So my grand quest for bootstrapping importlib into CPython is damn close to coming to fruition; I have one nasty bug blocking my way and I can't figure out what could be causing it. I'm hoping someone here will either know the solution off the top of their head or will have the time to have a quick

Re: [Python-Dev] cpython (3.2): remove unused import

On Sun, Feb 5, 2012 at 19:53, Christian Heimes wrote: > Am 06.02.2012 01:39, schrieb Brett Cannon: > > I'm going to assume pylint or pyflakes would throw too many warnings on > > the stdlib, but would it be worth someone's time to write a simple > > unused import

Re: [Python-Dev] cpython (3.2): remove unused import

On Mon, Feb 6, 2012 at 13:07, Christian Heimes wrote: > Am 06.02.2012 18:57, schrieb Brett Cannon: > > Ah, but does it run against Python 3? If so then this is something to > > suggest on python-mentor for someone to get their feet wet for > contributing. > > Probabl

Re: [Python-Dev] need help with frozen module/marshal/gc issue involving sub-interpreters for importlib bootstrapping

On Mon, Feb 6, 2012 at 11:32, Benjamin Peterson wrote: > 2012/2/6 Brett Cannon : > > Thanks for any help people can provide me on this now 5 year quest to get > > this work finished. > > Fixed. (_PyExc_Init was behaving badly.) That did it! Thanks, Benjamin! Doing on

Re: [Python-Dev] importlib quest

On Mon, Feb 6, 2012 at 14:49, Antoine Pitrou wrote: > On Mon, 6 Feb 2012 09:57:56 -0500 > Brett Cannon wrote: > > Thanks for any help people can provide me on this now 5 year quest to get > > this work finished. > > Do you have any plan to solve the performance issue? &

[Python-Dev] requirements for moving __import__ over to importlib?

I'm going to start this off with the caveat that hg.python.org/sandbox/bcannon#bootstrap_importlib is not completely at feature parity, but getting there shouldn't be hard. There is a FAILING file that has a list of the tests that are not passing because importlib bootstrapping and a comment as to

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Tue, Feb 7, 2012 at 15:49, Antoine Pitrou wrote: > On Tue, 7 Feb 2012 15:07:24 -0500 > Brett Cannon wrote: > > > > Now I'm going to be upfront and say I really did not want to have this > > performance conversation now as I have done *NO* profiling or analysis

Re: [Python-Dev] requirements for moving __import__ over to importlib?

gt; On Feb 07, 2012, at 03:07 PM, Brett Cannon wrote: > > >One is maintainability. Antoine mentioned how if change occurs everyone is > >going to have to be able to fix code in importlib, and that's the point! > I > >don't know about the rest of you but I find

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Tue, Feb 7, 2012 at 16:19, Paul Moore wrote: > On 7 February 2012 20:49, Antoine Pitrou wrote: > > Well, import time is so important that the Mercurial developers have > > written an on-demand import mechanism, to reduce the latency of > > command-line operations. > > One question here, I gue

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Tue, Feb 7, 2012 at 15:28, Dirkjan Ochtman wrote: > On Tue, Feb 7, 2012 at 21:24, Barry Warsaw wrote: > > Identifying the use cases are important here. For example, even if it > were a > > lot slower, Mailman wouldn't care (*I* might care because it takes > longer to > > run my test, but my

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Tue, Feb 7, 2012 at 16:51, PJ Eby wrote: > On Tue, Feb 7, 2012 at 3:07 PM, Brett Cannon wrote: > >> So, if there is going to be some baseline performance target I need to >> hit to make people happy I would prefer to know what that (real-world) >> benchmark is and wha

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Tue, Feb 7, 2012 at 17:42, Antoine Pitrou wrote: > On Tue, 7 Feb 2012 17:24:21 -0500 > Brett Cannon wrote: > > > > IOW you want the sys.modules case fast, which I will never be able to > match > > compared to C code since that is pure execution with no I/O. > &

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Tue, Feb 7, 2012 at 18:08, Antoine Pitrou wrote: > On Tue, 7 Feb 2012 17:16:18 -0500 > Brett Cannon wrote: > > > > > > IOW I really do not look forward to someone saying "importlib is so > much > > > > slower at importing a module containing `

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Tue, Feb 7, 2012 at 21:27, PJ Eby wrote: > > > On Tue, Feb 7, 2012 at 5:24 PM, Brett Cannon wrote: > >> >> On Tue, Feb 7, 2012 at 16:51, PJ Eby wrote: >> >>> On Tue, Feb 7, 2012 at 3:07 PM, Brett Cannon wrote: >>> >>>> So, if the

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Tue, Feb 7, 2012 at 22:47, Nick Coghlan wrote: > On Wed, Feb 8, 2012 at 12:54 PM, Terry Reedy wrote: > > On 2/7/2012 9:35 PM, PJ Eby wrote: > >> It's just that not everything I write can depend on Importing. > >> Throw an equivalent into the stdlib, though, and I guess I wouldn't have > >> t

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Tue, Feb 7, 2012 at 22:47, Nick Coghlan wrote [SNIP] > The fact that we have an undocumented PEP 302 based reimplementation > of imports squirrelled away in pkgutil to make pkgutil and runpy work > is sheer insanity (replacing *that* with importlib might actually be a > good first step towar

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Tue, Feb 7, 2012 at 18:26, Alex Gaynor wrote: > Brett Cannon python.org> writes: > > > > IOW you want the sys.modules case fast, which I will never be able to > match > compared to C code since that is pure execution with no I/O. > > > > > Sur

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Wed, Feb 8, 2012 at 11:09, Antoine Pitrou wrote: > Le mercredi 08 février 2012 à 11:01 -0500, Brett Cannon a écrit : > > > > > > On Tue, Feb 7, 2012 at 17:42, Antoine Pitrou > > wrote: > > On Tue, 7 Feb 2012 17:24:21 -050

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Wed, Feb 8, 2012 at 11:15, Brett Cannon wrote: > > > On Tue, Feb 7, 2012 at 22:47, Nick Coghlan wrote > > [SNIP] > > >> The fact that we have an undocumented PEP 302 based reimplementation >> of imports squirrelled away in pkgutil to make pkgutil an

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Wed, Feb 8, 2012 at 14:57, Terry Reedy wrote: > On 2/8/2012 11:13 AM, Brett Cannon wrote: > >> On Tue, Feb 7, 2012 at 22:47, Nick Coghlan > > > I'm not sure such an addition would help much with the base >>interpreter start up time though - mos

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Wed, Feb 8, 2012 at 15:31, Terry Reedy wrote: > On 2/8/2012 3:16 PM, Brett Cannon wrote: > >> On Wed, Feb 8, 2012 at 14:57, Terry Reedy >Would the following work? Treat a function as a 'loop' in that it >>may be executed repeatedly. Treat 'import

Re: [Python-Dev] ctypes/utils.py problem

Could you file a bug at bugs.python.org, David, so we don't lose track of this? On Wed, Feb 8, 2012 at 18:03, David Goulet wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi everyone, > > I'm working with the LTTng (Linux Tracing) team and we came across a > problem > with our user-

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Wed, Feb 8, 2012 at 20:28, PJ Eby wrote: > > > On Wed, Feb 8, 2012 at 4:08 PM, Brett Cannon wrote: > >> >> On Wed, Feb 8, 2012 at 15:31, Terry Reedy wrote: >> >>> For top-level imports, unless *all* are made lazy, then there *must* be >>> s

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Wed, Feb 8, 2012 at 20:26, Nick Coghlan wrote: > On Thu, Feb 9, 2012 at 2:09 AM, Antoine Pitrou > wrote: > > I guess my point was: why is there a function call in that case? The > > "import" statement could look up sys.modules directly. > > Or the built-in __import__ could still be written in

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Thu, Feb 9, 2012 at 13:43, PJ Eby wrote: > > On Feb 9, 2012 9:58 AM, "Brett Cannon" wrote: > > This actually depends on the type of ImportError. My current solution > actually would trigger an ImportError at the import statement if no finder > could locate the mod

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Thu, Feb 9, 2012 at 17:00, PJ Eby wrote: > On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyer wrote: > >> For those of you not watching -ideas, or ignoring the "Python TIOBE >> -3%" discussion, this would seem to be relevant to any discussion of >> reworking the import mechanism: >> >> http://mail.sc

Re: [Python-Dev] PEP 411: Provisional packages in the Python standard library

Other than the misspelling of "maintenante" instead of "maintenance", LGTM. On Fri, Feb 10, 2012 at 09:06, Eli Bendersky wrote: > Hi all, > > Following the intensive and fruitful discussion of the (now rejected) > PEP 408 ( > http://mail.python.org/pipermail/python-dev/2012-January/115850.html),

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Fri, Feb 10, 2012 at 15:07, PJ Eby wrote: > On Fri, Feb 10, 2012 at 1:05 PM, Brett Cannon wrote: > >> >> >> On Thu, Feb 9, 2012 at 17:00, PJ Eby wrote: >> >>> I did some crude timeit tests on frozenset(listdir()) and trapping >>> failed sta

Re: [Python-Dev] requirements for moving __import__ over to importlib?

On Fri, Feb 10, 2012 at 16:29, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/10/2012 03:38 PM, Brett Cannon wrote: > > Changes in any fashion to the directory. Do filesystems atomically > > update the mtime of a directory when they co

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

On Mon, Feb 13, 2012 at 23:16, Nick Coghlan wrote: > On Tue, Feb 14, 2012 at 1:42 PM, Eli Bendersky wrote: > > An open question remains on whether to deprecate cElementTree, now that > this > > change is in place. > > > > Currently in 3.3 the whole cElementTree module is: > > > > # Deprecated

Re: [Python-Dev] [Python-checkins] cpython: Issue #14043: Speed up importlib's _FileFinder by at least 8x, and add a new

On Sun, Feb 19, 2012 at 22:15, Nick Coghlan wrote: > However, "very cool" on adding the caching in the default importers :) Thanks to PJE for bringing the idea up again and Antoine discovering the approach *independently* from PJE and myself and actually writing the code. Now I *really* need t

Re: [Python-Dev] [Python-checkins] cpython: Issue #14043: Speed up importlib's _FileFinder by at least 8x, and add a new

On Mon, Feb 20, 2012 at 17:29, PJ Eby wrote: > On Mon, Feb 20, 2012 at 1:20 PM, Brett Cannon wrote: > >> On Sun, Feb 19, 2012 at 22:15, Nick Coghlan wrote: >> >>> However, "very cool" on adding the caching in the default importers :) >> >> &g

Re: [Python-Dev] hash randomization in 3.3

On Tue, Feb 21, 2012 at 15:05, Barry Warsaw wrote: > On Feb 21, 2012, at 02:58 PM, Benjamin Peterson wrote: > > >2012/2/21 Antoine Pitrou : > >> > >> Hello, > >> > >> Shouldn't it be enabled by default in 3.3? > > Yes. > > >Should you be able to disable it? > > No, but you should be able to provi

Re: [Python-Dev] hash randomization in 3.3

On Tue, Feb 21, 2012 at 15:58, Xavier Morel wrote: > On 2012-02-21, at 21:24 , Brett Cannon wrote: > > On Tue, Feb 21, 2012 at 15:05, Barry Warsaw wrote: > > > >> On Feb 21, 2012, at 02:58 PM, Benjamin Peterson wrote: > >> > >>> 2

Re: [Python-Dev] cpython: Refactor importlib to make it easier to re-implement in C.

On Thu, Feb 23, 2012 at 10:43, Antoine Pitrou wrote: > On Thu, 23 Feb 2012 16:18:19 +0100 > brett.cannon wrote: > > def _sanity_check(name, package, level): > > """Verify arguments are "sane".""" > > +if not hasattr(name, 'rpartition'): > > +raise TypeError("module name must be

Re: [Python-Dev] requirements for moving __import__ over to importlib?

; > Le 07/02/2012 23:21, Brett Cannon a écrit : > > On Tue, Feb 7, 2012 at 15:28, Dirkjan Ochtman > wrote: > >> [...] > >> Anyway, I think there was enough of a python3 port for Mercurial (from > >> various GSoC students) that you can probably run some of the

Re: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library

On Fri, Feb 24, 2012 at 13:23, Georg Brandl wrote: > Am 24.02.2012 18:46, schrieb Antoine Pitrou: > > > > Hello, > > > > On Sat, 25 Feb 2012 03:24:27 +1000 > > Nick Coghlan wrote: > >> To allow the PEP 407 authors to focus on making the case for doing > >> full CPython releases every 6 months (i

Re: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library

On Fri, Feb 24, 2012 at 21:08, Matt Joiner wrote: > I think every minor release should be fully supported. The current rate of > change is very high and there's a huge burden on implementers and > production users to keep up, so much so that upgrading is undesirable > except for serious enthusias

Re: [Python-Dev] [Python-checkins] cpython: Issue #14080: fix sporadic test_imp failure. Patch by Stefan Krah.

On Sun, Feb 26, 2012 at 12:13, antoine.pitrou wrote: > http://hg.python.org/cpython/rev/1d7472b015f0 > changeset: 75296:1d7472b015f0 > user:Antoine Pitrou > date:Sun Feb 26 18:09:50 2012 +0100 > summary: > Issue #14080: fix sporadic test_imp failure. Patch by Stefan Krah. > >

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

On Sat, Feb 25, 2012 at 22:13, Guido van Rossum wrote: > If this can encourage more projects to support Python 3 (even if it's > only 3.3 and later) and hence improve adoption of Python 3, I'm all > for it. > > +1 from me for the same reasons. If this were to go in then for Python 3.3 the sectio

Re: [Python-Dev] Spreading the Python 3 religion (was Re: PEP 414 - Unicode Literals for Python 3)

On Tue, Feb 28, 2012 at 09:53, Barry Warsaw wrote: > On Feb 28, 2012, at 08:41 AM, R. David Murray wrote: > > >Hmm. It seems to me that this argument implies that PEP 414 is just > >as likely to *slow down* adoption of Python3 as it is to speed it up, > >since if this issue is as big a barrier a

Re: [Python-Dev] Spreading the Python 3 religion (was Re: PEP 414 - Unicode Literals for Python 3)

On Tue, Feb 28, 2012 at 12:07, Vinay Sajip wrote: > v.loewis.de> writes: > > > One thing that the PEP will certainly achieve is to spread the myth that > > you cannot port to Python 3 if you also want to support Python 2.5. > That's > > because people will accept the "single source" approach as

Re: [Python-Dev] Adding a builtins parameter to eval(), exec() and __import__().

On Wed, Mar 7, 2012 at 10:56, Benjamin Peterson wrote: > 2012/3/7 Mark Shannon : > > Currently, it is impossible to allow one function access to sensitive > > functions like open(), while denying it to others, as any code can then > > get the builtins of another function via f.__globals__['builti

[Python-Dev] importlib cleared for merging into default!

At the language summit today I got clearance to merge my importlib bootstrap branch (http://hg.python.org/sandbox/bcannon#bootstrap_importlib) thanks to performance being about 5% slower using the normal_startup (which, as Thomas Wouters said, is less than the difference of using the newest gcc in

[Python-Dev] PEP 412 has been accepted

Since PEP 412 has code that doesn't break tests anymore (thanks to hash randomization), it was just accepted. Mark, can you make sure there is an up-to-date patch in the tracker so people can potentially look at the code at the sprints here at PyCon? And also please apply for core dev privileges (h

Re: [Python-Dev] Testsuite dependency on _testcapi

On Fri, Mar 9, 2012 at 14:44, Thomas Wouters wrote: > > While testing Python 2.7 internally (at Google) I noticed that (now that > ImportErrors aren't automatically test skips) lots of tests fail if you > don't have the _testcapi module. These tests are (as far as I've seen) > properly marked as

[Python-Dev] New PEP numbering scheme

It came up at the sprints about how to choose new PEP numbers. It was agreed that the newest, *lowest* number should be used (e.g. 418) and not the next highest number (e.g. 3156). I have already updated PEP 1 to reflect this. ___ Python-Dev mailing list

Re: [Python-Dev] Review of PEP 362 (signature object)

On Mon, Mar 12, 2012 at 20:51, Guido van Rossum wrote: > I'm very sympathetic to this PEP. I would accept it outright except I > have a few quibbles on details, and some questions and remarks. > > - There are several examples of poor English grammar, perhaps from > your co-author. Can you fix the

Re: [Python-Dev] [Python-checkins] cpython: Issue #14347: Update Misc/README list of files.

The two files that were added back in should probably just disappear (README.aix and README.coverty). Anyone disagree? On Sat, Mar 17, 2012 at 13:52, ned.deily wrote: > http://hg.python.org/cpython/rev/65a0a6fab127 > changeset: 75797:65a0a6fab127 > user:Ned Deily > date:Sat Ma

Re: [Python-Dev] possible distutils.sysconfig.get_config_var bug

If you could, Jordan, please file a bug at bugs.python.org so the discussion can happen there and be tracked better. On Wed, Mar 28, 2012 at 03:06, Jordan Schneider wrote: > Hi python-dev, > > Sorry if this is the wrong place to discuss this potential bug - feel free > to point me in the right d

Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo

On Mon, Apr 2, 2012 at 08:58, Thomas Spura wrote: > On Mon, Apr 2, 2012 at 2:54 PM, Stefan Behnel wrote: > > Antoine Pitrou, 02.04.2012 13:50: > >> On Sun, 1 Apr 2012 19:44:00 -0500 > >> Brian Curtin wrote: > >>> On Sun, Apr 1, 2012 at 17:31, Matěj Cepl wrote: > On 1.4.2012 23:46, Brian Curt

Re: [Python-Dev] PEP 412 Key-Sharing Dictionary

On Thu, Apr 12, 2012 at 10:25, Mark Shannon wrote: > I would like to get the new shared-keys dictionary implementation > committed, or rejected or further reviewed, if necessary. > It seems to have got a bit stuck at the moment. > > As far as I am concerned it is ready to go in. > Memory usage is

[Python-Dev] importlib is now bootstrapped (and what that means)

My multi-year project -- started in 2006 according to my blog -- to rewrite import in pure Python and then bootstrap it into CPython as *the* implementation of __import__() is finally over (mostly)! Hopefully I didn't break too much code in the process. =) Now this is "mostly" finished because the

[Python-Dev] making the import machinery explicit

To start off, what I am about to propose was brought up at the PyCon language summit and the whole room agreed with what I want to do here, so I honestly don't expect much of an argument (famous last words). In the "ancient" import.c days, a lot of import's stuff was hidden deep in the C code and

[Python-Dev] Require loaders set __package__ and __loader__

An open issue in PEP 302 is whether to require __loader__ attributes on modules. The claimed worry is memory consumption, but considering importlib and zipimport are already doing this that seems like a red herring. Requiring it, though, opens the door to people relying on its existence and thus st

Re: [Python-Dev] making the import machinery explicit

On Sat, Apr 14, 2012 at 17:12, Eric Snow wrote: > On Sat, Apr 14, 2012 at 2:03 PM, Brett Cannon wrote: > > To start off, what I am about to propose was brought up at the PyCon > > language summit and the whole room agreed with what I want to do here, > so I > > honestly

Re: [Python-Dev] Require loaders set __package__ and __loader__

On Sat, Apr 14, 2012 at 18:32, Guido van Rossum wrote: > On Sat, Apr 14, 2012 at 2:15 PM, Eric Snow > wrote: > > On Sat, Apr 14, 2012 at 2:56 PM, Brett Cannon wrote: > >> An open issue in PEP 302 is whether to require __loader__ attributes on > >> module

Re: [Python-Dev] Require loaders set __package__ and __loader__

On Sat, Apr 14, 2012 at 18:41, Christian Heimes wrote: > Am 15.04.2012 00:32, schrieb Guido van Rossum: > > Funny, I was just thinking about having a simple standard API that > > will let you open files (and list directories) relative to a given > > module or package regardless of how the thing i

Re: [Python-Dev] Require loaders set __package__ and __loader__

On Sat, Apr 14, 2012 at 18:56, Guido van Rossum wrote: > On Sat, Apr 14, 2012 at 3:50 PM, Brett Cannon wrote: > > On Sat, Apr 14, 2012 at 18:32, Guido van Rossum > wrote: > >> Funny, I was just thinking about having a simple standard API that > >> will let you op

Re: [Python-Dev] [Python-checkins] Daily reference leaks (556b9bafdee8): sum=1144

I'm going to guess my bootstrap patch caused most of these. =) test_capi is now plugged, so I'm going to assume Python/pythonrun.c:import_init() is taken care of. The real question is where in http://hg.python.org/cpython/rev/2dd046be2c88 are the other leaks coming from. Any help would be great as

Re: [Python-Dev] making the import machinery explicit

On Sun, Apr 15, 2012 at 07:26, Nick Coghlan wrote: > Hooray for finally having this to the point where it has been pushed to > trunk :) > > On Sun, Apr 15, 2012 at 8:16 AM, Brett Cannon wrote: > > Once again, it's just code that needs updating to run on Python 3.3 so I

Re: [Python-Dev] cpython: Rebuild importlib.h to incorporate added comments.

.org/cpython/rev/6a77697d2a63> >>> changeset: 76311:6a77697d2a63 >>> user:Brett Cannon >>> date:Sat Apr 14 21:18:48 2012 -0400 >>> summary: >>> Rebuild importlib.h to incorporate added comments. >>> >> >&

Re: [Python-Dev] making the import machinery explicit

On Sun, Apr 15, 2012 at 22:03, Nick Coghlan wrote: > On Mon, Apr 16, 2012 at 2:31 AM, Brett Cannon wrote: > > What about sys.path_importer_cache: all of it or just NullImporter/None > > entries (or should that be a boolean to this function)? And shouldn't it > be > &g

Re: [Python-Dev] cpython: Fix #10854. Make use of the new path and name attributes on ImportError

On Mon, Apr 16, 2012 at 07:19, Antoine Pitrou wrote: > On Mon, 16 Apr 2012 07:10:31 +0200 > brian.curtin wrote: > > PyErr_SetFromImportErrorWithNameAndPath > > Apparently this new function isn't documented anywhere. > > I forgot to write the docs for it when I committed Brian's code. Brian, do

Re: [Python-Dev] importlib is now bootstrapped (and what that means)

On Mon, Apr 16, 2012 at 10:07, "Martin v. Löwis" wrote: > > We have other instances of this (e.g. the Objects/typeslots.inc file > > is generated and checked in), but in the case of importlib, we have > > to use the ./python binary for freezing to avoid bytecode > > incompatibilities, which obvio

Re: [Python-Dev] importlib is now bootstrapped (and what that means)

On Mon, Apr 16, 2012 at 12:31, Antoine Pitrou wrote: > On Mon, 16 Apr 2012 12:15:16 -0400 > "R. David Murray" wrote: > > > > I don't see how depending on Cython is better than depending on having > > an existing Python. If the only benefit is semi-readable code, surely > > we do have source cod

Re: [Python-Dev] importlib is now bootstrapped (and what that means)

On Mon, Apr 16, 2012 at 13:04, "Martin v. Löwis" wrote: > > I don't see how depending on Cython is better than depending on having > > an existing Python. If the only benefit is semi-readable code, surely > > we do have source code for the pre-frozen module, and it is just a matter > > of convin

Re: [Python-Dev] importlib is now bootstrapped (and what that means)

On Mon, Apr 16, 2012 at 13:08, "Martin v. Löwis" wrote: > > So like execute hg diff on the dependent files and if nothing changed > > then touch the auto-generated file w/ 'touch' to prevent future attempts > > to execute the target? > > Exactly. There might be something better than hg diff, perh

Re: [Python-Dev] importlib is now bootstrapped (and what that means)

On Mon, Apr 16, 2012 at 20:27, Antoine Pitrou wrote: > On Tue, 17 Apr 2012 01:11:14 +0200 > Georg Brandl wrote: > > > > No, it's not just an existing Python, it is (at least currently) the same > > version of Python being built. Therefore I wrote about the bootstrapping > > problems when byteco

Re: [Python-Dev] cpython: Issue #13959: Re-implement imp.load_source() in imp.py.

On Tue, Apr 17, 2012 at 05:53, Antoine Pitrou wrote: > On Tue, 17 Apr 2012 04:11:31 +0200 > brett.cannon wrote: > > http://hg.python.org/cpython/rev/3b5b4b4bb43c > > changeset: 76371:3b5b4b4bb43c > > user:Brett Cannon > > date:Mon Apr 16 2

Re: [Python-Dev] importlib is now bootstrapped (and what that means)

On Tue, Apr 17, 2012 at 06:43, Eric V. Smith wrote: > On 4/17/2012 5:52 AM, Antoine Pitrou wrote: > > On Mon, 16 Apr 2012 20:41:56 -0400 > > Brett Cannon wrote: > >> On Mon, Apr 16, 2012 at 20:27, Antoine Pitrou > wrote: > >> > >>> On Tue, 17 A

Re: [Python-Dev] making the import machinery explicit

3.3 goes out. On Sat, Apr 14, 2012 at 16:03, Brett Cannon wrote: > To start off, what I am about to propose was brought up at the PyCon > language summit and the whole room agreed with what I want to do here, so I > honestly don't expect much of an argument (famous last word

Re: [Python-Dev] Require loaders set __package__ and __loader__

Anyone other than Eric have something to say on this proposal? Obviously the discussion went tangential before I saw a clear consensus that what I was proposing was fine with people. On Sat, Apr 14, 2012 at 16:56, Brett Cannon wrote: > An open issue in PEP 302 is whether to require __loade

Re: [Python-Dev] making the import machinery explicit

On Tue, Apr 17, 2012 at 13:45, Philip Jenvey wrote: > > On Apr 14, 2012, at 1:03 PM, Brett Cannon wrote: > > > And lastly, sticking None in sys.path_importer_cache would no longer > mean "do the implicit thing" and instead would mean the same as > NullImporter do

Re: [Python-Dev] importlib is now bootstrapped (and what that means)

On Tue, Apr 17, 2012 at 13:39, Antoine Pitrou wrote: > On Tue, 17 Apr 2012 11:41:32 -0400 > Brett Cannon wrote: > > > > Actually Cython would help with a subtle maintenance burden of > maintaining > > *any* C code for import. Right now, > > Python/import.c:PyIm

Re: [Python-Dev] webbrowser no longer support 'internet-config' on Mac

Please file a bug report at bugs.python.org so this isn't lost. On Wed, Apr 18, 2012 at 08:54, Leo wrote: > The doc says supported as in > http://docs.python.org/library/webbrowser.html > > but the code has been deleted in > http://hg.python.org/cpython/rev/66b3eda6283f > > Leo > > _

<    23   24   25   26   27   28   29   30   31   32   >