Re: [Python-Dev] hard linking executables

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

Re: [Python-Dev] hard linking executables

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 *al

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

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

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

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

Re: [Python-Dev] hard linking executables

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 b

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

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 f

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

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

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

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

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

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 proble

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

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 p

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

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'

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

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 acce

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

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

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

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 ask

Re: [Python-Dev] hard linking executables

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.

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

>> +- 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://mai

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

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. ___ Py

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

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 is

Re: [Python-Dev] hard linking executables

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 t

Re: [Python-Dev] hard linking executables

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

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

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 a

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

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, Ni

Re: [Python-Dev] hard linking executables

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

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

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

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

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

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

-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 af

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

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 > i

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

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 chan

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

> 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 P

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

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 tes

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

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

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

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

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

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

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

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 alr

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

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

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

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.

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

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.. (nothi

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

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, i

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

> 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

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

> 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/m

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

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

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

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

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

> > 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 m

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

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 in

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

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

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

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

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

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

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

> > 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 abo

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

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 thin

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

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

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

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 sup

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

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 inten

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

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('h

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

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

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

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 (exc

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

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