Re: [Python-Dev] [Python-checkins] peps: Note that ImportError will no longer be raised due to a missing __init__.py

It's actually an ImportWarning, not Error (or at least that's what I meant on import-sig). If the module is eventually found then there is no error. On Thu, Apr 19, 2012 at 18:56, eric.smith wrote: > http://hg.python.org/peps/rev/af61fe9a56fb > changeset: 4281:af61fe9a56fb > user:Eric V

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

On Fri, Apr 20, 2012 at 09:54, Eric V. Smith wrote: > On 04/14/2012 02:12 PM, Brett Cannon wrote: > > 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 __

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

On Fri, Apr 20, 2012 at 11:02, Eric Snow wrote: > On Fri, Apr 20, 2012 at 7:54 AM, Eric V. Smith wrote: > > On 04/14/2012 02:12 PM, Brett Cannon wrote: > >> My multi-year project -- started in 2006 according to my blog -- to > >> rewrite import in pure Python and the

[Python-Dev] Handling deprecations in the face of PEP 384

As I clean up Python/import.c and move much of its functionality into Lib/imp.py, I am about to run into some stuff that was not kept private to the file. Specifically, I have PyImport_GetMagicTag() and NullImporter_Type which I would like to chop out and move to Lib/imp.py. >From my reading of PE

Re: [Python-Dev] Handling deprecations in the face of PEP 384

On Sat, Apr 21, 2012 at 16:55, "Martin v. Löwis" wrote: > > From my reading of PEP 384 that means I would need to at least deprecate > > PyImport_getMagicTag(), correct (assuming I follow through with this; I > > might not bother)? > > All that PEP 384 gives you is that you MAY deprecate certain

Re: [Python-Dev] Handling deprecations in the face of PEP 384

On Sat, Apr 21, 2012 at 12:10, Barry Warsaw wrote: > On Apr 20, 2012, at 09:59 PM, Brett Cannon wrote: > > >As I clean up Python/import.c and move much of its functionality into > >Lib/imp.py, I am about to run into some stuff that was not kept private to > >the fi

Re: [Python-Dev] Handling deprecations in the face of PEP 384

On Sat, Apr 21, 2012 at 20:54, Eric Snow wrote: > On Sat, Apr 21, 2012 at 4:17 PM, Brett Cannon wrote: > > On Sat, Apr 21, 2012 at 12:10, Barry Warsaw wrote: > >> Strictly speaking, I do think you need to deprecate the APIs. I like > >> Nick's > >> sugg

Re: [Python-Dev] isolating import state during tests

On Sat, Apr 21, 2012 at 21:02, Eric Snow wrote: > It looks like the test suite accommodates a stable import state to > some extent, but would it be worth having a PEP-405-esque context > manager to help with this? For example, something along these lines: > > > class ImportState: ># sys.modul

[Python-Dev] path joining on Windows and imp.cache_from_source()

imp.cache_from_source() (and thus also imp.source_from_cache()) has special semantics compared to how os.path.join() works. For instance, if you look at test_imp you will notice it tries to use the same path separator as is the farthest right in the path it is given:: self.assertEqual(imp.cache_

Re: [Python-Dev] path joining on Windows and imp.cache_from_source()

On Sun, Apr 22, 2012 at 01:44, Glenn Linderman wrote: > On 4/21/2012 8:53 PM, Brett Cannon wrote: > > imp.cache_from_source() (and thus also imp.source_from_cache()) has > special semantics compared to how os.path.join() works. For instance, if > you look at test_imp you will not

Re: [Python-Dev] path joining on Windows and imp.cache_from_source()

On Sun, Apr 22, 2012 at 01:45, "Martin v. Löwis" wrote: > > Now that we can reuse os.path.join() (directly for source_from_cache(), > > indirectly through easy algorithmic copying in cache_from_source()) do > > we want to keep the "special" semantics, or can I change it to match > > what ntpath w

Re: [Python-Dev] package imports, sys.path and os.chdir()

On Fri, Apr 27, 2012 at 10:39, Christian Tismer wrote: > On 27.04.12 02:39, Nick Coghlan wrote: > >> On Fri, Apr 27, 2012 at 7:30 AM, Christian Tismer >> wrote: >> >>> No big deal and easy to work around, I just would like to understand why. >>> >> I don't like it either and want to change it, bu

Re: [Python-Dev] package imports, sys.path and os.chdir()

On Sat, Apr 28, 2012 at 04:08, Nick Coghlan wrote: > On Sat, Apr 28, 2012 at 6:00 AM, Brett Cannon wrote: > > I'm personally in favour of changing the insertion of '' to sys.path to > > inserting the cwd when the interpreter is launched. > > I'm

Re: [Python-Dev] package imports, sys.path and os.chdir()

On Sat, Apr 28, 2012 at 09:35, Benjamin Peterson wrote: > 2012/4/28 Nick Coghlan : > > On Sat, Apr 28, 2012 at 6:00 AM, Brett Cannon wrote: > >> I'm personally in favour of changing the insertion of '' to sys.path to > >> inserting the cwd when th

Re: [Python-Dev] package imports, sys.path and os.chdir()

On Sat, Apr 28, 2012 at 12:16, R. David Murray wrote: > On Sat, 28 Apr 2012 18:08:08 +1000, Nick Coghlan > wrote: > > On Sat, Apr 28, 2012 at 6:00 AM, Brett Cannon wrote: > > > I'm personally in favour of changing the insertion of '' to sys.path to > >

Re: [Python-Dev] Open PEPs and large-scale changes for 3.3

On Tue, May 1, 2012 at 07:57, Georg Brandl wrote: > With 3.3a3 tagged and the beta stage currently 2 months away, I would like > to draw your attention to the following list of possible features for 3.3 > as specified by PEP 398: > > Candidate PEPs: > > * PEP 362: Function Signature Object > Thi

Re: [Python-Dev] Open PEPs and large-scale changes for 3.3

On Tue, May 1, 2012 at 10:26, Yury Selivanov wrote: > On 2012-05-01, at 7:57 AM, Georg Brandl wrote: > > > With 3.3a3 tagged and the beta stage currently 2 months away, I would > like > > to draw your attention to the following list of possible features for 3.3 > > as specified by PEP 398: > > > >

Re: [Python-Dev] Python 3.3 cannot find BeautifulSoup but Python 3.2 can

This really isn't the right mailing list to ask this kind of question (I know you got help last time with your Debian-specific problem, but that was because people got overly excited =). Python-dev is meant for discussing the development *of* Python, not using it or developing *with* it. I would t

Re: [Python-Dev] sys.implementation

On Wed, May 9, 2012 at 5:57 AM, "Martin v. Löwis" wrote: > On 27.04.2012 09:34, Eric Snow wrote: > >> On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw wrote: >> >>> It's somewhat of a corner case, but I think a PEP couldn't hurt. The >>> rationale section would be useful, at least. >>> >> >> http

Re: [Python-Dev] sys.implementation

On Wed, May 9, 2012 at 10:50 AM, Antoine Pitrou wrote: > On Wed, 9 May 2012 10:44:59 -0400 > Brett Cannon wrote: > > > > > I wish there was a builtin class > > > > > > class record: > > >pass > > > > > > which can b

Re: [Python-Dev] Adding types.build_class for 3.3

On Wed, May 9, 2012 at 12:21 PM, Barry Warsaw wrote: > On May 09, 2012, at 05:20 PM, Nick Coghlan wrote: > > >Ah, good point. In that case, consider me convinced: static method it > >is. It can join mro() as the second non-underscore method defined on > >type(). > > +1 > > If I may dip into the b

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Wed, May 23, 2012 at 9:10 AM, Eric V. Smith wrote: > On 05/23/2012 09:02 AM, Nick Coghlan wrote: > > On Wed, May 23, 2012 at 10:31 PM, Eric V. Smith > wrote: > >> On 05/22/2012 09:49 PM, PJ Eby wrote: > >>> It shouldn't - all you should need is to use > >>> getattr(sys.modules[self.modname],

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Wed, May 23, 2012 at 3:35 PM, PJ Eby wrote: > On Wed, May 23, 2012 at 3:02 PM, Brett Cannon wrote: > >> If I understand the proposal correctly, this would be a change in >> NamespaceLoader in how it sets __path__ and in no way affect any other code >> since __import__

Re: [Python-Dev] [Python-checkins] cpython: issue 14660: Implement PEP 420, namespace packages.

On Fri, May 25, 2012 at 10:41 AM, Barry Warsaw wrote: > On May 25, 2012, at 10:31 AM, Brett Cannon wrote: > > >Is documentation coming in a separate commit? > > Yes. I've been reworking the import machinery documentation; it's a > work-in-progress on the pep

[Python-Dev] what is happening with the regex module going into Python 3.3?

About the only thing I can think of from the language summit that we discussed doing for Python 3.3 that has not come about is accepting the regex module and getting it into the stdlib. Is this still being worked towards? ___ Python-Dev mailing list Pytho

[Python-Dev] whither PEP 407 and 413 (release cycle PEPs)?

Are these dead in the water or are we going to try to change our release cycle? I'm just asking since 3.3 final is due out in about 3 months and deciding on this along with shifting things if we do make a change could end up taking that long and I suspect if we don't do this for 3.3 we are probably

Re: [Python-Dev] [Python-checkins] cpython: Eric Snow's implementation of PEP 421.

[Let's try this again since my last reply was rejected for being too large] On Mon, Jun 4, 2012 at 9:52 AM, barry.warsaw wrote: > http://hg.python.org/cpython/rev/9c445f4695c1 > changeset: 77339:9c445f4695c1 > parent: 77328:0808cb8c60fd > user:Barry Warsaw > date:Sun Jun

Re: [Python-Dev] [Python-checkins] cpython: Eric Snow's implementation of PEP 421.

On Mon, Jun 4, 2012 at 11:10 AM, Barry Warsaw wrote: > Thanks for the second set of eyes, Brett. > > On Jun 04, 2012, at 10:16 AM, Brett Cannon wrote: > > >> +.. data:: implementation > >> + > >> + An object containing the information about the implement

[Python-Dev] Updated PEP 362 (Function Signature Object)

http://bugs.python.org/issue15008 . --- PEP: 362 Title: Function Signature Object Version: $Revision$ Last-Modified: $Date$ Author: Brett Cannon , Jiwon Seo , Yury Selivanov , Larry Hastings < la...@hastings.org> Status: Draft Type: Standards Track C

Re: [Python-Dev] Updated PEP 362 (Function Signature Object)

On Wed, Jun 6, 2012 at 12:16 PM, Steven D'Aprano wrote: > Larry Hastings wrote: > > [...] >>> "Changes to the Signature object, or to any of its data members, >>> do not affect the function itself." >>> >>> which leaves the possibility that __signature__ may no longer match the >>> actual argumen

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

On Fri, Jun 8, 2012 at 12:39 PM, fwierzbi...@gmail.com < fwierzbi...@gmail.com> wrote: > On Fri, Jun 8, 2012 at 9:22 AM, Jeff Hardy wrote: > > On Fri, Jun 8, 2012 at 8:13 AM, Matti Picus > wrote: > >> > >> The windows port of pypy makes special demands on stdlib, specifically > that > >> files a

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

On Fri, Jun 8, 2012 at 2:21 PM, fwierzbi...@gmail.com wrote: > On Fri, Jun 8, 2012 at 10:59 AM, Brett Cannon wrote: > > R. David already replied to this, but just to reiterate: tests can always > > get updated, and code that fixes a bug (and leaving a file open can be > >

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

On Friday, June 8, 2012, Antoine Pitrou wrote: > Le 08/06/2012 20:29, Brett Cannon a écrit : > >> >> > P.S. Do we need a python-implementations mailing list or >>something for >> > discussing overall VM-related stuff among all VMs instead of >&

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

0, 2012 8:42 PM, "Guido van Rossum" wrote: > Really? Are we now proposing multiple lists? That just makes it easier > to miss stuff for me. > > On Sun, Jun 10, 2012 at 5:53 AM, Nick Coghlan wrote: > > On Sun, Jun 10, 2012 at 12:05 PM, Brett Cannon wrote: > >>>

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

On Mon, Jun 11, 2012 at 3:35 PM, PJ Eby wrote: > On Mon, Jun 11, 2012 at 12:33 PM, Jeff Hardy wrote: > >> On Mon, Jun 11, 2012 at 8:28 AM, Eric Snow >> wrote: >> > Nick's option 2 would be an improvement, but I imagine that option 3 >> > would have been the most effective by far. Of course, th

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

On Mon, Jun 11, 2012 at 12:39 PM, Barry Warsaw wrote: > On Jun 11, 2012, at 04:58 PM, Nick Coghlan wrote: > > >1. Asking on python-dev is considered adequate. If an implementation > >wants to be consulted on changes, one or more of their developers > >*must* follow python-dev sufficiently closely

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

On Monday, June 11, 2012, Stephen J. Turnbull wrote: > Brett Cannon writes: > > > But we already have the various SIGs carry out discussions outside of > > python-dev and just bring forward their results to python-dev when they > are > > ready. Why would this li

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

On Tue, Jun 12, 2012 at 4:09 AM, Stephen J. Turnbull wrote: > Brett Cannon writes: > > > Not necessarily. Just like discussions on SIGs can start and end > > there, I see no requirement that discussions on the list end up on > > python-dev. > > You've miss

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

On Tue, Jun 12, 2012 at 9:49 AM, fwierzbi...@gmail.com < fwierzbi...@gmail.com> wrote: > On Mon, Jun 11, 2012 at 10:46 PM, Nick Coghlan wrote: > > To allow easier transition to a separate list (if that seems necessary > > at a later date), my preferred colour for the bikeshed is > > [compatibilit

[Python-Dev] [compatibility-sig] making sure importlib.machinery.SourceLoader doesn't throw an exception if bytecode is not supported by a VM

I would like to have importlib just work out of the box for all VMs in 3.3 instead of requiring a minor patch in order to not throw an exception when loading from source and there is no bytecode. The relevant code for this discussion can be seen at http://hg.python.org/cpython/file/c2910971eb86/Lib

Re: [Python-Dev] Built-in sub modules

On Mon, Jun 11, 2012 at 11:37 PM, Nick Coghlan wrote: > On Tue, Jun 12, 2012 at 1:17 PM, Albert Zeyer > wrote: > > I also searched a bit around and I didn't directly found any easier > > way to do this. Only a post from 2009 > > (http://mail.python.org/pipermail/cplusplus-sig/2009-January/014178

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

On Tue, Jun 12, 2012 at 10:59 AM, Mark Lawrence wrote: > On 12/06/2012 15:40, Brett Cannon wrote: > >> >> Ah, but you helped make my point! For the people working on CPython, >> python-dev is a natural place. But what about PyPy, IronPython, or Jython >> (toss in C

Re: [Python-Dev] [compatibility-sig] making sure importlib.machinery.SourceLoader doesn't throw an exception if bytecode is not supported by a VM

On Tue, Jun 12, 2012 at 12:38 PM, Alex Gaynor wrote: > For PyPy: I'm not an expert in our import, but from looking at the source > > 1) imp.cache_from_source is unimplemented, it's an AttributeError. > Well, you will have it come Python 3.3 one way or another. =) > > 2) sys.dont_write_bytecode

Re: [Python-Dev] [compatibility-sig] making sure importlib.machinery.SourceLoader doesn't throw an exception if bytecode is not supported by a VM

On Tue, Jun 12, 2012 at 10:52 AM, Brett Cannon wrote: > I would like to have importlib just work out of the box for all VMs in 3.3 > instead of requiring a minor patch in order to not throw an exception when > loading from source and there is no bytecode. The relevant code for this >

Re: [Python-Dev] [compatibility-sig] making sure importlib.machinery.SourceLoader doesn't throw an exception if bytecode is not supported by a VM

On Tue, Jun 12, 2012 at 1:04 PM, fwierzbi...@gmail.com < fwierzbi...@gmail.com> wrote: > On Tue, Jun 12, 2012 at 9:38 AM, Alex Gaynor > wrote: > > For PyPy: I'm not an expert in our import, but from looking at the source > > > > 1) imp.cache_from_source is unimplemented, it's an AttributeError. >

Re: [Python-Dev] [compatibility-sig] making sure importlib.machinery.SourceLoader doesn't throw an exception if bytecode is not supported by a VM

On Tue, Jun 12, 2012 at 2:28 PM, Eric Snow wrote: > On Tue, Jun 12, 2012 at 10:48 AM, Brett Cannon wrote: > > I should mention another option is to add sys.dont_read_bytecode (I > think I > > have discussed this with Frank at some point). > > Or check for "sys.imp

Re: [Python-Dev] [compatibility-sig] making sure importlib.machinery.SourceLoader doesn't throw an exception if bytecode is not supported by a VM

On Tue, Jun 12, 2012 at 3:53 PM, Jeff Hardy wrote: > On Tue, Jun 12, 2012 at 12:01 PM, Brett Cannon wrote: > > On Tue, Jun 12, 2012 at 2:28 PM, Eric Snow > > wrote: > >> > >> On Tue, Jun 12, 2012 at 10:48 AM, Brett Cannon > wrote: > >>

Re: [Python-Dev] [compatibility-sig] making sure importlib.machinery.SourceLoader doesn't throw an exception if bytecode is not supported by a VM

On Jun 12, 2012 6:24 PM, "fwierzbi...@gmail.com" wrote: > > On Tue, Jun 12, 2012 at 12:01 PM, Brett Cannon wrote: > > > > > > On Tue, Jun 12, 2012 at 2:28 PM, Eric Snow > > wrote: > >> > >> On Tue, Jun 12, 2012 at 10:48 AM, Brett Canno

Re: [Python-Dev] [compatibility-sig] making sure importlib.machinery.SourceLoader doesn't throw an exception if bytecode is not supported by a VM

On Wed, Jun 13, 2012 at 1:18 AM, Nick Coghlan wrote: > On Wed, Jun 13, 2012 at 11:10 AM, Brett Cannon wrote: > >> > This does mean, though, that imp.cache_from_source() and > >> > imp.source_from_cache() might need to be updated to raise a reaso

Re: [Python-Dev] #12982: Should -O be required to *read* .pyo files?

On Tue, Jun 12, 2012 at 2:16 PM, Terry Reedy wrote: > http://bugs.python.org/**issue12982 > > Currently, cpython requires the -O flag to *read* .pyo files as well as > the write them. This is a nuisance to people who receive them from others, > without the sour

Re: [Python-Dev] #12982: Should -O be required to *read* .pyo files?

On Wed, Jun 13, 2012 at 10:47 PM, R. David Murray wrote: > On Thu, 14 Jun 2012 11:48:08 +1000, Nick Coghlan > wrote: > > On Thu, Jun 14, 2012 at 6:06 AM, Terry Reedy wrote: > > > On 6/13/2012 2:46 PM, Antoine Pitrou wrote: > > > > > >> Not only docstrings, but also asserts. I think running a pyo

Re: [Python-Dev] PEP 362 Third Revision

On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov wrote: [SNIP] > > > Let's consider replacement of 'Parameter.is_*' set of attributes with > a single 'Parameter.kind' attribute, which will have the following > possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'. > > (I think 'posit

Re: [Python-Dev] PEP 362 Third Revision

On Thu, Jun 14, 2012 at 12:39 PM, Yury Selivanov wrote: > On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote: > > > 2012/6/14 Yury Selivanov : > >> On 2012-06-14, at 11:24 AM, Brett Cannon wrote: > >>> On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov &

Re: [Python-Dev] Restricted API versioning

On Sat, Jun 23, 2012 at 5:31 PM, "Martin v. Löwis" wrote: > I've been thinking about extensions to the stable ABI. On the one hand, > introducing new API can cause extension modules not to run on older > Python versions. On the other hand, the new API may well be stable in > itself, i.e. remain av

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

On Sun, Jul 15, 2012 at 10:39 AM, Mark Shannon wrote: > Nick Coghlan wrote: > >> Right, I agree on the value in being able to return something to say >> "this cannot be converted to a concrete container". >> >> I still haven't seen a use case where the appropriate response to "I >> don't know" di

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

On Mon, Jul 16, 2012 at 3:36 AM, Stefan Behnel wrote: > Alex Gaynor, 15.07.2012 00:11: > > CPython currently defines an ``__length_hint__`` method on several > types, such > > as various iterators. This method is then used by various other > functions (such > > as ``map``) to presize lists based

Re: [Python-Dev] Unbinding of methods

On Thu, Jul 19, 2012 at 12:53 PM, M Stefan wrote: > Hey, > > As part of pickle4, I found it interesting to add the possibility > of pickling bound functions (instance methods). This is done by > pickling f.__self__ and f.__func__ separately, and then adding > a BIND opcode to tie them together. >

Re: [Python-Dev] Unbinding of methods

The issue is http://bugs.python.org/issue15397 [Stefan accidentally replied privately to me] On Thu, Jul 19, 2012 at 1:00 PM, Brett Cannon wrote: > > > On Thu, Jul 19, 2012 at 12:53 PM, M Stefan wrote: > >> Hey, >> >> As part of pickle4, I found it interestin

Re: [Python-Dev] cpython: Issue #15168: Move importlb.test to test.test_importlib.

On Fri, Jul 20, 2012 at 4:12 PM, Antoine Pitrou wrote: > On Fri, 20 Jul 2012 20:49:03 +0200 (CEST) > brett.cannon wrote: > > diff --git a/Lib/importlib/test/__init__.py > b/Lib/test/test_importlib/__init__.py > > rename from Lib/importlib/test/__init__.py > > rename to Lib/test/test_importlib/__

Re: [Python-Dev] python 3.3 b2

On Tue, Jul 31, 2012 at 1:56 AM, Nick Coghlan wrote: > On Tue, Jul 31, 2012 at 2:46 PM, Georg Brandl wrote: > > Am 30.07.2012 22:59, schrieb Barry Warsaw: > >> On Jul 30, 2012, at 10:22 PM, Georg Brandl wrote: > >> > >>>As I've explained on python-committers, it's currently on hold pending > >>>

Re: [Python-Dev] [Python-checkins] cpython: Issue #15502: Bring the importlib ABCs into line with the current state of the

Mostly as a note to myself (although if someone else wants to change this, then great), PathEntryFinder.find_loader() specifies self while the other docs don't bother to list it. And I just realized that the other classes defined in the importlib docs don't list their superclasses like MetaPathFin

Re: [Python-Dev] [Python-checkins] cpython: Update the What's New details for importlib based on doc/ABC changes.

Sorry about accidentally committing another minor cleanup to importlib in this commit; thought I had already committed it separately. On Thu, Aug 2, 2012 at 5:50 PM, brett.cannon wrote: > http://hg.python.org/cpython/rev/083534cd7874 > changeset: 78388:083534cd7874 > user: Bre

Re: [Python-Dev] PEP 366 is unclear about what it specifies

On Tue, Aug 7, 2012 at 4:52 PM, Stefan Behnel wrote: > Hi, > > could someone please add a sentence to PEP 366 that describes the actual > content of the new "__package__" attribute (and thus, the PEP)? > > http://www.python.org/dev/peps/pep-0366/ > > I had to read through almost the entire docume

Re: [Python-Dev] AST optimizer implemented in Python

On Sat, Aug 11, 2012 at 2:30 PM, Victor Stinner wrote: > Hi, > > I started to implement an AST optimizer in Python. It's easy to create > a new AST tree, so I'm surprised that I didn't find any existing > project. > > https://bitbucket.org/haypo/misc/src/tip/python/ast_optimizer.py > > To test its

Re: [Python-Dev] AST optimizer implemented in Python

On Sat, Aug 11, 2012 at 8:16 PM, Eric Snow wrote: > On Sat, Aug 11, 2012 at 6:03 PM, Brett Cannon wrote: > > It would also be very easy to expand importlib.abc.SourceLoader to add a > > method which is called with source and returns the bytecode to be written > > out > &g

Re: [Python-Dev] AST optimizer implemented in Python

On Sun, Aug 12, 2012 at 6:07 PM, Eric Snow wrote: > On Aug 12, 2012 12:56 PM, "PJ Eby" wrote: > > I'm not sure if this is directly related or not, but making this > > mechanism support custom compilation for new filename suffixes would > > be nice, especially for various e.g. HTML/XML templating

[Python-Dev] [compatibility-sig] do all VMs implement the ast module? (was: Re: AST optimizer implemented in Python)

On Mon, Aug 13, 2012 at 3:00 PM, Terry Reedy wrote: > On 8/13/2012 10:45 AM, Guido van Rossum wrote: > >> Not so fast. If you make this a language feature you force all Python >> implementations to support an identical AST API. That's a big step. >> > > I have been wondering about this. One could

Re: [Python-Dev] [Python-checkins] cpython: Push importlib ABC hierarchy chart.

For documentation, this appears to be for http://bugs.python.org/issue15628 . On Mon, Aug 13, 2012 at 3:19 PM, andrew.svetlov wrote: > http://hg.python.org/cpython/rev/1c8a6df94602 > changeset: 78547:1c8a6df94602 > user:Andrew Svetlov > date:Mon Aug 13 22:19:01 2012 +0300 > su

Re: [Python-Dev] [compatibility-sig] do all VMs implement the ast module? (was: Re: AST optimizer implemented in Python)

On Aug 13, 2012 5:22 PM, "fwierzbi...@gmail.com" wrote: > > On Mon, Aug 13, 2012 at 1:46 PM, Guido van Rossum wrote: > > On Mon, Aug 13, 2012 at 1:05 PM, fwierzbi...@gmail.com > > wrote: > >> On Mon, Aug 13, 2012 at 12:06 PM, Brett Cannon wrote: > >

Re: [Python-Dev] [compatibility-sig] do all VMs implement the ast module? (was: Re: AST optimizer implemented in Python)

On Mon, Aug 13, 2012 at 6:35 PM, fwierzbi...@gmail.com < fwierzbi...@gmail.com> wrote: > On Mon, Aug 13, 2012 at 3:10 PM, Brett Cannon wrote: > > > Direct. There is an AST grammar file that gets compiled into C and Python > > objects which are used by the compiler (c vers

Re: [Python-Dev] [Python-checkins] cpython: s/path importer/path based finder/ (because the path based finder is not an

Should that be "path-based"? On Sun, Aug 19, 2012 at 11:49 PM, nick.coghlan wrote: > http://hg.python.org/cpython/rev/2f9f5ab3d754 > changeset: 78664:2f9f5ab3d754 > user:Nick Coghlan > date:Mon Aug 20 13:49:08 2012 +1000 > summary: > s/path importer/path based finder/ (becaus

Re: [Python-Dev] [Infrastructure] Snakebite build slaves and developer SSH/GPG public keys

On Wed, Aug 22, 2012 at 7:03 PM, Nick Coghlan wrote: > On Thu, Aug 23, 2012 at 8:28 AM, Trent Nelson wrote: > > Hi folks, > > > > I've set up a bunch of Snakebite build slaves over the past week. > > One of the original goals was to provide Python committers with > > full access to t

Re: [Python-Dev] Snakebite build slaves and developer SSH/GPG public keys

On Fri, Aug 24, 2012 at 10:48 AM, Trent Nelson wrote: > On Fri, Aug 24, 2012 at 07:39:54AM -0700, Trent Nelson wrote: > > On Fri, Aug 24, 2012 at 07:27:09AM -0700, C. Titus Brown wrote: > > > Don't forget the heavy Xanax requirements on the part of the technical > owner of > > > the space. Dunno

Re: [Python-Dev] Summary of Python tracker Issues

On Fri, Aug 24, 2012 at 12:07 PM, Python tracker wrote: > > ACTIVITY SUMMARY (2012-08-17 - 2012-08-24) > Python tracker at http://bugs.python.org/ > > To view or respond to any of the issues listed below, click on the issue. > Do NOT respond to this message. > > Issues counts and deltas: > open

Re: [Python-Dev] [Python-checkins] cpython: Issue #15794: Relax a test case due to the deadlock detection's

Should there be a Misc/NEWS entry since we are in rc mode? On Tue, Aug 28, 2012 at 2:13 PM, antoine.pitrou wrote: > http://hg.python.org/cpython/rev/454dceb5fd56 > changeset: 78790:454dceb5fd56 > parent: 78788:06497bbdf4fe > user:Antoine Pitrou > date:Tue Aug 28 20:10:18 2

Re: [Python-Dev] benchmarks: Pathlib works under Python 3.

On Fri, Aug 31, 2012 at 12:49 PM, Antoine Pitrou wrote: > On Fri, 31 Aug 2012 17:52:38 +0200 (CEST) > brett.cannon wrote: > > http://hg.python.org/benchmarks/rev/873baf08045e > > changeset: 162:873baf08045e > > user:Brett Cannon > > date:

Re: [Python-Dev] Coverity scan

On Wed, Sep 5, 2012 at 8:43 AM, Christian Heimes wrote: > Am 03.09.2012 15:59, schrieb Christian Heimes: > > It be nice if we get Coverity scans up and running this week to check > > the upcoming release candidate for issues. > > Updates: > > - Noah has set up a VM for me on the PSF infrastructur

Re: [Python-Dev] Coverity scan

And a thanks to Christian and Stefan for picking this up and running with it. I have not been the best keeper of this stuff as of late, but now that Christian, Stefan, and I all have admin access to the data we can spread the load so that none of us become a bottleneck. On Wed, Sep 5, 2012 at 12:5

Re: [Python-Dev] Coverity scan

On Sat, Sep 8, 2012 at 6:41 AM, wrote: > > Zitat von Stefan Krah : > > After all, 99.99% of issues are either found by developers themselves or >> by gcc, Visual Studio, Valgrind, etc. It just occurred to me that for >> example >> we don't credit other tools in commit messages. >> > > I agree th

Re: [Python-Dev] [Python-checkins] devguide: Update committers list location.

Did you mean to use http://docs.python.org/devguide/developers.html instead of http://hg.python.org/committers.txt as the former lists why while the latter just lists usernames? On Sun, Sep 9, 2012 at 3:19 AM, georg.brandl wrote: > http://hg.python.org/devguide/rev/b40bfc99c54f > changeset: 548

Re: [Python-Dev] Snakebite v0.1: ready for beta testing.

Very cool, Trent! I also love the retro use of svn as a tie-in to how long you have been fighting to bring this project to fruition. =) On Tue, Sep 11, 2012 at 8:20 AM, Trent Nelson wrote: > Quick start: > > % cd ~ && svn co http://svn.snakebite.net/.snakebite && cd .snakebite && > sh snakeb

Re: [Python-Dev] packaging location ?

On Wed, Sep 12, 2012 at 3:28 PM, Lennart Regebro wrote: > On Wed, Sep 12, 2012 at 9:02 PM, Éric Araujo wrote: > > “find a PEP dictator and propose changes”. And when I started the > > thread about removing packaging in 3.3, hundreds of replies discussed > > changing the whole distutils architec

Re: [Python-Dev] Python 1.5 output file versions

First, this is the wrong mailing list for this question: python-dev is for discussing the development *of* Python, not *with* it. Second, the answer to your question is there is no built-in versioning support. On Wed, Sep 19, 2012 at 4:51 AM, Ido Yohanan wrote: > Hi, > > ** ** > > I am wor

Re: [Python-Dev] [Python-checkins] peps: add stub for wheel spec

We don't put stubs of PEPs into the repository, especially when they have not been vetted on python-ideas or some other public mailing list that is appropriate for the subject. You also mis-capitalized PyPy in this commit. On Thu, Sep 20, 2012 at 6:44 PM, daniel.holth wrote: > http://hg.python.o

Re: [Python-Dev] [RELEASED] Python 3.3.0 release candidate 3

On Fri, Sep 28, 2012 at 11:40 AM, Stefan Krah wrote: > Georg Brandl wrote: > > * A C implementation of the "decimal" module, with up to 80x speedup > > for decimal-heavy applications > > Could you bump up the factor to 120x in the final announcement? There were > a couple of performance impr

Re: [Python-Dev] [RELEASED] Python 3.3.0 release candidate 3

On Sat, Sep 29, 2012 at 9:07 AM, Paul Moore wrote: > On 29 September 2012 10:17, Stefan Krah wrote: > > Tim Delaney wrote: > >> If those numbers are similar in other benchmarks, would it be accurate > and/or > >> reasonable to include a statement along the lines of: > >> > >> "comparable to flo

Re: [Python-Dev] [RELEASED] Python 3.3.0 release candidate 3

On Sep 29, 2012 2:38 PM, "Guido van Rossum" wrote: > > On Sat, Sep 29, 2012 at 11:26 AM, Brett Cannon wrote: > > > > > > On Sat, Sep 29, 2012 at 9:07 AM, Paul Moore wrote: > >> > >> On 29 September 2012 10:17, Stefan Krah wrote: > >&g

Re: [Python-Dev] experimental: Misc/NEWS included in docs

On Sun, Sep 30, 2012 at 3:14 PM, Chris Jerdonek wrote: > On Sun, Sep 30, 2012 at 6:17 AM, Georg Brandl wrote: > > at http://docs.python.org/3.3/whatsnew/news.html, there is now > > a rendering of Misc/NEWS with tracker links and a crude filtering > > capability. I thought that this will compleme

[Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)

I am presenting the talk "Python 3.3: Trust Me, It's Better Than 2.7" as PyCon Argentina and Brasil (and US if they accept the talk). As part of that talk I need to be able to benchmark Python 3.3 against 2.7 (both from tip) using the unladen benchmarks (which now include benchmarks from PyPy that

Re: [Python-Dev] benchmarks: Force map to a list to guarantee the calculations are performed under

On Sun, Sep 30, 2012 at 7:11 PM, Antoine Pitrou wrote: > On Mon, 1 Oct 2012 01:00:42 +0200 (CEST) > brett.cannon wrote: > > http://hg.python.org/benchmarks/rev/e9f911fd9bd3 > > changeset: 184:e9f911fd9bd3 > > user:Brett Cannon > > date:

Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)

ter Avg: 0.899742 -> 0.017443: 51.58x faster Significant (t=692.55) Stddev: 0.00283 -> 0.00032: 8.8470x smaller On Sun, Sep 30, 2012 at 7:12 PM, Brett Cannon wrote: > I am presenting the talk "Python 3.3: Trust Me, It's Better Than 2.7" as > PyCon Argentina and Brasil (

Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)

On Sun, Sep 30, 2012 at 8:07 PM, Alexandre Vassalotti wrote: > > > On Sun, Sep 30, 2012 at 4:50 PM, Brett Cannon wrote: > >> I accidentally left out the telco benchmark, which is bad since cdecimal >> makes it just scream on Python 3.3 (and I verified with Python 3.2 t

Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)

On Sun, Sep 30, 2012 at 8:14 PM, Gregory P. Smith wrote: > Interesting results! > > Another data point for the benchmarks that would be interesting is memory > consumption of the python process during the runs. > > In 3.3 a reasonable place to gather this would be to add a callback to the > new g

Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)

On Sun, Sep 30, 2012 at 9:35 PM, Steven D'Aprano wrote: > On Sun, Sep 30, 2012 at 07:12:47PM -0400, Brett Cannon wrote: > > > > python3 perf.py -T --basedir ../benchmarks -f -b py3k > > ../cpython/builds/2.7-wide/bin/python ../cpython/builds/3.3/bin/python3.3 > &g

Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)

On Sun, Sep 30, 2012 at 8:28 PM, Antoine Pitrou wrote: > On Sun, 30 Sep 2012 19:12:47 -0400 > Brett Cannon wrote: > > > > ### mako_v2 ### > > Min: 0.137584 -> 0.287701: 2.09x slower > > Avg: 0.140620 -> 0.293204: 2.09x slower > > Significant (t=-296.1

Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)

On Mon, Oct 1, 2012 at 3:44 AM, Maciej Fijalkowski wrote: > On Mon, Oct 1, 2012 at 1:12 AM, Brett Cannon wrote: > > I am presenting the talk "Python 3.3: Trust Me, It's Better Than 2.7" as > > PyCon Argentina and Brasil (and US if they accept the talk). As part o

Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)

On Mon, Oct 1, 2012 at 7:54 AM, Antoine Pitrou wrote: > On Sun, 30 Sep 2012 21:49:20 -0400 > Brett Cannon wrote: > > > Note that Mako can use the Markupsafe library for faster operation. > > > This will skew the result if one of your Pythons has Markupsafe > > >

Re: [Python-Dev] Bootstrap issue: "select" is compiled "too late"

On Thu, Oct 4, 2012 at 9:17 AM, Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/10/12 14:34, Benjamin Peterson wrote: > > 2012/10/4 Jesus Cea : > >> Any suggestion about how to solve this? > > > > Easy solutions include somehow removing the dependence on > > subproces

Re: [Python-Dev] Bootstrap issue: "select" is compiled "too late"

On Thu, Oct 4, 2012 at 5:37 PM, Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/10/12 18:38, Nick Coghlan wrote: > > You can still technically deadlock, but you need a circular import > > *and* two different threads that start at different parts of the > > cycle. > >

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

On Tue, Oct 16, 2012 at 11:18 AM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10/16/2012 09:47 AM, Barry Warsaw wrote: > > On Oct 16, 2012, at 05:32 AM, Trent Nelson wrote: > > > >> Anyway, back to the original question: does anyone know of reasons > >> we shouldn'

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