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.
2011/7/27 Charles-François Natali neolo...@free.fr:
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
On 27/07/2011 03:04, Brett Cannon wrote:
On Tue, Jul 26, 2011 at 17:41, Nick Coghlan ncogh...@gmail.com
mailto:ncogh...@gmail.com wrote:
On Wed, Jul 27, 2011 at 12:10 AM, Éric Araujo mer...@netwok.org
mailto:mer...@netwok.org wrote:
Le 26/07/2011 15:30, Antoine Pitrou a écrit :
On Wed, 27 Jul 2011 02:25:56 +0200
senthil.kumaran python-check...@python.org wrote:
+def test_sites_no_connection_close(self):
+# Some sites do not send Connection: close header.
+# Verify that those work properly. (#issue12576)
+
+try:
+with
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
On Wed, 27 Jul 2011 20:16:01 +0800
Senthil Kumaran sent...@uthcode.com 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
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
On Wed, 27 Jul 2011 16:14:40 +0300
Eli Bendersky eli...@gmail.com 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
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
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
On Wed, 27 Jul 2011 16:14:40 +0300, Eli Bendersky eli...@gmail.com 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
On Wed, 27 Jul 2011 16:31:54 +0300
Eli Bendersky eli...@gmail.com 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
On Wed, Jul 27, 2011 at 16:44, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 27 Jul 2011 16:31:54 +0300
Eli Bendersky eli...@gmail.com 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
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
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
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
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:. (
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
On Wed, 27 Jul 2011 16:58:53 +0300, Eli Bendersky eli...@gmail.com 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
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..
On 7/27/2011 9:24 AM, Antoine Pitrou wrote:
On Wed, 27 Jul 2011 16:14:40 +0300
Eli Benderskyeli...@gmail.com 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
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
On Wed, Jul 27, 2011 at 06:36, R. David Murray rdmur...@bitdance.comwrote:
On Wed, 27 Jul 2011 16:14:40 +0300, Eli Bendersky eli...@gmail.com
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
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
---
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
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
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
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
Hi,
On 27/07/2011 20.31, eli.bendersky wrote:
http://hg.python.org/cpython/rev/8989aa5b357c
changeset: 71532:8989aa5b357c
user:Eli Benderskyeli...@gmail.com
date:Wed Jul 27 20:29:59 2011 +0300
summary:
fix doc typo for library/test.rst
files:
Doc/library/test.rst | 2
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
-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
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
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
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
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
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
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
On Tue, Jul 26, 2011 at 3:32 PM, Barry Warsaw ba...@python.org 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
On Wed, 27 Jul 2011 10:27:16 -0700
Brett Cannon br...@python.org 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
On Wed, 27 Jul 2011 19:36:36 +0200
charles-francois.natali python-check...@python.org 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.
+- 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
Dan Stromberg drsali...@gmail.com 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
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
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.
On Wed, Jul 27, 2011 at 2:53 PM, Victor Stinner
victor.stin...@haypocalc.com 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
On Thu, Jul 28, 2011 at 3:27 AM, Brett Cannon br...@python.org wrote:
On Wed, Jul 27, 2011 at 06:36, R. David Murray rdmur...@bitdance.com
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
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
On Wed, Jul 27, 2011 at 4:11 PM, Victor Stinner
victor.stin...@haypocalc.com 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
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
On Thu, Jul 28, 2011 at 9:38 AM, Guido van Rossum gu...@python.org 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
On Wed, Jul 27, 2011 at 6:00 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Jul 28, 2011 at 9:38 AM, Guido van Rossum gu...@python.org 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
On Wed, Jul 27, 2011 at 2:37 PM, Ben Finney ben+pyt...@benfinney.id.auwrote:
Dan Stromberg drsali...@gmail.com 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
On Thu, Jul 28, 2011 at 02:53, Steven D'Aprano st...@pearwood.info 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
2011/7/27 Guido van Rossum gu...@python.org:
On Wed, Jul 27, 2011 at 6:00 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Jul 28, 2011 at 9:38 AM, Guido van Rossum gu...@python.org wrote:
Users of codecs.open() or users of codecs.Stream* classes?
I would think both. Is there any reason to
Dan Stromberg drsali...@gmail.com writes:
On Wed, Jul 27, 2011 at 2:37 PM, Ben Finney ben+pyt...@benfinney.id.auwrote:
Dan Stromberg drsali...@gmail.com writes:
It's been suggested that […] if people had added symlinks first,
no one would've bothered adding hardlinks.
Well, that
Guido van Rossum gu...@python.org 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
56 matches
Mail list logo
