Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

On Tue, Jun 25, 2013 at 10:11:04PM -0400, "Eric V. Smith" wrote: > On 6/25/2013 9:33 PM, Senthil Kumaran wrote: > > > > > > > > On Tue, Jun 25, 2013 at 5:58 PM, Benjamin Peterson > > wrote: > > > > 2013/6/25 Victor Stinner >

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

.. or having hg "purging" unwanted build artifact (probably cleaning up the .hgignore file first) find $(srcdir)/* ... to avoid this problem. It won't expand the .hg top-level directory. Or find \( -type d -name .hg -prune \) -o ... Oleg. __

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

On 6/26/2013 6:43 AM, a.cava...@cavallinux.eu wrote: > .. or having hg "purging" unwanted build artifact (probably cleaning up > the .hgignore file first) How would that work? How could hg purge the .bak, .orig, .rej, .old, etc. files? >>> find $(srcdir)/* ... >>> >>> to avoid this problem. It wo

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

On 6/26/2013 8:18 AM, Eric V. Smith wrote: > On 6/26/2013 6:43 AM, a.cava...@cavallinux.eu wrote: >> .. or having hg "purging" unwanted build artifact (probably cleaning up >> the .hgignore file first) > > How would that work? How could hg purge the .bak, .orig, .rej, .old, > etc. files? > f

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

On Wed, Jun 26, 2013 at 08:18:27AM -0400, "Eric V. Smith" wrote: > >>> find $(srcdir)/* ... > >>> > >>> to avoid this problem. It won't expand the .hg top-level directory. > >> > >>Or find \( -type d -name .hg -prune \) -o ... > > I'm torn. Yours is more obvious, but we'd likely need to add

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

On 26 Jun, 2013, at 14:18, Eric V. Smith wrote: > On 6/26/2013 6:43 AM, a.cava...@cavallinux.eu wrote: >> .. or having hg "purging" unwanted build artifact (probably cleaning up >> the .hgignore file first) > > How would that work? How could hg purge the .bak, .orig, .rej, .old, > etc. files? >

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

On 6/26/2013 8:44 AM, Oleg Broytman wrote: > On Wed, Jun 26, 2013 at 08:18:27AM -0400, "Eric V. Smith" > wrote: > find $(srcdir)/* ... > > to avoid this problem. It won't expand the .hg top-level directory. Or find \( -type d -name .hg -prune \) -o ... >> >> I'm torn. You

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

On 6/26/2013 8:57 AM, Ronald Oussoren wrote: > > On 26 Jun, 2013, at 14:18, Eric V. Smith wrote: > >> On 6/26/2013 6:43 AM, a.cava...@cavallinux.eu wrote: >>> .. or having hg "purging" unwanted build artifact (probably cleaning up >>> the .hgignore file first) >> >> How would that work? How coul

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

How would that work? How could hg purge the .bak, .orig, .rej, .old, etc. files? hg purge (it's an extension) removes anything that isn't tracked (and not ignored in the .hgignore): kind of distclean. I hope this helps ___ Python-Dev mailing list

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

Le Wed, 26 Jun 2013 15:12:45 +0200, a.cava...@cavallinux.eu a écrit : > > > How would that work? How could hg purge the .bak, .orig, .rej, .old, > > etc. files? > > hg purge (it's an extension) removes anything that isn't tracked (and > not ignored in the .hgignore): kind of distclean. distclea

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

On Wed, Jun 26, 2013 at 8:12 AM, wrote: >Eric V. Smith wrote: >> How would that work? How could hg purge the .bak, .orig, .rej, .old, >> etc. files? > > > hg purge (it's an extension) removes anything that isn't tracked (and not > ignored in the .hgignore): kind of distclean. > > I hope this help

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

On Jun 26, 2013, at 09:04 AM, Eric V. Smith wrote: >I run 'make distclean' fairly often, but maybe it's just out of habit. >If I'm adding/deleting modules, I want to make sure there are no build >artifacts. And since I have modified files, a clean checkout won't help >(easily, at least). As do I.

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

On 26 Jun, 2013, at 15:39, Barry Warsaw wrote: > On Jun 26, 2013, at 09:04 AM, Eric V. Smith wrote: > >> I run 'make distclean' fairly often, but maybe it's just out of habit. >> If I'm adding/deleting modules, I want to make sure there are no build >> artifacts. And since I have modified files

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

On Wed, 26 Jun 2013 09:39:54 -0400, Barry Warsaw wrote: > On Jun 26, 2013, at 09:04 AM, Eric V. Smith wrote: > > >I run 'make distclean' fairly often, but maybe it's just out of habit. > >If I'm adding/deleting modules, I want to make sure there are no build > >artifacts. And since I have modifie

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

2013/6/26 Eric V. Smith : > I think that's exactly what's happening. > > From the bug report: > > find $(srcdir) '(' -name '*.fdc' -o -name '*~' \ >-o -name '[@,#]*' -o -name '*.old' \ >-o -name '*.orig' -o -name '*.rej' \ >

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

*~, .orig, .rej, .back should be kept. They are not generated by configure nor make. Ideally they should be left untracked not ignored. While devs can certainly add them to the .hgignore list to make life easier, a repository should be clean of extra files (or shown as untracked). I'd add t

Re: [Python-Dev] Relative path in co_filename for zipped modules

Reported as http://bugs.python.org/issue18307 On Wed, Jun 26, 2013 at 12:19 AM, R. David Murray wrote: > Please file this as a bug report on bugs.python.org so that it doesn't > get lost. > > See also http://bugs.python.org/issue13328 (which looks like a different bug > but could also be causing

Re: [Python-Dev] [Python-checkins] peps: Reject PEP 315.

On Wed, 26 Jun 2013 17:39:07 +0200, lukasz.langa wrote: > -Deferred; see > +Rejected; see > +http://mail.python.org/pipermail/python-ideas/2013-June/021610.html > + > +This PEP has been deferred since 2006; see > http://mail.python.org/pipermail/python-dev/2006-February/06071

Re: [Python-Dev] [Python-checkins] peps: Reject PEP 315.

On 26 cze 2013, at 18:18, R. David Murray wrote: > On Wed, 26 Jun 2013 17:39:07 +0200, lukasz.langa > wrote: >> -Deferred; see >> +Rejected; see >> +http://mail.python.org/pipermail/python-ideas/2013-June/021610.html >> + >> +This PEP has been deferred since 2006; see >> htt

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

Victor Stinner writes: > In my opinion, make distclean should only remove files generated by > configure and a build. It should not remove random files. FWIW, the GNU standard for these targets is something like: ## make clean or make mostlyclean ## Delete all files from the current dir

[Python-Dev] PyArg_ParseTupe(): parse unsigned integer and check for overflow

Hi, I don't understand why the B, H, I, k formats of PyArg_ParseTupe() do not check for overflow, whereas formats for signed numbers do check for overflow. What is the useful of ignoring overflow? http://docs.python.org/3/c-api/arg.html I would to parse an integer in [0; UINT_MAX] to fix the zlib

Re: [Python-Dev] PyArg_ParseTupe(): parse unsigned integer and check for overflow

On Wed, Jun 26, 2013 at 3:07 PM, Victor Stinner wrote: > I don't understand why the B, H, I, k formats of PyArg_ParseTupe() do > not check for overflow, whereas formats for signed numbers do check > for overflow. What is the useful of ignoring overflow? > http://docs.python.org/3/c-api/arg.html I

Re: [Python-Dev] [Python-checkins] peps: Reject PEP 315.

On 27 Jun 2013 03:12, "Łukasz Langa" wrote: > > On 26 cze 2013, at 18:18, R. David Murray wrote: > >> On Wed, 26 Jun 2013 17:39:07 +0200, lukasz.langa < python-check...@python.org> wrote: >>> >>> -Deferred; see >>> +Rejected; see >>> +http://mail.python.org/pipermail/python-ideas/2013

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

On 6/26/2013 9:02 AM, Eric V. Smith wrote: > On 6/26/2013 8:44 AM, Oleg Broytman wrote: >> On Wed, Jun 26, 2013 at 08:18:27AM -0400, "Eric V. Smith" >> wrote: >> find $(srcdir)/* ... >> >> to avoid this problem. It won't expand the .hg top-level directory. > >Or find \( -t

[Python-Dev] Reminder: an oft-forgotten rule about docstring formatting (PEP 257)

PEP 257 says this on the formatting of multi-line docstrings: """ Multi-line docstrings consist of a summary line just like a one-line docstring, followed by a blank line, followed by a more elaborate description. The summary line may be used by automatic indexing tools; it is important that it fi

Re: [Python-Dev] Reminder: an oft-forgotten rule about docstring formatting (PEP 257)

> I'd like to urge stdlib contributors and core devs to > heed it -- or explain why you can't. Where I can, I do, however I often find it difficult to come up with a one-liner, especially one that mentions the parameters to functions. If the one-line rule is going to be violated, I go whole hog an

Re: [Python-Dev] Reminder: an oft-forgotten rule about docstring formatting (PEP 257)

On 06/26/2013 07:08 PM, Skip Montanaro wrote: I'd like to urge stdlib contributors and core devs to heed it -- or explain why you can't. Where I can, I do, however I often find it difficult to come up with a one-liner, especially one that mentions the parameters to functions. If the one-line ru

Re: [Python-Dev] Reminder: an oft-forgotten rule about docstring formatting (PEP 257)

Skip Montanaro writes: > Where I can [conform to PEP 257], I do, however I often find it > difficult to come up with a one-liner, especially one that mentions > the parameters to functions. I think it's far better to make the synopsis a summary of the purpose of the function; no need to force th

[Python-Dev] Classes with ordered namespaces

There are two relevant class namespaces in this proposal: definition namespace and __dict__. Currently both are dicts. For class definition namespaces, I'd like to make the default an OrderedDict. With the implementation in issue16991, the change is trivial (basically 1-liners in 2 spots). This