Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On 12/16/2014 08:18 PM, R. David Murray wrote: On Tue, 16 Dec 2014 10:48:07 -0800, Mark Roberts wiz...@gmail.com wrote: Besides, using iteritems() and friends is generally a premature optimization, unless you know you'll have very large containers. Creating a list is cheap. [...] No. A premature optimization is one that is made before doing any performance analysis, so language features are irrelevant to that labeling. This doesn't mean you shouldn't use better idioms when they are clear. This is a relevant point. I would make it even stronger: using iteritems() is not a premature optimization, it is a statement of intent. More importantly, using items() in iteration is a statement of expectation that the dict will change during iteration. If this is not in fact the case, then items() is the wrong idiom for reasons of readability, not (just) efficiency. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] A metaclass for immutability
Hi all, Recently when I am writing a computer algebra system for a very special purpose, it is found that being able to have objects of user-defined classes immutable can be very nice. It would greatly enhance the safety of the code. For example in the code that I were writing, objects hold a lot of references to other objects of user-defined class. If other parts of the code mutates the objects that is referenced, quite expected things could happen. As a result, an initial tentative implementation of a metaclass for making objects of user-defined classes immutable is written and put into a Github repository https://github.com/tschijnmo/immutableclass. Since I am not a python expert yet, could you please help me 1. If such a metaclass is Pythonic? Is it considered a good practice to use such a metaclass in a code that needs frequent maintenance? 2. Is this metaclass of interest to other Python developers as well? I mean is it worth-while to try to put this, or something like this, into the standard Python library? 3. If the answer to the above questions are affirmative, is my current implementation Pythonic? Especially if it is better implemented as a class decorator rather than a metaclass? Most of the code should be quite straightforward. It is mimicked after the named tuple in the collections library. Just for the initialization, basically what I did is to make a mutable proxy class for every immutable class. This proxy class is attempted to carry as much behaviour of the immutable class as possible, except it is mutable.Then the initializer defined by users are in fact called with self being an instance of the proxy class, then the actual immutable object is built out of it. This is my first time posting to this list. Any feedback is greatly appreciated. Thank you! Regards, Jinmo ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Wed, Dec 17, 2014 at 12:56 AM, Guido van Rossum gu...@python.org wrote: This thread hasn't been productive for a really long time now. I agree. The constructive way would be to concentrate on looking for causes. I don't know if there is a discipline of programming language usability in computer science, but now is a good moment to apply it. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Proposal: Update PEP 1 to allow an explicit Provisional status for PEPs
Hi folks, The recent release of setuptools 8.0 brought with it the migration to the more explicit version handling semantics defined in PEP 440. Some of the feedback on that release showed us that we could really use the equivalent of PEP 411 for interoperability PEPs as well as for standard library modules: a way to say this is well defined enough for us to publish a reference implementation in the default packaging tools, but needs additional user feedback before we consider it completely stable. The reasons for this are mostly pragmatic: the kinds of tweaks we're talking about are small (in this specific case, changing the normalised form when publishing release candidates from 'c' to 'rc' , when installation tools are already required to accept either spelling as valid), but updating hyperlinks, other documentation references, etc means that spinning a full PEP revision just for that change would be excessively expensive in contributor time and energy. So over on distutils-sig, we're currently considering PEP 440 provisional until we're happy with the feedback we're receiving on setuptools 8.x and the upcoming pip 6.0 release. However, I'd be happier if we could communicate that status more explicitly through the PEP process, especially as I think such a capability would be useful more generally as we move towards implementing metadata 2.0 and potentially other enhancements for pip 7+ next year. If folks are OK with this idea, I'll go ahead and make the appropriate changes to PEP 1 and the PEP index generator. I'm also happy to file a tracker issue, or write a short PEP, if folks feel making such a change requires a little more formality in its own right. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: Update PEP 1 to allow an explicit Provisional status for PEPs
On 12/17/2014 12:57 PM, Nick Coghlan wrote: If folks are OK with this idea, I'll go ahead and make the appropriate changes to PEP 1 and the PEP index generator. I'm also happy to file a tracker issue, or write a short PEP, if folks feel making such a change requires a little more formality in its own right. We have provisional for modules, it would seem to also make sense for PEPs. A tracker issue would be good. -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: Update PEP 1 to allow an explicit Provisional status for PEPs
On Dec 18, 2014, at 06:57 AM, Nick Coghlan wrote: However, I'd be happier if we could communicate that status more explicitly through the PEP process, especially as I think such a capability would be useful more generally as we move towards implementing metadata 2.0 and potentially other enhancements for pip 7+ next year. If folks are OK with this idea, I'll go ahead and make the appropriate changes to PEP 1 and the PEP index generator. I'm also happy to file a tracker issue, or write a short PEP, if folks feel making such a change requires a little more formality in its own right. Hi Nick. What specific changes do you propose to PEP 1 and/or the PEP process? FWIW, if they are fairly simple, then I think a tracker issue with at least the PEP 1 authors nosied would be fine. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: Update PEP 1 to allow an explicit Provisional status for PEPs
On 18 December 2014 at 08:10, Barry Warsaw ba...@python.org wrote: On Dec 18, 2014, at 06:57 AM, Nick Coghlan wrote: However, I'd be happier if we could communicate that status more explicitly through the PEP process, especially as I think such a capability would be useful more generally as we move towards implementing metadata 2.0 and potentially other enhancements for pip 7+ next year. If folks are OK with this idea, I'll go ahead and make the appropriate changes to PEP 1 and the PEP index generator. I'm also happy to file a tracker issue, or write a short PEP, if folks feel making such a change requires a little more formality in its own right. Hi Nick. What specific changes do you propose to PEP 1 and/or the PEP process? FWIW, if they are fairly simple, then I think a tracker issue with at least the PEP 1 authors nosied would be fine. Yeah, good point - I'll want a tracker issue regardless to host the Reitveld review. Filed at http://bugs.python.org/issue23077 My current thinking is that for future PEPs relying on PEP 411 to include a provisional API directly in the standard library, the Provisional state would effectively replace the Accepted state: Draft - Provisional (with PEP 411 disclaimer on the implementation) - Final (PEP 411 disclaimer removed) For interoperability standards track PEPs, I'd propose tweaking their flow to allow the use of the Active state, and stop using Accepted/Final entirely: Draft - Provisional - Active (- Superseded) However, looking at that, I'm starting to wonder if the PEPs like WSGI, the database API, the crypto API, and the packaging PEPs should be pulled out into a new PEP category (e.g. Standards Track (Interoperability)) to reflect the fact that they're defining a protocol, not just a particular standard library API. At the moment, we have an odd split where many of those are listed under Other Informational PEPs (together with things like the instructions for doing releases), while the packaging interoperability PEPs are Standards Track PEPs currently listed under Accepted PEPs. I think the next step would be for me to come up with a draft patch, and then if we think it needs a PEP for broader review (which now seems likely to me), we can decide that on the tracker issue. Cheers, Nick. P.S. You'd think I'd have learned my lesson by now when it comes to pulling on the thread that is PEP 1, but apparently not :) -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
Attached patch defines a new type struct_timespec for the time module. A
new capsule exports the type along with to/from converters - opening a
bridge for C, and for example the datetime module.
Your comments welcomed. If people feel this is worth the effort and
going the right direction, I should be able to finish doco, unit-tests,
whatever else is missing with a bit of guidance and move on other
datetime aspects.
Regards,
Matthieu
diff -r 5754f069b123 Include/timemodule.h
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/Include/timemodule.h Wed Dec 17 18:21:28 2014 -0800
@@ -0,0 +1,56 @@
+#ifndef Py_TIMEMODULE_H
+#define Py_TIMEMODULE_H
+#ifdef __cplusplus
+extern C {
+#endif
+
+#ifdef HAVE_CLOCK_GETTIME
+typedef struct timespec _PyTime_timespec;
+#else
+typedef struct {
+time_t tv_sec; /* seconds */
+long tv_nsec; /* nanoseconds */
+} _PyTime_timespec;
+#endif
+
+
+#define PyTime_CAPSULE_NAME time._C_API
+
+typedef struct {
+PyTypeObject *StrucTimespecType;
+PyObject *(*PyStructTimespecFromCStructTimespec)(_PyTime_timespec *);
+int (*PyStructTimespecToCStructTimespec)(PyObject*, _PyTime_timespec *);
+} PyTime_C_API;
+
+
+#ifndef TIME_MODULE
+
+static PyTime_C_API *api = NULL;
+
+#define PyStructTimespecFromCStructTimespec \
+ api-PyStructTimespecFromCStructTimespec
+
+#define PyStructTimespecToCStructTimespec \
+ api-PyStructTimespecToCStructTimespec
+
+#define StructTimespec_Check(op) \
+ PyObject_TypeCheck(op, api-StrucTimespecType)
+
+#define StructTimespec_CheckExact(op) \
+ (Py_TYPE(op) == api-StrucTimespecType)
+
+static int
+import_time(void)
+{
+api = (PyTime_C_API*)PyCapsule_Import(PyTime_CAPSULE_NAME, 0);
+return (api != NULL) ? 0 : -1;
+}
+
+#endif
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* !defined(Py_TIMEMODULE_H) */
+
diff -r 5754f069b123 Modules/timemodule.c
--- a/Modules/timemodule.c Sat Nov 22 12:54:57 2014 -0800
+++ b/Modules/timemodule.c Wed Dec 17 18:21:28 2014 -0800
@@ -30,6 +30,9 @@
#endif /* MS_WINDOWS */
#endif /* !__WATCOMC__ || __QNX__ */
+#define TIME_MODULE
+#include timemodule.h
+
/* Forward declarations */
static int floatsleep(double);
static PyObject* floattime(_Py_clock_info_t *info);
@@ -270,8 +273,25 @@
9,
};
+static PyStructSequence_Field struct_timespec_type_fields[] = {
+{tv_sec, seconds},
+{tv_nsec, nanoseconds},
+{0}
+};
+
+static PyStructSequence_Desc struct_timespec_type_desc = {
+time.struct_timespec,
+POSIX.1b structure for a time value.,
+struct_timespec_type_fields,
+2,
+};
+
+
static int initialized;
static PyTypeObject StructTimeType;
+static PyTypeObject StrucTimespecType;
+#define StructTimespec_Check(op) PyObject_TypeCheck(op, StrucTimespecType)
+#define StructTimespec_CheckExact(op) (Py_TYPE(op) == StrucTimespecType)
static PyObject *
@@ -1284,13 +1304,13 @@
PyDoc_STRVAR(module_doc,
This module provides various functions to manipulate time values.\n\
\n\
-There are two standard representations of time. One is the number\n\
+There are three standard representations of time. One is the number\n\
of seconds since the Epoch, in UTC (a.k.a. GMT). It may be an integer\n\
or a floating point number (to represent fractions of seconds).\n\
The Epoch is system-defined; on Unix, it is generally January 1st, 1970.\n\
The actual value can be retrieved by calling gmtime(0).\n\
\n\
-The other representation is a tuple of 9 integers giving local time.\n\
+Another representation is a tuple of 9 integers giving local time.\n\
The tuple items are:\n\
year (including century, e.g. 1998)\n\
month (1-12)\n\
@@ -1305,6 +1325,11 @@
if it is 1, the time is given in the DST time zone;\n\
if it is -1, mktime() should guess based on the date and time.\n\
\n\
+The other representation is a tuple of 2 integers similar to Posix.1b\n\
+struct timespec. The tuple items are:\n\
+ seconds\n\
+ nanoseconds (0-9)\n\
+\n\
Variables:\n\
\n\
timezone -- difference in seconds between UTC and local standard time\n\
@@ -1340,10 +1365,51 @@
NULL
};
+/*
+ * C API capsule
+ */
+
+static PyObject *
+PyStructTimespecFromCStructTimespec(_PyTime_timespec * ts)
+{
+PyObject *v = PyStructSequence_New(StrucTimespecType);
+if (v == NULL)
+return NULL;
+
+#define SET(i,val) PyStructSequence_SET_ITEM(v, i, PyLong_FromLong((long) val))
+SET(0, ts-tv_sec);
+SET(1, ts-tv_nsec);
+#undef SET
+if (PyErr_Occurred()) {
+Py_XDECREF(v);
+return NULL;
+}
+
+return v;
+}
+
+int PyStructTimespecToCStructTimespec(PyObject* obj, _PyTime_timespec * ts)
+{
+
+if (! StructTimespec_Check(obj))
+return -1;
+
+ts-tv_sec = PyLong_AsLong(PyStructSequence_GET_ITEM(obj,0));
+ts-tv_nsec = PyLong_AsLong(PyStructSequence_GET_ITEM(obj,1));
+
+return 0;
+}
+
+static PyTime_C_API api = {
+StrucTimespecType,
+PyStructTimespecFromCStructTimespec,
+PyStructTimespecToCStructTimespec
+};
+
Re: [Python-Dev] datetime nanosecond support (ctd?)
On Wed, Dec 17, 2014 at 7:52 PM, Matthieu Bec mdcb...@gmail.com wrote: Attached patch defines a new type struct_timespec for the time module. A new capsule exports the type along with to/from converters - opening a bridge for C, and for example the datetime module. I'd recommend opening a new issue in the bug tracker (bugs.python.org) and attach the patch there. Attaching it to an email is a good way for it to get lost and forgotten. :) -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] fixing broken link in pep 3
Hello my name is Raymond and I would like to fix a broken link on pep 3. If you go to https://www.python.org/dev/peps/pep-0003/ and click on link http://www.python.org/dev/workflow/, it returns a 404. What is the correct url? Should we also update the description It has been replaced by the Issue Workflow? After I'll get the correct answers, I will submit a patch. Thanks for your help. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
