Re: [Python-Dev] svn diff -r {2001-01-01}
On Mon, Nov 21, 2005 at 11:48:29PM +0100, Martin v. L?wis wrote: you will have to look up the closest revision number manually (e.g. in viewcvs, or through svn log). svn annotate (aka svn blame) may help too. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] test_cmd_line on Windows
A.B., Khalid wrote: Currently test_directories of test_cmd_line fails on the latest Python 2.4.2 from svn branch and from the svn head. The reason it seems is that the test assumes that the local language of Windows is English and so tries to find the string denied in the returned system error messages of the commands (python .) and (python .). But while it is true that the first command (python .) does return an English string error message even on so-called non-English versions of Windows, the same does not seem to be true for the second command (python .), which seems to return a locale-related string error message. And since the latter test is looking for the English denied in a non-English language formated string, the test fails in non-English versions of Windows. Does the popen2.popen4() used by the test provide return values of the execute command? Using os.system() instead seems to provide enough information: On Windows: Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import os os.system(python .) Zugriff verweigert 1 os.system(python NUL:) Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. 0 On Linux: Python 2.4.2 (#1, Oct 3 2005, 15:51:22) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type help, copyright, credits or license for more information. import os os.system(python .) 35584 os.system(python /dev/null) 0 Can you provide a patch to test_cmd_line.py? Bye, Walter Dörwald ___ 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] Patch Req. # 1351020 1351036: PythonD modifications
quote who=[EMAIL PROTECTED] On Sat, Nov 19, 2005 at 11:06:16PM +0100, Martin v. Löwis wrote: [EMAIL PROTECTED] wrote: I would appreciate feedback concerning these patches before the next PythonD (for DOS/DJGPP) is released. PEP 11 says that DOS is not supported anymore since Python 2.0. So I am -1 on reintroducing support for it. The local python community here in Sydney indicated that python.org is only upset when groups port the source to 'obscure' systems and *don't* submit patches... It is possible that I was misinformed. If we have someeone who is volunteering the time to make it work, not just today but in the future as well, we shouldn't rule out re-adding support. I am not sure about the future myself. DJGPP 2.04 has been parked at beta for two years now. It might be fair to say that the *general* DJGPP developer base has shrunk a little bit. But the PythonD userbase has actually grown since the first release three years ago. For the time being, people get very angry when the servers go down here :-) I've taken a glance at the patch. There are probably a few things to quarrel over--for instance, it looks like a site.py change will cause python to print a blank line when it's started, and the removal of a '#define HAVE_FORK 1' in posixmodule.c---but this still doesn't mean the re-addition of DOS as a supported platform should be rejected out of hand. Well, that's for sure! These patches have never been reviewed by python.org before, so I am sure that there are *plenty* of ways to better fit DOS support into the Python source. Fork will never work under DOS, no matter how much we dream :-) The empty line 'print' was a legacy error to kludge the ANSI color scheme to work correctly. Long story. It can be ignored. In fact, none of the changes to site.py are essential for python to work under DOS. They are 'additions' that most of the PythonD userbase seem to enjoy, but few knew how to do for themselves at one time. But they aren't essential tto the port. The important aspects are the path and stat stuff. Nothing works without them. I should mention that one thing that never did get ported was the build scripts themselves to accomodate DJGPP-DOS. For a complete port, we must still look at Modules/makesetup to remember that although directory separators \\ or / are OK, the path separator : is definitely not. ; must be used. So far, we have simply changed Setup and the Makefiles by hand after initial confiure. Ben - Stay ahead of the information curve. Receive MCAD news and jobs on your desktop daily. Subscribe today to the MCAD CafeNews newsletter. [ http://www10.mcadcafe.com/nl/newsletter_subscribe.php ] It's informative and essential. ___ 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] str.dedent
/ msg = textwrap.dedent('''\
// IDLE's subprocess can't connect to %s:%d. This may be due \
// to your personal firewall configuration. It is safe to \
// allow this internal connection because no data is visible on \
// external ports.''' % address)
//
/
Unfortunately, it won't help, since the 'dedent' method won't treat
those spaces as indentation.
So that it would be usefull to implicit parser dedent on string with 'd' prefix
/ msg = d'''\
// IDLE's subprocess can't connect to %s:%d. This may be due \
// to your personal firewall configuration. It is safe to \
// allow this internal connection because no data is visible on \
// external ports.''' % address/
___
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] Patch Req. # 1351020 1351036: PythonD modifications
It's not that much availability of the platform I worry about, but the commitment of the Python porter. We need somebody to forward bug reports to, and somebody to intervene if incompatible changes are made. This person would also indicate that the platform is no longer available, and hence the port can be removed. Regards, Martin I think the port has beed supported for three years now. I am not sure what kind of commitment you are looking for, but the patch and software are supplied under the same terms of liability and warranty as anything else under the GPL. Bug reports can be sent to either [EMAIL PROTECTED], [EMAIL PROTECTED] or [EMAIL PROTECTED] ___ 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] ast status, memory leaks, etc
Hello,
Purify is not so difficult to use: just run and learn to read the output ;-)
My config: Win2k using VC6sp5, and only 512Mb RAM.
I downloaded the snapshot dated 2005/11/21 05:01,
commented out #define WITH_PYMALLOC,
built in debug mode,
modified the rt.bat file to use purify,
and ran rt -d.
Here are the most important results so far :
1 - Memory error in test_coding, while importing bad_coding.py :
IPR: Invalid pointer read in tok_nextc {1 occurrence}
Reading 1 byte from 0x048af076 (1 byte at 0x048af076 illegal)
Address 0x048af076 points into a malloc'd block in unallocated
region of heap 0x0312
Thread ID: 0x718
Error location
tok_nextc [tokenizer.c:881]
tok_get[tokenizer.c:1104]
PyTokenizer_Get [tokenizer.c:1495]
parsetok [parsetok.c:125]
PyParser_ParseFileFlags [parsetok.c:89]
PyParser_ASTFromFile [pythonrun.c:1293]
parse_source_module [import.c:778]
load_source_module [import.c:905]
load_module[import.c:1665]
import_submodule [import.c:2259]
2 - Stack overflow in test_compile.test_extended_arg. No need to
Purify, the debug build is enough to reproduce the problem.
Because of the stack overflow, the test suite stopped. I ran some
random tests alone, to get memory leak reports, but there is no
significant message so far.
Today I'll try the complete test suite, excluding test_compile only.
--
Amaury
___
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] a Python interface for the AST (WAS: DRAFT: python-dev...)
I wrote (in the summary): While there is no interface to the AST yet, one is intended for the not-so-distant future. Simon Burton wrote: who is doing this ? I am mad keen to get this happening. Brett Cannon wrote: No one yet. Some ideas have been tossed around (read the thread for details), but no one has sat down to hammer out the details. Might happen at PyCon. Simon Burton wrote: Yes, i've been reading the threads but I don't see anything about a python interface. Why I'm asking is because I could probably convince my employer to let me (or an intern) work on it. And pycon is not until febuary. I am likely to start hacking on this before then. Basically, all I saw was your post asking for a Python interface[1], and a few not yet responses. I suspect that if you were to volunteer to head up the work on the Python interface, no one would be likely to stop you. ;-) [1]http://mail.python.org/pipermail/python-dev/2005-October/057611.html Steve -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ 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] a Python interface for the AST (WAS: DRAFT: python-dev...)
On 11/22/05, Brett Cannon [EMAIL PROTECTED] wrote: But if I had my way I think that having all AST objects be PyObjects and then providing support for all three ways of getting access to the AST (command-line, sys iterable, function for specific code object) would be fantastic. There needs to be a function that takes a filename (or string of code) and returns an AST. Hmm, it would be nice to give a function a module name (like from an import statement) and have Python resolve it using the normal sys.path iteration. n ___ 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] a Python interface for the AST (WAS: DRAFT: python-dev...)
On 11/22/05, Neal Norwitz [EMAIL PROTECTED] wrote: On 11/22/05, Brett Cannon [EMAIL PROTECTED] wrote: But if I had my way I think that having all AST objects be PyObjects and then providing support for all three ways of getting access to the AST (command-line, sys iterable, function for specific code object) would be fantastic. There needs to be a function that takes a filename (or string of code) and returns an AST. Yes and I guess. =) I can see the filename to check a module useful for stuff like PyChecker. But for a string of code, I don't think it would be that critical; if you provide a way to get the AST for a code object you can just pass the string to compile() and then get the AST from there. Hmm, it would be nice to give a function a module name (like from an import statement) and have Python resolve it using the normal sys.path iteration. Yep, import path - filename path would be cool. -Brett ___ 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] a Python interface for the AST (WAS: DRAFT: python-dev...)
At 06:32 PM 11/22/2005 -0800, Brett Cannon wrote: Hmm, it would be nice to give a function a module name (like from an import statement) and have Python resolve it using the normal sys.path iteration. Yep, import path - filename path would be cool. Zipped and frozen modules don't have filename paths, so I'd personally rather see fewer stdlib modules making the assumption that modules are files. Instead, extensions to the PEP 302 loader protocol should be used to support introspection, assuming there aren't already equivalent capabilities available. For example, PEP 302 allows a 'get_source()' method on loaders, and I believe the zipimport loader supports that. (I don't know about frozen modules.) The main barrier to this being really usable is the absence of loader objects for the built-in import process. This was proposed by PEP 302, but never actually implemented, probably due to time constraints on the Python 2.3 release schedule. It's relatively easy to implement this missing loader class in Python, though, and in fact the PEP 302 regression test in the stdlib does exactly that. Some work, however, would be required to port this to C and expose it from an appropriate module (imp?). ___ 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
