Cheers
On Apr 21, 2012 10:25 AM, R. David Murray rdmur...@bitdance.com wrote:
On Sat, 21 Apr 2012 08:54:56 +0800, Matt Joiner anacro...@gmail.com
wrote:
I'm getting one of these every couple of days. What's the deal?
On Apr 21, 2012 1:03 AM, Python tracker
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
On Apr 21, 2012 7:11 AM, Nick Coghlan ncogh...@gmail.com 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
On Sat, 21 Apr 2012 23:09:08 +1000, Nick Coghlan ncogh...@gmail.com 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
(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
On Sun, Apr 22, 2012 at 12:55 AM, PJ Eby p...@telecommunity.com 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
On Sun, Apr 22, 2012 at 12:43 AM, R. David Murray rdmur...@bitdance.com wrote:
On Sat, 21 Apr 2012 23:09:08 +1000, Nick Coghlan ncogh...@gmail.com wrote:
Since it's not very discoverable that way, would anyone object if I
moved things around so it was exposed as collections.MappingProxy
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 chop
On Sat, Apr 21, 2012 at 11:30 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Apr 22, 2012 at 12:55 AM, PJ Eby p...@telecommunity.com 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
Antoine Pitrou solip...@pitrou.net 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
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 in
On Sat, Apr 21, 2012 at 16:55, Martin v. Löwis mar...@v.loewis.de 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
On Sat, Apr 21, 2012 at 12:10, Barry Warsaw ba...@python.org 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
On Sat, Apr 21, 2012 at 4:17 PM, Brett Cannon br...@python.org wrote:
On Sat, Apr 21, 2012 at 12:10, Barry Warsaw ba...@python.org 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
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
On Sat, Apr 21, 2012 at 20:54, Eric Snow ericsnowcurren...@gmail.comwrote:
On Sat, Apr 21, 2012 at 4:17 PM, Brett Cannon br...@python.org wrote:
On Sat, Apr 21, 2012 at 12:10, Barry Warsaw ba...@python.org wrote:
Strictly speaking, I do think you need to deprecate the APIs. I like
Nick's
On Sat, Apr 21, 2012 at 21:02, Eric Snow ericsnowcurren...@gmail.comwrote:
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
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::
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 (i.e.
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
20 matches
Mail list logo
