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

2013-06-26 Thread Oleg Broytman 
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  > >:
> > > And then I ran "make distclean"...
> > 
> > You've left us hanging...
> > 
> > 
> > Yeah, the final part is here: http://bz.selenic.com/show_bug.cgi?id=3954#c4
> > But still I have question as why hg complained about @README in the
> > first place.
> > Also, I hope make distclean is not working "inside" .hg folder.
> 
> 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' \
>  -o -name '*.bak' ')' \
>  -exec rm -f {} ';'
> 
> Will find files beginning with '@' inside subdirectories of $(srcdir)/.hg.
> 
> Just this week I saw someone use the logical equivalent of:
> 
> find $(srcdir)/* ...
> 
> to avoid this problem. It won't expand the .hg top-level directory.

   Or find \( -type d -name .hg -prune \) -o ...

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/[email protected]
   Programmers don't die, they just GOSUB without RETURN.
___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-26 Thread a . cavallo 
.. 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.


___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-26 Thread Eric V. Smith 
On 6/26/2013 6:43 AM, [email protected] 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 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 .svn, .git,
etc. Maybe find $(srcdir)/[a-zA-Z]* ... would be good enough to ignore
all dot directories/files?

-- 
Eric.
___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-26 Thread Eric V. Smith 
On 6/26/2013 8:18 AM, Eric V. Smith wrote:
> On 6/26/2013 6:43 AM, [email protected] 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 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 .svn, .git,
> etc. Maybe find $(srcdir)/[a-zA-Z]* ... would be good enough to ignore
> all dot directories/files?
> 

Sorry for the mis-attribution. "Yours" refers to Oleg.

-- 
Eric.
___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-26 Thread Oleg Broytman 
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 .svn, .git,

   How many of those dot-files/directories are there beside .*ignore?

> etc. Maybe find $(srcdir)/[a-zA-Z]* ... would be good enough to ignore
> all dot directories/files?

   On the other hand yes, I think it'd be enough.

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/[email protected]
   Programmers don't die, they just GOSUB without RETURN.
___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-26 Thread Ronald Oussoren 

On 26 Jun, 2013, at 14:18, Eric V. Smith  wrote:

> On 6/26/2013 6:43 AM, [email protected] 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 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 .svn, .git,
> etc. Maybe find $(srcdir)/[a-zA-Z]* ... would be good enough to ignore
> all dot directories/files?

Is the find command in the distclean target still needed? The comment for the 
distclean target says it is used to clean up the tree for distribution, but 
that's easier to accomplish by using a clean checkout.

The target is still useful to get a clean tree when you're building with srcdir 
== builddir, but you don't need the find command for that.

Ronald

___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-26 Thread Eric V. Smith 
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. Yours is more obvious, but we'd likely need to add .svn, .git,
> 
>How many of those dot-files/directories are there beside .*ignore?

That's all I can think of. And the files don't matter in this case,
anyway. So probably just .svn, .hg, .git is all we'd need.

>> etc. Maybe find $(srcdir)/[a-zA-Z]* ... would be good enough to ignore
>> all dot directories/files?
> 
>On the other hand yes, I think it'd be enough.

I can go either way.

-- 
Eric.
___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-26 Thread Eric V. Smith 
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, [email protected] 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 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 .svn, .git,
>> etc. Maybe find $(srcdir)/[a-zA-Z]* ... would be good enough to ignore
>> all dot directories/files?
> 
> Is the find command in the distclean target still needed? The comment for the 
> distclean target says it is used to clean up the tree for distribution, but 
> that's easier to accomplish by using a clean checkout.
> 
> The target is still useful to get a clean tree when you're building with 
> srcdir == builddir, but you don't need the find command for that.

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).

But me running distclean is not the same as answering your question
about the find command being needed, I realize.

-- 
Eric.
___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-26 Thread a . cavallo 



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
[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] End of the mystery "@README.txt Mercurial bug"

2013-06-26 Thread Antoine Pitrou 
Le Wed, 26 Jun 2013 15:12:45 +0200,
[email protected] 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 removes only what we want to remove, while hg purge will
remove any untracked file, including any files that you may have wanted
to keep (notes, work-in-progress patches, personal data files, etc.).

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] End of the mystery "@README.txt Mercurial bug"

2013-06-26 Thread Zachary Ware 
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 helps

I've recently discovered purge and have started using it on Windows
since there is no `make distclean`, and it is very effective.  `hg
purge -p` shows what will be removed (which should match anything with
a ? in `hg status`), `hg purge` removes it, and `hg purge --all`
clears out everything that's not tracked (including things listed in
.hgignore) giving a fresh checkout without having to re-download.
Very convenient, especially since it's a built-in extension.
___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-26 Thread Barry Warsaw 
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 think it still makes sense for us to include a working distclean,
especially since it's a very common target for make-based builds.

-Barry

___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-26 Thread Ronald Oussoren 

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, a clean checkout won't help
>> (easily, at least).
> 
> As do I.  I think it still makes sense for us to include a working distclean,
> especially since it's a very common target for make-based builds.

Sure, but is it necessary to run the find command for removing backup files in 
make distclean?

When the find command is removed you'd still end up with a tree that's clean 
enough to perform a build from scratch, although the tree won't be perfectly 
clean. 

BTW. I usually build in a separate directory, that makes cleaning up even 
easier :-)

Ronald
> 
> -Barry
> 
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.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] End of the mystery "@README.txt Mercurial bug"

2013-06-26 Thread R. David Murray 
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 modified files, a clean checkout won't help
> >(easily, at least).
> 
> As do I.  I think it still makes sense for us to include a working distclean,
> especially since it's a very common target for make-based builds.

We also sometimes ask someone reporting an issue to do a make distclean
and recompile, and many of these reporters will be working from a tarball
rather than a checkout.  Sure, they could re-unpack the tarball (if they
haven't deleted it already), but make distclean is easier.

--David
___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-26 Thread Victor Stinner 
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' \
>-o -name '*.bak' ')' \
>-exec rm -f {} ';'
>
> Will find files beginning with '@' inside subdirectories of $(srcdir)/.hg.

In my opinion, make distclean should only remove files generated by
configure and a build. It should not remove random files.

*~, .orig, .rej, .back should be kept. They are not generated by
configure nor make.

What are these "@*", ",*" and "#*" files? Why does "make distclean" remove them?

"make distclean" removes also the "tags" file which is generated by
the ctags program, useful tool to browse the C source code (ex: in
vim). Why does "make distclean" remove it?

In short, the whole "find ... -exec rm -f {} ';'" command should be
removed from "make distclean". (They are other commands to remove
Makefile, "*.o" files, etc.) If someone really need such cleanup,
another Makefile rule should be added.

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-06-26 Thread a . cavallo 

*~, .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 that generated files (like the one generated from pgen) 
shouldn't be part of defaul make target but keept as fully tracked files 
(and regenerated on demand through a special make target).


I hope this helps.



___
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] Relative path in co_filename for zipped modules

2013-06-26 Thread Vitaly Murashev 
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 you problems).
>
> --David
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-06-26 Thread R. David Murray 
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/060718.html
>  
>  Subsequent efforts to revive the PEP in April 2009 did not
>  meet with success because no syntax emerged that could
> -compete with a while-True and an inner if-break.
> +compete with the following form:
>  
> -A syntax was found for a basic do-while loop but it found
> -had little support because the condition was at the top:
> +while True:
> +
> +if not :
> +break
> +
>  
> -do ... while :
> -
> +Users of the language are advised to use that form when a do-while
> +loop would have been appropriate.

Why delete the information about what was found wanting?

--David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-06-26 Thread Łukasz Langa 
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
>> http://mail.python.org/pipermail/python-dev/2006-February/060718.html
>> 
>> Subsequent efforts to revive the PEP in April 2009 did not
>> meet with success because no syntax emerged that could
>> -compete with a while-True and an inner if-break.
>> +compete with the following form:
>> 
>> -A syntax was found for a basic do-while loop but it found
>> -had little support because the condition was at the top:
>> +while True:
>> +
>> +if not :
>> +break
>> +
>> 
>> -do ... while :
>> -
>> +Users of the language are advised to use that form when a do-while
>> +loop would have been appropriate.
> 
> Why delete the information about what was found wanting?

This was a mention of an alternative possible syntax. I don't feel it was worth 
keeping this particular one while not discussing any other alternatives at all. 
If you'd rather keep this information, it would be better off to have it to an 
"Alternative approaches" section.

-- 
Best regards,
Łukasz Langa

WWW: http://lukasz.langa.pl/
Twitter: @llanga
IRC: ambv on #python-dev

___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-26 Thread Stephen J. Turnbull 
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 directory that are normally
##  created by building the program.  Don't delete the files that
##  record the configuration.  Also preserve files that could be
##  made by building, but normally aren't because the distribution
##  comes with them.
##  Delete `.dvi' files here if they are not part of the
##  distribution.

## make distclean
##  Delete all files from the current directory that are created by
##  configuring or building the program.  If you have unpacked the
##  source and built the program without creating any other files,
##  `make distclean' should leave only the files that were in the
##  distribution.

## make realclean
##  Delete everything from the current directory that can be
##  reconstructed with this Makefile.  This typically includes
##  everything deleted by distclean, plus more: C source files
##  produced by Bison, tags tables, info files, and so on.

## make extraclean
##  Still more severe - delete backup and autosave files, too.

This is from the XEmacs Makefile.in.in, so it's not authoritative.
Still, it seems pretty intuitive and presumably is in wide use, not to
forget matching Victor's preferred usage for 'distclean'.

___
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] PyArg_ParseTupe(): parse unsigned integer and check for overflow

2013-06-26 Thread Victor Stinner 
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 module on
64-bit system:
http://bugs.python.org/issue18294

How should I implement that? Use "O" format and then use
PyLong_Check(), PyLong_AsLong(), and check value <= UINT_MAX?

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-06-26 Thread Guido van Rossum 
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 think this is really old DNA. It comes from times when 0x
and -1 were equivalent -- we borrowed this cavalier attitude from old
C code.

I worry that "fixing" this would break some old libraries relying on
the feature, so I hope we can avoid changes in this area (the older
the DNA, the more hidden dependencies it has ;-).

> I would to parse an integer in [0; UINT_MAX] to fix the zlib module on
> 64-bit system:
> http://bugs.python.org/issue18294
>
> How should I implement that? Use "O" format and then use
> PyLong_Check(), PyLong_AsLong(), and check value <= UINT_MAX?

Why can't you use the K format? It won't reject out-of-range values,
but it will convert them to in-range so there aren't any attacks
possible based on bypassing the range check. I'm probably
misunderstanding something -- I don't completely understand that bug
report. :-(

-- 
--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] [Python-checkins] peps: Reject PEP 315.

2013-06-26 Thread Nick Coghlan 
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 <
[email protected]> 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/060718.html
>>>
>>> Subsequent efforts to revive the PEP in April 2009 did not
>>> meet with success because no syntax emerged that could
>>> -compete with a while-True and an inner if-break.
>>> +compete with the following form:
>>>
>>> -A syntax was found for a basic do-while loop but it found
>>> -had little support because the condition was at the top:
>>> +while True:
>>> +
>>> +if not :
>>> +break
>>> +
>>>
>>> -do ... while :
>>> -
>>> +Users of the language are advised to use that form when a do-while
>>> +loop would have been appropriate.
>>
>>
>> Why delete the information about what was found wanting?
>
>
> This was a mention of an alternative possible syntax. I don't feel it was
worth keeping this particular one while not discussing any other
alternatives at all. If you'd rather keep this information, it would be
better off to have it to an "Alternative approaches" section.

It was relevant because it was the most acceptable alternative found, and
we *still* didn't think it was an improvement over the status quo.

We don't generally significantly edit PEPs when accepting or rejecting them.

Cheers,
Nick.

>
> --
> Best regards,
> Łukasz Langa
>
> WWW: http://lukasz.langa.pl/
> Twitter: @llanga
> IRC: ambv on #python-dev
>
>
> ___
> 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] End of the mystery "@README.txt Mercurial bug"

2013-06-26 Thread Eric V. Smith 
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 \( -type d -name .hg -prune \) -o ...
>>>
>>> I'm torn. Yours is more obvious, but we'd likely need to add .svn, .git,
>>
>>How many of those dot-files/directories are there beside .*ignore?
> 
> That's all I can think of. And the files don't matter in this case,
> anyway. So probably just .svn, .hg, .git is all we'd need.
> 
>>> etc. Maybe find $(srcdir)/[a-zA-Z]* ... would be good enough to ignore
>>> all dot directories/files?
>>
>>On the other hand yes, I think it'd be enough.
> 
> I can go either way.
> 

I created http://bugs.python.org/issue18312 to track this.

-- 
Eric.
___
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] Reminder: an oft-forgotten rule about docstring formatting (PEP 257)

2013-06-26 Thread Guido van Rossum 
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 on one line and is separated from the
rest of the docstring by a blank line. [...]
"""

I still like this rule, but it is violated frequently, in the stdlib
and elsewhere. I'd like to urge stdlib contributors and core devs to
heed it -- or explain why you can't.

-- 
--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] Reminder: an oft-forgotten rule about docstring formatting (PEP 257)

2013-06-26 Thread Skip Montanaro 
> 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 don't
bother with the blank line either.  (If I'm going to punch a hole in a
rule, I might as well create one big enough to comfortably walk
through.)

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] Reminder: an oft-forgotten rule about docstring formatting (PEP 257)

2013-06-26 Thread Ethan Furman 

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 rule is going to be violated, I go whole hog and don't
bother with the blank line either.  (If I'm going to punch a hole in a
rule, I might as well create one big enough to comfortably walk
through.)


Why do the parameters have to be in the summary?  You could do them better 
justice in the following paragraphs.

--
~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] Reminder: an oft-forgotten rule about docstring formatting (PEP 257)

2013-06-26 Thread Ben Finney 
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 the parameters in there if they don't fit
naturally in the sentence fragment.

A list of the parameters and return value can go in the detailed
description.

-- 
 \   “Theology is the effort to explain the unknowable in terms of |
  `\ the not worth knowing.” —Henry L. Mencken |
_o__)  |
Ben Finney

___
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] Classes with ordered namespaces

2013-06-26 Thread Eric Snow 
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 change would make it
unnecessary to write a custom metaclass just for a __prepare__().  PEP
422 alleviates that problem somewhat.  However, I expect OrderedDict
is by far the most common type returned by __prepare__(), so having it
be the default would proportionately reduce the need for people to
write metaclasses or learn about the PEP 422 API.  You may ask what is
the point if they aren't using a metaclass.  That leads to the other
half of the proposal.

Once I have a class, I'd like to know the definition order without
needing a metaclass.  Unfortunately it's not as simple as using the C
OrderedDict (issue16991 again) for tp_dict, etc.  That change is
actually pretty trivial.  However, it causes problems because the
concrete C API (PyDict_*) doesn't play nice with subclasses and the
concrete API is used on class __dict__ all over the place.  The
alternative I propose is to add __definition_order__ or similar to
classes.  It would be a list of the names from the definition
namespace, in definition order (making use of the new default there).
Having a class's __dict__ be ordered isn't important if the definition
order is available somewhere.  Again, using the C OrderedDict, the
change to add __definition_order__ is pretty trivial.

FWIW, Guido already expressed some approval[1].

-eric


[1] http://mail.python.org/pipermail/python-ideas/2013-February/019704.html
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com