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
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 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
> 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
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_
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
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
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 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
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 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
> 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
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
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.
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 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 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
(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 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
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
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
21 matches
Mail list logo
