[Python-Dev] a new type for sys.implementation
The implementation for sys.implementation is going to use a new (but
"private") type[1]. It's basically equivalent to the following:
class namespace:
def __init__(self, **kwargs):
self.__dict__.update(kwargs)
def __repr__(self):
keys = (k for k in self.__dict__ if not k.startswith('_'))
pairs = ("{}={!r}".format(k, self.__dict__[k]) for k in sorted(keys))
return "{}({})".format(type(self).__name__, ", ".join(pairs))
There were other options for the type, but the new type was the best
fit and not hard to do. Neither the type nor its API is directly
exposed publicly, but it is still accessible through
"type(sys.implementation)".
This brings me to a couple of questions:
1. should we make the new type un-instantiable (null out tp_new and tp_init)?
2. would it be feasible to officially add the type (or something like
it) in 3.3 or 3.4?
I've had quite a bit of positive feedback on the type (otherwise I
wouldn't bother bringing it up). But, if we don't add a type like
this to Python, I'd rather close the loophole and call it good (i.e.
*not* introduce a new type by stealth). My preference is for the type
(or equivalent) to be blessed in the language. Regardless of the
specific details of such a type, my more immediate concern is with the
impact on sys.implementation of python-dev's general sentiment in this
space.
-eric
[1] http://bugs.python.org/issue14673
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
On Thu, May 31, 2012 at 01:21:36AM -0600, Eric Snow wrote: > 1. should we make the new type un-instantiable (null out tp_new and tp_init)? Please don't. "Consenting adults" and all that. There's little things more frustrating that having a working type that does exactly what you want, except that some B&D coder has made it un-instantiable. Leave it undocumented and/or a single underscore name for the time being, with an aim to make it public in 3.4 if it is useful and there are no major objections. -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
Eric Snow wrote:
The implementation for sys.implementation is going to use a new (but
"private") type[1]. It's basically equivalent to the following:
Does this really need to be written in C rather than Python?
class namespace:
def __init__(self, **kwargs):
self.__dict__.update(kwargs)
def __repr__(self):
keys = (k for k in self.__dict__ if not k.startswith('_'))
pairs = ("{}={!r}".format(k, self.__dict__[k]) for k in sorted(keys))
return "{}({})".format(type(self).__name__, ", ".join(pairs))
There were other options for the type, but the new type was the best
fit and not hard to do. Neither the type nor its API is directly
exposed publicly, but it is still accessible through
"type(sys.implementation)".
This brings me to a couple of questions:
1. should we make the new type un-instantiable (null out tp_new and tp_init)?
2. would it be feasible to officially add the type (or something like
it) in 3.3 or 3.4?
I've had quite a bit of positive feedback on the type (otherwise I
wouldn't bother bringing it up). But, if we don't add a type like
this to Python, I'd rather close the loophole and call it good (i.e.
*not* introduce a new type by stealth). My preference is for the type
(or equivalent) to be blessed in the language. Regardless of the
specific details of such a type, my more immediate concern is with the
impact on sys.implementation of python-dev's general sentiment in this
space.
-eric
[1] http://bugs.python.org/issue14673
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/mark%40hotpy.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Make parameterized tests in email less hackish.
On Thu, 31 May 2012 13:11:14 +1000, Nick Coghlan wrote: > I'm not clear on why this is a metaclass rather than a simple class decorator. Because I didn't think of it. I don't (yet) think of "class" and "decorator" in the same sentence :) > On Thu, May 31, 2012 at 11:54 AM, r.david.murray > wrote: > > + Â Â In a _params dictioanry, the keys become part of the name of the > > generated > > + Â Â tests. Â In a _params list, the values in the list are converted > > into a > > + Â Â string by joining the string values of the elements of the tuple by > > '_' and > > + Â Â converting any blanks into '_'s, and this become part of the name. > > Â The > > + Â Â full name of a generated test is the portion of the _params name > > before the > > + Â Â '_params' portion, plus an '_', plus the name derived as explained > > above. > > Your description doesn't match your examples or implementation. > Assuming the example and implementation are correct (and they look > more sensible than the currently described approach), I believe that > last sentence should be: > > "The full name of a generated test is a 'test_' prefix, the portion > of the test function name after the '_as_' separator, plus an '_', > plus the name derived as explained above." Oops, yes. Thanks for the catch. --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
On Thu, May 31, 2012 at 8:26 PM, Mark Shannon wrote: > Eric Snow wrote: >> >> The implementation for sys.implementation is going to use a new (but >> "private") type[1]. It's basically equivalent to the following: > > > Does this really need to be written in C rather than Python? Yes, because we want to use it in the sys module. As you get lower down in the interpreter stack, implementing things in Python actually starts getting painful because of bootstrapping issues (e.g. that's why both _structseq and collections.namedtuple exist). Personally, I suggest we just expose the new type as types.SimpleNamespace (implemented in Lib/types.py as "SimpleNamespace = type(sys.implementation)" and call it done. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
On May 31, 2012, at 01:21 AM, Eric Snow wrote:
>The implementation for sys.implementation is going to use a new (but
>"private") type[1]. It's basically equivalent to the following:
>
>class namespace:
>def __init__(self, **kwargs):
>self.__dict__.update(kwargs)
>def __repr__(self):
>keys = (k for k in self.__dict__ if not k.startswith('_'))
>pairs = ("{}={!r}".format(k, self.__dict__[k]) for k in sorted(keys))
>return "{}({})".format(type(self).__name__, ", ".join(pairs))
>
>There were other options for the type, but the new type was the best
>fit and not hard to do. Neither the type nor its API is directly
>exposed publicly, but it is still accessible through
>"type(sys.implementation)".
I did the initial review of the four patches that Eric uploaded and I agreed
with him that this was the best fit for sys.implementation. (I need to review
his updated patch, which I'll try to get to later today.)
>This brings me to a couple of questions:
>
>1. should we make the new type un-instantiable (null out tp_new and tp_init)?
I don't think this is necessary.
>2. would it be feasible to officially add the type (or something like
>it) in 3.3 or 3.4?
I wouldn't be against it, but the implementation above (or really, the C
equivalent in Eric's patch) isn't quite appropriate to be that type.
Specifically, while I think that filtering out _names in the repr is fine for
sys.implementation, it would not be appropriate for a generalized, public
type.
OTOH, I'd have no problem just dropping that detail from sys.implementation
too. (Note of course that even with that, you can get the full repr via
sys.implementation.__dict__.)
Cheers,
-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
On May 31, 2012, at 10:31 PM, Nick Coghlan wrote: >Personally, I suggest we just expose the new type as >types.SimpleNamespace (implemented in Lib/types.py as "SimpleNamespace >= type(sys.implementation)" and call it done. Great idea, +1. Eric, if you want to remove the special case for _names in the repr, and update your patch to include types.SimpleNamespace, I'd happily review it again and support its inclusion. Cheers, -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
On Thu, May 31, 2012 at 9:06 AM, Barry Warsaw wrote: > On May 31, 2012, at 10:31 PM, Nick Coghlan wrote: > >>Personally, I suggest we just expose the new type as >>types.SimpleNamespace (implemented in Lib/types.py as "SimpleNamespace >>= type(sys.implementation)" and call it done. > > Great idea, +1. > > Eric, if you want to remove the special case for _names in the repr, and > update your patch to include types.SimpleNamespace, I'd happily review it > again and support its inclusion. Will do. -eric ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VS 11 Express is Metro only.
I hereby predict that Microsoft will revert this decision, and that VS Express 11 will be able to build CPython. But will it be able to target Windows XP? I have now tried, and it seems that the chances are really low (unless you use the VS 2010 tool chain, in which case you can just as well use VS 2010 Express in the first place). The VS 11 linker sets the "OS version" and "subsystem version" to 6.0, which means that XP refuses to recognize the files as executables. While the /subsystem switch allows to specify a different version, specifying 5.02 (needed for XP) gives an error that this is smaller than the minimum supported version. So for that reason alone, VS 11 cannot produce binaries that work on XP, but that would be easy to change for MS. In addition, the CRT uses various API in its startup code already that are Vista+. I already mentioned GetTickCount64, which is used to initialize the security cookie (for /GS). In addition, TLS is now implemented using FlsAlloc to better support fibers, which is also Vista+. This dependency cannot be easily broken, except to access FlsAlloc through LoadLibrary/GetProcAddress or weak externals. There may be more dependencies on Vista+. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a new type for sys.implementation
2012/5/31 Nick Coghlan : > On Thu, May 31, 2012 at 8:26 PM, Mark Shannon wrote: >> Eric Snow wrote: >>> >>> The implementation for sys.implementation is going to use a new (but >>> "private") type[1]. It's basically equivalent to the following: >> >> >> Does this really need to be written in C rather than Python? > > Yes, because we want to use it in the sys module. As you get lower > down in the interpreter stack, implementing things in Python actually > starts getting painful because of bootstrapping issues (e.g. that's > why both _structseq and collections.namedtuple exist). sys.implementation could be added by site or some other startup file. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.3.0 alpha 4
On behalf of the Python development team, I'm happy to announce the
fourth alpha release of Python 3.3.0.
This is a preview release, and its use is not recommended in
production settings.
Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x. Major new features and changes
in the 3.3 release series are:
* PEP 380, syntax for delegating to a subgenerator ("yield from")
* PEP 393, flexible string representation (doing away with the
distinction between "wide" and "narrow" Unicode builds)
* A C implementation of the "decimal" module, with up to 80x speedup
for decimal-heavy applications
* The import system (__import__) is based on importlib by default
* The new "packaging" module (also known as distutils2, and released
standalone under this name), implementing the new packaging formats
and deprecating "distutils"
* The new "lzma" module with LZMA/XZ support
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* PEP 412, a new key-sharing dictionary implementation that
significantly saves memory for object-oriented code
* The new "faulthandler" module that helps diagnosing crashes
* The new "unittest.mock" module
* The new "ipaddress" module
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
switched on by default
For a more extensive list of changes in 3.3.0, see
http://docs.python.org/3.3/whatsnew/3.3.html (*)
To download Python 3.3.0 visit:
http://www.python.org/download/releases/3.3.0/
Please consider trying Python 3.3.0 with your code and reporting any bugs
you may notice to:
http://bugs.python.org/
Enjoy!
(*) Please note that this document is usually finalized late in the release
cycle and therefore may have stubs and missing entries at this point.
--
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
