Re: [Python-Dev] c/ElementTree XML serialisation
On 2012-05-09, at 01:41 , Alex Leach wrote: True. I might not need the CDATA tag to wrap the javascript then, but I still need and symbols. I have no idea how to write a loop in javascript without one. Erm… you have them? What do you think `lt;` and `gt;` are? As to writing a loop in javascript without and , == and != generally work rather well, as does Array.prototype.forEach[0] [0] https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/forEach ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On Wed, May 9, 2012 at 3:10 AM, Nick Coghlan ncogh...@gmail.com wrote: On Wed, May 9, 2012 at 8:37 AM, Tres Seaver tsea...@palladion.com wrote: No, the mcl in the call is just the designated metaclass - the *actual* metaclass of the resulting class definition may be something different. That's why this is a separate method from mcl.__new__. Why not make it a static method, if there is no notion of a useful 'cls' argument? We need the explicitly declared metaclass as well as the bases in order to determine the correct metaclass. Note, that the current patch (at http://bugs.python.org/issue14588) obtains the explicitly declared metaclass from the keywords dict (exactly like the class statement). As a static method, the invocation would look like: type.build_class(mcl, bases, keywords, exec_body) So I think, that in theory, this static method could work exactly like the operator.build_class function in the patch: type.build_class(name, bases, kwds, exec_body) (it doesn't need the mcls in a separate argument, it is in kwds). Since mcl will always be an instance of type in 3.x (due to all classes being subtypes of object), it makes more sense to just make it a class method and invoke the method on the declared metaclass: mcl.build_class(bases, keywords, exec_body) We could do that, but mcl will always be an instance of type in 3.x is not strictly true: an arbitrary callable is still allowed as a metaclass in a class statement, so I think the build_class function should support it too. The following assertion *does not* hold reliably: cls = mcl.build_class(bases, keywords, exec_body) assert type(cls) == mcl # Not guaranteed Right. Instead, the invariant that holds is the weaker assertion: cls = mcl.build_class(bases, keywords, exec_body) assert isinstance(cls, mcl) But if mcl is an arbitrary callable, this is also not always true (of course, then the invocation above wouldn't work, but with a class statement we could still create such classes: def f(mcls, name, bases): ... return 0 ... class C(metaclass=f): ... pass ... C 0 Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On Wed, May 9, 2012 at 4:37 PM, Daniel Urban urban.dani...@gmail.com wrote: On Wed, May 9, 2012 at 3:10 AM, Nick Coghlan ncogh...@gmail.com wrote: We need the explicitly declared metaclass as well as the bases in order to determine the correct metaclass. Note, that the current patch (at http://bugs.python.org/issue14588) obtains the explicitly declared metaclass from the keywords dict (exactly like the class statement). 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(). Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
Nick Coghlan wrote: On Wed, May 9, 2012 at 4:37 PM, Daniel Urban urban.dani...@gmail.com wrote: On Wed, May 9, 2012 at 3:10 AM, Nick Coghlan ncogh...@gmail.com wrote: We need the explicitly declared metaclass as well as the bases in order to determine the correct metaclass. Note, that the current patch (at http://bugs.python.org/issue14588) obtains the explicitly declared metaclass from the keywords dict (exactly like the class statement). 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(). Be careful adding methods to type. Because type is its own metaclass descriptors can appear to add strangely: int.mro() [class 'int', class 'object'] type.mro() Traceback (most recent call last): File stdin, line 1, in module TypeError: descriptor 'mro' of 'type' object needs an argument As a consequence of this, making build_class either a class method or a static method will cause a direct call to type.build_class() to fail as neither class method nor static method are callable. Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On Wed, May 9, 2012 at 5:57 PM, Mark Shannon m...@hotpy.org wrote: As a consequence of this, making build_class either a class method or a static method will cause a direct call to type.build_class() to fail as neither class method nor static method are callable. We'll make sure it *behaves* like a static method, even if it's technically something else under the hood. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
Nick Coghlan wrote: On Wed, May 9, 2012 at 5:57 PM, Mark Shannon m...@hotpy.org wrote: As a consequence of this, making build_class either a class method or a static method will cause a direct call to type.build_class() to fail as neither class method nor static method are callable. We'll make sure it *behaves* like a static method, even if it's technically something else under the hood. What I am saying is that you *don't* want it to behave like a static method, you want it to behave like a builtin-function. Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On Wed, May 09, 2012 at 08:57:55AM +0100, Mark Shannon wrote: As a consequence of this, making build_class either a class method or a static method will cause a direct call to type.build_class() to fail as neither class method nor static method are callable. This might be a good reason to make them callable, especially staticmethod. I understand that at the language summit, this was considered a good idea: http://python.6.n6.nabble.com/Callable-non-descriptor-class-attributes-td1884829.html It certainly seems long overdue: confusion due to staticmethods not being callable go back a long time: http://stackoverflow.com/questions/3932948/ http://grokbase.com/t/python/python-list/11bhhtv95y/staticmethod-makes-my-brain-hurt http://mail.python.org/pipermail/python-list/2004-August/272593.html -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Point of building without threads?
Antoine Pitrou solip...@pitrou.net wrote: _decimal is about 12% faster without threads, because the expensive thread local context can be disabled. If you cached the last thread id along with the corresponding context, perhaps it could speed things up in most scenarios? Nice. This reduces the speed difference to about 4%! Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] c/ElementTree XML serialisation
Is there a better way? Dear Alex, As Terry indicates: python-dev is a list for the development *of* Python, not the development *with* Python. Use the general python-list or the xml-sig list for this kind of question. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On 27.04.2012 09:34, Eric Snow wrote: On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsawba...@python.org 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://mail.python.org/pipermail/python-ideas/2012-April/014954.html Interesting proposal. I have a number of comments: - namespace vs. dictionary. Barry was using it in the form sys.implementation.version. I think this is how it should work, yet the PEP says that sys.implementation is a dictionary, which means that you would need to write sys.implementation['version'] I think the PEP should be silent on the type of sys.implementation, in particular, it should not mandate that it be a module (else from sys.implementation import url ought to work) [Update: it seems this is already reflected in the PEP. I wonder where the requirement for a new type comes from. I think making it a module should be conforming, even though probably discouraged for cpython, as it would make people think that they can rely on it being a module. I wish there was a builtin class class record: pass which can be used to create objects which have only attributes and no methods. Making it a type should also work: class implementation: name = cpython version = (3,3,0) in which case it would an instance of an existing type, namely, type] - under-specified attributes: run-time environment doesn't mean much to me - my first guess is that it is the set of environment variables, i.e. a dictionary identical to os.environ. I assume you mean something different ... gc_type is supposedly a string, but I cannot guess what possible values it may have. I also wonder why it's relevant. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Point of building without threads?
On Wed, 9 May 2012 11:26:29 +0200 Stefan Krah ste...@bytereef.org wrote: Antoine Pitrou solip...@pitrou.net wrote: _decimal is about 12% faster without threads, because the expensive thread local context can be disabled. If you cached the last thread id along with the corresponding context, perhaps it could speed things up in most scenarios? Nice. This reduces the speed difference to about 4%! Note that you don't need the actual thread id, the Python thread state is sufficient: PyThreadState_GET should be a simply variable lookup in release builds. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] c/ElementTree XML serialisation
On Wednesday 09 May 2012 08:02:09 Xavier Morel wrote: | Erm… you have them? What do you think `lt;` and `gt;` are? I was under the impression that those (let's call them) HTML representations of and don't get interpreted correctly by Javascript engines. I'll have to check that though.. | | As to writing a loop in javascript without and , == and != generally | work rather well, as does Array.prototype.forEach[0] Thanks for the tips! Cheers, Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] c/ElementTree XML serialisation
On Wednesday 09 May 2012 08:02:09 Xavier Morel wrote: | Erm… you have them? What do you think `lt;` and `gt;` are? I was under the impression that those (let's call them) HTML representations of and don't get interpreted correctly by Javascript engines. I'll have to check that though.. | | As to writing a loop in javascript without and , == and != generally | work rather well, as does Array.prototype.forEach[0] Thanks for the tips! Cheers, Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On Wed, May 9, 2012 at 3:05 AM, Steven D'Aprano st...@pearwood.info wrote: I understand that at the language summit, this was considered a good idea: http://python.6.n6.nabble.com/Callable-non-descriptor-class-attributes-td1884829.html asideFYI, this was at the 2011 language summit/aside -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On Wed, May 9, 2012 at 5:57 AM, Martin v. Löwis mar...@v.loewis.dewrote: On 27.04.2012 09:34, Eric Snow wrote: On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsawba...@python.org 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://mail.python.org/**pipermail/python-ideas/2012-** April/014954.htmlhttp://mail.python.org/pipermail/python-ideas/2012-April/014954.html Interesting proposal. I have a number of comments: - namespace vs. dictionary. Barry was using it in the form sys.implementation.version. I think this is how it should work, yet the PEP says that sys.implementation is a dictionary, which means that you would need to write sys.implementation['version'] I think the PEP should be silent on the type of sys.implementation, in particular, it should not mandate that it be a module (else from sys.implementation import url ought to work) [Update: it seems this is already reflected in the PEP. I wonder where the requirement for a new type comes from. I think making it a module should be conforming, even though probably discouraged for cpython, as it would make people think that they can rely on it being a module. That stems from people arguing over whether sys.implementation should be a dict or a tuple, and people going it shouldn't be a sequence since it lacks a proper order, but then others saying it shouldn't be a dict because it isn't meant to be mutated (or something since I argued for the dict). So Eric (I suspect) went with what made sense to him. I wish there was a builtin class class record: pass which can be used to create objects which have only attributes and no methods. I have heard this request now a bazillion times over the years. Why don't we have such an empty class sitting somewhere in the stdlib with a constructor classmethod to simply return new instances (and if you want to get really fancy, optional keyword arguments to update the instance with the keys/values passed in)? Is it simply because it's just two lines of Python that *everyone* has replicated at some point? -Brett Making it a type should also work: class implementation: name = cpython version = (3,3,0) in which case it would an instance of an existing type, namely, type] - under-specified attributes: run-time environment doesn't mean much to me - my first guess is that it is the set of environment variables, i.e. a dictionary identical to os.environ. I assume you mean something different ... gc_type is supposedly a string, but I cannot guess what possible values it may have. I also wonder why it's relevant. Regards, Martin __**_ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/**mailman/listinfo/python-devhttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/**mailman/options/python-dev/** brett%40python.orghttp://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On Wed, May 9, 2012 at 3:57 AM, Martin v. Löwis mar...@v.loewis.de wrote: Interesting proposal. I have a number of comments: Thanks for taking a look, Martin. - namespace vs. dictionary. Barry was using it in the form sys.implementation.version. I think this is how it should work, yet the PEP says that sys.implementation is a dictionary, which means that you would need to write sys.implementation['version'] I think the PEP should be silent on the type of sys.implementation, in particular, it should not mandate that it be a module (else from sys.implementation import url ought to work) [Update: it seems this is already reflected in the PEP. I wonder where the requirement for a new type comes from. I think making it a module should be conforming, even though probably discouraged for cpython, as it would make people think that they can rely on it being a module. I wish there was a builtin class class record: pass which can be used to create objects which have only attributes and no methods. Making it a type should also work: class implementation: name = cpython version = (3,3,0) in which case it would an instance of an existing type, namely, type] The type for sys.implementation has slowly shifted from the original proposal. At this point it's settled into where I think it will stay, a custom type. I've covered the choice of type in the rationale section. However, there may be merit in not being so specific about the type. I'll give that some thought. - under-specified attributes: run-time environment doesn't mean much to me - my first guess is that it is the set of environment variables, i.e. a dictionary identical to os.environ. I assume you mean something different ... gc_type is supposedly a string, but I cannot guess what possible values it may have. I also wonder why it's relevant. Sorry for the confusion. These are from the examples section for sys.implementation.metadata. I believe the current version of the PEP is more clear on the distinction. Thanks again for the feedback. -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On Wed, 9 May 2012 10:44:59 -0400 Brett Cannon br...@python.org wrote: I wish there was a builtin class class record: pass which can be used to create objects which have only attributes and no methods. I have heard this request now a bazillion times over the years. Why don't we have such an empty class sitting somewhere in the stdlib with a constructor classmethod to simply return new instances (and if you want to get really fancy, optional keyword arguments to update the instance with the keys/values passed in)? Is it simply because it's just two lines of Python that *everyone* has replicated at some point? In this case, it's because sys is a built-in module written in C, and importing Python code is a no-go. We have a similar problem with ABCs: io jumps through hoops to register its implementation classes with the I/O ABCs. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On Wed, May 9, 2012 at 8:44 AM, Brett Cannon br...@python.org wrote: On Wed, May 9, 2012 at 5:57 AM, Martin v. Löwis mar...@v.loewis.de wrote: [Update: it seems this is already reflected in the PEP. I wonder where the requirement for a new type comes from. I think making it a module should be conforming, even though probably discouraged for cpython, as it would make people think that they can rely on it being a module. That stems from people arguing over whether sys.implementation should be a dict or a tuple, and people going it shouldn't be a sequence since it lacks a proper order, but then others saying it shouldn't be a dict because it isn't meant to be mutated (or something since I argued for the dict). So Eric (I suspect) went with what made sense to him. Yep. -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On Wed, May 9, 2012 at 8:50 AM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 9 May 2012 10:44:59 -0400 Brett Cannon br...@python.org wrote: I wish there was a builtin class class record: pass which can be used to create objects which have only attributes and no methods. I have heard this request now a bazillion times over the years. Why don't we have such an empty class sitting somewhere in the stdlib with a constructor classmethod to simply return new instances (and if you want to get really fancy, optional keyword arguments to update the instance with the keys/values passed in)? Is it simply because it's just two lines of Python that *everyone* has replicated at some point? In this case, it's because sys is a built-in module written in C, and importing Python code is a no-go. Something I've remotely considered is an approach like namedtuple takes: define a pure Python template, .format() it, and exec it. However, this is partly a reflection of my lack of familiarity with using the C-API. As well, the only place I've seen this done in the CPython code base is with namedtuple. Consequently, I was planning on taking the normal approach. Should the namedtuple-exec technique be avoided at the C level? -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Rietveld integration problem?
I recently added an issue http://bugs.python.org/issue14712 to track PEP 405 integration. The code is in my sandbox repo, and I've created a patch using the Create Patch button on the tracker. The diff has been created, but I don't seem to see a review link to Rietveld. The issue is on Rietveld but for some reason the patch set hasn't attached to it. An earlier version of the patch (which I've since unlinked) had the same problem - even after several days, the review link never appeared. It's done so automatically in the past, e.g. for issue http://bugs.python.org/issue1521950 Is it something I'm doing wrong, or is there a problem with the issue tracker/Rietveld integration? Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On Wed, May 9, 2012 at 10:50 AM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 9 May 2012 10:44:59 -0400 Brett Cannon br...@python.org wrote: I wish there was a builtin class class record: pass which can be used to create objects which have only attributes and no methods. I have heard this request now a bazillion times over the years. Why don't we have such an empty class sitting somewhere in the stdlib with a constructor classmethod to simply return new instances (and if you want to get really fancy, optional keyword arguments to update the instance with the keys/values passed in)? Is it simply because it's just two lines of Python that *everyone* has replicated at some point? In this case, it's because sys is a built-in module written in C, and importing Python code is a no-go. Sure, but couldn't we define this empty class in C code so that you can use the C API with it as well and just provide a C function to get a new instance? -Brett We have a similar problem with ABCs: io jumps through hoops to register its implementation classes with the I/O ABCs. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
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 bikeshed paint once more. I think it would be useful to
establish a naming convention for alternative constructors implemented as
{static,class}methods. I don't like `build_class()` much. Would you be
opposed to `type.new()`?
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On May 08, 2012, at 09:03 PM, Eric Snow wrote: This is defined as the version of the implementation, while sys.version_info is the version of the language. The semantics of sys.version_info have been sufficiently squishy in the past, as the XXX implies. This PEP shouldn't try to untangle that, so I think it be better to represent both values explicitly in sys.implementation. Definitely tangled. So, sys.implementation.version and sys.implementation.lang_version? Also, my inclination is to not have a sys.version equivalent in sys.implementation for now, in the interest of keeping things as bare-bones as possible to start. I think it would be fine, if PEP 421 was clear about the semantics of sys.implementation.version and was silent about trying to disentangle the semantics of sys.version. IOW, the PEP can say that the semantics of sys.version are fuzzy, but not try to clear it up. Then it would be explicit (as it already is) that sys.implementation.version describes the version of the implementation, not the version of the language compliance. If the latter is useful later, then it can use the PEP 421 described process to propose a new sys.implementation value that describes a language compliance variable. * I mildly prefer sys.implementation.name to be lower cased. My intuition is that to be safe, most comparisons of the value will coerce to lower case, which is easy enough in Python, but perhaps a bit more of a pain in C. I don't feel really strongly about this though. (A counter argument is that the value might be printed, so a case-sensitive version would be better.) I'm not sure it makes a lot of difference. Since cache_tag will be provided by the implementation, I don't have any strong use-cases that would constrain the name itself. Still, my preference is for lower case as well. I'll mull this one over. Cool. As I said, I'm on the fence about it too. :) * I've said before that I think the keys in sys.implementation should be locked down (i.e. not writable). I've been on and off about this. It's certainly not too hard to do, it makes sense, and I don't see a lot of reason not to do it. I'll give it a go. Maybe it doesn't matter. We're all adults here. I think there are two good choices. Either the PEP explicitly describes sys.implementation as immutable, or it is silent about it. IOW, I don't think the PEP should explicitly allow sys.implementation to be mutable. I think sys.implementation.metadata should be the same type. This I wonder about. The more I think about it, the more it fits. I'll give it a day and if that still holds I'll work it in. Cool. Thanks for the feedback, Barry! Feels like the PEP's getting close. Indeed! Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
Sure, but couldn't we define this empty class in C code so that you can use the C API with it as well and just provide a C function to get a new instance? That would be easy. All you need is a dictoffset. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On May 09, 2012, at 08:51 AM, Eric Snow wrote: The type for sys.implementation has slowly shifted from the original proposal. At this point it's settled into where I think it will stay, a custom type. I've covered the choice of type in the rationale section. However, there may be merit in not being so specific about the type. I'll give that some thought. Right. See my previous follow up for what I think the PEP should say about the semantics of the type, without being so specific about the actual type. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On May 09, 2012, at 11:09 AM, Brett Cannon wrote: Sure, but couldn't we define this empty class in C code so that you can use the C API with it as well and just provide a C function to get a new instance? +1 ISTM to be a companion to collections.namedtuple. IWBNI this new type was also exposed in the collections module. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On Wed, May 9, 2012 at 12:21 PM, Barry Warsaw ba...@python.org 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 bikeshed paint once more. I think it would be
useful to
establish a naming convention for alternative constructors implemented as
{static,class}methods. I don't like `build_class()` much. Would you be
opposed to `type.new()`?
Depends on how far you want this new term to go since new is somewhat
overloaded thanks to __new__(). I personally like create().
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
Given that the statement form is referred to as a class definition, and this is the dynamic equivalent, I'm inclined to go with type.define(). Dynamic type definition is more consistent with existing terminology than dynamic type creation. -- Sent from my phone, thus the relative brevity :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On Thu, 10 May 2012 08:14:55 +1000, Nick Coghlan ncogh...@gmail.com wrote: Given that the statement form is referred to as a class definition, and this is the dynamic equivalent, I'm inclined to go with type.define(). Dynamic type definition is more consistent with existing terminology than dynamic type creation. Yeah, but that's the statement form. I think of the characters in the .py file as the definition. If I'm creating a class dynamically...I'm creating(*) it, not defining it. I don't think it's a big deal, though. Either word will work. --David (*) Actually, come to think of it, I probably refer to it as constructing the class, rather than creating or defining it. It's the type equivalent of constructing an instance, perhaps? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
Nick Coghlan wrote: In that case, consider me convinced: static method it is. -0.93. Static methods are generally unpythonic, IMO. Python is not Java -- we have modules. Something should only go in a class namespace if it somehow relates to that particular class, and other classes could might implement it differently. That's not the case with build_class(). -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On Wed, May 9, 2012 at 10:39 AM, Barry Warsaw ba...@python.org wrote: On May 08, 2012, at 09:03 PM, Eric Snow wrote: Definitely tangled. So, sys.implementation.version and sys.implementation.lang_version? Also, my inclination is to not have a sys.version equivalent in sys.implementation for now, in the interest of keeping things as bare-bones as possible to start. I think it would be fine, if PEP 421 was clear about the semantics of sys.implementation.version and was silent about trying to disentangle the semantics of sys.version. IOW, the PEP can say that the semantics of sys.version are fuzzy, but not try to clear it up. Then it would be explicit (as it already is) that sys.implementation.version describes the version of the implementation, not the version of the language compliance. If the latter is useful later, then it can use the PEP 421 described process to propose a new sys.implementation value that describes a language compliance variable. Whoops. I meant that I'm okay with having sys.implementation.version and sys.implementation.lang_version, both as analogs to sys.version_info. My inclination is to not include the analog to sys.version. However, with the way that you put it, I think you're right that we could put off the lang_version attribute for later. * I've said before that I think the keys in sys.implementation should be locked down (i.e. not writable). I've been on and off about this. It's certainly not too hard to do, it makes sense, and I don't see a lot of reason not to do it. I'll give it a go. Maybe it doesn't matter. We're all adults here. I think there are two good choices. Either the PEP explicitly describes sys.implementation as immutable, or it is silent about it. IOW, I don't think the PEP should explicitly allow sys.implementation to be mutable. Agreed. -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On 05/09/2012 09:53 AM, Barry Warsaw wrote: On May 09, 2012, at 11:09 AM, Brett Cannon wrote: Sure, but couldn't we define this empty class in C code so that you can use the C API with it as well and just provide a C function to get a new instance? +1 ISTM to be a companion to collections.namedtuple. IWBNI this new type was also exposed in the collections module. I like Alex Martelli's approach, which I recall was exactly this: class namespace: def __init__(**kwargs): self.__dict__ = kwargs That means all the initializers you pass in to the constructor get turned into members. //arry/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On Thu, May 10, 2012 at 2:53 AM, Barry Warsaw ba...@python.org wrote: On May 09, 2012, at 11:09 AM, Brett Cannon wrote: Sure, but couldn't we define this empty class in C code so that you can use the C API with it as well and just provide a C function to get a new instance? +1 ISTM to be a companion to collections.namedtuple. IWBNI this new type was also exposed in the collections module. Please, no. No new just-like-a-namedtuple-except-you-can't-iterate-over-it type, and definitely not one exposed in the collections module. We've been over this before: collections.namedtuple *is* the standard library's answer for structured records. TOOWTDI, and the way we have already chosen includes iterability as one of its expected properties. People shouldn't be so quick to throw away ordered iterability - it makes a lot of things like generic display routines and serialisation *much* easier, and without incurring the runtime cost of multiple calls to sorted(). The original concern (that sys.implementation may differ in length across implementations) has been eliminated by moving all implementation specific values into sys.implementation.metadata. The top-level record now has a consistent length for any given language version. The fact that the length of the record may still change in *future* versions of Python can be handled through documentation - we can simply tell people it's OK to iterate over the fields, and even to use tuple unpacking, but if you want to future proof your code, make sure to include the trailing ', *' to ignore any fields that get added in the future. To help focus the discussion, I am going to propose a specific (albeit still somewhat hypothetical) use case: a cross-implementation testing system that wants to be able to consistently capture data about the version of Python that was tested, *without* needing implementation specific code in the metadata capture step. That produces the following set of requirements: 1. sys.implementation should be immutable for a given execution of Python 2. repr(sys.implementation) should display all recorded details of the implementation 3. It should be possible to write a generic, future-proof, serialisation of sys.implementation that captures all recorded details collections.namedtuple meets all those requirements (_structseq doesn't meet the last one at this point, but more on that later) It also shows that we only need to place very minimal constraints on sys.implementation.metadata: the type of that structure can be entirely up to the implementation, with the only requirement being that repr(sys.implementation.metadata) should produce a string that accurately captures the stored information. The only cross-implementation operation that is supported on that field would be to take its representation. Now, because this is going to be in the sys module, for CPython, we would actually need to use _structseq rather than collections.namedtuple. To do so in a useful way, _structseq should get two new additions: - the _fields attribute - the _asdict method As an added bonus, sys.float_info and sys.hash_info would also gain the new operations. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On Thu, May 10, 2012 at 10:03 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Python is not Java -- we have modules. Something should only go in a class namespace if it somehow relates to that particular class, and other classes could might implement it differently. That's not the case with build_class(). Not true - you *will* get a type instance out of any sane call to type.define(). Technically, you could probably declare your metaclass such that you get a non-type object instead (just as you can with a class definition), but that means you're really just using an insanely convoluted way to make an ordinary function call. If you didn't want to invoke the full PEP 3115 find metaclass/prepare namespace/execute body/call metaclass dance, why would you be calling type.define instead of just calling the metaclass directly? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On May 09, 2012, at 05:47 PM, Larry Hastings wrote: I like Alex Martelli's approach, which I recall was exactly this: class namespace: def __init__(**kwargs): self.__dict__ = kwargs That means all the initializers you pass in to the constructor get turned into members. Well, __init__(self, **kws), but yeah. :) -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On Wed, May 9, 2012 at 7:33 PM, Nick Coghlan ncogh...@gmail.com wrote: Please, no. No new just-like-a-namedtuple-except-you-can't-iterate-over-it type, and definitely not one exposed in the collections module. We've been over this before: collections.namedtuple *is* the standard library's answer for structured records. TOOWTDI, and the way we have already chosen includes iterability as one of its expected properties. People shouldn't be so quick to throw away ordered iterability - it makes a lot of things like generic display routines and serialisation *much* easier, and without incurring the runtime cost of multiple calls to sorted(). The original concern (that sys.implementation may differ in length across implementations) has been eliminated by moving all implementation specific values into sys.implementation.metadata. The top-level record now has a consistent length for any given language version. The fact that the length of the record may still change in *future* versions of Python can be handled through documentation - we can simply tell people it's OK to iterate over the fields, and even to use tuple unpacking, but if you want to future proof your code, make sure to include the trailing ', *' to ignore any fields that get added in the future. Good point. I'd forgotten about that new tuple unpacking syntax. FYI, a named tuple was my original choice. I'm going to sit on this a few days though. Who knows, we might be back to using a dict by then. wink Key points: * has dotted access * is immutable Both reflect the nature of sys.implementation as currently described (a fixed set of attributes on an dotted-access namespace). To help focus the discussion, I am going to propose a specific (albeit still somewhat hypothetical) use case: a cross-implementation testing system that wants to be able to consistently capture data about the version of Python that was tested, *without* needing implementation specific code in the metadata capture step. That produces the following set of requirements: 1. sys.implementation should be immutable for a given execution of Python 2. repr(sys.implementation) should display all recorded details of the implementation 3. It should be possible to write a generic, future-proof, serialisation of sys.implementation that captures all recorded details collections.namedtuple meets all those requirements (_structseq doesn't meet the last one at this point, but more on that later) It also shows that we only need to place very minimal constraints on sys.implementation.metadata: the type of that structure can be entirely up to the implementation, with the only requirement being that repr(sys.implementation.metadata) should produce a string that accurately captures the stored information. The only cross-implementation operation that is supported on that field would be to take its representation. Nice. Now, because this is going to be in the sys module, for CPython, we would actually need to use _structseq rather than collections.namedtuple. To do so in a useful way, _structseq should get two new additions: - the _fields attribute - the _asdict method Sounds good to me regardless of the PEP. -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Allow use of sphinx-autodoc in the standard library documentation?
One of the requirements for acceptance of PEP 3144 if the provision of a reStructuredText API reference. The current plan for dealing with that is to use Spinx apidoc to create a skeleton, and then capture the rewritten ReST produced by autodoc. However, it occurs to me that the module reference could actually *use* autodoc, with additional prose added to supplement the docstrings, rather than completely replacing them. I'd initially dismissed this idea out of hand, but recently realised I didn't have any especially strong arguments against it (and there are all the usual avoid double-keying data arguments in favour). So, given the advantages of autodoc, is there a concrete reason why we can't use it for the documentation of *new* standard library modules? Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
We've been over this before: collections.namedtuple *is* the standard library's answer for structured records. And I think it's a really ugly answer, and one that deserves a parallel that is not a tuple. If this is contentious, I'll write a PEP. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On Thu, May 10, 2012 at 3:34 PM, Martin v. Löwis mar...@v.loewis.de wrote: We've been over this before: collections.namedtuple *is* the standard library's answer for structured records. And I think it's a really ugly answer, and one that deserves a parallel that is not a tuple. If this is contentious, I'll write a PEP. Yes, please. One of the original arguments that delayed the introduction of the collections module was the fear that it would lead to the introduction of tons of subtly different data types, making it substantially harder to choose the right data type for a given application. I see this proposal as the realisation of that fear. Unordered types can be a PITA for testing, for display and for generic serialisation, so I definitely want to see a PEP before we add a new one that basically has its sole reason for existence being you can iterate over and index the field values in a namedtuple. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
