Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/24/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 7/12/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> > On 7/11/07, Andy C <[EMAIL PROTECTED]> wrote:
> > > The good thing about this is that it's extremely simple -- basically
> > > 20 lines of C code to add a -z flag that calls a 3-line Python
> > > function in the runpy module.
> >
> > Instead of requiring a -z flag, why not have the interpreter peak at
> > the file to see if it starts with one of the ZIP magic numbers?
> >
> > That way it Just Works.
>
> I guess you wouldn't recognize a zip file if it hits you in the face.
> Literally. :-)
>
> Zip files don't start with a magic number.
ZIP files *do* start with a magic number; either PK\03\04 (non-empty
archive) or PK\05\06 (empty archive). This is rather easy to notice,
as I did in the bad old days of DOS, and i recently doubly verified it
('zip'+'khexedit', and
http://en.wikipedia.org/wiki/ZIP_%28file_format%29; I tried the
infozip website too, but it seems to be down.)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two spaces or one?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 23, 2007, at 10:18 PM, Talin wrote: > In PEP 9 there's a requirement that PEPs must follow the "emacs > convention" of 2 spaces after a period. (I didn't know this was an > emacs > convention, I thought it was a convention of people who used > typewriters.) > [...] > So if we're not going to enforce the rule consistently (and it > seems as > if we're not), can we then just remove it from PEP 9? I'm not saying > that we should change the rule to one space, I'm suggesting that we > just > drop the requirement and let people use whatever they prefer. As an emacs dinosaur, I'd prefer to keep the recommendation, but I also acknowledge that the smaller mammals nipping at my heals will eventually take over the world. I've recently had similar discussions in another community and I was actually kind of amazed to learn that auto-refilling of paragraphs itself was somewhat of an anachronism. Emacs will probably go the way of the vinyl record (though the latter is seeing a resurgence lately :). Changing "must" to "should" in PEP 9 would encourage but not enforce consistency, and I think that would be fine. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRqXs7nEjvBPtnXfVAQLZWAP/UGGslCnGukFXJOvXoOyQE34baFAxKEyY NmXmZnpGfnhNOgASG1zxpAzPd6PtHQUMzwk0FXwlHVHpwg9Lb+IxFGZlRAgY2Tya KspvunDYlRFGAlG13Zg+GsQZI6cOOLqjKqwPsAcNXe9NIQhTA8hJ6vYcGSbE/I3q 73INGJg5uU4= =keXE -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two spaces or one?
I'm with Barry. I still use Emacs. Emacs's paragraph filling algorithm, whether invoked explicitly via M-q or implicitly via auto-wrap mode, distinguishes the usage of periods based on the number of spaces following them. Two or more spaces are used to separate sentences. One space (for example, G. D. Montanaro) following a period is considered a non-breakable space. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] -z, -i and -m, maybe bug in runpy?
Phillip J. Eby wrote: > While trying to get my -z replacement patch to work, I stumbled > across a bug in the -m implementation (and in runpy). It seems that > when you run the code of a -m module, it is *not* run in the __main__ > module namespace! > > So even though __name__=='__main__', globals() is not > sys.modules['__main__'].__dict__. This seems wrong to me. Does > anybody know why runpy doesn't actually run the code in the target module? After implementing the runpy explicit relative import tests over the last couple of days, it actually occurred to me earlier today that I didn't have a test for this scenario. When I thought of the test, I was also pretty sure it would fail - it appears I was right :) > One consequence of this is that the -i option is much less useful > when you use -m, because the script's globals have disappeared before > you get to the interpreter prompt. > > At this point, I've successfully gotten a -z replacement patch, > except that it inherits this apparent bug from -m, which for a while > led me to believe my patch was broken (when in fact it works fine, > apart from inheriting the -m behavior). > > Does anybody know if this behavior is intended, and if so, why? And > what are the consequences of changing/fixing it? I think it's a bug - when fiddling with the sys module runpy.run_module() only uses the real module name, and not the requested run_name. It should actually modify both so that the assertion "globals() is sys.modules[__name__].__dict__" is correct when running the module. So, I propose that if runpy.run_module is told it has permission to modify the sys module, and run_name is specified and exists in sys.modules, then runpy will use that module to execute the code, instead of creating a new temporary module. If run_name isn't in sys.modules, then the temporary module used to execute the code will be stored in both places. This is a semantic change so we can't really backport it, but we can at least fix it for 2.6. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two spaces or one?
On Tue, Jul 24, 2007, [EMAIL PROTECTED] wrote: > > I'm with Barry. I still use Emacs. Emacs's paragraph filling algorithm, > whether invoked explicitly via M-q or implicitly via auto-wrap mode, > distinguishes the usage of periods based on the number of spaces following > them. Two or more spaces are used to separate sentences. One space (for > example, G. D. Montanaro) following a period is considered a non-breakable > space. There's no need to invoke Emacs to argue for the superiority of two spaces after each sentence, according to this vi user. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two spaces or one?
[EMAIL PROTECTED] wrote: > I'm with Barry. I still use Emacs. Emacs's paragraph filling algorithm, > whether invoked explicitly via M-q or implicitly via auto-wrap mode, > distinguishes the usage of periods based on the number of spaces following > them. Two or more spaces are used to separate sentences. One space (for > example, G. D. Montanaro) following a period is considered a non-breakable > space. > How very twentieth-century :-) regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] -z, -i and -m, maybe bug in runpy?
Nick Coghlan wrote: > Phillip J. Eby wrote: >> While trying to get my -z replacement patch to work, I stumbled across >> a bug in the -m implementation (and in runpy). It seems that when you >> run the code of a -m module, it is *not* run in the __main__ module >> namespace! >> >> So even though __name__=='__main__', globals() is not >> sys.modules['__main__'].__dict__. This seems wrong to me. Does >> anybody know why runpy doesn't actually run the code in the target >> module? > > After implementing the runpy explicit relative import tests over the > last couple of days, it actually occurred to me earlier today that I > didn't have a test for this scenario. When I thought of the test, I was > also pretty sure it would fail - it appears I was right :) OK, I've now had a closer look, and the problem isn't what I initially thought when I read your message (the test which I expected to fail actually passed without changing the current implementation). It turns out that while the module is actually executing it does the right thing - the problem only arises when the run_module function attempts to clean up after itself by reverting some of the changes it makes to the sys module. The specific problem is this sentence from the run_module docs: "Both sys.argv[0] and sys.modules[__name__] are restored to their original values before the function returns." It looks like those semantics are a mistake - the changes to the sys module should persist after the function terminates, leaving it to the calling code to decide whether or not it wants to restore the original state. >> One consequence of this is that the -i option is much less useful when >> you use -m, because the script's globals have disappeared before you >> get to the interpreter prompt. See above - the problem is that the function is cleaning up after itself and deleting things that may still be of interest when -i is also specified. >> At this point, I've successfully gotten a -z replacement patch, except >> that it inherits this apparent bug from -m, which for a while led me >> to believe my patch was broken (when in fact it works fine, apart from >> inheriting the -m behavior). >> >> Does anybody know if this behavior is intended, and if so, why? And >> what are the consequences of changing/fixing it? It was intended enough to be documented that way, but I don't recall putting any significant thought into that aspect of the implementation, and nor do I remember anyone else questioning it. The fact that it completely breaks the -i switch seems more than enough reason to consider it a bug, though. I've changed the behaviour in r56520 to simply leave the alterations to sys in place when the function terminates. While this is a definite change to the interface (and hence not a candidate for direct backporting), I think the difference is small enough for the 2.5 to 2.6 transition. If enough people prefer, I can switch the code to an approach which fixes -m while leaving the semantics of runpy.run_module alone. This would involve renaming the version of run_module I just checked into SVN have -m invoke that version directly. run_module would be changed to wrap the function used by -m in the necessary code to restore the sys module to something more closely resembling its original state. That would also be the approach to take if we decided we wanted to backport this fix to the 2.5 maintenance branch. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Calling back into python from C
I realise I'm going to get slapped for asking a userish question here - sorry in advance. I'm looking for an explanation for why things are the way they are, the doco and py source aren't providing the missing info, and it looks like I'm bumping into an old Python bug (fixed in r38830 by mwh on 2005-04-18). I'm working on an C extension that needs to call back into python. Generally the GIL has been released when I need to do the callback, but I can't be sure. So I need to save the GIL state, get the lock, then restore it at the end. As far as I can tell from the doco, the recommended way to do this is to use PyGILState_Ensure() and PyGILState_Release(), but prior to r38830, PyGILState_Release incorrectly used PyEval_ReleaseThread when it should have been using PyEval_SaveThread() (I think), and the result is SEGV. This poses a problem, as I need to support Python versions back to 2.3. Am I correct in using PyGILState_Ensure() and PyGILState_Release()? If so, how do I support back to Py 2.3? Copy the current fixed PyGILState_Release() into my code (ick)? -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Failure on assorted buildbots - Address already in use
A lot of the buildbots are red at the moment, which makes it harder to tell if a checkin broke anything new on other platforms. I've checked in a change to test_resource that should hopefully make some of the Debian buildbots happier, but several of the other buildbots are reporting a variety of "Address already in use" errors in the subthreads created by test_urllib2. Anyone have any ideas? Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two spaces or one?
On 7/24/07, Aahz <[EMAIL PROTECTED]> wrote: > On Tue, Jul 24, 2007, [EMAIL PROTECTED] wrote: > > > > I'm with Barry. I still use Emacs. Emacs's paragraph filling algorithm, > > whether invoked explicitly via M-q or implicitly via auto-wrap mode, > > distinguishes the usage of periods based on the number of spaces following > > them. Two or more spaces are used to separate sentences. One space (for > > example, G. D. Montanaro) following a period is considered a non-breakable > > space. I made this argument in private to Talin before he went here for a second opinion. Apparently it wasn't strong enough. :-) > There's no need to invoke Emacs to argue for the superiority of two > spaces after each sentence, according to this vi user. Indeed. After all, we're talking about PEP 9, which is a *plaintext* format. Check out http://www.python.org/dev/peps/pep-0009/ and you'll see that it is rendered in a fixed-width font with line breaks exactly where they are in the source, and the two spaces make a difference for readability. How about in PEP 9 we keep the recommendation, perhaps weakened to "should" or "ought"; but in PEP 12 (the ReST equivalent) we remove it altogether because it doesn't affect the rendering. And let's please not make this into a bikeshed discussion than it already is. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failure on assorted buildbots - Address already in use
2007/7/24, Nick Coghlan <[EMAIL PROTECTED]>:
> some of the Debian buildbots happier, but several of the other buildbots
> are reporting a variety of "Address already in use" errors in the
> subthreads created by test_urllib2.
Test pass ok in my machine.
However, if in another terminal I make...
>>> import socket
>>> s = socket.socket()
>>> s.bind(("127.0.0.1", 8080))
...the test fails exactly like in the buildbot.
Maybe the tests should be changed to use a not-so-standard port.
Regards,
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Py3k: error byte-compiling with distutils
I'm porting some of my code to py3k, and I started from the C size.
After this, all extensions compiled fine, but after a 'setup.py
install', I got the following:
File "/usr/local/python/3.0/lib/python3.0/distutils/util.py", line
498, in byte_compile
compile(file, cfile, dfile)
File "/usr/local/python/3.0/lib/python3.0/py_compile.py", line 127, in compile
py_exc = PyCompileError(err.__class__,err.args,dfile or file)
File "/usr/local/python/3.0/lib/python3.0/py_compile.py", line 48, in __init__
tbtext = ''.join(traceback.format_exception_only(exc_type, exc_value))
File "/usr/local/python/3.0/lib/python3.0/traceback.py", line 196,
in format_exception_only
lines.append("%s: %s\n" % (stype, str(msg)))
UnboundLocalError: local variable 'msg' referenced before assignment
At this point, I had not updated my python code, so it surelly had
some py3k-invalid things. Looking at 'traceback.py', it seems there is
something wrong in 'format_exception_only', so this error.
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two spaces or one?
> Emacs will probably go the way of the vinyl record (though the latter > is seeing a resurgence lately :). Doubt it. Even as we speak, there's probably a student planning to implement Python 3 in ELisp as a SOC project... Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k: error byte-compiling with distutils
On 7/24/07, Lisandro Dalcin <[EMAIL PROTECTED]> wrote:
> I'm porting some of my code to py3k, and I started from the C size.
> After this, all extensions compiled fine, but after a 'setup.py
> install', I got the following:
>
> File "/usr/local/python/3.0/lib/python3.0/distutils/util.py", line
> 498, in byte_compile
> compile(file, cfile, dfile)
> File "/usr/local/python/3.0/lib/python3.0/py_compile.py", line 127, in
> compile
> py_exc = PyCompileError(err.__class__,err.args,dfile or file)
> File "/usr/local/python/3.0/lib/python3.0/py_compile.py", line 48, in
> __init__
> tbtext = ''.join(traceback.format_exception_only(exc_type, exc_value))
> File "/usr/local/python/3.0/lib/python3.0/traceback.py", line 196,
> in format_exception_only
> lines.append("%s: %s\n" % (stype, str(msg)))
> UnboundLocalError: local variable 'msg' referenced before assignment
>
>
> At this point, I had not updated my python code, so it surelly had
> some py3k-invalid things. Looking at 'traceback.py', it seems there is
> something wrong in 'format_exception_only', so this error.
Try again -- I think this bug was introduced a few days ago. Kurt
Kaiser promised to roll it bck, but it hasn't happened yet it seems.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/24/07, David Gowers <[EMAIL PROTECTED]> wrote:
> On 7/24/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 7/12/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> > > On 7/11/07, Andy C <[EMAIL PROTECTED]> wrote:
> > > > The good thing about this is that it's extremely simple -- basically
> > > > 20 lines of C code to add a -z flag that calls a 3-line Python
> > > > function in the runpy module.
> > >
> > > Instead of requiring a -z flag, why not have the interpreter peak at
> > > the file to see if it starts with one of the ZIP magic numbers?
> > >
> > > That way it Just Works.
> >
> > I guess you wouldn't recognize a zip file if it hits you in the face.
> > Literally. :-)
> >
> > Zip files don't start with a magic number.
>
> ZIP files *do* start with a magic number; either PK\03\04 (non-empty
> archive) or PK\05\06 (empty archive). This is rather easy to notice,
> as I did in the bad old days of DOS, and i recently doubly verified it
> ('zip'+'khexedit', and
> http://en.wikipedia.org/wiki/ZIP_%28file_format%29; I tried the
> infozip website too, but it seems to be down.)
You can believe that, but it's not the whole story. You can *prepend*
arbitrary data and the zip tools can still read the archive.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] -z, -i and -m, maybe bug in runpy?
At 12:16 AM 7/25/2007 +1000, Nick Coghlan wrote: >I've changed the behaviour in r56520 to simply leave the alterations to >sys in place when the function terminates. While this is a definite >change to the interface (and hence not a candidate for direct >backporting), I think the difference is small enough for the 2.5 to 2.6 >transition. Your fix is a definite improvement for me, my "run any importable" patch is looking a lot better. There's just one problem left, which is that runpy is overwriting sys.argv[0] even if it doesn't need to. So, when running from a zipfile, sys.argv[0] ends up None, which is wrong. However, if I ask runpy not to mess with sys, it creates a new module namespace to run the code in, bringing me right back to square one (i.e., not being run in __main__). Any thoughts? My fallback at this point would be to add an option to run_module() to request that sys.argv[0] be used in place of calling _get_filename(). It seems ugly to do that, though, if only because there are already so many arguments to that function. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Py3k: 'range' fail
I did a fresh checkout as below (is p3yk the right branch?) $ svn co http://svn.python.org/projects/python/branches/p3yk python-3k after building and installing, I get $ python3.0 Python 3.0x (p3yk:56529, Jul 24 2007, 15:58:59) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> range(0,10,2) Traceback (most recent call last): File "", line 1, in SystemError: NULL result without error in PyObject_Call >>> -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k: 'range' fail
Yes, range() on the p3yk branch seems broken. However, this bug has been fixed in the py3k-struni, the branch where most the development for Python 3000 is taking place. -- Alexandre On 7/24/07, Lisandro Dalcin <[EMAIL PROTECTED]> wrote: > I did a fresh checkout as below (is p3yk the right branch?) > > $ svn co http://svn.python.org/projects/python/branches/p3yk python-3k > > after building and installing, I get > > $ python3.0 > Python 3.0x (p3yk:56529, Jul 24 2007, 15:58:59) > [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> range(0,10,2) > Traceback (most recent call last): > File "", line 1, in > SystemError: NULL result without error in PyObject_Call > >>> ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Py3k: error during 'make install' in py3k-struni ?
Afther checking out the py3k-struni branch, 'make install' issued this:
Compiling /usr/local/python/3.0/lib/python3.0/test/test_tarfile.py ...
*** SyntaxError: ('expected string, bytes found',
('/usr/local/python/3.0/lib/python3.0/test/test_tarfile.py', 0, 0,
None))
If this is expected to fail, please forget this.
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k: error during 'make install' in py3k-struni ?
Yeah, that particular test is not yet working. (Fixes are welcome --
see http://wiki.python.org/moin/Py3kStrUniTests for how to help.)
I believe I rigged "make install" to continue after this error -- did
the rest of the install complete?
FWIW, a better place to discuss Py3k bleeding edge stuff is
[EMAIL PROTECTED] Sign up at the usual place. (I've CC'ed that
list now -- please remove python-dev from followups.)
--Guido
On 7/24/07, Lisandro Dalcin <[EMAIL PROTECTED]> wrote:
> Afther checking out the py3k-struni branch, 'make install' issued this:
>
> Compiling /usr/local/python/3.0/lib/python3.0/test/test_tarfile.py ...
> *** SyntaxError: ('expected string, bytes found',
> ('/usr/local/python/3.0/lib/python3.0/test/test_tarfile.py', 0, 0,
> None))
>
> If this is expected to fail, please forget this.
>
> --
> Lisandro Dalcín
> ---
> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two spaces or one?
Bill Janssen wrote: > Someone wrote: > >Emacs will probably go the way of the vinyl record (though the latter > > is seeing a resurgence lately :). > > Doubt it. Even as we speak, there's probably a student planning to > implement Python 3 in ELisp as a SOC project... And run it on a computer built out of valves. (You get much better sound out of your MP3s on a valve computer, you know...:-) -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failure on assorted buildbots - Address already in use
Facundo Batista wrote:
> 2007/7/24, Nick Coghlan <[EMAIL PROTECTED]>:
>
> > some of the Debian buildbots happier, but several of the other buildbots
> > are reporting a variety of "Address already in use" errors in the
> > subthreads created by test_urllib2.
>
> Test pass ok in my machine.
>
> However, if in another terminal I make...
>
> >>> import socket
> >>> s = socket.socket()
> >>> s.bind(("127.0.0.1", 8080))
>
> ...the test fails exactly like in the buildbot.
>
> Maybe the tests should be changed to use a not-so-standard port.
Or use port 0 to let the operating system pick a free port:
>>> import socket
>>> s = socket.socket()
>>> s.bind(("127.0.0.1", 0))
>>> s.getsockname()
('127.0.0.1', 42669)
-Andrew.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
