Re: [Python-Dev] [Python-checkins] cpython: test.support: add requires_mac_ver() function
Hi,
On 01/06/2011 13.28, victor.stinner wrote:
http://hg.python.org/cpython/rev/35212b113730
changeset: 70574:35212b113730
user:Victor Stinner
date:Wed Jun 01 12:28:04 2011 +0200
summary:
test.support: add requires_mac_ver() function
I would expect this to be a decorator, similar to requires_IEEE_754 and
requires_zlib.
Add also linux_version() to __all__.
For consistency, this should be a decorator too, possibly named
requires_linux_ver().
A requires_windows(_ver) sounds like a useful addition too, given the
number of tests that are specific to Windows.
files:
Lib/test/support.py | 22 +-
Lib/test/test_math.py | 7 ---
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/Lib/test/support.py b/Lib/test/support.py
--- a/Lib/test/support.py
+++ b/Lib/test/support.py
@@ -37,7 +37,8 @@
"Error", "TestFailed", "ResourceDenied", "import_module",
"verbose", "use_resources", "max_memuse", "record_original_stdout",
"get_original_stdout", "unload", "unlink", "rmtree", "forget",
-"is_resource_enabled", "requires", "find_unused_port", "bind_port",
+"is_resource_enabled", "requires", "linux_version", "requires_mac_ver",
+"find_unused_port", "bind_port",
"IPV6_ENABLED", "is_jython", "TESTFN", "HOST", "SAVEDCWD", "temp_cwd",
"findfile", "sortdict", "check_syntax_error", "open_urlresource",
"check_warnings", "CleanImport", "EnvironmentVarGuard",
"TransientResource",
@@ -299,6 +300,25 @@
except ValueError:
return 0, 0, 0
+def requires_mac_ver(*min_version):
+"""Raise SkipTest if the OS is Mac OS X and the OS X version if less than
+min_version.
+
+For example, support.requires_linux_version(10, 5) raises SkipTest if the
This should be requires_mac_ver
+version is less than 10.5.
+"""
+if sys.platform != 'darwin':
+return
+version_txt = platform.mac_ver()[0]
+try:
+version = tuple(map(int, version_txt.split('.')))
+except ValueError:
+return
+if version< min_version:
+min_version_txt = '.'.join(map(str, min_version))
+raise unittest.SkipTest("Mac OS X %s or higher required, not %s"
+% (min_version_txt, version_txt))
+
HOST = 'localhost'
def find_unused_port(family=socket.AF_INET, socktype=socket.SOCK_STREAM):
diff --git a/Lib/test/test_math.py b/Lib/test/test_math.py
--- a/Lib/test/test_math.py
+++ b/Lib/test/test_math.py
@@ -2,6 +2,7 @@
# Should not do tests around zero only
from test.support import run_unittest, verbose, requires_IEEE_754
+from test import support
import unittest
import math
import os
@@ -669,10 +670,10 @@
self.assertTrue(math.isnan(math.log2(NAN)))
@requires_IEEE_754
-@unittest.skipIf(sys.platform == 'darwin'
- and platform.mac_ver()[0].startswith('10.4.'),
- 'Mac OS X Tiger log2() is not accurate enough')
def testLog2Exact(self):
+# log2() is not accurate enough on Mac OS X Tiger (10.4)
+support.requires_mac_ver(10, 5)
+
# Check that we get exact equality for log2 of powers of 2.
actual = [math.log2(math.ldexp(1.0, n)) for n in range(-1074, 1024)]
expected = [float(n) for n in range(-1074, 1024)]
Best Regards,
Ezio Melotti
___
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] Some additions to .hgignore
On 31/05/2011 23:59, Sandro Tosi wrote: Hi all, following http://docs.python.org/devguide/coverage.html doc you'll end up with several "new" files/dirs in your checkout: - .coverage, used by coveragepy to save its info - coverage/ , the symlink to coveragepy/coverage - htmlcov/ , the dir where the coverage HTML pages are written I think they should be added to .hgignore so that hg st won't show them. I'm writing here since I don't think an issue is needed for such matter, if that's not the case, I apologize. That sounds good to me. An issue certainly wouldn't hurt. All the best, Michael Regards, -- 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] Sniffing passwords from PyPI using insecure connection
On Jun 01, 2011, at 02:33 AM, Terry Reedy wrote: >On 6/1/2011 1:37 AM, "Martin v. Löwis" wrote: >>> The requested one character change is >>> -DEFAULT_REPOSITORY = 'http://pypi.python.org/pypi' >>> +DEFAULT_REPOSITORY = 'https://pypi.python.org/pypi' >>> >>> If Tarek (or perhaps Eric) agree that it is appropriate and otherwise >>> innocuous, then Martin and Barry can decide whether to include in 2.5/2. >6. >> >> I don't plan any further 2.5 releases, so unless a critical security >> issue pops up, 2.5.6 will have been the last release. > >OK. I removed 2.5 from all open issues, closing a few. You could remove 2.5 >from the displayed version list so that people cannot add it back or to new >issues. I followed up on the tracker. I'm +0 on adding this to 2.6, but not until after the 2.6.7 release on Friday. How well has this change been tested? Are there people for whom this could break things? -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] Extending os.chown() to accept user/group names
Wiadomość napisana przez Martin v. Löwis w dniu 2011-06-01, o godz. 08:48: >> Le mercredi 25 mai 2011 à 18:46 +0200, Charles-François Natali a écrit : >>> While we're at it, adding a "recursive" argument to this shutil.chown >>> could also be useful. >> >> I don't like the idea of a recursive flag. > > I think shutil.chown should aim to mimic chown(1). At least GNU chown > has a -R flag (not sure about POSIX chown), and it's useful in practice. cp(1) and rm(1) also have "-r", still there are `shutil.copytree` and `shutil.rmtree`. I would like to keep that consistency, e.g. to have `shutil.chown` and `shutil.chowntree` as previously discussed by Charles-François, Nick and Petri. -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. ___ 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] Docs for the packaging module
Hi, Looks like nobody cares enough about the packaging docs :) If there is no feedback, here’s what I propose to do: - Add new Doc/library/packaging* files (library reference for developers of packaging tools) - Add new packaging-based “Installing Python Projects” to Doc/install, replacing old distutils docs - Add new packaging-based “Distributing Python Projects” Doc/packaging, replacing old distutils docs (+ link to it from the main HTML page instead of linking to Doc/distutils) For users needing the legacy distutils docs in 3.3, I would move the older distutils Doc/install/index.rst to Doc/distutils/install.rst, and add a link to Doc/distutils in Doc/library/distutils (because the main page would no longer link to Doc/distutils). Regards ___ 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] Docs for the packaging module
2011/6/1 Éric Araujo : > Hi, > > Looks like nobody cares enough about the packaging docs :) Perhaps your solutions are perfect already. :) > If there is > no feedback, here’s what I propose to do: > > - Add new Doc/library/packaging* files (library reference for developers > of packaging tools) > > - Add new packaging-based “Installing Python Projects” to Doc/install, > replacing old distutils docs > > - Add new packaging-based “Distributing Python Projects” Doc/packaging, > replacing old distutils docs (+ link to it from the main HTML page > instead of linking to Doc/distutils) > > For users needing the legacy distutils docs in 3.3, I would move the > older distutils Doc/install/index.rst to Doc/distutils/install.rst, and > add a link to Doc/distutils in Doc/library/distutils (because the main > page would no longer link to Doc/distutils). Or we could just delete them and have people look at docs for old versions of Python. -- 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] Docs for the packaging module
Hi Benjamin, >> For users needing the legacy distutils docs in 3.3, I would move the >> older distutils Doc/install/index.rst to Doc/distutils/install.rst, and >> add a link to Doc/distutils in Doc/library/distutils (because the main >> page would no longer link to Doc/distutils). > > Or we could just delete them and have people look at docs for old > versions of Python. Given that we haven’t removed the code, I would prefer to keep the doc too. Tarek has given me the greenlight, so I will commit the new docs momentarily. Cheers ___ 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] Docs for the packaging module
I do care :) Looks fine Please push, as we can always change and fix things afterwards in the tip before 3.3 is out. Le 1 juin 2011 19:38, "Éric Araujo" a écrit : > Hi, > > Looks like nobody cares enough about the packaging docs :) If there is > no feedback, here’s what I propose to do: > > - Add new Doc/library/packaging* files (library reference for developers > of packaging tools) > > - Add new packaging-based “Installing Python Projects” to Doc/install, > replacing old distutils docs > > - Add new packaging-based “Distributing Python Projects” Doc/packaging, > replacing old distutils docs (+ link to it from the main HTML page > instead of linking to Doc/distutils) > > For users needing the legacy distutils docs in 3.3, I would move the > older distutils Doc/install/index.rst to Doc/distutils/install.rst, and > add a link to Doc/distutils in Doc/library/distutils (because the main > page would no longer link to Doc/distutils). > > Regards > ___ > 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/ziade.tarek%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] Docs for the packaging module
On Wed, 01 Jun 2011 19:15:54 +0200, wrote: > Looks like nobody cares enough about the packaging docs :) If there is > no feedback, hereâs what I propose to do: I think you should go ahead and make your changes, and then we'll be able to see what it really looks like and decide if anything ought to be tweaked. -- 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
[Python-Dev] Question about Module Loading
If a Python program imported a module, say numpy for example, where in the source is this line interpreted and then handled by import.c ? Thank you in advance! ___ 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] Question about Module Loading
On Wed, 01 Jun 2011 10:54:13 -0700, Timothy Kadich wrote: > If a Python program imported a module, say numpy for example, where in the > source is this line interpreted and then handled by import.c ? Your question is not as simple as you think (I think), but I'm guessing you will want to look at Python/ceval.c. -- 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] Question about Module Loading
2011/6/1 Timothy Kadich : > If a Python program imported a module, say numpy for example, where in the > source is this line interpreted and then handled by import.c ? Many different files. Start from TARGET(IMPORT_NAME) in ceval.c. -- 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] Question about Module Loading
I don't understand what you mean by "TARGET(IMPORT_NAME)". I can't find that string in ceval.c. On 1 June 2011 12:04, Benjamin Peterson wrote: > 2011/6/1 Timothy Kadich : > > If a Python program imported a module, say numpy for example, where in > the > > source is this line interpreted and then handled by import.c ? > > Many different files. Start from TARGET(IMPORT_NAME) in ceval.c. > > > -- > 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] Question about Module Loading
Nevermind. In 2.6 (what I'm working with) it's "case IMPORT_NAME:" Thank you for letting me know where to start. On 1 June 2011 15:43, Timothy Kadich wrote: > I don't understand what you mean by "TARGET(IMPORT_NAME)". I can't find > that string in ceval.c. > > > On 1 June 2011 12:04, Benjamin Peterson wrote: > >> 2011/6/1 Timothy Kadich : >> > If a Python program imported a module, say numpy for example, where in >> the >> > source is this line interpreted and then handled by import.c ? >> >> Many different files. Start from TARGET(IMPORT_NAME) in ceval.c. >> >> >> -- >> 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] [Python-checkins] cpython (2.7): Multiple clean-ups to the docs for builtin functions.
On 6/1/2011 6:50 PM, raymond.hettinger wrote:
- with open("mydata.txt") as fp:
- for line in iter(fp.readline, "STOP"):
> process_line(line)
As noted on the tracker, this will always loop forever. Even if "STOP"
is corrected to "STOP\n", it will still loop forever if the file does
not have the magic value.
+ with open('mydata.txt') as fp:
+ for line in iter(fp.readline, ''):
> process_line(line)
While I have a big problem with infinite loops, I have a (smaller)
problem with useless code. The new loop line line is a roundabout way to
spell "for line in fp". While this would have been useful before files
were turned into iterables (if there was such a time after iter() was
introduced), it is not now.
What might be useful and what the example could show is how to stop
early if a sentinel is present, while still stopping when the iterable
runs out. The following alternate fix to the original does just that.
with open("mydata.txt") as fp:
for line in iter(fp.__next__, "STOP\n"):
process_line(line)
A tested a runnable variation with and without the exact sentinal. It
generalizes to *any* iteration than one might want to stop early.
This still has the objection that the loop could be written as
for line in fp:
if line == "STOP\n":
break
process_line(line)
which is easily generalized to any stopping conditions.
It is hard to think of useful examples of iter(func, sentinal). To be
sure of someday stopping, func must someday (either certainly or with
probability 1) either raise StopIteration or produce the sentinal (which
should therefore be hard to misspell). To be useful, func should not be
a method of an iterable (or at least not produce the same objects as the
iterable would when iterated.) It also must produce different values, at
least sometimes, when called, which means either maintaining internal
state or pulling values from another source.
Here is a completely different example which meets these criteria. It
can actually be run (though not doctested ;-). It uses random.randint to
produce 25 random waiting times for a binary process to hit one of the
two values.
from random import randint
for i in range(25):
print(sum(iter(lambda:randint(0,1), 0)), end=',')
The outer loop could be removed, but it hints at how this could be used
for empirical probability studies.
---
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
