On Tue, Jun 25, 2013 at 10:11:04PM -0400, Eric V. Smith e...@trueblade.com
wrote:
On 6/25/2013 9:33 PM, Senthil Kumaran wrote:
On Tue, Jun 25, 2013 at 5:58 PM, Benjamin Peterson benja...@python.org
mailto:benja...@python.org wrote:
2013/6/25 Victor Stinner
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?
find
On Wed, Jun 26, 2013 at 08:18:27AM -0400, Eric V. Smith e...@trueblade.com
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
On 26 Jun, 2013, at 14:18, Eric V. Smith e...@trueblade.com 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.
On 6/26/2013 8:44 AM, Oleg Broytman wrote:
On Wed, Jun 26, 2013 at 08:18:27AM -0400, Eric V. Smith
e...@trueblade.com 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
On 6/26/2013 8:57 AM, Ronald Oussoren wrote:
On 26 Jun, 2013, at 14:18, Eric V. Smith e...@trueblade.com 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
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
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.
distclean
On Wed, Jun 26, 2013 at 8:12 AM, a.cava...@cavallinux.eu 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
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. I
On 26 Jun, 2013, at 15:39, Barry Warsaw ba...@python.org 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
On Wed, 26 Jun 2013 09:39:54 -0400, Barry Warsaw ba...@python.org 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
2013/6/26 Eric V. Smith e...@trueblade.com:
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' \
*~, .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
Reported as http://bugs.python.org/issue18307
On Wed, Jun 26, 2013 at 12:19 AM, R. David Murray rdmur...@bitdance.com 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
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-June/021610.html
+
+This PEP has been deferred since 2006; see
On 26 cze 2013, at 18:18, R. David Murray rdmur...@bitdance.com 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-June/021610.html
+
+This PEP has been
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
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
On Wed, Jun 26, 2013 at 3:07 PM, Victor Stinner
victor.stin...@gmail.com 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?
On 27 Jun 2013 03:12, Łukasz Langa luk...@langa.pl wrote:
On 26 cze 2013, at 18:18, R. David Murray rdmur...@bitdance.com wrote:
On Wed, 26 Jun 2013 17:39:07 +0200, lukasz.langa
python-check...@python.org wrote:
-Deferred; see
+Rejected; see
+
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
e...@trueblade.com wrote:
find $(srcdir)/* ...
to avoid this problem. It won't expand the .hg top-level directory.
Or find \( -type d -name .hg
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 fits
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 and
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
Skip Montanaro s...@pobox.com 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
26 matches
Mail list logo
