Re: [Python-Dev] hard linking executables

[Neil Schemenauer]

Guido van Rossum  wrote:
> I ought to remember why because I remember I was involved. (And I have
> a feeling that the change Antoine dug up was just a refactoring,

You are correct.  I checked Python 1.5.2 and it also creates hard
links (prior to Makefile overhaul).

> The best I can come up with is that when it's a hard link, you can
> replace either "python" or "python2.1" with another version without
> disturbing the other.

So, I don't think anyone has a good argument for the status quo.  A
symlink would make more sense to me.

  Neil

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hard linking executables

[Ben Finney]

Dan Stromberg  writes:

> On Wed, Jul 27, 2011 at 2:37 PM, Ben Finney wrote:
>
> > Dan Stromberg  writes:
> >
> > > It's been suggested that […] if people had added symlinks first,
> > > no one would've bothered adding hardlinks.
> >
> > Well, that suggestion is faulty. It ignores the fact that *all*
> > ordinary files on Unix are hard links. Any ordinary file entry in a
> > directory is a hard link to the file's data.
>
> Not really. Whether hard links is supported is mostly a matter of what
> filesystem you are using - in modern times. It's true that filesystems
> with complete POSIX semantics probably all support hardlinks, but
> that's far from every file on any given *ix. And of course, POSIX
> doesn't appear to have been created until the late 1990's.

POSIX didn't create those semantics, though; it formalised semantics
that were already long-time convention.

My only point was that, unlike symbolic links, hard linking isn't some
added feature, it's a property of the way Unix filesystems represent
normal files. And you're right that I mean “on filesystems with POSIX
semantics”.

> It's much easier to imagine a system with no hardlinks, than to
> imagine a system with no symlinks.

Why imagine? There have been many of both.

-- 
 \“But it is permissible to make a judgment after you have |
  `\examined the evidence. In some circles it is even encouraged.” |
_o__)—Carl Sagan, _The Burden of Skepticism_, 1987 |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)

[Benjamin Peterson]

2011/7/27 Guido van Rossum :
> On Wed, Jul 27, 2011 at 6:00 PM, Nick Coghlan  wrote:
>> On Thu, Jul 28, 2011 at 9:38 AM, Guido van Rossum  wrote:
 Users of codecs.open() or users of codecs.Stream* classes?
>>>
>>> I would think both. Is there any reason to continue using codecs.open()?
>>
>> It's the easiest way to write Unicode friendly code that spans both 2.x and 
>> 3.x.
>
> Even on 2.6, where the io module exists?

io on 2.6 is fairly broken and dead slow. The advantage of codecs.open
is it hasn't changed in the very long time. It still has the same
reliable buggy behavior no matter what version you're on.

I don't see the problem with leaving codecs.open() to rot a few more
releases before deprecating it while leaving messaging in the docs
suggesting io.*.

>
>> The problem is that naive 2.x code will migrate to the optimised IO
>> stack automatically on the 2.x -> 3.x transition, while code that
>> tried to do the right thing has to be changed manually (either in 3.x
>> only, or by switching to the io module for 2.x as well) in order to
>> adjust for the differences in argument order.
>>
>> The idea behind changing codecs.open to be a wrapper around io.open
>> was to allow such code to switch to the new optimised IO stack as
>> easily as code that just uses the open builtin. If it's acceptable for
>> the builtin behaviour to change (far more substantially), why not
>> change codecs.open as well?
>
> Aren't the cases different? Using built-in open() just means you want
> to open a file in the default way. Using codecs.open() presumably
> means that you've thought about Unicode.
>
> TBH, I said I was only -0 on the PEP, and if the stream returned by
> codecs.open() in 3.3 is sufficiently compatible with the stream
> returned the same function returns in 3.2, I am okay with it. (Except
> I also want you to cut a trillion dollars from the non-military
> budget, without raising taxes. :-)

May I suggest you include the military budget? :)



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Eli Bendersky]

On Thu, Jul 28, 2011 at 02:53, Steven D'Aprano  wrote:

> Eli Bendersky wrote:
>
>  Sure, but I'm still leery of two functions with the same name doing acting
>> slightly differently.
>>
>
>
> and then in a later post:
>
>
>  As I mentioned elsewhere, it's not good practice to have two functions
>> with
>> the same name doing something slightly different, in different modules in
>> the code-base.
>>
>
> artist.draw() and gunslinger.draw() do not necessarily need to do the same
> thing,
>

Of course, but why do you ignore the "slightly different". Had
support.rmtree been something completely different from shutil.rmtree, I
wouldn't have a problem with it. But it just calls rmtree and ignores some
errors. This is the part I have the problem with.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hard linking executables

[Dan Stromberg]

On Wed, Jul 27, 2011 at 2:37 PM, Ben Finney wrote:

> Dan Stromberg  writes:
>
> > It's been suggested that *ix has hardlinks because someone thought up
> > hardlinks before someone thought up symlinks - IOW, there are those who
> > suggest that if people had added symlinks first, no one would've bothered
> > adding hardlinks.
>
> Well, that suggestion is faulty. It ignores the fact that *all* ordinary
> files on Unix are hard links. Any ordinary file entry in a directory is
> a hard link to the file's data.
>

Not really.  Whether hard links is supported is mostly a matter of what
filesystem you are using - in modern times.  It's true that filesystems with
complete POSIX semantics probably all support hardlinks, but that's far from
every file on any given *ix.  And of course, POSIX doesn't appear to have
been created until the late 1990's.


> The “hard links” capability, therefore, isn't something that was added;
> it's fundamental to Unix filesystems from their inception.
>

Hard linking was reportedly in Unix Version 1, but I see nothing indicating
it was in the original Unics of 1969.  Then again, I don't see much of
anything on the net about what was and wasn't in Unics.


> The ‘ln’ command adds *additional* hard links to an existing file's
> data; but, once added, they're exactly the same as any other ordinary
> file entry.
>

Well, if you're in a filesystem that supports hardlinking anyway.
Supporting that isn't inherent.  It requires some sort of on-disk
representation for persistence, and not all filesystems support that.


> > Symlinks are almost always more flexible, and almost always more
> > clear.
>
> Yet many tools don't work as expected with symbolic links which will
> work with an ordinary file (a “hard link”). One can argue that such
> tools are to that extent buggy, but symbolic links produce deliberately
> different behaviour which is sometimes not what one needs.
>

Please recall that I was paraphrasing someone saying that hardlinks were
seldom better, not never better.  I don't know that there's anything in your
post that addresses that.

It's much easier to imagine a system with no hardlinks, than to imagine a
system with no symlinks.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)

[Guido van Rossum]

On Wed, Jul 27, 2011 at 6:00 PM, Nick Coghlan  wrote:
> On Thu, Jul 28, 2011 at 9:38 AM, Guido van Rossum  wrote:
>>> Users of codecs.open() or users of codecs.Stream* classes?
>>
>> I would think both. Is there any reason to continue using codecs.open()?
>
> It's the easiest way to write Unicode friendly code that spans both 2.x and 
> 3.x.

Even on 2.6, where the io module exists?

> The problem is that naive 2.x code will migrate to the optimised IO
> stack automatically on the 2.x -> 3.x transition, while code that
> tried to do the right thing has to be changed manually (either in 3.x
> only, or by switching to the io module for 2.x as well) in order to
> adjust for the differences in argument order.
>
> The idea behind changing codecs.open to be a wrapper around io.open
> was to allow such code to switch to the new optimised IO stack as
> easily as code that just uses the open builtin. If it's acceptable for
> the builtin behaviour to change (far more substantially), why not
> change codecs.open as well?

Aren't the cases different? Using built-in open() just means you want
to open a file in the default way. Using codecs.open() presumably
means that you've thought about Unicode.

TBH, I said I was only -0 on the PEP, and if the stream returned by
codecs.open() in 3.3 is sufficiently compatible with the stream
returned the same function returns in 3.2, I am okay with it. (Except
I also want you to cut a trillion dollars from the non-military
budget, without raising taxes. :-)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)

[Nick Coghlan]

On Thu, Jul 28, 2011 at 9:38 AM, Guido van Rossum  wrote:
>> Users of codecs.open() or users of codecs.Stream* classes?
>
> I would think both. Is there any reason to continue using codecs.open()?

It's the easiest way to write Unicode friendly code that spans both 2.x and 3.x.

The problem is that naive 2.x code will migrate to the optimised IO
stack automatically on the 2.x -> 3.x transition, while code that
tried to do the right thing has to be changed manually (either in 3.x
only, or by switching to the io module for 2.x as well) in order to
adjust for the differences in argument order.

The idea behind changing codecs.open to be a wrapper around io.open
was to allow such code to switch to the new optimised IO stack as
easily as code that just uses the open builtin. If it's acceptable for
the builtin behaviour to change (far more substantially), why not
change codecs.open as well?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Steven D'Aprano]

Eli Bendersky wrote:


Sure, but I'm still leery of two functions with the same name doing acting
slightly differently.



and then in a later post:


As I mentioned elsewhere, it's not good practice to have two functions with
the same name doing something slightly different, in different modules in
the code-base.


artist.draw() and gunslinger.draw() do not necessarily need to do the 
same thing, and I don't agree that a (futile) preference for globally 
unique names is good practice: it can lead to unnecessarily long names 
(artist.draw_with_pencil_on_paper) or redundant characters prefixing the 
name (itertools.imap -- what does the "i" in imap tell you that the 
itertools didn't already?). Solving this problem is what namespaces are for.


Renaming test.support.ulink to something else doesn't fix the problem of 
unsupported support functions being used in third-party code. It may 
even *encourage* it, by making the extra functionality more explicit.


However, is there any reason why test.support itself shouldn't be 
renamed test._support, or possibly _test.support, so that the *entire* 
suite is marked as a private implementation detail?




--
Steven

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)

[Guido van Rossum]

On Wed, Jul 27, 2011 at 4:11 PM, Victor Stinner
 wrote:
> Le 28/07/2011 00:36, Guido van Rossum a écrit :
>>
>> Sorry Victor, I somehow didn't see that message even though I received
>> it (I probably thought it was a continuation of the python-dev thread
>> which I've been ignoring).
>
> No problem.
>
>> no, there's no particular hurry
>
> That's why it's a deprecation process and the removal is schedule for later:
> "3.4 (or maybe later)". I added "or maybe later" before reopening a new
> thread on this list.

That still sounds fairly aggressive.

>> no, I don't think you should change codecs.open() to call io.open()
>
> The PEP is useless without this change. If we don't deprecate any class and
> don't change codecs.open(), it's better to just reject the PEP.

Why? (Not that I am against rejecting the PEP. I feel weakly opinioned
in this case, about -0.)

>> start deprecating them formally once we feel that most users have switched
>
> Users of codecs.open() or users of codecs.Stream* classes?

I would think both. Is there any reason to continue using codecs.open()?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)

[Victor Stinner]

Le 28/07/2011 00:36, Guido van Rossum a écrit :

Sorry Victor, I somehow didn't see that message even though I received
it (I probably thought it was a continuation of the python-dev thread
which I've been ignoring).


No problem.


no, there's no particular hurry


That's why it's a deprecation process and the removal is schedule for 
later: "3.4 (or maybe later)". I added "or maybe later" before reopening 
a new thread on this list.



no, I don't think you should change codecs.open() to call io.open()


The PEP is useless without this change. If we don't deprecate any class 
and don't change codecs.open(), it's better to just reject the PEP.



start deprecating them formally once we feel that most users have switched


Users of codecs.open() or users of codecs.Stream* classes?

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

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Nick Coghlan]

On Thu, Jul 28, 2011 at 3:27 AM, Brett Cannon  wrote:
> On Wed, Jul 27, 2011 at 06:36, R. David Murray 
> wrote:
>> Perhaps what we could do is move the documentation for test.support to
>> the devguide, and then vet the test suite so that unlink and friends
>> are always called as 'support.unlink', etc.
>
> I like this solution since this issue of documenting test.support keeps
> coming up. Otherwise we can not document test.support, but  then we need to
> do a pass through the module to make sure  that the docstrings are properly
> updated and we start deprecating some of the stuff in there that is just
> pure cruft.

+1 for relocating this to the devguide. The only reason this is in the
main docs now is that it used to be the only way to easily get pretty
documentation for it.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)

[Guido van Rossum]

On Wed, Jul 27, 2011 at 2:53 PM, Victor Stinner
 wrote:
> Hi,
>
> Three weeks ago, I posted a draft on my PEP on this mailing list. I tried to
> include all remarks you made, and the PEP is now online:
>
>   http://www.python.org/dev/peps/pep-0400/
>
> It's now unclear to me if the PEP will be accepted or rejected. I don't know
> what to do to move forward. I asked Guido in private, but I didn't get any
> answer.
>
> Victor

Sorry Victor, I somehow didn't see that message even though I received
it (I probably thought it was a continuation of the python-dev thread
which I've been ignoring).

Unfortunately I don't have time to go back and read the whole thread.
I think I haven't used codecs.StreamReader/Writer myself, and I don't
think I've seen much use of them either (which doesn't mean there
isn't). My gut feeling is that yes, they should eventually go away,
but no, there's no particular hurry, and no, I don't think you should
change codecs.open() to call io.open().

I think the best thing is to campaign (e.g. in docs) for people to
stop using codecs.open/StreamReader/Writer and start deprecating them
formally once we feel that most users have switched. It's possible
that that could happen before 3.3 is released, but I'm kind of
doubtful about that myself.

Sorry again for missing your private emails!

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)

[Victor Stinner]

Hi,

Three weeks ago, I posted a draft on my PEP on this mailing list. I 
tried to include all remarks you made, and the PEP is now online:


   http://www.python.org/dev/peps/pep-0400/

It's now unclear to me if the PEP will be accepted or rejected. I don't 
know what to do to move forward.


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

[Python-Dev] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)

[Victor Stinner]

Hi,

Three weeks ago, I posted a draft on my PEP on this mailing list. I 
tried to include all remarks you made, and the PEP is now online:


   http://www.python.org/dev/peps/pep-0400/

It's now unclear to me if the PEP will be accepted or rejected. I don't 
know what to do to move forward. I asked Guido in private, but I didn't 
get any answer.


Victor

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hard linking executables

[Ben Finney]

Dan Stromberg  writes:

> It's been suggested that *ix has hardlinks because someone thought up
> hardlinks before someone thought up symlinks - IOW, there are those who
> suggest that if people had added symlinks first, no one would've bothered
> adding hardlinks.

Well, that suggestion is faulty. It ignores the fact that *all* ordinary
files on Unix are hard links. Any ordinary file entry in a directory is
a hard link to the file's data.

The “hard links” capability, therefore, isn't something that was added;
it's fundamental to Unix filesystems from their inception.

The ‘ln’ command adds *additional* hard links to an existing file's
data; but, once added, they're exactly the same as any other ordinary
file entry.

> Symlinks are almost always more flexible, and almost always more
> clear.

Yet many tools don't work as expected with symbolic links which will
work with an ordinary file (a “hard link”). One can argue that such
tools are to that extent buggy, but symbolic links produce deliberately
different behaviour which is sometimes not what one needs.

-- 
 \ “Wrinkles should merely indicate where smiles have been.” —Mark |
  `\Twain, _Following the Equator_ |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (2.7): - Issue #12603: Fix pydoc.synopsis() on files with non-negative st_mtime.

[Charles-François Natali]

>> +- Issue #12603: Fix pydoc.synopsis() on files with non-negative
>> st_mtime.
>> +
>
> Surely you mean non-positive? Non-negative st_mtime being the common
> case.

Of course (st_mtime <= 0).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (2.7): - Issue #12603: Fix pydoc.synopsis() on files with non-negative st_mtime.

[Antoine Pitrou]

On Wed, 27 Jul 2011 19:36:36 +0200
charles-francois.natali  wrote:
>  
> +- Issue #12603: Fix pydoc.synopsis() on files with non-negative st_mtime.
> +

Surely you mean non-positive? Non-negative st_mtime being the common
case.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Antoine Pitrou]

On Wed, 27 Jul 2011 10:27:16 -0700
Brett Cannon  wrote:
> >
> > Perhaps what we could do is move the documentation for test.support to
> > the devguide, and then vet the test suite so that unlink and friends
> > are always called as 'support.unlink', etc.
> >
> 
> I like this solution since this issue of documenting test.support keeps
> coming up. Otherwise we can not document test.support, but  then we need to
> do a pass through the module to make sure  that the docstrings are properly
> updated and we start deprecating some of the stuff in there that is just
> pure cruft.

We don't need to deprecate that cruft, we can just remove it (and all
uses of it, of course).

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hard linking executables

[Guido van Rossum]

On Tue, Jul 26, 2011 at 3:32 PM, Barry Warsaw  wrote:
> On Jul 27, 2011, at 12:19 AM, Antoine Pitrou wrote:
>
>>Ok, apparently the decision to make hard links for executables dates at
>>least back to:
>
> That still doesn't explain *why* hardlinks were originally chosen instead of
> symlinks.  In the absence of any other compelling argument against it, I think
> they should all consistently be symlinks.  I don't see any Ubuntu or Debian
> (where /usr/bin/python3 -> python3.2) bug reports indicating any problems, and
> I haven't experienced any issues with it personally.

I ought to remember why because I remember I was involved. (And I have
a feeling that the change Antoine dug up was just a refactoring,
moving an existing hard-link target to a different file. Because in my
memory the hard link was my idea and I implemented it. But that change
is Neil Schemenauer's.)

But I can't. :-(

The best I can come up with is that when it's a hard link, you can
replace either "python" or "python2.1" with another version without
disturbing the other. And I think it has something to do with
altinstall vs. install. So it would mean that after first installing
2.1 (so python and python2.1 are the same file), and then
alt-installing 2.1.1, the original 2.1 binary is still accessible as
"python". But I don't know why you'd want that.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hard linking executables

[Dan Stromberg]

It's been suggested that *ix has hardlinks because someone thought up
hardlinks before someone thought up symlinks - IOW, there are those who
suggest that if people had added symlinks first, no one would've bothered
adding hardlinks.

Symlinks are almost always more flexible, and almost always more clear.

The main counterexample seems to be rsync-based backup systems, that will
hardlink identical files of a given pathname.  But that seems to be a bit of
a mess when it comes time to transfer such a backup from one filesystem to
another.

On Tue, Jul 26, 2011 at 3:32 PM, Barry Warsaw  wrote:

> On Jul 27, 2011, at 12:19 AM, Antoine Pitrou wrote:
>
> >Ok, apparently the decision to make hard links for executables dates at
> >least back to:
>
> That still doesn't explain *why* hardlinks were originally chosen instead
> of
> symlinks.  In the absence of any other compelling argument against it, I
> think
> they should all consistently be symlinks.  I don't see any Ubuntu or Debian
> (where /usr/bin/python3 -> python3.2) bug reports indicating any problems,
> and
> I haven't experienced any issues with it personally.
>
> >changeset:   16221:588691f806f4
> >branch:  legacy-trunk
> >user:Neil Schemenauer 
> >date:Wed Jan 24 17:11:43 2001 +
> >files:   Makefile.pre.in
> >description:
> >Flat makefile based on toplevel Makefile.in and makefiles in build
> >subdirectories.  Those other makefiles will go away eventually.
> >
> >[...]
> >
> >+# Install the interpreter (by creating a hard link to python$(VERSION))
> >+bininstall:altbininstall
> >+   -if test -f $(BINDIR)/$(PYTHON); \
> >+   then rm -f $(BINDIR)/$(PYTHON); \
> >+   else true; \
> >+   fi
> >+   (cd $(BINDIR); $(LN) python$(VERSION)$(EXEEXT) python$(EXEEXT))
> >+
>
> -Barry
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/drsalists%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Email-SIG] email-6.0.0.a1

[Barry Warsaw]

On Jul 19, 2011, at 05:21 PM, R. David Murray wrote:

>OK, so I've released the first iteration of the email6 package on pypi
>as email-6.0.0a1.  After install you import it as email6.  This will
>allow anyone curious and/or motivated to test it out under Python 3.2.
>I'm especially interested in anyone with a working program that uses
>email in 3.2: it should be completely backward compatible, and if it
>isn't I want to know ASAP.[*]

It'll take some time to digest, but congratulations RDM!  You've accomplished
an impressive milestone.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

[Barry Warsaw]

First off, kudos to PJE for his work on this PEP.  He really had the key
insight for this new approach, and did a great job of explaining his vision in
a clear way so that I think everybody over on import-sig "got it".

On Jul 20, 2011, at 08:57 AM, P.J. Eby wrote:

>At 06:46 PM 7/20/2011 +1000, Nick Coghlan wrote:
>>On Wed, Jul 20, 2011 at 1:58 PM, P.J. Eby  wrote:
>> > So, without further ado, here it is:
>>
>>I pushed this version up to the PEPs repo, so it now has a number
>>(402) and can be read in prettier HTML format:
>>http://www.python.org/dev/peps/pep-0402/
>
>Technically, shouldn't this be a 3XXX series PEP?  Or are we not doing those
>any more now that all PEPs would be 3XXX?

Great question.  I don't know if we want/need to make the distinction any
more.  It does feel a little odd putting Python 3 PEPs (the only kind of new
Standards Track PEPs) in the 0XXX numbers, but now that we're all moving to
Python 3 , it seems like segregating new PEPs to the 3XXX range is a bit
contrived.

I think filling up 0XXX is probably fine.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hard linking executables

[Barry Warsaw]

On Jul 27, 2011, at 12:19 AM, Antoine Pitrou wrote:

>Ok, apparently the decision to make hard links for executables dates at
>least back to:

That still doesn't explain *why* hardlinks were originally chosen instead of
symlinks.  In the absence of any other compelling argument against it, I think
they should all consistently be symlinks.  I don't see any Ubuntu or Debian
(where /usr/bin/python3 -> python3.2) bug reports indicating any problems, and
I haven't experienced any issues with it personally.

>changeset:   16221:588691f806f4
>branch:  legacy-trunk
>user:Neil Schemenauer 
>date:Wed Jan 24 17:11:43 2001 +
>files:   Makefile.pre.in
>description:
>Flat makefile based on toplevel Makefile.in and makefiles in build
>subdirectories.  Those other makefiles will go away eventually.
>
>[...]
>
>+# Install the interpreter (by creating a hard link to python$(VERSION))
>+bininstall:altbininstall
>+   -if test -f $(BINDIR)/$(PYTHON); \
>+   then rm -f $(BINDIR)/$(PYTHON); \
>+   else true; \
>+   fi
>+   (cd $(BINDIR); $(LN) python$(VERSION)$(EXEEXT) python$(EXEEXT))
>+

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Ethan Furman]

Eli Bendersky wrote:


I like this solution since this issue of documenting
test.support keeps
coming up. Otherwise we can not document test.support,


We already do.

25.6. test.support — Utility functions for tests
is about half of the page that also contains
25.5. test — Regression tests package for Python
The latter contains
25.5.1. Writing Unit Tests for the test package
which should also be moved to the dev guide if 25.6 is.


+1
 


That would leave 25.5 as a short page explaining what lib/test is
and how to run the tests, which is something user sometimes need to do.


Out of curiosity, why would a user need to run Python's tests?



Curiosity.  ;)

~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Terry Reedy]

On 7/27/2011 1:57 PM, Eli Bendersky wrote:


Out of curiosity, why would a user need to run Python's tests?


If one compiles Python, running the tests is essential.
Some people like to run a test suite to verify an installation.
Sometimes people have problems that might arise from an installation 
getting messed up.


Whatever is left of 25.5 in the public doc, I think *all* the info 
should be in the dev guide.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/27/2011 01:57 PM, Eli Bendersky wrote:

> Out of curiosity, why would a user need to run Python's tests?

A couple of cases occur to me:

- - To verify that they got a corrrect build with all expected modules
  included.

- - To test the build after updating an underlying system library.



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4wVB4ACgkQ+gerLs4ltQ5NSACfXg7QoZAFNHWehT81oPTUwzoo
+m4AnRMQFcGod1/3XxEk/T6CDVpE7i7c
=/VoI
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: fix doc typo for library/test.rst

[Eli Bendersky]

Actually I think this is no longer true.  import_fresh_module raises an
ImportError if *name* can't be imported, or returns None if the fresh module
is not found.

>
> Its use case is to enable or block accelerations for modules that
> optionally provide one.  All the modules that currently use
> import_fresh_module are (afaik) always available (json, warnings, heapq), so
> raising SkipTest when the module is missing is not useful now.
> It returns None in the case an acceleration is missing, so e.g. in "cjson =
> import_fresh_module('json', fresh=['_json'])" cjson will be None and it will
> be possible to do things like @skipUnless(cjson, 'requires _json').  Here
> raising an ImportError will defeat (part of) the purpose of the function,
> i.e. avoiding:
> try:
>  import _json
> except ImportError:
>  _json = None
>
> and raising a SkipTest when the accelerations are missing is not an option
> if there are other tests (e.g. the tests for the Python implementation).
>
> These changes come from 
> http://hg.python.org/cpython/**rev/c1a12a308c5b.
>   Before the change import_fresh_module was still returning the module
> (e.g. json) even when the acceleration (fresh=['_json']) was missing, and
> the C tests were run twice using the same pure-python module used for the Py
> ones.
>
> The typo and the wrong doc is also on 2.7.
>
>
Ezio, thanks. I opened issue 12645 to track this.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: fix doc typo for library/test.rst

[Ezio Melotti]

Hi,

On 27/07/2011 20.31, eli.bendersky wrote:

http://hg.python.org/cpython/rev/8989aa5b357c
changeset:   71532:8989aa5b357c
user:Eli Bendersky
date:Wed Jul 27 20:29:59 2011 +0300
summary:
   fix doc typo for library/test.rst

files:
   Doc/library/test.rst |  2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/Doc/library/test.rst b/Doc/library/test.rst
--- a/Doc/library/test.rst
+++ b/Doc/library/test.rst
@@ -447,7 +447,7 @@
 Module and package deprecation messages are suppressed during this import
 if *deprecated* is ``True``.

-   This function will raise :exc:`unittest.SkipTest` is the named module
+   This function will raise :exc:`unittest.SkipTest` if the named module


Actually I think this is no longer true.  import_fresh_module raises an 
ImportError if *name* can't be imported, or returns None if the fresh 
module is not found.


Its use case is to enable or block accelerations for modules that 
optionally provide one.  All the modules that currently use 
import_fresh_module are (afaik) always available (json, warnings, 
heapq), so raising SkipTest when the module is missing is not useful now.
It returns None in the case an acceleration is missing, so e.g. in 
"cjson = import_fresh_module('json', fresh=['_json'])" cjson will be 
None and it will be possible to do things like @skipUnless(cjson, 
'requires _json').  Here raising an ImportError will defeat (part of) 
the purpose of the function, i.e. avoiding:

try:
  import _json
except ImportError:
  _json = None

and raising a SkipTest when the accelerations are missing is not an 
option if there are other tests (e.g. the tests for the Python 
implementation).


These changes come from http://hg.python.org/cpython/rev/c1a12a308c5b .  
Before the change import_fresh_module was still returning the module 
(e.g. json) even when the acceleration (fresh=['_json']) was missing, 
and the C tests were run twice using the same pure-python module used 
for the Py ones.


The typo and the wrong doc is also on 2.7.

Best Regards,
Ezio Melotti


 cannot be imported.

 Example use::



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Eli Bendersky]

> I like this solution since this issue of documenting test.support keeps
>> coming up. Otherwise we can not document test.support,
>>
>
> We already do.
>
> 25.6. test.support — Utility functions for tests
> is about half of the page that also contains
> 25.5. test — Regression tests package for Python
> The latter contains
> 25.5.1. Writing Unit Tests for the test package
> which should also be moved to the dev guide if 25.6 is.
>
>
+1


> That would leave 25.5 as a short page explaining what lib/test is and how
> to run the tests, which is something user sometimes need to do.
>
>
Out of curiosity, why would a user need to run Python's tests?

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Terry Reedy]

On 7/27/2011 1:27 PM, Brett Cannon wrote:


Perhaps what we could do is move the documentation for test.support to
the devguide, and then vet the test suite so that unlink and friends
are always called as 'support.unlink', etc.


I like this solution since this issue of documenting test.support keeps
coming up. Otherwise we can not document test.support,


We already do.

25.6. test.support — Utility functions for tests
is about half of the page that also contains
25.5. test — Regression tests package for Python
The latter contains
25.5.1. Writing Unit Tests for the test package
which should also be moved to the dev guide if 25.6 is.

That would leave 25.5 as a short page explaining what lib/test is and 
how to run the tests, which is something user sometimes need to do.




but  then we need
to do a pass through the module to make sure  that the docstrings are
properly updated and we start deprecating some of the stuff in there
that is just  pure cruft.


I believe that is what Eli is doing and hence the suggestion to dump 
.rmtree. Agreed that missing doc strings should be 'updated' from ''.



--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Terry Reedy]

On 7/27/2011 9:24 AM, Antoine Pitrou wrote:


Docstrings are sufficient for own our purposes.


>>> import test.support as t
>>> help(t.rmtree)
Help on function rmtree in module test.support:

rmtree(path)

;-)

--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Eli Bendersky]

> ---
> Side note: test.support.import_fresh_**module typo. /is/if/ in
> "This function will raise unittest.SkipTest is the named module cannot be
> imported."
>

Fixed in 8989aa5b357c

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Eli Bendersky]

> Ezio, this is also a good idea, but currently I really think placing
>> this documentation in the devguide is probably the best approach. Now we
>> have a very nice Devguide, and this documentation simply belongs there,
>> and not in the user-visible portion of the official Python documentation.
>>
>
> You mean the dev guide only accessible online?


Yes. You can also pull it from http://hg.python.org/devguide/ for a local
copy (hg.python.org also allows to download a ZIP).

My point being - isn't the official Python documentation targeted at *users*
of Python, and wasn't the devguide specifically created for *developers* of
Python? If so, then test.support clearly being the domain of developers
rather than users, belongs in the devguide.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Brett Cannon]

On Wed, Jul 27, 2011 at 06:36, R. David Murray wrote:

> On Wed, 27 Jul 2011 16:14:40 +0300, Eli Bendersky 
> wrote:
> > 1. In the documentation of test.support mention explicitly that it's code
> > for CPython's internal use only, and these APIs aren't guaranteed to be
> > stable.
>
> This was already done.
>
> > 2. Some functions like unlink and rmtree are obviously redundant, and
> shadow
> > frequently used Python stdlib functions, so I would either kill them
> > completely or at least rename them appropriately.
>
> But they aren't redundant, since the test.support versions ignore
> errors.
>
> Perhaps what we could do is move the documentation for test.support to
> the devguide, and then vet the test suite so that unlink and friends
> are always called as 'support.unlink', etc.
>

I like this solution since this issue of documenting test.support keeps
coming up. Otherwise we can not document test.support, but  then we need to
do a pass through the module to make sure  that the docstrings are properly
updated and we start deprecating some of the stuff in there that is just
pure cruft.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Terry Reedy]

On 7/27/2011 10:27 AM, Eli Bendersky wrote:



Initially I was *for* documenting, but this thing with showing up
in the index is a compelling counter-point.


"The basic version makes entries in the general index; if no index
entry is desired, you can give the directive option flag :noindex:."
(http://docs.python.org/documenting/markup.html#information-units)


Ezio, this is also a good idea, but currently I really think placing
this documentation in the devguide is probably the best approach. Now we
have a very nice Devguide, and this documentation simply belongs there,
and not in the user-visible portion of the official Python documentation.


You mean the dev guide only accessible online? It could be included in 
HowTos (Help develop Python). If you are going to un-index the section, 
whereever it is, please put the entries in alpha order instead of the 
current jumble. Or is the current order somehow makes sense, an 
alphabetical index at the top.



--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Terry Reedy]

On 7/27/2011 9:24 AM, Antoine Pitrou wrote:

On Wed, 27 Jul 2011 16:14:40 +0300
Eli Bendersky  wrote:



Will it take long for newbie code to appear with the test.support version?
Not to mention that grepping code that imports the "unlink" function
directly doesn't reveal which one is being used.

I think this is troublesome. I think at least two separate actions are
required here:

1. In the documentation of test.support mention explicitly that it's code
for CPython's internal use only, and these APIs aren't guaranteed to be
stable.


There is a top-level note at
http://docs.python.org/dev/library/test.html, but it won't be visible
by people who arrive at an anchor point.


I think the 'Note' (gray box), not a 'Warning' (red box) should be 
repeated at the top of the test.support section. Or, or in addition, 
footnote each entry (with same number jumping to same footnote, if this 
can be done): "test.support.verbose(1). Seeing every entry decorated 
with the same footnote number should indicate there there is something 
unusual, and that we really mean it.



I think officially documenting test.support is a mistake. There is no
guarantee that APIs are stable or will even continue to exist.
Docstrings are sufficient for own our purposes.


Maybe sufficient for you, but if I am to learn and use this stuff, I 
need a proper listing. Individual docstrings require that you know the 
object exists and its name. Any help(module) listing is harder for me to 
use than the doc chapter.



2. Some functions like unlink and rmtree are obviously redundant, and shadow
frequently used Python stdlib functions, so I would either kill them
completely or at least rename them appropriately.


They are not redundant, since they provide slightly different semantics
(for example, they silence errors that happen when the path doesn't
exist).


rmtree has an ignore_errors=False parameter "ignore_errors is true, 
errors resulting from failed removals will be ignored; ". If that does 
not ignore enough errors, then perhaps it should be changed.


os.unlink is an alias for os.remove. The doc for the latter says error 
if path is a directory or a file in use on Windows (but not *nix). 
Neither should be case in test uses. Doc does not specify errors if file 
not exist or other conditions (inadequate permission.


Being thin wrappers, a quiet param is not allowed in os.remove/unlink, 
though I can imagine others wanting a quieted version for removal of 
files whose creation might have failed. In anycase, naming the quieted 
version in test.support unlink_quiet or q_remove or something would make 
its reason-for-being and use clearer.


---
Side note: test.support.import_fresh_module typo. /is/if/ in
"This function will raise unittest.SkipTest is the named module cannot 
be imported."


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Fix closes Issue12576 - fix urlopen behavior on sites which do not send (or

[Senthil Kumaran]

On Wed, Jul 27, 2011 at 02:21:59PM +0200, Antoine Pitrou wrote:
> transient_internet doesn't silence ValueError at all.

Yes, that is correct. I missed recollecting it in the first place. I
guess, I did not see using a content manager withing another context
manager block as something nice.. (nothing wrong but just the indented
code with additional wrap of exceptional handler).

But yes, it would be better to wrap it with transient_internet call.
Shall do.

> Well, the test should simply call close() as is done in other tests.

I tried that before responding, it does not silence the Resource
Warning. The fix (at least for these cases where Connection:close
header is not sent) lies in closing request in the urllib.request. It
is tricky as the server is not sending a Connection:close header which
httplib relies on to close the socket.

-- 
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[R. David Murray]

On Wed, 27 Jul 2011 16:58:53 +0300, Eli Bendersky  wrote:
> R. David Murray wrote:
> > But they aren't redundant, since the test.support versions ignore
> > errors.
> 
> As I mentioned elsewhere, it's not good practice to have two functions with
> the same name doing something slightly different, in different modules in
> the code-base.

Well, that would seem to be a matter of opinion.  I see your point, but
I'm not sure that I agree.  But see below.

> What do you mean by vetting the test suite so that unlink is always taken
> from test.support? I suppose some tests would specifically want the original
> unlink's functionality. In fact, at least a few tests use os.unlink
> exlicitly.

What I mean is that if the test code always did:

import support

[...]

support.unlink('testtempfile')

then there would be no confusion when someone grepped the code for
'unlink' or was reading the code without having noticed the import.
That is, give the functions a unique name by using the 'support'
name space explicitly, rather than by renaming them within the
module.

--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #11049: adding some tests to test.support

[Eli Bendersky]

> Thanks. I also saw this documented in the {!a} formatting

> > documentation.
> >
> > Was it left out of the library/stdtypes doc on purpose (to encourage
> > the new str.format), or is this an omission?
>
> Certainly an omission.
>
>
Alright, I created issue 12644 as a reminder to add this.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Eli Bendersky]

>  Initially I was *for* documenting, but this thing with showing up in the
> index is a compelling counter-point.
>
>
> "The basic version makes entries in the general index; if no index entry is
> desired, you can give the directive option flag :noindex:." (
> http://docs.python.org/documenting/markup.html#information-units)
>

Ezio, this is also a good idea, but currently I really think placing this
documentation in the devguide is probably the best approach. Now we have a
very nice Devguide, and this documentation simply belongs there, and not in
the user-visible portion of the official Python documentation.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Ezio Melotti]

  
  
Hi,

On 27/07/2011 16.35, Eli Bendersky wrote:

  

  

  > 1. In the documentation of test.support mention
  explicitly that it's code
  > for CPython's internal use only, and these APIs
  aren't guaranteed to be
  > stable.
  

There is a top-level note at
http://docs.python.org/dev/library/test.html,
but it won't be visible
by people who arrive at an anchor point.

I think officially documenting test.support is a mistake.
There is no
guarantee that APIs are stable or will even continue to
exist.
Docstrings are sufficient for own our purposes.
  
  
Initially I was *for* documenting, but this thing with
showing up in the index is a compelling counter-point. 
  

  


"The basic version makes entries in the general index; if no index
entry is desired, you can give the directive option flag :noindex:."
(http://docs.python.org/documenting/markup.html#information-units)

Best Regards,
Ezio Melotti


  

  
> 2. Some functions like unlink and rmtree are obviously
redundant, and shadow
> frequently used Python stdlib functions, so I would
either kill them
> completely or at least rename them appropriately.

  
  They are not redundant, since they
provide slightly different semantics
(for example, they silence errors that happen when the path
doesn't
exist).
  


Sure, but I'm still leery of two functions with the same name
doing acting slightly differently.

Eli

  
  


  

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #11049: adding some tests to test.support

[Antoine Pitrou]

Le mercredi 27 juillet 2011 à 16:54 +0300, Eli Bendersky a écrit :
> 
> Thanks. I also saw this documented in the {!a} formatting
> documentation.
> 
> Was it left out of the library/stdtypes doc on purpose (to encourage
> the new str.format), or is this an omission?

Certainly an omission.

Regards

Antoine.



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Eli Bendersky]

> > 2. Some functions like unlink and rmtree are obviously redundant, and
> shadow
> > frequently used Python stdlib functions, so I would either kill them
> > completely or at least rename them appropriately.
>
> But they aren't redundant, since the test.support versions ignore
> errors.
>

As I mentioned elsewhere, it's not good practice to have two functions with
the same name doing something slightly different, in different modules in
the code-base.


>
> Perhaps what we could do is move the documentation for test.support to
> the devguide, and then vet the test suite so that unlink and friends
> are always called as 'support.unlink', etc.
>
>
Moving the documentation to the devguide is a good compromise between not
documenting them at all and placing the documentation in a user-visible
location.

What do you mean by vetting the test suite so that unlink is always taken
from test.support? I suppose some tests would specifically want the original
unlink's functionality. In fact, at least a few tests use os.unlink
exlicitly.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #11049: adding some tests to test.support

[Eli Bendersky]

On Wed, Jul 27, 2011 at 16:44, Antoine Pitrou  wrote:

> On Wed, 27 Jul 2011 16:31:54 +0300
> Eli Bendersky  wrote:
> >
> > I wasn't aware of '%a' at all? It doesn't appear to be documented, and
> > Python 2.6 doesn't support it:
> >
> > ValueError: unsupported format character 'a' (0x61) at index 1
> >
> > If it's new, it should at least be documented in library/stdtypes with
> the
> > other formatting operations.
>
> It's new in 3.x and maps to the ascii() builtin:
>
> >>> ascii('hé')
> "'h\\xe9'"
> >>> '%a' % 'hé'
> "'h\\xe9'"
>
> The docstring for ascii():
>
>ascii(object) -> string
>
>As repr(), return a string containing a printable representation of
>an object, but escape the non-ASCII characters in the string
>returned by repr() using \x, \u or \U escapes.  This generates a
>string similar to that returned by repr() in Python 2.
>
>
Thanks. I also saw this documented in the {!a} formatting documentation.

Was it left out of the library/stdtypes doc on purpose (to encourage the new
str.format), or is this an omission?

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #11049: adding some tests to test.support

[Antoine Pitrou]

On Wed, 27 Jul 2011 16:31:54 +0300
Eli Bendersky  wrote:
> 
> I wasn't aware of '%a' at all? It doesn't appear to be documented, and
> Python 2.6 doesn't support it:
> 
> ValueError: unsupported format character 'a' (0x61) at index 1
> 
> If it's new, it should at least be documented in library/stdtypes with the
> other formatting operations.

It's new in 3.x and maps to the ascii() builtin:

>>> ascii('hé')
"'h\\xe9'"
>>> '%a' % 'hé'
"'h\\xe9'"

The docstring for ascii():

ascii(object) -> string

As repr(), return a string containing a printable representation of
an object, but escape the non-ASCII characters in the string
returned by repr() using \x, \u or \U escapes.  This generates a
string similar to that returned by repr() in Python 2.

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[R. David Murray]

On Wed, 27 Jul 2011 16:14:40 +0300, Eli Bendersky  wrote:
> 1. In the documentation of test.support mention explicitly that it's code
> for CPython's internal use only, and these APIs aren't guaranteed to be
> stable.

This was already done.

> 2. Some functions like unlink and rmtree are obviously redundant, and shadow
> frequently used Python stdlib functions, so I would either kill them
> completely or at least rename them appropriately.

But they aren't redundant, since the test.support versions ignore
errors.

Perhaps what we could do is move the documentation for test.support to
the devguide, and then vet the test suite so that unlink and friends
are always called as 'support.unlink', etc.

--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Eli Bendersky]

> > 1. In the documentation of test.support mention explicitly that it's code
> > for CPython's internal use only, and these APIs aren't guaranteed to be
> > stable.
>
> There is a top-level note at
> http://docs.python.org/dev/library/test.html, but it won't be visible
> by people who arrive at an anchor point.
>
> I think officially documenting test.support is a mistake. There is no
> guarantee that APIs are stable or will even continue to exist.
> Docstrings are sufficient for own our purposes.
>

Initially I was *for* documenting, but this thing with showing up in the
index is a compelling counter-point.

> 2. Some functions like unlink and rmtree are obviously redundant, and
shadow
> frequently used Python stdlib functions, so I would either kill them
> completely or at least rename them appropriately.

They are not redundant, since they provide slightly different semantics
> (for example, they silence errors that happen when the path doesn't
> exist).
>

Sure, but I'm still leery of two functions with the same name doing acting
slightly differently.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #11049: adding some tests to test.support

[Eli Bendersky]

> > I would use %r instead of %s for both fields here.  Non-ASCII characters
> > and unseen whitespace are at least two reasons to overuse %r in
> > debug/error messages instead of %s.
>
> Actually, you want %a for non-ASCII messages to be escaped.
> (however, there's hardly any reason to worry about it when it comes to
> stdlib module names)
>

I wasn't aware of '%a' at all? It doesn't appear to be documented, and
Python 2.6 doesn't support it:

ValueError: unsupported format character 'a' (0x61) at index 1

If it's new, it should at least be documented in library/stdtypes with the
other formatting operations.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Antoine Pitrou]

On Wed, 27 Jul 2011 16:14:40 +0300
Eli Bendersky  wrote:
> 
> Will it take long for newbie code to appear with the test.support version?
> Not to mention that grepping code that imports the "unlink" function
> directly doesn't reveal which one is being used.
> 
> I think this is troublesome. I think at least two separate actions are
> required here:
> 
> 1. In the documentation of test.support mention explicitly that it's code
> for CPython's internal use only, and these APIs aren't guaranteed to be
> stable.

There is a top-level note at
http://docs.python.org/dev/library/test.html, but it won't be visible
by people who arrive at an anchor point.

I think officially documenting test.support is a mistake. There is no
guarantee that APIs are stable or will even continue to exist.
Docstrings are sufficient for own our purposes.

> 2. Some functions like unlink and rmtree are obviously redundant, and shadow
> frequently used Python stdlib functions, so I would either kill them
> completely or at least rename them appropriately.

They are not redundant, since they provide slightly different semantics
(for example, they silence errors that happen when the path doesn't
exist).

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

[Eli Bendersky]

>
>
>
> The mere fact that these functions exist in a different module suggests
> different semantics from those found in other places in the stdlib. I don't
> think they should be renamed simply because some code imports the functions
> directly instead of the module itself (suggesting they should be doing the
> latter over the former). Now if the functions are redundant that's something
> else entirely and removal should be fine.
>

I will try to clarify my concern.

Documented functions from test.support currently appear in the global index
of the Sphinx-generated documentation. Suppose we document test.support's
"unlink". Now the index entry for "unlink" will contain two "unlink"
references (*), with slightly different semantics - one in os and another in
test.support

Will it take long for newbie code to appear with the test.support version?
Not to mention that grepping code that imports the "unlink" function
directly doesn't reveal which one is being used.

I think this is troublesome. I think at least two separate actions are
required here:

1. In the documentation of test.support mention explicitly that it's code
for CPython's internal use only, and these APIs aren't guaranteed to be
stable.
2. Some functions like unlink and rmtree are obviously redundant, and shadow
frequently used Python stdlib functions, so I would either kill them
completely or at least rename them appropriately.

Eli


(*) Actually, three, since there's also xml.dom.minidom.Node, but that's
obviously unrelated).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Fix closes Issue12576 - fix urlopen behavior on sites which do not send (or

[Antoine Pitrou]

On Wed, 27 Jul 2011 20:16:01 +0800
Senthil Kumaran  wrote:
> On Wed, Jul 27, 2011 at 11:52:32AM +0200, Antoine Pitrou wrote:
> > > +
> > > +try:
> > > +with urllib.request.urlopen('http://www.imdb.com') as res:
> > > +pass
> > 
> > Can you please at least use support.transient_internet() as in other
> > tests in this file?
> 
> It was intentional because ValueError was raised from context manager
> use case for a bug where the request object was closed prematurely.
> support.transient_internet, I believe would not have covered that
> case (Usage scenario).

Unless I'm reading wrongly, transient_internet doesn't silence
ValueError at all.

> > > +res = req.read()
> > > +self.assertTrue(res)
> > 
> > Also, when does "req" get closed? Right now I get resource warnings:
> 
> I shall fix this one. I think, attempting to fix the Resource warning
> caused the regression wherein the request object closed prematurely. I
> shall look at this.

Well, the test should simply call close() as is done in other tests.

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Fix closes Issue12576 - fix urlopen behavior on sites which do not send (or

[Senthil Kumaran]

On Wed, Jul 27, 2011 at 11:52:32AM +0200, Antoine Pitrou wrote:
> > +
> > +try:
> > +with urllib.request.urlopen('http://www.imdb.com') as res:
> > +pass
> 
> Can you please at least use support.transient_internet() as in other
> tests in this file?

It was intentional because ValueError was raised from context manager
use case for a bug where the request object was closed prematurely.
support.transient_internet, I believe would not have covered that
case (Usage scenario).

> > +req = urllib.request.urlopen('http://www.imdb.com')
> 
> Why a second time?

When used outside of context manager, it gave empty response instead
of ValueError and the test case was to check that.

> > +res = req.read()
> > +self.assertTrue(res)
> 
> Also, when does "req" get closed? Right now I get resource warnings:

I shall fix this one. I think, attempting to fix the Resource warning
caused the regression wherein the request object closed prematurely. I
shall look at this.

Thanks,
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Fix closes Issue12576 - fix urlopen behavior on sites which do not send (or

[Antoine Pitrou]

On Wed, 27 Jul 2011 02:25:56 +0200
senthil.kumaran  wrote:
>  
> +def test_sites_no_connection_close(self):
> +# Some sites do not send Connection: close header.
> +# Verify that those work properly. (#issue12576)
> +
> +try:
> +with urllib.request.urlopen('http://www.imdb.com') as res:
> +pass

Can you please at least use support.transient_internet() as in other
tests in this file?

> +except ValueError as e:
> +self.fail("urlopen failed for sites not sending 
> Connection:close")
> +else:
> +self.assertTrue(res)
> +
> +req = urllib.request.urlopen('http://www.imdb.com')

Why a second time?

> +res = req.read()
> +self.assertTrue(res)

Also, when does "req" get closed? Right now I get resource warnings:

test_sites_no_connection_close (test.test_urllib2net.OtherNetworkTests) ... 
/home/antoine/cpython/default/Lib/socket.py:342: ResourceWarning: unclosed 

  self._sock = None
/home/antoine/cpython/default/Lib/socket.py:342: ResourceWarning: unclosed 

  self._sock = None
ok


Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #11049: adding some tests to test.support

[Michael Foord]

On 27/07/2011 03:04, Brett Cannon wrote:



On Tue, Jul 26, 2011 at 17:41, Nick Coghlan > wrote:


On Wed, Jul 27, 2011 at 12:10 AM, Éric Araujo mailto:mer...@netwok.org>> wrote:
> Le 26/07/2011 15:30, Antoine Pitrou a écrit :
>> Actually, you want %a for non-ASCII messages to be escaped.
>
> Thanks for the reminder, I should use more %a instead of %r.  In the
> packaging code however, we can't, given that we want to backport.
>
>> (however, there's hardly any reason to worry about it when it
comes to
>> stdlib module names)
>
> I lacked context to see that.  If the code in question only ever
handles
> stdlib modules, then okay.

The other reason to use %r is to get the enclosing quotes in the
displayed message. That reason applies even in cases like this where
the escaping aspect isn't a concern.


And then you make it {!r} so you can use str.format and you complete 
the tweak of the string formatting! =) Seriously, though, it wouldn't 
hurt to update it to use str.format().




Well, except that {!r} is twice as verbose as %r

Michael



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Comments of the PEP 3151

[Nick Coghlan]

2011/7/27 Charles-François Natali :
>>> I assume that ESHUTDOWN is the errno in question?  (This is also already 
>>> mentioned in the PEP.)
>>
>> Indeed, I mentioned it in the PEP, as it appears in asyncore.py.
>> But I can't find it on www.opengroup.org, and no man page on my Linux
>> system (except the "errno" man page) seems to mention it.
>
> It's not POSIX, but it's defined on Linux and FreeBSD (at least):
> http://lxr.free-electrons.com/source/include/asm-generic/errno.h#L81
> http://fxr.watson.org/fxr/source/sys/errno.h?v=FREEBSD53#L122
>
>> The description from errnomodule.c says "Cannot send after transport
>> endpoint shutdown", but send() actually returns EPIPE, not ESHUTDOWN,
>> when the socket has been shutdown:
>
> Indeed, as required by POSIX.
>
> But grepping through the Linux kernel source code, it seems to be used
> extensively for USB devices, see
> http://lxr.free-electrons.com/ident?i=ESHUTDOWN
> So the "transport endpoint" doesn't necessarily refer to a socket.
> It's also documented in
> http://lxr.free-electrons.com/source/Documentation/usb/error-codes.txt
>
> Finally, I found one place in the networking stack where ESHUTDOWN is
> used, in the SCTP code:
> http://lxr.free-electrons.com/source/net/sctp/outqueue.c#L329

Perhaps the right thing to do is to just have a ConnectionBrokenError
that covers EPIPE, ESHUTDOWN and ECONNRESET? The current version of
the PEP has these as two separate exception types (BrokenPipeError for
the first two and ConnectionResetError for the last), but I'm not
seeing a strong reason to avoid combining them.

(ECONNABORTED and ECONNREFUSED are different, since they relate to
failures when *initiating* a connection)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Comments of the PEP 3151

[Charles-François Natali]

>> I assume that ESHUTDOWN is the errno in question?  (This is also already 
>> mentioned in the PEP.)
>
> Indeed, I mentioned it in the PEP, as it appears in asyncore.py.
> But I can't find it on www.opengroup.org, and no man page on my Linux
> system (except the "errno" man page) seems to mention it.

It's not POSIX, but it's defined on Linux and FreeBSD (at least):
http://lxr.free-electrons.com/source/include/asm-generic/errno.h#L81
http://fxr.watson.org/fxr/source/sys/errno.h?v=FREEBSD53#L122

> The description from errnomodule.c says "Cannot send after transport
> endpoint shutdown", but send() actually returns EPIPE, not ESHUTDOWN,
> when the socket has been shutdown:

Indeed, as required by POSIX.

But grepping through the Linux kernel source code, it seems to be used
extensively for USB devices, see
http://lxr.free-electrons.com/ident?i=ESHUTDOWN
So the "transport endpoint" doesn't necessarily refer to a socket.
It's also documented in
http://lxr.free-electrons.com/source/Documentation/usb/error-codes.txt

Finally, I found one place in the networking stack where ESHUTDOWN is
used, in the SCTP code:
http://lxr.free-electrons.com/source/net/sctp/outqueue.c#L329
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com