Re: [Python-Dev] [Python-checkins] cpython (3.2): test_os: add TemporaryFileTests to the testcase list
I tried to find which commit removes TemporaryFileTests from the testcase list (to see if there is a good reason to do that, or if it's just a mistake): it's somewhere between Python 2.x and Python 3.0, but I didn't find the commit. Is there a tool to detect that a testcase is never executed to ensure that there is no other forgiven testcase? Victor Le vendredi 01 juillet 2011 à 03:06 +0200, victor.stinner a écrit : > http://hg.python.org/cpython/rev/00a874ad4fc9 > changeset: 71104:00a874ad4fc9 > branch: 3.2 > parent: 71101:7c60c1b41da9 > user:Victor Stinner > date:Fri Jul 01 02:56:15 2011 +0200 > summary: > test_os: add TemporaryFileTests to the testcase list > > The testcase was never executed, it's now fixed. > > files: > Lib/test/test_os.py | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > > diff --git a/Lib/test/test_os.py b/Lib/test/test_os.py > --- a/Lib/test/test_os.py > +++ b/Lib/test/test_os.py > @@ -1344,6 +1344,7 @@ > PidTests, > LoginTests, > LinkTests, > +TemporaryFileTests, > ) ___ 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] PEP 397 (Python launcher for Windows) reference implementation
Mark Hammond gmail.com> writes: > The intention is that there only be a single launcher, as only one app > can be associated with .py files. OTOH though, file associations can be > configured per-user IIRC, and assuming that is the case, we could avoid > my multiple-ini-file usecase above by just allowing a different launcher > to be registered for a specific user. This is sounding difficult from > the UI perspective though (ie, does the installer then need to ask that > question, will there be a post-install technique for per-user > registration, etc?) I don't like this, for the reasons you state. I think it would be better if the PEP was changed to say that there is intended to be just one launcher installation per machine. As the intention is for the launcher to ship with Python, and there can be multiple Pythons installed, I presume we'll have to handle this by installing the launcher in some common-to-all-Pythons location somewhere outside a Python installation location, such as "c:\Program Files\Python Launcher". This should be stated in the PEP, and we'll also need to indicate how the launcher will be cleaned up if for some strange reason someone uninstalls all Pythons from a machine. Then we can just state that there's a global .ini file (where the launcher is installed) and a local one (in the user's APPDATA). From that perspective, it makes sense to have items in the local (APPDATA) override the global (launcher installation location). > Sure, that would be awesome! I think that will mean your impl is fairly > close to the first draft of the PEP I checked into HG, which is nice and > still quite useful to use :) Okay, I'll do this soon - once I've added a few tests. I've updated the implementation to include help output. BTW I thought of another thing that perhaps needs handling: what if a customized command points to the launcher itself? It'd be turtles all the way down :-) Regards, Vinay Sajip ___ 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: Issue #12451: Add support.create_empty_file()
On Thu, 30 Jun 2011 23:25:59 +0200
victor.stinner wrote:
> http://hg.python.org/cpython/rev/0c49260e85a0
> changeset: 71103:0c49260e85a0
> user:Victor Stinner
> date:Thu Jun 30 23:25:47 2011 +0200
> summary:
> Issue #12451: Add support.create_empty_file()
>
> We don't need to create a temporary buffered binary or text file object just
> to
> create an empty file.
Is there a reason for this?
I find it quite explicit and obvious what the following does:
with open("somefile", "wb"):
pass
so I wonder what replacing it with support.create_empty_file() brings
(except from having to lookup yet another helper function).
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: Issue #12451: Add support.create_empty_file()
Le vendredi 01 juillet 2011 à 11:24 +0200, Antoine Pitrou a écrit :
> On Thu, 30 Jun 2011 23:25:59 +0200
> victor.stinner wrote:
> > http://hg.python.org/cpython/rev/0c49260e85a0
> > changeset: 71103:0c49260e85a0
> > user:Victor Stinner
> > date:Thu Jun 30 23:25:47 2011 +0200
> > summary:
> > Issue #12451: Add support.create_empty_file()
> >
> > We don't need to create a temporary buffered binary or text file object
> > just to
> > create an empty file.
>
> Is there a reason for this?
The code was correct. I think that a function with an explicit name is
better than the open().close() pattern (which has various flavours, see
the diff). This pattern came sometimes with a comment explaining what it
does (create an empty file), which let me think that it's not easy to
understand what it is supposed to do (if you don't have the comment).
My initial need was to make quiet a warning (of my patched Python, see
#12451) if a file is opened in text mode without an explicit encoding.
> I find it quite explicit and obvious what the following does:
>
> with open("somefile", "wb"):
> pass
For "wb", the only gain is to avoid the creation of temporary FileIO and
BufferedWriter objects, a micro optimisation. Most of the time, "w" mode
was used, so another temporary TextIOWrapper object was also created. I
also saw "w+" mode (use BufferedRandom+TextIOWrapper objects).
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] time.sleep(-1) behaviour
On Thu, Jun 30, 2011 at 15:13, Ulrich Eckhardt wrote: > Hi! > > This is a request for clarification for the thread "how to call a function for > evry 10 seconds" from the user mailinglist/newsgroup. > > > The gist is this: > 1. On Linux/Python 2.6, time.sleep(-1.0) raises an IOError. > 2. On MS Windows/Python 2.5 or 2.7 this sleeps forever. It seems that > converting this to a 32-bit integer for Sleep() causes an underflow. > 3. Is the behaviour under MS Windows acceptable or a bug? On the Windows side, Sleep(-1) as "infinite" is correct and documented: http://msdn.microsoft.com/en-us/library/ms686298(v=vs.85).aspx -- Tim Lesher ___ 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 (3.2): test_os: add TemporaryFileTests to the testcase list
On Fri, Jul 1, 2011 at 7:18 PM, Victor Stinner wrote: > I tried to find which commit removes TemporaryFileTests from the > testcase list (to see if there is a good reason to do that, or if it's > just a mistake): it's somewhere between Python 2.x and Python 3.0, but I > didn't find the commit. > > Is there a tool to detect that a testcase is never executed to ensure > that there is no other forgiven testcase? Coverage data for the test suite itself. 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] time.sleep(-1) behaviour
On Fri, Jul 1, 2011 at 10:17 PM, Tim Lesher wrote: > On Thu, Jun 30, 2011 at 15:13, Ulrich Eckhardt > wrote: >> Hi! >> >> This is a request for clarification for the thread "how to call a function >> for >> evry 10 seconds" from the user mailinglist/newsgroup. >> >> >> The gist is this: >> 1. On Linux/Python 2.6, time.sleep(-1.0) raises an IOError. >> 2. On MS Windows/Python 2.5 or 2.7 this sleeps forever. It seems that >> converting this to a 32-bit integer for Sleep() causes an underflow. > >> 3. Is the behaviour under MS Windows acceptable or a bug? > > On the Windows side, Sleep(-1) as "infinite" is correct and documented: > > http://msdn.microsoft.com/en-us/library/ms686298(v=vs.85).aspx For Sleep, yes, but the time.sleep() docs [1] are completely silent on the behaviour of negative sleep values at the Python level. Question 3 isn't "Is there something wrong with Sleep()?", it is "Is there something wrong with the way time.sleep() *uses* Sleep()?" My personal preference would be to standardise on ValueError (since the negative sleep value is the real problem), or, failing that, at least raising an exception of some kind. [1] http://docs.python.org/dev/library/time#time.sleep 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] time.sleep(-1) behaviour
Le vendredi 01 juillet 2011 à 08:17 -0400, Tim Lesher a écrit : > On Thu, Jun 30, 2011 at 15:13, Ulrich Eckhardt > wrote: > > Hi! > > > > This is a request for clarification for the thread "how to call a function > > for > > evry 10 seconds" from the user mailinglist/newsgroup. > > > > > > The gist is this: > > 1. On Linux/Python 2.6, time.sleep(-1.0) raises an IOError. > > 2. On MS Windows/Python 2.5 or 2.7 this sleeps forever. It seems that > > converting this to a 32-bit integer for Sleep() causes an underflow. > > > 3. Is the behaviour under MS Windows acceptable or a bug? > > On the Windows side, Sleep(-1) as "infinite" is correct and documented: > > http://msdn.microsoft.com/en-us/library/ms686298(v=vs.85).aspx I answered on the bug tracker: http://bugs.python.org/issue12459 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] [Python-checkins] cpython (3.2): test_os: add TemporaryFileTests to the testcase list
On Fri, 2011-07-01 at 11:18 +0200, Victor Stinner wrote: > I tried to find which commit removes TemporaryFileTests from the > testcase list (to see if there is a good reason to do that, or if it's > just a mistake): it's somewhere between Python 2.x and Python 3.0, but I > didn't find the commit. For what it's worth, $ hg grep --all TemporaryFileTests Lib/test/test_os.py Lib/test/test_os.py:45773:+:class TemporaryFileTests(unittest.TestCase): Lib/test/test_os.py:43680:-:class TemporaryFileTests(unittest.TestCase): Lib/test/test_os.py:43680:-:TemporaryFileTests, will show where TemporaryFileTests was removed and added. ___ 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] time.sleep(-1) behaviour
On Fri, Jul 1, 2011 at 08:46, Nick Coghlan wrote: > For Sleep, yes, but the time.sleep() docs [1] are completely silent on > the behaviour of negative sleep values at the Python level. Question 3 > isn't "Is there something wrong with Sleep()?", it is "Is there > something wrong with the way time.sleep() *uses* Sleep()?" That makes sense. Better to be consistent within the time API--I know the different semantics of time.clock() have confused people around here. -- Tim Lesher ___ 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 (3.2): test_os: add TemporaryFileTests to the testcase list
Le vendredi 01 juillet 2011 à 14:55 +0200, Ross Lagerwall a écrit : > On Fri, 2011-07-01 at 11:18 +0200, Victor Stinner wrote: > > I tried to find which commit removes TemporaryFileTests from the > > testcase list (to see if there is a good reason to do that, or if it's > > just a mistake): it's somewhere between Python 2.x and Python 3.0, but I > > didn't find the commit. > > For what it's worth, > > $ hg grep --all TemporaryFileTests Lib/test/test_os.py > Lib/test/test_os.py:45773:+:class TemporaryFileTests(unittest.TestCase): > Lib/test/test_os.py:43680:-:class TemporaryFileTests(unittest.TestCase): > Lib/test/test_os.py:43680:-:TemporaryFileTests, > > > will show where TemporaryFileTests was removed and added. It was added in the middle of an horrible trunk->3.x merge: "Merged revisions 61239-61249,61252-61257,61260-61264,61269-61275,61278-61279,61285-61286,61288-61290,61298,61303-61305, svn+ssh://python...@svn.python.org/python/trunk" To find which commit removed a function in a file, hg bisect can be used (trick given on #mercurial): PREVREV=$(hg id); hg bisect -r; hg bisect -g 0; hg bisect -c 'grep -q tmpnam Modules/posixmodule.c'; hg update $PREVREV Even if it searchs in ~70.000 commits, it takes less than a second to find the commit which removed tmpnam in Python 3: changeset: 43680:a8818ffe24d1 parent: 43673:d66018ed3ded user:Guido van Rossum date:Thu Oct 25 23:18:51 2007 + files: Doc/library/os.rst Lib/test/test_os.py Lib/test/test_posix.py Misc/NEWS Modules/posixmodule.c description: Patch 1318 by Christian Heimes: remove os.tmpnam(), os.tempnam(), and os.tmpfile(). Note: I did a new commit on test_os in Python 3.3 to remove TemporaryFileTests (again): most tests were useless because os.tmpnam(), os.tempnam() and os.tmpfile() don't exist anymore in Python 3.3. I moved remaining useful tests to another testcase. 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] What happened to Python 3.2.1?
Hi Python 3.2.1 was scheduled to be released on 6/19, I believe but there is no mention of it anywhere. Has it been delayed? Thanks. ___ 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] What happened to Python 3.2.1?
On Fri, Jul 1, 2011 at 09:01, David P. Riedel wrote: > Hi > > Python 3.2.1 was scheduled to be released on 6/19, I believe but there is > no mention of it anywhere. Has it been delayed? > > Thanks. There are two remaining blockers for the release: http://bugs.python.org/issue12346 and http://bugs.python.org/issue12291 ___ 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] What happened to Python 3.2.1?
On Fri, 1 Jul 2011 09:38:04 -0500 Brian Curtin wrote: > On Fri, Jul 1, 2011 at 09:01, David P. Riedel wrote: > > > Hi > > > > Python 3.2.1 was scheduled to be released on 6/19, I believe but there is > > no mention of it anywhere. Has it been delayed? > > > > Thanks. > > > There are two remaining blockers for the release: > http://bugs.python.org/issue12346 and http://bugs.python.org/issue12291 Perhaps http://bugs.python.org/issue12213 should also be a blocker? ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2011-06-24 - 2011-07-01) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open2850 ( +5) closed 21399 (+64) total 24249 (+69) Open issues with patches: 1233 Issues opened (50) == #5572: packaging should respect the LIBS configure env var http://bugs.python.org/issue5572 reopened by eric.araujo #11363: Curses - add missing functions to doc http://bugs.python.org/issue11363 reopened by eric.araujo #12401: unset PYTHON* environment variables when running tests http://bugs.python.org/issue12401 opened by henry.precheur #12403: Mention sys.displayhook in code module docs and the compile bu http://bugs.python.org/issue12403 opened by tebeka #12405: packaging does not record/remove directories it creates http://bugs.python.org/issue12405 opened by vinay.sajip #12406: msi.py needs updating for Python 3.3 http://bugs.python.org/issue12406 opened by vinay.sajip #12410: Create a new helper function that enable to test that an opera http://bugs.python.org/issue12410 opened by mouad #12411: cgi.parse_multipart is broken on 3.x http://bugs.python.org/issue12411 opened by jonas.wagner #12412: non defined representation for pwd.struct_passwd http://bugs.python.org/issue12412 opened by fgarciar #12413: make faulthandler dump traceback of child processes http://bugs.python.org/issue12413 opened by neologix #12414: getsizeof() on code objects is wrong http://bugs.python.org/issue12414 opened by benjamin.peterson #12415: Missing: How to checkout the Doc sources http://bugs.python.org/issue12415 opened by philip #12416: packaging does not have hooks callable during distribution rem http://bugs.python.org/issue12416 opened by vinay.sajip #12418: python should inherit the library search path from the compile http://bugs.python.org/issue12418 opened by vorlon #12420: distutils tests fail if PATH is not defined http://bugs.python.org/issue12420 opened by henry.precheur #12423: signal handler doesn't handle SIGABRT from os.abort http://bugs.python.org/issue12423 opened by kisielk #12424: distutils2: extension section uses bad environment marker sepa http://bugs.python.org/issue12424 opened by eli.collins #12425: gettext breaks on empty plural-forms value http://bugs.python.org/issue12425 opened by djc #12426: packaging.tests.test_command_install_dist.InstallTestCase fail http://bugs.python.org/issue12426 opened by haypo #12427: packaging register fails because "POST data should be bytes" http://bugs.python.org/issue12427 opened by vinay.sajip #12428: functools test coverage http://bugs.python.org/issue12428 opened by Thorney #12429: test_io.check_interrupted_write() sporadic failures on FreeBSD http://bugs.python.org/issue12429 opened by haypo #12432: remove a bunch of unused imports in Lib http://bugs.python.org/issue12432 opened by vincele #12434: Strengthen 2.7 io types warning http://bugs.python.org/issue12434 opened by terry.reedy #12436: Provide reference to detailed installation instructions http://bugs.python.org/issue12436 opened by ncoghlan #12437: _ctypes.dlopen does not include errno in OSError http://bugs.python.org/issue12437 opened by anacrolix #12438: IDLE problem displaying warning message http://bugs.python.org/issue12438 opened by JBernardo #12439: BaseHTTPServer's send_reponse adds extra "\r\n" when using HTT http://bugs.python.org/issue12439 opened by Yoav.Weiss #12440: test_ssl.test_options() failure on Snow Leopard: can't clear o http://bugs.python.org/issue12440 opened by haypo #12441: _GLOBAL_DEFAULT_TIMEOUT remains as an object() in HTTPConnecti http://bugs.python.org/issue12441 opened by juanjux #12445: dict view values objects are missing tp_richcmp and tp_as_numb http://bugs.python.org/issue12445 opened by Julian #12446: StreamReader Readlines behavior odd http://bugs.python.org/issue12446 opened by Thomas.Barnet-Lamb #12448: smtplib's __main__ doesn't flush when prompting http://bugs.python.org/issue12448 opened by anacrolix #12449: Add accelerator "F" to button "Finish" in all MSI installers m http://bugs.python.org/issue12449 opened by cool-RR #12451: open: avoid the locale encoding when possible http://bugs.python.org/issue12451 opened by haypo #12452: reuse plistlib in sysconfig; deprecation process in plistlib http://bugs.python.org/issue12452 opened by haypo #12453: test_import.test_failing_import_sticks() sporadic failures http://bugs.python.org/issue12453 opened by haypo #12454: mailbox: use ASCII to read/write .mh_sequences files http://bugs.python.org/issue12454 opened by haypo #12455: urllib2 forces title() on header names, breaking some requests http://bugs.python.org/issue12455 opened by Cal.Leeming #12456: Hangs in concurrent.futures http://bugs.python.org/issue12456 opened by rosslagerwall #12457: type() returns incorrect type for nes
Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
Mark Hammond gmail.com> writes: > Sure, that would be awesome! I think that will mean your impl is fairly > close to the first draft of the PEP I checked into HG, which is nice and > still quite useful to use :) My C implementation of the launcher is now available at https://bitbucket.org/vinay.sajip/pylauncher It's been built using VS 2008, and tested on Windows 7 (32-bit) with ActivePython 2.6.2.2 and ActivePython 3.2.0.0 installed. I've added support for .ini files [commands] section; I haven't looked at implementing [defaults] yet. There's incomplete support for -32 suffix at the moment - that can be looked at in due course. A couple of points: I've also allowed for /usr/local/bin/python as a built-in command, this can always be removed later if YAGNI. I've assumed that if a customised command is provided with arguments in the shebang line, these will be ignored - if people want to run with different options they can always define more customised commands. If you agree with this, the PEP should probably explicitly state this. In a couple of cases I've implemented using fixed size arrays - for the lists of installed Pythons and customised commands. Of course these can be made dynamic, but what's there is good enough for the moment for exploration. Do have a play, and let me know what you think. Regards, Vinay Sajip ___ 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] What happened to Python 3.2.1?
Le vendredi 01 juillet 2011 à 16:43 +0200, Antoine Pitrou a écrit : > On Fri, 1 Jul 2011 09:38:04 -0500 > Brian Curtin wrote: > > On Fri, Jul 1, 2011 at 09:01, David P. Riedel wrote: > > > > > Hi > > > > > > Python 3.2.1 was scheduled to be released on 6/19, I believe but there is > > > no mention of it anywhere. Has it been delayed? > > > > > > Thanks. > > > > > > There are two remaining blockers for the release: > > http://bugs.python.org/issue12346 and http://bugs.python.org/issue12291 > > Perhaps http://bugs.python.org/issue12213 should also be a blocker? If you care of interlaced read-write, you may also see http://bugs.python.org/issue12215 I don't think that #12213 and #12215 are blocker. Nobody noticed it since the introduction of the io module (ok, except me), it's not a regression. Python 3.2.1 contains fixes of regressions, users are waiting for them (e.g. "\r" in the Windows console). Can't we schedule another release later to fix #12213 and #12215? 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] [Python-checkins] cpython (3.2): #11873: fix test regex so it covers windows os.sep as well.
Le vendredi 01 juillet 2011 à 17:54 +0200, r.david.murray a écrit :
> http://hg.python.org/cpython/rev/f8ece8c93918
> changeset: 71119:f8ece8c93918
> branch: 3.2
> parent: 71117:3f30cfe51315
> user:R David Murray
> date:Fri Jul 01 11:51:50 2011 -0400
> summary:
> #11873: fix test regex so it covers windows os.sep as well.
>
> files:
> Lib/test/test_compileall.py | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> diff --git a/Lib/test/test_compileall.py b/Lib/test/test_compileall.py
> --- a/Lib/test/test_compileall.py
> +++ b/Lib/test/test_compileall.py
> @@ -248,7 +248,7 @@
> self.assertEqual(b'', quiet)
>
> def test_regexp(self):
> -self.assertRunOK('-q', '-x', 'ba[^\/]*$', self.pkgdir)
> +self.assertRunOK('-q', '-x', r'ba[^\/]*$', self.pkgdir)
> self.assertNotCompiled(self.barfn)
> self.assertCompiled(self.initfn)
I'm not sure that your regex is correct. You may have to use a double
slash or it is interpreted by the regex :-/
>>> import re
>>> re.match(r'ba[^\/]*$', 'babar')
<_sre.SRE_Match object at 0x7f420559a7e8>
>>> re.match(r'ba[^\/]*$', 'babar/')
>>> re.match(r'ba[^\/]*$', 'babar\\a')
<_sre.SRE_Match object at 0x7f420559a850>
Correct regex:
>>> re.match(r'ba[^\\/]*$', 'baba\\')
>>> re.match(r'ba[^\\/]*$', 'baba/')
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
