Re: [Python-Dev] HAVE_FSTAT?
2013/5/17 Antoine Pitrou : > > Hello, > > Some pieces of code are still guarded by: > #ifdef HAVE_FSTAT > ... > #endif > > I would expect all systems to have fstat() these days. It's pretty > basic POSIX, and even Windows has had it for ages. Shouldn't we simply > make those code blocks unconditional? It would avoid having to maintain > unused fallback paths. I was sure I'd seen a post/bug report about this: http://bugs.python.org/issue12082 The OP was trying to build Python on an embedded platform without fstat(). cf ___ 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] Purpose of Doctests [Was: Best practices for Enum]
On Sun, May 19, 2013 at 4:41 PM, Raymond Hettinger wrote: > nicer repr" is worth "Sorry, I broke your tests, made your published > examples > out of date, and slowed down your code." While the first two considerations are always potentially applicable when using enums, the latter should only be true for code that uses str() and repr() a lot. For other operations, int-based enums shouldn't add any more overhead than namedtuple does for tuples. I agree with basically everything you said, but I don't want "enums are slower than normal integers" to become a meme - there really shouldn't be a speed difference for any arithmetic operations when using IntEnum. 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] HAVE_FSTAT?
On Sun, 19 May 2013 10:08:39 +0200 Charles-François Natali wrote: > 2013/5/17 Antoine Pitrou : > > > > Hello, > > > > Some pieces of code are still guarded by: > > #ifdef HAVE_FSTAT > > ... > > #endif > > > > I would expect all systems to have fstat() these days. It's pretty > > basic POSIX, and even Windows has had it for ages. Shouldn't we simply > > make those code blocks unconditional? It would avoid having to maintain > > unused fallback paths. > > I was sure I'd seen a post/bug report about this: > http://bugs.python.org/issue12082 > > The OP was trying to build Python on an embedded platform without fstat(). Ah, right. Ok, judging by the answers I'm being consistent in my opinions :-) I still wonder why an embedded platform can't provide at least some emulation of fstat(), even by returning fake values. Not providing such a basic function must break a lot of existing third-party software. Regards Antoine. ___ 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] Ordering keyword dicts
> On Sat, May 18, 2013 at 10:27 PM, Raymond Hettinger > wrote: >> BTW, I'm +1 on the idea for ordering keyword-args. It makes >> it easier to debug if the arguments show-up in the order they >> were created. AFAICT, no purpose is served by scrambling them >> (which is exacerbated by the new randomized hashing security feature). (This is really for Raymond, though I'm replying to Guido's post.) I'm having a hard time understanding why this matters. Maybe I'm just dense on a Sunday morning. Can you explain what makes it difficult to debug about keyword arguments if they are held in a normal dictionary? Debugging at the Python level or the C level? Can you give an example where it would be easier to debug? If it makes it easier here, would it make it easier to debug other dictionary usage if they were ordered? Skip ___ 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] Ordering keyword dicts
On Sat, 18 May 2013 22:47:35 -0700 Guido van Rossum wrote: > On Sat, May 18, 2013 at 10:27 PM, Raymond Hettinger > wrote: > > BTW, I'm +1 on the idea for ordering keyword-args. It makes > > it easier to debug if the arguments show-up in the order they > > were created. AFAICT, no purpose is served by scrambling them > > (which is exacerbated by the new randomized hashing security feature). > > I'm slow at warming up to the idea. My main concern is speed -- since > most code doesn't need it and function calls are already slow (and > obviously very common :-) it would be a shame if this slowed down > function calls that don't need it noticeably. > > An observation is that it's only necessary to preserve order if the > function definition uses **kwds. AFAIK we currently don't know if this > is the case when the call is made though, but perhaps the information > could be made available to the call site somehow. > > There are also many special cases to consider; e.g. using **kwds in > the call where kwds is an unordered dict, or calls from C, or calls to > C. > > But maybe someone considers this a challenge and comes up with a > patch? The benefits to *some* use cases would be obvious. The main use case seems to be the OrderedDict constructor itself. Otherwise, I can't think of any situation where I would've wanted it. Changing keyword arguments to be an OrderedDict without impacting performance in all the cases you mentioned (and without breaking C-level compatibility) would be a real, tough challenge. Regards Antoine. ___ 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] More compact dictionaries with faster iteration
On Sun, May 19, 2013 at 7:27 AM, Raymond Hettinger wrote: > > On May 15, 2013, at 4:32 AM, Christian Tismer wrote: > > What is the current status of this discussion? > I'd like to know whether it is a considered alternative implementation. > > > As far as I can tell, I'm the only one working on it (and a bit slowly at > that). > My plan is to implement it for frozensets to see how it works out. > > Frozensets are a nice first experiment for several reasons: > * The current implementation is cleaner than dictionaries >(which have become more complicated due to key-sharing). > * It will be easy to benchmark (by racing sets vs frozen sets) >for an apples-to-apples comparison. > * There is no need to have a list-like over-allocation scheme >since frozensets can't grow after they are created. >That will guarantee a significant space savings and >it will simplify the coding. > * I wrote the code for setobject.c so I know all the ins-and-outs. > > > > There is also a discussion in python-ideas right now where this > alternative is mentioned, and I think especially for small dicts > as **kwargs, it could be a cheap way to introduce order. > > > The compaction of keys and values into a dense array was > intended to save space, improve cache performance, and > improve iteration speed. The ordering was just a side-effect > and one that is easily disturbed if keys ever get deleted. > > So a compacted dict might be a cheap way to introduce order > for kwargs, but it would need special handling if the user decided > to delete keys. > > BTW, I'm +1 on the idea for ordering keyword-args. It makes > it easier to debug if the arguments show-up in the order they > were created. AFAICT, no purpose is served by scrambling them > (which is exacerbated by the new randomized hashing security feature). > > > Raymond The completely ordered dict is easy to get too - you mark deleted entries instead of removing them (then all the keys are in order) and every now and then you just compact the whole thing by removing all the delted entries, presumably on the resize or so. Cheers, fijal ___ 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] Ordering keyword dicts
On Sun, May 19, 2013 at 11:01 PM, Antoine Pitrou wrote: > The main use case seems to be the OrderedDict constructor itself. > Otherwise, I can't think of any situation where I would've wanted it. I've had a couple related to populating other mappings where order matters, at least from a predictability and readability perspective, even if it's not strictly required from a standards compliance point of view (think writing XML attributes, etc). I quite liked the idea of a simple flag attribute on function objects that the interpreter checked, with a decorator in functools (or even the builtins) to set it. It's not a particularly elegant solution, but it would get the job done with minimal performance impact on existing functions. 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] HAVE_FSTAT?
Fake values would probably cause hard to debug problems. It's a long standing Python tradition not to offer low level APIs that the platform doesn't have. — Sent from Mailbox On Sun, May 19, 2013 at 5:20 AM, Antoine Pitrou wrote: > On Sun, 19 May 2013 10:08:39 +0200 > Charles-François Natali wrote: >> 2013/5/17 Antoine Pitrou : >> > >> > Hello, >> > >> > Some pieces of code are still guarded by: >> > #ifdef HAVE_FSTAT >> > ... >> > #endif >> > >> > I would expect all systems to have fstat() these days. It's pretty >> > basic POSIX, and even Windows has had it for ages. Shouldn't we simply >> > make those code blocks unconditional? It would avoid having to maintain >> > unused fallback paths. >> >> I was sure I'd seen a post/bug report about this: >> http://bugs.python.org/issue12082 >> >> The OP was trying to build Python on an embedded platform without fstat(). > Ah, right. Ok, judging by the answers I'm being consistent in my > opinions :-) > I still wonder why an embedded platform can't provide at least some > emulation of fstat(), even by returning fake values. Not providing > such a basic function must break a lot of existing third-party software. > Regards > Antoine. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.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] HAVE_FSTAT?
On Sun, 19 May 2013 07:47:14 -0700 (PDT) "Guido van Rossum" wrote: > Fake values would probably cause hard to debug problems. It's a long standing > Python tradition not to offer low level APIs that the platform doesn't have. I meant the platform, not Python. Regards Antoine. > — > Sent from Mailbox > > On Sun, May 19, 2013 at 5:20 AM, Antoine Pitrou > wrote: > > > On Sun, 19 May 2013 10:08:39 +0200 > > Charles-François Natali wrote: > >> 2013/5/17 Antoine Pitrou : > >> > > >> > Hello, > >> > > >> > Some pieces of code are still guarded by: > >> > #ifdef HAVE_FSTAT > >> > ... > >> > #endif > >> > > >> > I would expect all systems to have fstat() these days. It's pretty > >> > basic POSIX, and even Windows has had it for ages. Shouldn't we simply > >> > make those code blocks unconditional? It would avoid having to maintain > >> > unused fallback paths. > >> > >> I was sure I'd seen a post/bug report about this: > >> http://bugs.python.org/issue12082 > >> > >> The OP was trying to build Python on an embedded platform without fstat(). > > Ah, right. Ok, judging by the answers I'm being consistent in my > > opinions :-) > > I still wonder why an embedded platform can't provide at least some > > emulation of fstat(), even by returning fake values. Not providing > > such a basic function must break a lot of existing third-party software. > > Regards > > Antoine. > > ___ > > Python-Dev mailing list > > [email protected] > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > http://mail.python.org/mailman/options/python-dev/guido%40python.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] Ordering keyword dicts
Hm. Wouldn'tvevery call site be slowed down by checking for that flag? — Sent from Mailbox On Sun, May 19, 2013 at 7:42 AM, Nick Coghlan wrote: > On Sun, May 19, 2013 at 11:01 PM, Antoine Pitrou wrote: >> The main use case seems to be the OrderedDict constructor itself. >> Otherwise, I can't think of any situation where I would've wanted it. > I've had a couple related to populating other mappings where order > matters, at least from a predictability and readability perspective, > even if it's not strictly required from a standards compliance point > of view (think writing XML attributes, etc). > I quite liked the idea of a simple flag attribute on function objects > that the interpreter checked, with a decorator in functools (or even > the builtins) to set it. It's not a particularly elegant solution, but > it would get the job done with minimal performance impact on existing > functions. > 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/guido%40python.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] Ordering keyword dicts
On Sun, May 19, 2013 at 4:40 PM, Nick Coghlan wrote: > On Sun, May 19, 2013 at 11:01 PM, Antoine Pitrou wrote: >> The main use case seems to be the OrderedDict constructor itself. >> Otherwise, I can't think of any situation where I would've wanted it. > > I've had a couple related to populating other mappings where order > matters, at least from a predictability and readability perspective, > even if it's not strictly required from a standards compliance point > of view (think writing XML attributes, etc). > > I quite liked the idea of a simple flag attribute on function objects > that the interpreter checked, with a decorator in functools (or even > the builtins) to set it. It's not a particularly elegant solution, but > it would get the job done with minimal performance impact on existing > functions. > > Cheers, > Nick. Note that raymonds proposal would make dicts and ordereddicts almost exactly the same speed. ___ 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] HAVE_FSTAT?
On Mon, May 20, 2013 at 12:51 AM, Antoine Pitrou wrote:
> On Sun, 19 May 2013 07:47:14 -0700 (PDT)
> "Guido van Rossum" wrote:
>> Fake values would probably cause hard to debug problems. It's a long
>> standing Python tradition not to offer low level APIs that the platform
>> doesn't have.
>
> I meant the platform, not Python.
For CPython derivatives like PyMite, it can help to get things to compile.
Perhaps rather than dropping it, we can just replace all the complex
fallback code with code that triggers 'RuntimeError("Operation
requires fstat, which is not available on this platform")'.
Derivatives that support fstat-free platforms will have a clear place
to put their custom code, but we get the simpler assumption of fstat
always being available for the code paths we care about (and can
reasonably test).
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] Ordering keyword dicts
On 19 May 2013 11:57, Guido van Rossum wrote: > Hm. Wouldn'tvevery call site be slowed down by checking for that flag? Actually, when I was thinking on the subject I came to the same idea, of having some functions marked differently so they would use a different call mechanism - but them I wondered around having a different opcode for the ordered-dict calls. Would that be feasible? js -><- > — > Sent from Mailbox > > > On Sun, May 19, 2013 at 7:42 AM, Nick Coghlan wrote: >> >> On Sun, May 19, 2013 at 11:01 PM, Antoine Pitrou >> wrote: >> > The main use case seems to be the OrderedDict constructor itself. >> > Otherwise, I can't think of any situation where I would've wanted it. >> >> I've had a couple related to populating other mappings where order >> matters, at least from a predictability and readability perspective, >> even if it's not strictly required from a standards compliance point >> of view (think writing XML attributes, etc). >> >> I quite liked the idea of a simple flag attribute on function objects >> that the interpreter checked, with a decorator in functools (or even >> the builtins) to set it. It's not a particularly elegant solution, but >> it would get the job done with minimal performance impact on existing >> functions. >> >> 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/guido%40python.org > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br > ___ 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] HAVE_FSTAT?
On Mon, 20 May 2013 01:09:19 +1000
Nick Coghlan wrote:
> On Mon, May 20, 2013 at 12:51 AM, Antoine Pitrou wrote:
> > On Sun, 19 May 2013 07:47:14 -0700 (PDT)
> > "Guido van Rossum" wrote:
> >> Fake values would probably cause hard to debug problems. It's a long
> >> standing Python tradition not to offer low level APIs that the platform
> >> doesn't have.
> >
> > I meant the platform, not Python.
>
> For CPython derivatives like PyMite, it can help to get things to compile.
It's not a CPython derivative.
Regards
Antoine.
>
> Perhaps rather than dropping it, we can just replace all the complex
> fallback code with code that triggers 'RuntimeError("Operation
> requires fstat, which is not available on this platform")'.
>
> Derivatives that support fstat-free platforms will have a clear place
> to put their custom code, but we get the simpler assumption of fstat
> always being available for the code paths we care about (and can
> reasonably test).
>
> 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] Purpose of Doctests [Was: Best practices for Enum]
Anyway, if you're doing arithmetic on enums you're doing it wrong. — Sent from Mailbox On Sun, May 19, 2013 at 4:55 AM, Nick Coghlan wrote: > On Sun, May 19, 2013 at 4:41 PM, Raymond Hettinger > wrote: >> nicer repr" is worth "Sorry, I broke your tests, made your published >> examples >> out of date, and slowed down your code." > While the first two considerations are always potentially applicable > when using enums, the latter should only be true for code that uses > str() and repr() a lot. For other operations, int-based enums > shouldn't add any more overhead than namedtuple does for tuples. > I agree with basically everything you said, but I don't want "enums > are slower than normal integers" to become a meme - there really > shouldn't be a speed difference for any arithmetic operations when > using IntEnum. > 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/guido%40python.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
[Python-Dev] Async subprocesses on Windows with tulip
Attached is a pretty trivial example of asynchronous interaction with a python subprocess using tulip on Windows. It does not use transports or protocols -- instead sock_recv() and sock_sendall() are used inside tasks. I am not sure what the plan is for dealing with subprocesses currently. Shall I just add this to the examples folder for now? -- Richard ''' Example of asynchronous interaction with a subprocess on Windows. This requires use of overlapped pipe handles and (a modified) iocp proactor. ''' import itertools import logging import msvcrt import os import subprocess import sys import tempfile import _winapi import tulip from tulip import _overlapped, windows_events, events PIPE = subprocess.PIPE BUFSIZE = 8192 _mmap_counter=itertools.count() def _pipe(duplex=True, overlapped=(True, True)): ''' Return handles for a pipe with one or both ends overlapped. ''' address = tempfile.mktemp(prefix=r'\\.\pipe\python-pipe-%d-%d-' % (os.getpid(), next(_mmap_counter))) if duplex: openmode = _winapi.PIPE_ACCESS_DUPLEX access = _winapi.GENERIC_READ | _winapi.GENERIC_WRITE obsize, ibsize = BUFSIZE, BUFSIZE else: openmode = _winapi.PIPE_ACCESS_INBOUND access = _winapi.GENERIC_WRITE obsize, ibsize = 0, BUFSIZE openmode |= _winapi.FILE_FLAG_FIRST_PIPE_INSTANCE if overlapped[0]: openmode |= _winapi.FILE_FLAG_OVERLAPPED if overlapped[1]: flags_and_attribs = _winapi.FILE_FLAG_OVERLAPPED else: flags_and_attribs = 0 h1 = h2 = None try: h1 = _winapi.CreateNamedPipe( address, openmode, _winapi.PIPE_WAIT, 1, obsize, ibsize, _winapi.NMPWAIT_WAIT_FOREVER, _winapi.NULL) h2 = _winapi.CreateFile( address, access, 0, _winapi.NULL, _winapi.OPEN_EXISTING, flags_and_attribs, _winapi.NULL) ov = _winapi.ConnectNamedPipe(h1, overlapped=True) ov.GetOverlappedResult(True) return h1, h2 except: if h1 is not None: _winapi.CloseHandle(h1) if h2 is not None: _winapi.CloseHandle(h2) raise class PipeHandle: ''' Wrapper for a pipe handle ''' def __init__(self, handle): self._handle = handle @property def handle(self): return self._handle def fileno(self): return self._handle def close(self, *, CloseHandle=_winapi.CloseHandle): if self._handle is not None: CloseHandle(self._handle) self._handle = None __del__ = close def __enter__(self): return self def __exit__(self, t, v, tb): self.close() class Popen(subprocess.Popen): ''' Subclass of Popen which uses overlapped pipe handles wrapped with PipeHandle instead of normal file objects for stdin, stdout, stderr. ''' _WriteWrapper = PipeHandle _ReadWrapper = PipeHandle def __init__(self, args, *, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=False, shell=False, cwd=None, env=None, startupinfo=None, creationflags=0, restore_signals=True, start_new_session=False, pass_fds=()): stdin_rfd = stdout_wfd = stderr_wfd = None stdin_wh = stdout_rh = stderr_rh = None if stdin == PIPE: stdin_rh, stdin_wh = _pipe(False, (False, True)) stdin_rfd = msvcrt.open_osfhandle(stdin_rh, os.O_RDONLY) if stdout == PIPE: stdout_rh, stdout_wh = _pipe(False, (True, False)) stdout_wfd = msvcrt.open_osfhandle(stdout_wh, 0) if stderr == PIPE: stderr_rh, stderr_wh = _pipe(False, (True, False)) stderr_wfd = msvcrt.open_osfhandle(stderr_wh, 0) try: super().__init__(args, stdin=stdin_rfd, stdout=stdout_wfd, stderr=stderr_wfd, executable=executable, preexec_fn=preexec_fn, close_fds=close_fds, shell=shell, cwd=cwd, env=env, startupinfo=startupinfo, creationflags=creationflags, restore_signals=restore_signals, start_new_session=start_new_session, pass_fds=pass_fds) except: for h in (stdin_wh, stdout_rh, stderr_rh): _winapi.CloseHandle(h) raise else: if stdin_wh is not None: self.stdin = self._WriteWrapper(stdin_wh) if stdout_rh is not None: self.stdout = self._ReadWrapper(stdout_rh) if stderr_rh is not None: self.stderr = self._ReadWrapper(stderr_rh) finally: if stdin == PIPE: os.close(stdin_rfd) if stdout == PIPE: os.c
Re: [Python-Dev] Async subprocesses on Windows with tulip
Shouldn't this go to the python-tulip list? 2013/5/19 Richard Oudkerk : > Attached is a pretty trivial example of asynchronous interaction with a > python subprocess using tulip on Windows. It does not use transports or > protocols -- instead sock_recv() and sock_sendall() are used inside tasks. > > I am not sure what the plan is for dealing with subprocesses currently. > Shall I just add this to the examples folder for now? > > -- > Richard > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/benjamin%40python.org > -- 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] Purpose of Doctests [Was: Best practices for Enum]
On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger < [email protected]> wrote: > > On May 14, 2013, at 9:39 AM, Gregory P. Smith wrote: > > Bad: doctests. > > > I'm hoping that core developers don't get caught-up in the "doctests are > bad meme". > Don't doctests intended for CPython not work on Jython, Pypy, IronPython... I've been avoiding them for this reason. ___ 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] Async subprocesses on Windows with tulip
On 19/05/2013 5:03pm, Benjamin Peterson wrote: > Shouldn't this go to the python-tulip list? Yes. Sorry about that. -- Richard ___ 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] Purpose of Doctests [Was: Best practices for Enum]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2013 10:48 AM, Guido van Rossum wrote: > Anyway, if you're doing arithmetic on enums you're doing it wrong. Hmm, bitwise operations, even? Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGZMoAACgkQ+gerLs4ltQ79qwCgq6FWTl6ZDIDctBg69In47YB2 +FkAnj5cEyw1szQ8GCl6aQ9+aGKcwp3y =d/xt -END PGP SIGNATURE- ___ 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] Purpose of Doctests [Was: Best practices for Enum]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2013 12:14 PM, Dan Stromberg wrote: > On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger < > [email protected]> wrote: > >> >> On May 14, 2013, at 9:39 AM, Gregory P. Smith >> wrote: >> >> Bad: doctests. >> >> >> I'm hoping that core developers don't get caught-up in the "doctests >> are bad meme". >> > > Don't doctests intended for CPython not work on Jython, Pypy, > IronPython... > > I've been avoiding them for this reason. "Naive" doctests depend a lot on repr, and hence tend to break even between minor releases of CPython. Folks who use a lot of them apply a great deal of elbow grease to working around that problem, e.g. through "renoormalizing" the output: https://github.com/zopefoundation/zope.testing/blob/master/src/zope/testing/renormalizing.txt Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGZM1YACgkQ+gerLs4ltQ6zRACgx266WAzy1RDX0vOm7fThXzi5 zX4AoNyZFGBOML2XR4ZOecXwzG6XaHW+ =yGon -END PGP SIGNATURE- ___ 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] Purpose of Doctests [Was: Best practices for Enum]
On 5/19/2013 4:13 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2013 10:48 AM, Guido van Rossum wrote: Anyway, if you're doing arithmetic on enums you're doing it wrong. Hmm, bitwise operations, even? Those are logic, not arithmetic as usually understood. (The fact that one can do each with the other is beside the point.) ___ 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] Why is documentation not inline?
This is more out of curiosity than to spark change (although I wouldn't argue against it): Does anyone know why it was decided to document external to source files rather than inline? When rapidly digging through source, it would be much more helpful to see parameter docs than to either have to find source lines (that can easily be missed) to figure out the intention. Case in point, I've been digging through cookiejar.py and request.py to figure out their interactions. When reading through build_opener, it took me a few minutes to figure out that each element of *handlers can be either an instance /or/ a class definition (I was looking at how to define a custom cookiejar for an HTTPCookieProcessor). Yes, I'm (now) aware that there's some documentation at the top of request.py, but it would have been helpful to have it right in the definition of build_opener. It seems like external docs is standard throughout the stdlib. Is there an actual reason for this? Thanks, -- Demian Brecht http://demianbrecht.github.com ___ 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] Why is documentation not inline?
On Sun, 19 May 2013 15:29:37 -0700 Demian Brecht wrote: > This is more out of curiosity than to spark change (although I > wouldn't argue against it): Does anyone know why it was decided to > document external to source files rather than inline? > > When rapidly digging through source, it would be much more helpful to > see parameter docs than to either have to find source lines (that can > easily be missed) to figure out the intention. Case in point, I've > been digging through cookiejar.py and request.py to figure out their > interactions. When reading through build_opener, it took me a few > minutes to figure out that each element of *handlers can be either an > instance /or/ a class definition (I was looking at how to define a > custom cookiejar for an HTTPCookieProcessor). Yes, I'm (now) aware > that there's some documentation at the top of request.py, but it would > have been helpful to have it right in the definition of build_opener. > > It seems like external docs is standard throughout the stdlib. Is > there an actual reason for this? Have you seen the length of the documentation pages? Putting them inline in the stdlib module would make the code much harder to skim through. Regards Antoine. ___ 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] Why is documentation not inline?
2013/5/19 Demian Brecht : > This is more out of curiosity than to spark change (although I > wouldn't argue against it): Does anyone know why it was decided to > document external to source files rather than inline? > > When rapidly digging through source, it would be much more helpful to > see parameter docs than to either have to find source lines (that can > easily be missed) to figure out the intention. Case in point, I've > been digging through cookiejar.py and request.py to figure out their > interactions. When reading through build_opener, it took me a few > minutes to figure out that each element of *handlers can be either an > instance /or/ a class definition (I was looking at how to define a > custom cookiejar for an HTTPCookieProcessor). Yes, I'm (now) aware > that there's some documentation at the top of request.py, but it would > have been helpful to have it right in the definition of build_opener. > > It seems like external docs is standard throughout the stdlib. Is > there an actual reason for this? ernal One is legacy. It certainly wasn't possible with the old LaTeX doc system. Another is that even if you do have API documentation inline, you have to have a lot of juggling in the external file to create the desired narrative structure which may not be the same as the code layout in the 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
Re: [Python-Dev] Ordering keyword dicts
On 20 May 2013 00:57, "Guido van Rossum" wrote: > > Hm. Wouldn'tvevery call site be slowed down by checking for that flag? Yeah, I forgot about having to push everything through the tp_call slot, so we can't easily limit the ordering check to just those cases where the callable accepts arbitrary kwargs. Cheers, Nick. > — > Sent from Mailbox > > > On Sun, May 19, 2013 at 7:42 AM, Nick Coghlan wrote: >> >> On Sun, May 19, 2013 at 11:01 PM, Antoine Pitrou wrote: >> > The main use case seems to be the OrderedDict constructor itself. >> > Otherwise, I can't think of any situation where I would've wanted it. >> >> I've had a couple related to populating other mappings where order >> matters, at least from a predictability and readability perspective, >> even if it's not strictly required from a standards compliance point >> of view (think writing XML attributes, etc). >> >> I quite liked the idea of a simple flag attribute on function objects >> that the interpreter checked, with a decorator in functools (or even >> the builtins) to set it. It's not a particularly elegant solution, but >> it would get the job done with minimal performance impact on existing >> functions. >> >> 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/guido%40python.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] Purpose of Doctests [Was: Best practices for Enum]
On 20 May 2013 06:25, "Terry Jan Reedy" wrote: > > On 5/19/2013 4:13 PM, Tres Seaver wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 05/19/2013 10:48 AM, Guido van Rossum wrote: >>> >>> Anyway, if you're doing arithmetic on enums you're doing it wrong. >> >> >> Hmm, bitwise operations, even? > > > Those are logic, not arithmetic as usually understood. (The fact that one can do each with the other is beside the point.) I consider those to be binary arithmetic, but it's a fair point. The word I really wanted was "comparison" anyway, since the main intended uses of enums are as flags, lookup keys and marker values. Cheers, Nick. > > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ 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] Why is documentation not inline?
@benjamin: Ah, i see. I wasn't around pre-Sphinx. However, unless there's some custom build steps that I'm unaware of that may prevent it, it should still be relatively easy to maintain the desired narrative structure as long as the inline API docs are kept terse. @antoine: Sorry, I may not have been clear. I wasn't advocating the inclusion of the /entire/ doc pages inline. I'm advocating terse documentation for the stdlib APIs and parameters. Narrative documentation can (and should be) maintained externally, but could use autodoc to include the terse references when desired. This would ensure that the same docs are available (and consistent) when reading the documentation as well as when neck-deep in code. On Sun, May 19, 2013 at 3:32 PM, Antoine Pitrou wrote: > On Sun, 19 May 2013 15:29:37 -0700 > Demian Brecht wrote: >> This is more out of curiosity than to spark change (although I >> wouldn't argue against it): Does anyone know why it was decided to >> document external to source files rather than inline? >> >> When rapidly digging through source, it would be much more helpful to >> see parameter docs than to either have to find source lines (that can >> easily be missed) to figure out the intention. Case in point, I've >> been digging through cookiejar.py and request.py to figure out their >> interactions. When reading through build_opener, it took me a few >> minutes to figure out that each element of *handlers can be either an >> instance /or/ a class definition (I was looking at how to define a >> custom cookiejar for an HTTPCookieProcessor). Yes, I'm (now) aware >> that there's some documentation at the top of request.py, but it would >> have been helpful to have it right in the definition of build_opener. >> >> It seems like external docs is standard throughout the stdlib. Is >> there an actual reason for this? > > Have you seen the length of the documentation pages? Putting them > inline in the stdlib module would make the code much harder to skim > through. > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/demianbrecht%40gmail.com -- Demian Brecht http://demianbrecht.github.com ___ 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] [RELEASED] Python 2.7.5
Hi all, I just installed Python 2.7.5 64-bit () on a Windows 7 64-bit OS computer. When I evaluate sys.maxint I don't get what I was expected. I get this: Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)] on win32 Type "copyright", "credits" or "license()" for more information. >>> import sys >>> sys.maxint 2147483647 >>> import platform >>> platform.machine() 'AMD64' >>> import os >>> os.environ['PROCESSOR_ARCHITECTURE'] 'AMD64' >>> Should I not get a 64-bit integer maxint (9223372036854775807) for sys.maxint ? Or is there something I am missing here? Thanks! / Pierre Rouleau On Thu, May 16, 2013 at 6:23 AM, "Martin v. Löwis" wrote: > Am 16.05.13 10:42, schrieb Ben Hoyt: > > > FYI, I tried this just now with Python 2.7.4 running, and the > > installer nicely tells you that "some files that need to be updated > > are currently in use ... the following applications are using files, > > please close them and click Retry ... python.exe (Process Id: 5388)". > > > > So you can't do it while python.exe is running, but at least it > > notifies you and gives you the option to retry. Good work, whoever did > > this installer. > > This specific feature is part of the MSI technology itself, so the honor > goes to Microsoft in this case. They also have an advanced feature where > the installer can tell the running application to terminate, and then > restart after installation (since Vista, IIRC). Unfortunately, this > doesn't apply to Python, as a "safe restart" is typically not feasible. > > FWIW, I'm the one who put together the Python installer. > > 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/prouleau001%40gmail.com > -- /Pierre ___ 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] [RELEASED] Python 2.7.5
2013/5/19 Pierre Rouleau : > Hi all, > > I just installed Python 2.7.5 64-bit () on a Windows 7 64-bit OS computer. > When I evaluate sys.maxint I don't get what I was expected. I get this: > > Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)] on > win32 > Type "copyright", "credits" or "license()" for more information. import sys sys.maxint > 2147483647 import platform platform.machine() > 'AMD64' import os os.environ['PROCESSOR_ARCHITECTURE'] > 'AMD64' > > > Should I not get a 64-bit integer maxint (9223372036854775807) for > sys.maxint ? This is correct. sizeof(long) != sizeof(void *) on Win64, and size Python int's are platform longs, you get the maxsize of a 32-bit int. Check sys.maxsize for comparison. -- 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] Purpose of Doctests [Was: Best practices for Enum]
On Sun, May 19, 2013 at 1:13 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 05/19/2013 10:48 AM, Guido van Rossum wrote: >> Anyway, if you're doing arithmetic on enums you're doing it wrong. > > Hmm, bitwise operations, even? I think it's rather pointless to do bitwise operations on python enums. We're not that close to the machine. MarkJ Tacoma, Washington ___ 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] [RELEASED] Python 2.7.5
OK thanks, Benjamin, you are correct sys.maxsize is 2*63-1 on it. I was under the impression that Python was using int_64_t for the implementation of Win64 based integers. Most probably because I've sen discussion on Python 64 bits and those post were most probably were in the scope of some Unix-type platform. Regards, On Sun, May 19, 2013 at 6:56 PM, Benjamin Peterson wrote: > 2013/5/19 Pierre Rouleau : > > Hi all, > > > > I just installed Python 2.7.5 64-bit () on a Windows 7 64-bit OS > computer. > > When I evaluate sys.maxint I don't get what I was expected. I get this: > > > > Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit > (AMD64)] on > > win32 > > Type "copyright", "credits" or "license()" for more information. > import sys > sys.maxint > > 2147483647 > import platform > platform.machine() > > 'AMD64' > import os > os.environ['PROCESSOR_ARCHITECTURE'] > > 'AMD64' > > > > > > > Should I not get a 64-bit integer maxint (9223372036854775807) for > > sys.maxint ? > > This is correct. sizeof(long) != sizeof(void *) on Win64, and size > Python int's are platform longs, you get the maxsize of a 32-bit int. > Check sys.maxsize for comparison. > > > > -- > Regards, > Benjamin > -- /Pierre ___ 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] Purpose of Doctests [Was: Best practices for Enum]
On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger < [email protected]> wrote: > > On May 14, 2013, at 9:39 AM, Gregory P. Smith wrote: > > Bad: doctests. > > > I'm hoping that core developers don't get caught-up in the "doctests are > bad meme". > So long as doctests insist on comparing the repr of things being the number one practice that people use when writing them there is no other position I can hold on the matter. reprs are not stable and never have been. ordering changes, hashes change, ids change, pointer values change, wording and presentation of things change. none of those side effect behaviors were ever part of the public API to be depended on. That one can write doctests that don't depend on such things as the repr doesn't ultimately matter because the easiest thing to do, as encouraged by examples that are pasted from an interactive interpreter session into docs, is to have the interactive interpreter show the repr and not add code to check things in a accurate-for-testing manner that would otherwise make the documentation harder for a human to read. Instead, we should be clear about their primary purpose which is to test > the examples given in docstrings. In many cases, there is a great deal > of benefit to docstrings that have worked-out examples (see the docstrings > in the decimal module for example). In such cases it is also worthwhile > to make sure those examples continue to match reality. Doctests are > a vehicle for such assurance. In other words, doctests have a perfectly > legitimate use case. > I really do applaud the goal of keeping examples in documentation up to date. But doctest as it is today is the wrong approach to that. A repr mismatch does not mean the example is out of date. We should continue to encourage users to make thorough unit tests > and to leave doctests for documentation. That said, it should be > recognized that some testing is better than no testing. And doctests > may be attractive in that regard because it is almost effortless to > cut-and-paste a snippet from the interactive prompt. That isn't a > best practice, but it isn't a worst practice either. > Not quite, they at least tested something (yay!) but it is uncomfortably close to a worst practice. It means someone else needs to come understand the body of code containing this doctest when they make an unrelated change that triggered a behavior change as a side effect that the doctested code may or may not actually depend on but does not actually declare its intent one way or another for the purposes of being a readable example rather than accurate test. bikeshed colors: If doctest were never called a test but instead were called docchecker to not imply any testing aspect that might've helped (too late? the cat's out of the bag). Or if it never compared anything but simply ran the example code to generate and update the doc examples from the statements with the current actual results of execution instead of doing string comparisons... (ie: more of an documentation example "keep up to date" tool) Another meme that I hope dispel is the notion that the core developers > are free to break user code (such as doctests) if they believe the > users aren't coding in accordance with best practices. Our goal is to > improve their lives with our modifications, not to make their lives > more difficult. > Educating users how to apply best practices and making that easier for them every step of the way is a primary goal. Occasionally we'll have to do something annoying in the process but we do try to limit that. In my earlier message I suggested that someone improve doctest to not do dumb string comparisons of reprs. I still think that is a good goal if doctest is going to continue to be promoted. It would help alleviate many of the issues with doctests and bring them more in line with the issues many people's regular unittests have. As Tres already showed in an example, individual doctest using projects jump through hoops to do some of that today; centralizing saner repr comparisons for less false failures as an actual doctest feature just makes sense. Successful example: We added a bunch of new comparison methods to unittest in 2.7 that make it much easier to write tests that don't depend on implementation details such as ordering. Many users prefer to use those new features; even with older Python's via unittest2 on pypi. It doesn't mean users always write good tests, but a higher percentage of tests written are more future proof than they were before because it became easier. Currently, we face an adoption problem with Python 3. At PyCon, > an audience of nearly 2500 people said they had tried Python 3 > but weren't planning to convert to it in production code. All of the > coredevs are working to make Python 3 more attractive than Python 2, > but we also have to be careful to not introduce obstacles to conversion. > Breaking tests makes it much harder to convert (especia
Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]
2013/5/19 Gregory P. Smith : > Idea: I don't believe anybody has written a fixer for lib2to3 that applies > fixers to doctests. That'd be an interesting project for someone. 2to3 can operate on doctests, though it doesn't do anything different to them than it does to normal sourcecode. -- 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] [RELEASED] Python 2.7.5
On that topic of bitness for 64-bit platforms, would it not be better for CPython to be written such that it uses the same 64-bit strategy on all 64-bit platforms, regardless of the OS? As it is now, Python running on 64-bit Windows behaves differently (in terms of bits for the Python's integer) than it is behaving in other platforms. I assume that the Python C code is using the type 'long' instead of something like the C99 int64_t. Since Microsoft is using the LLP64 model and everyone else is using the LP64, code using the C 'long' type would mean something different on Windows than Unix-like platforms. Isn't that unfortunate? Would it not be better to hide the difference at Python level? Or is it done this way to allow existing C extension modules to work the way they were and request Python code that depends on integer sizes to check sys.maxint? Also, I would imagine that the performance delta between a Windows 32-bit Python versus 64-bit Python is not as big as it would be on a Unix computer. As far as I can se Python-64 bits on Windows 64-bit OS has a larger address space and probably does not benefit from anything else. Has anyone have data on this? Thanks -- /Pierre ___ 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] [RELEASED] Python 2.7.5
On Sun, 19 May 2013 19:37:46 -0400 Pierre Rouleau wrote: > On that topic of bitness for 64-bit platforms, would it not be better for > CPython to be written such that it uses the same 64-bit strategy on all > 64-bit platforms, regardless of the OS? > > As it is now, Python running on 64-bit Windows behaves differently (in > terms of bits for the Python's integer) than it is behaving in other > platforms. I assume that the Python C code is using the type 'long' > instead of something like the C99 int64_t. Since Microsoft is using the > LLP64 model and everyone else is using the LP64, code using the C 'long' > type would mean something different on Windows than Unix-like platforms. > Isn't that unfortunate? Well, it's Microsoft's choice. But from a Python point of view, which C type a Python int maps to is of little relevance. Moreover, the development version is 3.4, and in Python 3 the int type is a variable-length integer type (sys.maxint doesn't exist anymore). So this discussion is largely moot now. Regards Antoine. ___ 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] [RELEASED] Python 2.7.5
On Sun, May 19, 2013 at 7:41 PM, Antoine Pitrou wrote: > On Sun, 19 May 2013 19:37:46 -0400 > Pierre Rouleau wrote: > > > On that topic of bitness for 64-bit platforms, would it not be better for > > CPython to be written such that it uses the same 64-bit strategy on all > > 64-bit platforms, regardless of the OS? > > > > As it is now, Python running on 64-bit Windows behaves differently (in > > terms of bits for the Python's integer) than it is behaving in other > > platforms. I assume that the Python C code is using the type 'long' > > instead of something like the C99 int64_t. Since Microsoft is using the > > LLP64 model and everyone else is using the LP64, code using the C 'long' > > type would mean something different on Windows than Unix-like platforms. > > Isn't that unfortunate? > > Well, it's Microsoft's choice. But from a Python point of view, which C > type a Python int maps to is of little relevance. > Fair > > Moreover, the development version is 3.4, and in Python 3 the int > type is a variable-length integer type (sys.maxint doesn't exist > anymore). So this discussion is largely moot now. > > Good to know. Too bad there still are libraries not supporting Python 3. Thanks. > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/prouleau001%40gmail.com > -- /Pierre ___ 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] Why is documentation not inline?
On 20 May 2013 08:51, "Demian Brecht" wrote: > > @benjamin: Ah, i see. I wasn't around pre-Sphinx. However, unless > there's some custom build steps that I'm unaware of that may prevent > it, it should still be relatively easy to maintain the desired > narrative structure as long as the inline API docs are kept terse. That's what docstrings are for - abbreviated docs for use when reading the code and at the interactive prompt. The prose docs are designed to be a more discursive introduction to the full details of each operation, whereas docstrings are usually written more to provide someone that already knows what the function does with a reminder of the details. Cheers, Nick. > > @antoine: Sorry, I may not have been clear. I wasn't advocating the > inclusion of the /entire/ doc pages inline. I'm advocating terse > documentation for the stdlib APIs and parameters. Narrative > documentation can (and should be) maintained externally, but could use > autodoc to include the terse references when desired. This would > ensure that the same docs are available (and consistent) when reading > the documentation as well as when neck-deep in code. > > On Sun, May 19, 2013 at 3:32 PM, Antoine Pitrou wrote: > > On Sun, 19 May 2013 15:29:37 -0700 > > Demian Brecht wrote: > >> This is more out of curiosity than to spark change (although I > >> wouldn't argue against it): Does anyone know why it was decided to > >> document external to source files rather than inline? > >> > >> When rapidly digging through source, it would be much more helpful to > >> see parameter docs than to either have to find source lines (that can > >> easily be missed) to figure out the intention. Case in point, I've > >> been digging through cookiejar.py and request.py to figure out their > >> interactions. When reading through build_opener, it took me a few > >> minutes to figure out that each element of *handlers can be either an > >> instance /or/ a class definition (I was looking at how to define a > >> custom cookiejar for an HTTPCookieProcessor). Yes, I'm (now) aware > >> that there's some documentation at the top of request.py, but it would > >> have been helpful to have it right in the definition of build_opener. > >> > >> It seems like external docs is standard throughout the stdlib. Is > >> there an actual reason for this? > > > > Have you seen the length of the documentation pages? Putting them > > inline in the stdlib module would make the code much harder to skim > > through. > > > > Regards > > > > Antoine. > > > > > > ___ > > Python-Dev mailing list > > [email protected] > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: http://mail.python.org/mailman/options/python-dev/demianbrecht%40gmail.com > > > > -- > Demian Brecht > http://demianbrecht.github.com > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ 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] Purpose of Doctests [Was: Best practices for Enum]
On May 19, 2013 4:31 PM, "Benjamin Peterson" wrote: > > 2013/5/19 Gregory P. Smith : > > Idea: I don't believe anybody has written a fixer for lib2to3 that applies > > fixers to doctests. That'd be an interesting project for someone. > > 2to3 can operate on doctests, though it doesn't do anything different > to them than it does to normal sourcecode. > Oh cool. I didn't realize that already existed! > > -- > 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] [RELEASED] Python 2.7.5
On 20/05/2013 12:47am, Pierre Rouleau wrote: Moreover, the development version is 3.4, and in Python 3 the int type is a variable-length integer type (sys.maxint doesn't exist anymore). So this discussion is largely moot now. Good to know. Too bad there still are libraries not supporting Python 3. Thanks. Even in Python 2, if the result of arithmetic on ints which would overflow, the result automatically gets promoted to a long integer which is variable-length. >>> 2**128 340282366920938463463374607431768211456L >>> type(2), type(2**128) (, ) So the size of an int is pretty much irrelevant. -- Richard ___ 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] Purpose of Doctests [Was: Best practices for Enum]
On 5/19/2013 7:22 PM, Mark Janssen wrote: On Sun, May 19, 2013 at 1:13 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2013 10:48 AM, Guido van Rossum wrote: Anyway, if you're doing arithmetic on enums you're doing it wrong. Hmm, bitwise operations, even? I think it's rather pointless to do bitwise operations on python enums. We're not that close to the machine. It makes sense if the enums represent bit-oriented values that will be used close to the machine. Python is used in many disciplines. --Ned. MarkJ Tacoma, Washington ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ned%40nedbatchelder.com ___ 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] Purpose of Doctests [Was: Best practices for Enum]
On Sun, 19 May 2013 20:04:03 -0400 Ned Batchelder wrote: > On 5/19/2013 7:22 PM, Mark Janssen wrote: > > On Sun, May 19, 2013 at 1:13 PM, Tres Seaver wrote: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> On 05/19/2013 10:48 AM, Guido van Rossum wrote: > >>> Anyway, if you're doing arithmetic on enums you're doing it wrong. > >> Hmm, bitwise operations, even? > > I think it's rather pointless to do bitwise operations on python > > enums. We're not that close to the machine. > > It makes sense if the enums represent bit-oriented values that will be > used close to the machine. Python is used in many disciplines. Then it's up to the library writer to not use enums in that case. (assuming the performance of bitwise operations is critical here, which I doubt) Regards Antoine. ___ 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] Purpose of Doctests [Was: Best practices for Enum]
On Mon, May 20, 2013 at 10:14 AM, Antoine Pitrou wrote: > On Sun, 19 May 2013 20:04:03 -0400 > Ned Batchelder wrote: >> On 5/19/2013 7:22 PM, Mark Janssen wrote: >> > On Sun, May 19, 2013 at 1:13 PM, Tres Seaver wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> >> Hash: SHA1 >> >> >> >> On 05/19/2013 10:48 AM, Guido van Rossum wrote: >> >>> Anyway, if you're doing arithmetic on enums you're doing it wrong. >> >> Hmm, bitwise operations, even? >> > I think it's rather pointless to do bitwise operations on python >> > enums. We're not that close to the machine. >> >> It makes sense if the enums represent bit-oriented values that will be >> used close to the machine. Python is used in many disciplines. > > Then it's up to the library writer to not use enums in that case. > (assuming the performance of bitwise operations is critical here, which > I doubt) This is the point I was trying to make: once you use IntEnum (as you would in any case where you need bitwise operators), Enum gets out of the way for everything other than __str__, __repr__, and one other slot (that escapes me for the moment...). The metaclass does extra work at definition time so there shouldn't be any runtime overhead - the slots should be inherited directly from the non-Enum parent. 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] Purpose of Doctests [Was: Best practices for Enum]
[Raymond Hettinger] > I'm hoping that core developers don't get caught-up in the "doctests are bad > meme". > > Instead, we should be clear about their primary purpose which is to test > the examples given in docstrings. I disagree. > In many cases, there is a great deal of benefit to docstrings that have > worked-out examples (see the docstrings in the decimal module for > example). In such cases it is also worthwhile to make sure those examples > continue to match reality. Doctests are a vehicle for such assurance. That's representative of how doctest was developed: to help me in keeping some well-defined mathematical functions working as intended. It still excels in that particular area (a few examples to illustrate normal cases, and a few more to illustrate well-defined end and error cases - and that's all there _is_ to be tested). > In other words, doctests have a perfectly legitimate use case. But more than just one ;-) Another great use has nothing to do with docstrings: using an entire file as "a doctest". This encourages writing lots of text explaining what you're doing,. with snippets of code interspersed to illustrate that the code really does behave in the ways you've claimed. > We should continue to encourage users to make thorough unit tests > and to leave doctests for documentation. I'd rather encourage users to turn their brains on when writing doctest files - and when writing unit tests. I've lost count of how many times I've seen a unit test fail, then stared helplessly at the unit test code just trying to figure out what the author thought they were doing. A lot of comments in the test code could have helped that, but - outside of doctest-based tests - there's typically very little explanatory text in testing code. picking-your-poison-ly y'rs - tim ___ 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] Why is documentation not inline?
@nick: Yes, I realize what docstrings are for (I should have used that term rather than "inline" docs, my bad there :)). I think the problem that I've run into is simply inconsistencies in methods of documenting code (and the few times that it would have been helpful, what I was looking at had not been authored using docstrings). Is the usage of docstrings a requirement (or a strong suggestion) for new commits (I didn't see anything while reading the submission guidelines)? If not, would it perhaps be a worthy addition? On Sun, May 19, 2013 at 4:51 PM, Nick Coghlan wrote: > > On 20 May 2013 08:51, "Demian Brecht" wrote: >> >> @benjamin: Ah, i see. I wasn't around pre-Sphinx. However, unless >> there's some custom build steps that I'm unaware of that may prevent >> it, it should still be relatively easy to maintain the desired >> narrative structure as long as the inline API docs are kept terse. > > That's what docstrings are for - abbreviated docs for use when reading the > code and at the interactive prompt. > > The prose docs are designed to be a more discursive introduction to the full > details of each operation, whereas docstrings are usually written more to > provide someone that already knows what the function does with a reminder of > the details. > > Cheers, > Nick. > >> >> @antoine: Sorry, I may not have been clear. I wasn't advocating the >> inclusion of the /entire/ doc pages inline. I'm advocating terse >> documentation for the stdlib APIs and parameters. Narrative >> documentation can (and should be) maintained externally, but could use >> autodoc to include the terse references when desired. This would >> ensure that the same docs are available (and consistent) when reading >> the documentation as well as when neck-deep in code. >> >> On Sun, May 19, 2013 at 3:32 PM, Antoine Pitrou >> wrote: >> > On Sun, 19 May 2013 15:29:37 -0700 >> > Demian Brecht wrote: >> >> This is more out of curiosity than to spark change (although I >> >> wouldn't argue against it): Does anyone know why it was decided to >> >> document external to source files rather than inline? >> >> >> >> When rapidly digging through source, it would be much more helpful to >> >> see parameter docs than to either have to find source lines (that can >> >> easily be missed) to figure out the intention. Case in point, I've >> >> been digging through cookiejar.py and request.py to figure out their >> >> interactions. When reading through build_opener, it took me a few >> >> minutes to figure out that each element of *handlers can be either an >> >> instance /or/ a class definition (I was looking at how to define a >> >> custom cookiejar for an HTTPCookieProcessor). Yes, I'm (now) aware >> >> that there's some documentation at the top of request.py, but it would >> >> have been helpful to have it right in the definition of build_opener. >> >> >> >> It seems like external docs is standard throughout the stdlib. Is >> >> there an actual reason for this? >> > >> > Have you seen the length of the documentation pages? Putting them >> > inline in the stdlib module would make the code much harder to skim >> > through. >> > >> > Regards >> > >> > Antoine. >> > >> > >> > ___ >> > Python-Dev mailing list >> > [email protected] >> > http://mail.python.org/mailman/listinfo/python-dev >> > Unsubscribe: >> > http://mail.python.org/mailman/options/python-dev/demianbrecht%40gmail.com >> >> >> >> -- >> Demian Brecht >> http://demianbrecht.github.com >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com -- Demian Brecht http://demianbrecht.github.com ___ 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] Ordering keyword dicts
Joao S. O. Bueno wrote: Actually, when I was thinking on the subject I came to the same idea, of having some functions marked differently so they would use a different call mechanism - but them I wondered around having a different opcode for the ordered-dict calls. Would that be feasible? No, because the callee is the only one that knows whether it requires its keyword args to be ordered. In fact, not even the callee might know at the time of the call. Consider a function that takes **kwds and passes them on to another function that requires ordered keywords. -- Greg ___ 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] What if we didn't have repr?
On Sun, May 19, 2013 at 4:27 PM, Gregory P. Smith wrote: > Now you've got me wondering what Python would be like if repr, `` and > __repr__ never existed as language features. Upon first thoughts, I actually > don't see much downside (no, i'm not advocating making that change). > Something to ponder. I have pondered it many times, although usually in the form "Why do we need both str and repr?" Unfortunately I always come back to the same issue: I really want print() of a string to write just the characters of the string (without quotes), but I also really want the >>> prompt to write the string with quotes (and escapes). Moreover, these are just two examples of the different use cases -- repr() is more useful whenever you are writing a value for a debugging purpose (e.g. when logging), and str() is more useful when writing a value as "output" of a program. One could argume that the only type for which it makes sense to distinguish between the two is str itself -- indeed I rarely define different __repr__ and __str__ functions for new classes I create (but I do note that PEP 435 does define them differently for enum members). But for the str type, it's pretty important to have str(s) equal to s, and it's also pretty important to have a way to produce a string literal from a string value. And it would be annoying if we only had str()/__str__() as a general protocol and repr() was just a string method -- imagine the number of times people would be calling s.repr() in order to have unambiguous debug output only to get a traceback because s is None or some other non-str object... So it looks like we really need both str(x) and repr(x). But maybe we only need the __repr__ protocol? str(x) could just special-case its own type, and use repr(x) (or x.__repr__(), which is the same) in all other cases. The __repr__() method on the string type would do just what it does today. But there would not be a __str__() protocol at all. That would reduce some confusion and make the language spec a tiny bit smaller, and it might stop people from proposing/requesting that str() of a list should return something different than its repr(). It also would make it a little harder for some classes (like enums) to do something nicer when printed. But IIRC there are almost no builtin types that use this feature. Personally I think that "Color.red" still looks like debug output, intended for the developer of the program, not for its user. If I wanted to show a Color to an end user of my program, I'd be printing x.name anyway. And for debugging, "Color.red" suits me fine as well -- it even fulfills the (always informal!) rule of thumb that the repr() of an object should resemble an expression that has that object as a value better than the repr() currently defined in the PEP. After all, if I really wanted to know what was inside, I could always print x.value... Please don't see this as a proposal to change the language. Like Greg, I'm not advocating, just pondering. (With the exception that if I was allowed to use the time machine to go back a couple of weeks, I'd adjust PEP 435 to define str(x) as x.name, e.g. "red", and repr(x) as what is currently defined as str(x), e.g. "Color.red".) -- --Guido van Rossum (python.org/~guido) ___ 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] Purpose of Doctests [Was: Best practices for Enum]
On 20/05/13 09:27, Gregory P. Smith wrote: On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger < [email protected]> wrote: On May 14, 2013, at 9:39 AM, Gregory P. Smith wrote: Bad: doctests. I'm hoping that core developers don't get caught-up in the "doctests are bad meme". So long as doctests insist on comparing the repr of things being the number one practice that people use when writing them there is no other position I can hold on the matter. reprs are not stable and never have been. I think this *massively* exaggerates the "problem" with doc tests. I make heavy use of them, and have no problem writing doc tests that work in code running over multiple versions, including from 2.4 through 3.3. Objects that I write myself, I control the repr and can make it as stable as I wish. Many built-in types also have stable reprs. The repr for small ints is not going to change, the repr for floats like 0.5, 0.25, 0.125 etc. are stable and predictable, lists and tuples and strings all have stable well-defined reprs. Dicts are a conspicuous counter-example, but there are trivial work-arounds. Doc tests are not limited to a simple-minded "compare the object's repr". You can write as much, or as little, scaffolding around the test as you need. If the scaffolding becomes too large, that's a sign that the test doesn't belong in documentation and should be moved out, perhaps into a unit test, or perhaps into a separate "literate testing" document that can be as big as necessary without overwhelming the doc string. ordering changes, hashes change, ids change, pointer values change, wording and presentation of things change. none of those side effect behaviors were ever part of the public API to be depended on. Then don't write doctests that depend on those things. It really is that simple. There's no rule that says doctests have to test the entire API. Doctests in docstrings are *documentation first*, so you write tests that make good documentation. The fact that things that are not stable parts of the API can be tested is independent of the framework you use to do the testing. If I, as an ignorant and foolish developer, wrote a unit test like this: class MyDumbTest(unittest.TestCase): def testSpamRepr(self): x = Spam(arg) self.assertEquals(repr(x), "") we shouldn't conclude that "unit tests are bad", but that MyDumbTest is bad and needs to be fixed. Perhaps the fix is to re-write the test to care less about the exact repr. (Doctest's ellipsis directive is excellent for that.) Perhaps the fix is to give the Spam object a stable repr that doesn't suck. Or perhaps the fix is to just say, this doesn't need to be a test at all. (And doctest has a directive for that too.) They are all good solutions to the "problem" of unit testing things that aren't part of the API, and they are also good solutions to the same problem when it comes to doctests. [...] I really do applaud the goal of keeping examples in documentation up to date. But doctest as it is today is the wrong approach to that. A repr mismatch does not mean the example is out of date. No, it means that either the test was buggy, or the test has failed. I must admit that I don't understand what you think happens with doc testing in practice. You give the impression that there are masses of doc tests being written that look like this: x = Spam(arg) print(x) and therefore the use of doc tests are bad because it leads to broken tests. But I don't understand why you think that nobody has noticed that this test will have failed right from the start, and will have fixed it immediately. I suppose it is possible that some people write doc tests but never run them, not even once, but that's no different from those who write unit tests but never run them. They're hardly representative of the average developer, who either doesn't write tests at all, or who both writes and runs them and will notice if they fail. [...] In my earlier message I suggested that someone improve doctest to not do dumb string comparisons of reprs. I still think that is a good goal if doctest is going to continue to be promoted. It would help alleviate many of the issues with doctests and bring them more in line with the issues many people's regular unittests have. As Tres already showed in an example, individual doctest using projects jump through hoops to do some of that today; centralizing saner repr comparisons for less false failures as an actual doctest feature just makes sense. If a test needs to jump through hoops to work, then it doesn't belong as a test in the doc string. It should be a unit test, or possibly a separate test file that can be as big and complicated as needed. If you want to keep it as an example, but not actually run it, doctest has a skip directive. There's no need to complicate doctest by making it "smarter" (and therefore more likely to be buggy, harder to use, or both).
Re: [Python-Dev] Why is documentation not inline?
On Mon, May 20, 2013 at 11:19 AM, Demian Brecht wrote: > @nick: Yes, I realize what docstrings are for (I should have used that > term rather than "inline" docs, my bad there :)). I think the problem > that I've run into is simply inconsistencies in methods of documenting > code (and the few times that it would have been helpful, what I was > looking at had not been authored using docstrings). > > Is the usage of docstrings a requirement (or a strong suggestion) for > new commits (I didn't see anything while reading the submission > guidelines)? If not, would it perhaps be a worthy addition? It's already covered by PEP 8 : http://www.python.org/dev/peps/pep-0008/#documentation-strings (and yes, reviewers should be checking for that in new patches and commits) 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] What if we didn't have repr?
On Mon, May 20, 2013 at 11:46 AM, Guido van Rossum wrote: > On Sun, May 19, 2013 at 4:27 PM, Gregory P. Smith wrote: >> Now you've got me wondering what Python would be like if repr, `` and >> __repr__ never existed as language features. Upon first thoughts, I actually >> don't see much downside (no, i'm not advocating making that change). >> Something to ponder. > > I have pondered it many times, although usually in the form "Why do we > need both str and repr?" > So it looks like we really need both str(x) and repr(x). But maybe we > only need the __repr__ protocol? str(x) could just special-case its > own type, and use repr(x) (or x.__repr__(), which is the same) in all > other cases. The __repr__() method on the string type would do just > what it does today. But there would not be a __str__() protocol at > all. In my own code, I tend to map "__repr__" to either object identity (the classic "" format) or object reconstruction (the not-quite-as-classic-but-still-popular "ClassName(constructor_args)" format). I then tend to use "__str__" to emit something that matches any equivalence classes defined through "__eq__". This way of thinking about it does correlate with the "for developers" and "for end user" distinction, but without needing to think about it in those terms. However, even that approach has its limitations, and I offer the existence of both the pprint module and the "__format__" protocol as evidence, along with the multitude of context specific conversion and escaping functions. In many respects, conversion of arbitrary objects to context-appropriate strings is a signature use case for single dispatch generic functions. 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] Purpose of Doctests [Was: Best practices for Enum]
Gregory P. Smith writes: > I really do applaud the goal of keeping examples in documentation up to > date. But doctest as it is today is the wrong approach to that. A repr > mismatch does not mean the example is out of date. Of course it does. The user sees something in the doc that's different from what his interpreter tells him. That may not bother a long-time user of the module, or one who hangs out on python-commits (uh-huh, uh-huh, yeah, right), but it worries new ones, and it should. "What else may have changed?" is what they should be thinking. Also, there are many cases where the output of a function is defined by some external protocol: XML, JSON, RFC , etc. Here doctests are very valuable. There are lots of testing applications where doctests suck. There are lots of testing applications where doctests are pretty much the optimal balance between ease of creation and ease of maintenance. I wouldn't be surprised if there are applications (RAD?) where *creating* tests as doctests and *converting* to a more precisely-specified framework in maintenance is best practice. Maybe somebody (not me, I do far too little testing even with doctests :-( ) should write an informational PEP. ___ 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] Purpose of Doctests [Was: Best practices for Enum]
On 05/19/2013 05:24 PM, Nick Coghlan wrote: This is the point I was trying to make: once you use IntEnum (as you would in any case where you need bitwise operators), Enum gets out of the way for everything other than __str__, __repr__, and one other slot (that escapes me for the moment...). __getnewargs__ and __new__ But if you do math, the result is no longer an Enum of any type. -- ~Ethan~ ___ 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] Purpose of Doctests [Was: Best practices for Enum]
On Mon, May 20, 2013 at 1:51 AM, Gregory P. Smith wrote: > > On May 19, 2013 4:31 PM, "Benjamin Peterson" wrote: >> >> 2013/5/19 Gregory P. Smith : >> > Idea: I don't believe anybody has written a fixer for lib2to3 that >> > applies >> > fixers to doctests. That'd be an interesting project for someone. >> >> 2to3 can operate on doctests, though it doesn't do anything different >> to them than it does to normal sourcecode. > > Oh cool. I didn't realize that already existed! It won't change any output, though, which still means that they tend to break. ___ 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
