The internal dictproxy class was recently exposed as types.MappingProxyType.
Since it's not very discoverable that way, would anyone object if I
moved things around so it was exposed as collections.MappingProxy
instead? The main benefit to doing so is to get it into the table of
specialised contai
On Apr 21, 2012 7:11 AM, "Nick Coghlan" wrote:
>
> The internal dictproxy class was recently exposed as
types.MappingProxyType.
>
> Since it's not very discoverable that way, would anyone object if I
> moved things around so it was exposed as collections.MappingProxy
> instead? The main benefit to
On Sat, 21 Apr 2012 23:09:08 +1000, Nick Coghlan wrote:
> Since it's not very discoverable that way, would anyone object if I
> moved things around so it was exposed as collections.MappingProxy
> instead? The main benefit to doing so is to get it into the table of
> specialised container types at
(Sorry I'm so late to this discussion.)
I think that it's important to take into account the fact that PEP 3115
doesn't require namespaces to implement anything more than __setitem__ and
__getitem__ (with the latter not even needing to do anything but raise
KeyError).
Among other things, this mea
On Sun, Apr 22, 2012 at 12:55 AM, PJ Eby wrote:
> (Sorry I'm so late to this discussion.)
>
> I think that it's important to take into account the fact that PEP 3115
> doesn't require namespaces to implement anything more than __setitem__ and
> __getitem__ (with the latter not even needing to do a
On Sun, Apr 22, 2012 at 12:43 AM, R. David Murray wrote:
> On Sat, 21 Apr 2012 23:09:08 +1000, Nick Coghlan wrote:
>> Since it's not very discoverable that way, would anyone object if I
>> moved things around so it was exposed as collections.MappingProxy
>> instead? The main benefit to doing so i
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 file. Specifically, I have PyImport_GetMagicTag() and NullImporter_Type
>which I would like to c
On Sat, Apr 21, 2012 at 11:30 AM, Nick Coghlan wrote:
> On Sun, Apr 22, 2012 at 12:55 AM, PJ Eby wrote:
> > Personally, I think __build_class__ should be explicitly exposed and
> > supported, if for no other reason than that it allows one to re-implement
> > old-style __metaclass__ support in 2.
Antoine Pitrou writes:
> For the record, we don't have any stable OS X buildbots anymore.
> If you want to contribute a build slave (I hear we may have Apple
> employees reading this list), please take a look at
> http://wiki.python.org/moin/BuildBot
I realize it may not qualify for the official
> 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 API
(namely, all API not guaranteed as stable). If an API is not i
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
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 file. Specifically, I have PyImpor
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
>> suggestion to make them C wrappers which just call back into Python.
>
>
> That was my plan, but the amou
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.modules is part of the interpreter state, so
# repopulate (do
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
> >> suggestion to make them C wrappers which just
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
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_
> 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 would do when there can be more than one path separator on
> an OS
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 notice it tries to use the same path
separator as is the farthest right in the pat
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 notice it tries to u
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
21 matches
Mail list logo
