[Python-Dev] CRLF line endings
To facilitate review of the PEP 405 reference implementation, I want to update my sandbox repository on hg.python.org with the relevant changes, so I can create a patch for Rietveld. I've added some files with CRLF line endings: Lib/venv/scripts/nt/Activate.ps1 Lib/venv/scripts/nt/Dectivate.ps1 Lib/venv/scripts/nt/activate.bat Although these are text files, the CRLF line endings are needed because otherwise, the files won't be presented correctly on Windows, e.g. in Notepad. I'd like to update the .hgeol file to add these entries, as otherwise the commit hook rejects them. Can anyone please let me know if they object? Otherwise I'll go ahead and add them to .hgeol in the next hour or so. Regards, Vinay Sajip ___ 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] outdated info on download pages for older versions
On 2 May 2012, at 18:06, Ezio Melotti wrote: > On 02/05/2012 19.33, Michael Foord wrote: >> On 2 May 2012, at 16:55, Terry Reedy wrote: >>> I would send the above to [email protected] (should be at the bottom of >>> pages). We develop CPython but do not directly manage the website. >> Not true. The download pages are administered by the release managers not >> the web team. >> >> For the record, the best way of contacting the web team (such as it is) is >> the pydotorg-www mailing list. There are precious few people (even fewer >> than there are in the web team...) responding to emails on the webmaster >> alias. :-) >> >> Michael > > I'm pretty sure that several core devs are able (and possibly willing) to > help out with the website, but AFAIU they have to request commit right for a > separate repo where the website lives or report issues via mail. Is there > any practical reason why the repo for the website is not on hg with all the > other repos (cpython/devguide/peps/etc.) except that no one ported it yet? Anyone willing to assist with website maintenance (even occasional typo fixes) should email their ssh keys to the [email protected] mailing list (no need to join) and send an intro to the pydotorg-www mailing list (preferable to join). Michael > > Best Regards, > Ezio Melotti > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] CRLF line endings
On Thu, May 3, 2012 at 10:50 PM, Vinay Sajip wrote: > Although these are text files, the CRLF line endings are needed because > otherwise, the files won't be presented correctly on Windows, e.g. in Notepad. Not all Windows editors choke on \n line endings; when I'm on Windows and run into one, I open it in Wordpad (or, if I have one, a dedicated programming editor like SciTE or the Open Watcom editor). AFAIK only Notepad (of standard Windows utilities) has trouble. Not sure if that makes a difference or not. Chris Angelico ___ 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] CRLF line endings
Chris Angelico gmail.com> writes: > Not all Windows editors choke on \n line endings; when I'm on Windows > and run into one, I open it in Wordpad (or, if I have one, a dedicated > programming editor like SciTE or the Open Watcom editor). AFAIK only > Notepad (of standard Windows utilities) has trouble. > > Not sure if that makes a difference or not. It's only really an issue for new / inexperienced users, I agree. Since these files are installed only on Windows systems, there's no reason for them not to have the native line endings. Regards, Vinay Sajip ___ 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] CRLF line endings
On Fri, May 4, 2012 at 1:28 AM, Vinay Sajip wrote: > It's only really an issue for new / inexperienced users, I agree. Since these > files are installed only on Windows systems, there's no reason for them not to > have the native line endings. Then sure, doesn't make a lot of difference that it's only Notepad. Somebody needs to rewrite that ancient editor and give Windows a better default... ChrisA ___ 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: Issue #14687: str%tuple now uses an optimistic "unicode writer" instead of an
On 5/3/2012 7:16 AM, victor.stinner wrote: http://hg.python.org/cpython/rev/f1db931b93d3 changeset: 76730:f1db931b93d3 user:Victor Stinner date:Thu May 03 13:10:40 2012 +0200 summary: Issue #14687: str%tuple now uses an optimistic "unicode writer" instead of an accumulator. Directly write characters into the output (don't use a temporary list): resize and widen the string on demand. I am curious whether these optimizations for str % tuple get applied to equivalent str.format(*tuple) calls or if you plan to make them do so. It seems to me that there could be one internal function that does the concatenation, with lengthening and resizing, of literal and formatted substrings, for both interfaces. tjr ___ 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] CRLF line endings
Zitat von Chris Angelico : On Thu, May 3, 2012 at 10:50 PM, Vinay Sajip wrote: Although these are text files, the CRLF line endings are needed because otherwise, the files won't be presented correctly on Windows, e.g. in Notepad. Not all Windows editors choke on \n line endings; when I'm on Windows and run into one, I open it in Wordpad (or, if I have one, a dedicated programming editor like SciTE or the Open Watcom editor). AFAIK only Notepad (of standard Windows utilities) has trouble. Not sure if that makes a difference or not. I think that .bat files strictly *have* to have CRLF line endings. Not sure about PowerShell, though. In any case, having CRLF for these files sounds good to me. 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] [Python-checkins] cpython: Issue #14687: str%tuple now uses an optimistic "unicode writer" instead of an
>> http://hg.python.org/cpython/rev/f1db931b93d3 >> changeset: 76730:f1db931b93d3 >> user: Victor Stinner >> date: Thu May 03 13:10:40 2012 +0200 >> summary: >> Issue #14687: str%tuple now uses an optimistic "unicode writer" instead >> of an >> accumulator. Directly write characters into the output (don't use a >> temporary >> list): resize and widen the string on demand. > > I am curious whether these optimizations for str % tuple get applied to > equivalent str.format(*tuple) calls or if you plan to make them do so. It > seems to me that there could be one internal function that does the > concatenation, with lengthening and resizing, of literal and formatted > substrings, for both interfaces. I just wrote a patch for str.format(). http://bugs.python.org/issue14716 The speed up is between 0% and 27%. Victor ___ 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: unicode_writer: add finish() method and assertions to write_str() method
2012/5/3 victor.stinner : > Py_LOCAL_INLINE(void) Do these have to be marked inline? -- 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
Re: [Python-Dev] [Python-checkins] cpython: unicode_writer: add finish() method and assertions to write_str() method
>> Py_LOCAL_INLINE(void) > > Do these have to be marked inline? Functions used in loops, yes: the inline keyword *does* impact performances (5% slower). I removed the keyword for the other unicode_writer methods. Victor ___ 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] Optimize Unicode strings in Python 3.3
Hi,
Different people are working on improving performances of Unicode
strings in Python 3.3. This Python version is very different from
Python 3.2 because of the PEP 393, and it is still unclear to me what
is the best way to create a new Unicode string.
There are different approachs:
* Use the legacy (Py_UNICODE) API, PyUnicode_READY() converts the
result to the canonical form. CJK codecs are still using this API.
* Use a Py_UCS4 buffer and then convert to the canonical form (ASCII,
UCS1 or UCS2). Approach taken by io.StringIO. io.StringIO is not only
used to write, but also to read and so a Py_UCS4 buffer is a good
compromise.
* PyAccu API: optimized version of chunks=[]; for ...: ...
chunks.append(text); return ''.join(chunks).
* Two steps: compute the length and maximum character of the output
string, allocate the output string and then write characters. str%args
was using it.
* Optimistic approach. Start with a ASCII buffer, enlarge and widen
(to UCS2 and then UCS4) the buffer when new characters are written.
Approach used by the UTF-8 decoder and by str%args since today.
The optimistic approach uses realloc() to resize the string. It is
faster than the PyAccu approach (at least for short ASCII strings),
maybe because it avoids the creating of temporary short strings.
realloc() looks to be efficient on Linux and Windows (at least Seven).
Various notes:
* PyUnicode_READ() is slower than reading a Py_UNICODE array.
* Some decoders unroll the main loop to process 4 or 8 bytes (32 or
64 bits CPU) at each step.
I am interested if you know other tricks to optimize Unicode strings
in Python, or if you are interested to work on this topic.
There are open issues related to optimizing Unicode:
#11313: Speed up default encode()/decode()
#12807: Optimization/refactoring for {bytearray, bytes, unicode}.strip()
#14419: Faster ascii decoding
#14624: Faster utf-16 decoder
#14625: Faster utf-32 decoder
#14654: More fast utf-8 decoding
#14716: Use unicode_writer API for str.format()
Victor
___
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] CRLF line endings
On 5/3/2012 2:00 PM, [email protected] wrote: I think that .bat files strictly *have* to have CRLF line endings. Nope. Both .bat and .cmd work fine with LF only in Win7 (and IIRC, in XP as well, but I just tested Win7) ___ 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] time.clock_info() field names
> To me, "adjusted" and "is_adjusted" both imply that an adjustment > has already been made; "adjustable" only implies that it is possible. The documentation is: "True if the clock can be adjusted (e.g. by a NTP daemon), False otherwise." I prefer "adjustable", because no OS tell us if the clock has an ajustement or not... except Windows: see GetSystemTimeAdjustment(). http://msdn.microsoft.com/en-us/library/windows/desktop/ms724394%28v=vs.85%29.aspx I propose to rename is_adjusted (which is now called adjusted) to adjustable, and not use GetSystemTimeAdjustment() on Windows but hardcode the value to True for the system clock, False for other functions (GetTick, QueryPerformanceCounter, ...). Victor ___ 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] time.clock_info() field names
On 04May2012 01:47, Victor Stinner wrote: | I prefer "adjustable", because no OS tell us if the clock has an | ajustement or not... except Windows: see GetSystemTimeAdjustment(). | http://msdn.microsoft.com/en-us/library/windows/desktop/ms724394%28v=vs.85%29.aspx | | I propose to rename is_adjusted (which is now called adjusted) to | adjustable, I'm -1 on that. To my mind "adjustable" suggests that the caller can adjust the clock, while "adjusted" suggests that the clock may be adjusted by a mechanism outside the caller's hands. That latter is the meaning in the context of the PEP. Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ I'm not making any of this up you know. - Anna Russell ___ 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] time.clock_info() field names
> I'm -1 on that. To my mind "adjustable" suggests that the caller can > adjust the clock, while "adjusted" suggests that the clock may be adjusted > by a mechanism outside the caller's hands. That latter is the meaning > in the context of the PEP. Anyway, the implementation and/or the documentation is buggy and should be fixed (especially the Windows case). Victor ___ 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] CRLF line endings
On Fri, May 4, 2012 at 7:00 AM, wrote: > In any case, having CRLF for these files sounds good to me. Right. While Windows has been getting much better at coping with LF only line endings over the years, being able to explicitly flag files for CRLF endings is the entire reason we held out for the EOL extension before making the switch to Mercurial. 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] time.clock_info() field names
On Fri, May 4, 2012 at 10:12 AM, Cameron Simpson wrote: > On 04May2012 01:47, Victor Stinner wrote: > | I prefer "adjustable", because no OS tell us if the clock has an > | ajustement or not... except Windows: see GetSystemTimeAdjustment(). > | > http://msdn.microsoft.com/en-us/library/windows/desktop/ms724394%28v=vs.85%29.aspx > | > | I propose to rename is_adjusted (which is now called adjusted) to > | adjustable, > > I'm -1 on that. To my mind "adjustable" suggests that the caller can > adjust the clock, while "adjusted" suggests that the clock may be adjusted > by a mechanism outside the caller's hands. That latter is the meaning > in the context of the PEP. +1 The connotations of "adjusted" and "adjustable" are slightly different and, in this case, "adjusted" is a better fit. The fact that "adjusted" may be misinterpreted as "this clock has been adjusted in the past" (incorrectly leaving out the "and/or may be adjusted in the future" part) is still closer to the mark than the likely misinterpretation of "adjustable" as meaning "can be adjusted directly by the application" (which is simply false, unless the application starts tinkering with the relevant platform specific time configuration interfaces, which aren't exposed by the standard library). Regards, 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] Optimize Unicode strings in Python 3.3
Various notes: * PyUnicode_READ() is slower than reading a Py_UNICODE array. * Some decoders unroll the main loop to process 4 or 8 bytes (32 or 64 bits CPU) at each step. I am interested if you know other tricks to optimize Unicode strings in Python, or if you are interested to work on this topic. Beyond creation, the most frequent approach is to specialize loops for all three possible width, allowing the compiler to hard-code the element size. This brings it back in performance to the speed of accessing a Py_UNICODE array (or faster for 1-byte strings). A possible micro-optimization might be to use pointer arithmetic instead of indexing. However, I would expect that compilers will already convert a counting loop into pointer arithmetic if the index is only ever used for array access. A source of slow-down appears to be widening copy operations. I wonder whether microprocessors are able to do this faster than what the compiler generates out of a naive copying loop. Another potential area for further optimization is to better pass-through PyObject*. Some APIs still use char* or Py_UNICODE*, when the caller actually holds a PyObject*, and the callee ultimate recreates an object out of the pointers being passed. Some people (hi Larry) still think that using a rope representation for string concatenation might improve things, see #1569040. 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] [Python-checkins] cpython: Issue #14127: Add ns= parameter to utime, futimes, and lutimes.
2012/5/3 larry.hastings :
> diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
> --- a/Modules/posixmodule.c
> +++ b/Modules/posixmodule.c
> @@ -3572,28 +3572,194 @@
> #endif /* HAVE_UNAME */
>
>
> +static int
> +split_py_long_to_s_and_ns(PyObject *py_long, time_t *s, long *ns)
> +{
> + int result = 0;
> + PyObject *divmod;
> + divmod = PyNumber_Divmod(py_long, billion);
> + if (!divmod)
> + goto exit;
> + *s = _PyLong_AsTime_t(PyTuple_GET_ITEM(divmod, 0));
> + if ((*s == -1) && PyErr_Occurred())
> + goto exit;
> + *ns = PyLong_AsLong(PyTuple_GET_ITEM(divmod, 1));
> + if ((*s == -1) && PyErr_Occurred())
> + goto exit;
> +
> + result = 1;
> +exit:
> + Py_XDECREF(divmod);
> + return result;
> +}
> +
> +
> +typedef int (*parameter_converter_t)(PyObject *, void *);
> +
> +typedef struct {
> + /* input only */
> + char path_format;
> + parameter_converter_t converter;
> + char *function_name;
> + char *first_argument_name;
> + PyObject *args;
> + PyObject *kwargs;
> +
> + /* input/output */
> + PyObject **path;
> +
> + /* output only */
> + int now;
> + time_t atime_s;
> + long atime_ns;
> + time_t mtime_s;
> + long mtime_ns;
> +} utime_arguments;
> +
> +#define DECLARE_UA(ua, fname) \
> + utime_arguments ua; \
> + memset(&ua, 0, sizeof(ua)); \
> + ua.function_name = fname; \
> + ua.args = args; \
> + ua.kwargs = kwargs; \
> + ua.first_argument_name = "path"; \
> +
> +/* UA_TO_FILETIME doesn't declare atime and mtime for you */
> +#define UA_TO_FILETIME(ua, atime, mtime) \
> + time_t_to_FILE_TIME(ua.atime_s, ua.atime_ns, &atime); \
> + time_t_to_FILE_TIME(ua.mtime_s, ua.mtime_ns, &mtime)
> +
> +/* the rest of these macros declare the output variable for you */
> +#define UA_TO_TIMESPEC(ua, ts) \
> + struct timespec ts[2]; \
> + ts[0].tv_sec = ua.atime_s; \
> + ts[0].tv_nsec = ua.atime_ns; \
> + ts[1].tv_sec = ua.mtime_s; \
> + ts[1].tv_nsec = ua.mtime_ns
> +
> +#define UA_TO_TIMEVAL(ua, tv) \
> + struct timeval tv[2]; \
> + tv[0].tv_sec = ua.atime_s; \
> + tv[0].tv_usec = ua.atime_ns / 1000; \
> + tv[1].tv_sec = ua.mtime_s; \
> + tv[1].tv_usec = ua.mtime_ns / 1000
> +
> +#define UA_TO_UTIMBUF(ua, u) \
> + struct utimbuf u; \
> + utimbuf.actime = ua.atime_s; \
> + utimbuf.modtime = ua.mtime_s
> +
> +#define UA_TO_TIME_T(ua, timet) \
> + time_t timet[2]; \
> + timet[0] = ua.atime_s; \
> + timet[1] = ua.mtime_s
> +
> +
> +/*
> + * utime_read_time_arguments() processes arguments for the utime
> + * family of functions.
> + * returns zero on failure.
> + */
> +static int
> +utime_read_time_arguments(utime_arguments *ua)
> +{
> + PyObject *times = NULL;
> + PyObject *ns = NULL;
> + char format[24];
> + char *kwlist[4];
> + char **kw = kwlist;
> + int return_value;
> +
> + *kw++ = ua->first_argument_name;
> + *kw++ = "times";
> + *kw++ = "ns";
> + *kw = NULL;
> +
> + sprintf(format, "%c%s|O$O:%s",
> + ua->path_format,
> + ua->converter ? "&" : "",
> + ua->function_name);
> +
> + if (ua->converter)
> + return_value = PyArg_ParseTupleAndKeywords(ua->args, ua->kwargs,
> + format, kwlist, ua->converter, ua->path, ×, &ns);
> + else
> + return_value = PyArg_ParseTupleAndKeywords(ua->args, ua->kwargs,
> + format, kwlist, ua->path, ×, &ns);
> +
> + if (!return_value)
> + return 0;
> +
> + if (times && ns) {
> + PyErr_Format(PyExc_RuntimeError,
Why not a ValueError or TypeError?
> + "%s: you may specify either 'times'"
> + " or 'ns' but not both",
> + ua->function_name);
> + return 0;
> + }
> +
> + if (times && (times != Py_None)) {
Conditions in parenthesis like this is not style.
> + if (!PyTuple_CheckExact(times) || (PyTuple_Size(times) != 2)) {
> + PyErr_Format(PyExc_TypeError,
> + "%s: 'time' must be either"
> + " a valid tuple of two ints or None",
> + ua->function_name);
> + return 0;
> + }
> + ua->now = 0;
> + return (_PyTime_ObjectToTimespec(PyTuple_GET_ITEM(times, 0),
> + &(ua->atime_s), &(ua->atime_ns)) != -1)
> + && (_PyTime_ObjectToTimespec(PyTuple_GET_ITEM(times, 1),
Put && on previous line like Python.
> + &(ua->mtime_s), &(ua->mtime_ns)) != -1);
> + }
> +
> + if (ns) {
> + if (!PyTuple_CheckExact(ns) || (PyTuple_Size(ns) != 2)) {
> + PyErr_Format(PyExc_TypeError,
> + "%s: 'ns' must be a valid tuple of two ints",
> + ua->function_name);
> + return 0;
> + }
> + ua->now = 0;
> + return (split_py_long_to_s_and_ns(PyTuple_GET_ITEM(ns, 0),
> + &
Re: [Python-Dev] Another buildslave - Ubuntu again
On Thu, May 3, 2012 at 12:46 AM, Antoine Pitrou wrote: > Daily code coverage builds would be nice, but that's probably beyond > what the current infrastructure can offer. It would be nice if someone > wants to investigate that. Code coverage buildbots would indeed be good. I could give a try on this. What kind of infra changes would be required? I presume, it is the server side that you are referring to. Thank you, Senthil ___ 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: Issue #14127: Add ns= parameter to utime, futimes, and lutimes.
On 05/03/2012 10:07 PM, Benjamin Peterson wrote:
+if (times&& ns) {
+PyErr_Format(PyExc_RuntimeError,
Why not a ValueError or TypeError?
Well it's certainly not a TypeError. The 3.2 documentation defines
TypeError as:
Raised when an operation or function is applied to an object of
inappropriate type. The associated value is a string giving details
about the type mismatch.
If someone called os.utime with both times and ns, and the values of
each would have been legal if they'd been passed in in isolation, what
would be the type mismatch?
ValueError seems like a stretch. The 3.2 documentation defines
ValueError as
Raised when a built-in operation or function receives an argument
that has the right type but an inappropriate value, and the
situation is not described by a more precise exception such as
IndexError.
To me this describes a specific class of errors where a single value is
invalid in isolation, like an overly-long string for a path on Windows,
or a negative integer for some integer value that must always be 0 or
greater. The error with utime is a different sort of error; you are
passing in two presumably legal values, but the function requires that
you pass in at most one.
The only way I can see ValueError as being the right choice is from the
awkward perspective of "if you passed in times, then the only valid
value for ns is None" (or vice-versa).
Are there existing APIs that use ValueError for just this sort of
situation? I dimly recall there being something like this but I can't
recall it.
Is using RuntimeError some sort of Pythonic faux pas?
+if (times&& (times != Py_None)) {
Conditions in parenthesis like this is not style.
Can you point me to where this is described in PEP 7? I can't find it.
+return (_PyTime_ObjectToTimespec(PyTuple_GET_ITEM(times, 0),
+&(ua->atime_s),&(ua->atime_ns)) != -1)
+&& (_PyTime_ObjectToTimespec(PyTuple_GET_ITEM(times, 1),
Put&& on previous line like Python.
Okay.
Since I have questions regarding two of your three suggested changes,
I'll hold off on making any changes until the dust settles a little.
Finally, I appreciate the feedback, but... why post it to python-dev?
You could have sent me private email, or posted to the issue (#14127),
the latter of which would have enabled using rich chocolaty Rietveld.
I've seen a bunch of comments on checkins posted here and it all leaves
me scratching my head.
//arry/
___
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: Issue #14127: Add ns= parameter to utime, futimes, and lutimes.
On Fri, May 4, 2012 at 4:04 PM, Larry Hastings wrote: > Finally, I appreciate the feedback, but... why post it to python-dev? You > could have sent me private email, or posted to the issue (#14127), the > latter of which would have enabled using rich chocolaty Rietveld. I've seen > a bunch of comments on checkins posted here and it all leaves me scratching > my head. It's just the way post-checkin review is set up - the "Follow-up-to" header for the python-checkins mailing list is python-dev. Such comments are rare enough and the fact that they apply to already committed code is important enough that there hasn't been a major push to get the scheme changed to anything else (by contrast, the old process where comments went back to python-checkins *was* problematic, as they would get lost in the flow of actual checkin messages, hence the switch to the current system). 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
