Re: [Python-Dev] svn diff -r {2001-01-01}

2005-11-22 Thread Oleg Broytmann 
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
[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] test_cmd_line on Windows

2005-11-22 Thread Walter Dörwald 
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 >>
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
[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] Patch Req. # 1351020 & 1351036: PythonD modifications

2005-11-22 Thread decker 

> 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
[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] str.dedent

2005-11-22 Thread Sokolov Yura 
>>/ 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
[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] Patch Req. # 1351020 & 1351036: PythonD modifications

2005-11-22 Thread Ben Decker 
> 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
[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] s/hotshot/lsprof

2005-11-22 Thread Floris Bruynooghe 
Hello

On Mon, Nov 21, 2005 at 12:14:30PM +0100, Armin Rigo wrote:
> On Sun, Nov 20, 2005 at 08:55:49PM -0500, Tim Peters wrote:
> > We should note that hotshot didn't intend to reduce total time
> > overhead.  What it's aiming at here is to be less disruptive (than
> > profile.py) to the code being profiled _while_ that code is running. 
> 
> > hotshot tries to stick with tiny little C functions that pack away a
> > tiny amount of data each time, and avoid memory alloc/dealloc, to try
> > to minimize this disruption.  It looked like it was making real
> > progress on this at one time ;-)
> 
> I see the point.  I suppose that we can discuss if hotshot is really
> nicer on the D cache, as it produces a constant stream of data, whereas
> classical profilers like lsprof would in the common case only update a
> few counters in existing data structures.  I can tweak lsprof a bit
> more, though -- there is a malloc on each call, but it could be avoided.
> 
> Still, people generally agree that profile.py, while taking a longer
> time overall, gives more meaningful results than hotshot.

When I looked into this at the beginning of the summer I could find
none around on the net.  And since hotshot had been around a lot
longer then the new lsprof I just made a conservative choice.

> Now Brett's
> student, Floris, extended hotshot to allow custom timers.  This is
> essential, because it enables testing.  The timing parts of hotshot were
> not tested previously.

Don't be too enthousiastic here.  My aim was to replicate the profile
module and thus I needed to hack this into hotshot.  However I feel
like it is not entirely in hotshot's ideals to do this.  The problem
is that the call to the timing function is accounted to the code that
is being profiled afaik.  Since a generic timer interface was needed
this means that the call goes out from the C code back to Python and
back to whatever-the-timing-function-is-writtin-in.  Thus wrongly
accounting even more time to the profiled code (not sure how long
execing a python statement takes from a C module).  Just keep this in
mind.

> Given the high correlation between untestedness and brokenness, you bet
> that Floris' adapted test_profile for hotshot gives wrong numbers.  (My
> guess is that Floris overlooked that test_profile was an output test, so
> he didn't compare the resulting numbers with the expected ones.)

Iirc I did compare the output of test_profile between profile and my
wrapper.  This was one of my checks to make sure it was wrapped
correctly.  So could you tell me how they are different?

On a stdlib note, one recommended and good working profiler would
definitely be better then two or three all with their own quirks.


Greetings
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.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] s/hotshot/lsprof

2005-11-22 Thread Floris Bruynooghe 
On Mon, Nov 21, 2005 at 12:14:26PM +0100, Armin Rigo wrote:
> Hi Brett, hi Floris,
> 
> On Sat, Nov 19, 2005 at 04:12:28PM -0800, Brett Cannon wrote:
> > Just  for everyone's FYI while we are talking about profilers, Floris
> > Bruynooghe (who I am cc'ing on this so he can contribute to the
> > conversation), for Google's Summer of Code, wrote a replacement for
> > 'profile' that uses Hotshot directly.  Thanks to his direct use of
> > Hotshot and rewrite of pstats it loads Hotshot data 30% faster and
> > also alleviates keeping 'profile' around and its slightly questionable
> > license.
> 
> Thanks for the note!  30% faster than an incredibly long time is still
> quite long, but that's an improvment, I suppose.

It is indeed still a long time.  But is was more of a secondary aim
really.

>  However, this code is
> not ready yet.  For example the new loader gives wrong results in the
> presence of recursive function calls.

Afaik I did test recursive calls etc.  I must admit that I don't think
anyone else appart form me tested it, which is far from ideal and thus
it is bound to still have bugs.

Could you provide a test case for this?

Cheers
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.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] ast status, memory leaks, etc

2005-11-22 Thread Amaury Forgeot d'Arc 
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
[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] DRAFT: python-dev Summary for 2005-11-01 through 2005-11-15

2005-11-22 Thread Tony Meyer 
Surprise!  It's November, and here's a November summary .  Thanks to all those that proofread the triple summary hit last week; if anyone can spare some time to take a look over these in the next couple of days, that would be great.  As always, corrections and suggestions to 
[EMAIL PROTECTED] or [EMAIL PROTECTED].  A couple of largish threads were skipped: one continuing discussion about freezing (I couldn't come up with a summary longer than "the heated debate continued"), and one on weak reference dereference notifications (I wasn't sure what to say).  If anyone wants those summarized, let me know (ideally with some hints!) and I'll add them in.
=Announcements=PyPy 0.8.0 and Gothenburg PyPy Sprint II`PyPy 0.8.0`_ has been released.  This third release of PyPy includes a translatable parser and AST compiler, some speed enhancements (transated PyPy is now about 10 times faster than 
0.7, but still 10-20 times slower than CPython), increased language compliancy, and some experimental features are now translatable.  This release also includes snapshots of interesting, but not yet completed, subprojects including the OOtyper (a RTyper variation for higher-level backends), a _javascript_ backend, a limited (PPC) assembler backend, and some bits for a socket module.
The next PyPy Sprint is also coming up soon.  The Gothenborg PyPy Sprint II is on the 7th to 11th of December 2005 in Gothenborg, Sweden.  Its focus is heading towards phase 2, which means JIT work, alternate threading modules, and logic programming.  Newcomer-friendly introductions will also be given.  The main topics that are currently scheduled are the L3 interpreter (a small fast interpreter for "assembler-level" flow graphs), Stackless (
e.g. Tasklets or Greenlets), porting C modules from CPython, optimization/debugging work, and logic programming in Python... _`PyPy 0.8.0`:  http://codespeak.net/pypy/dist/pypy/doc/release-0.8.0.html
 Contributing threads:(1) - `PyPy 0.8.0 is released! `__(1) - `Gothenburg PyPy Sprint II: 7th - 11th December 2005 `__[TAM]PyCon Sprint suggestionsEvery PyCon has featured a python-dev `sprint`_.  For the past few years, hacking on the AST branch has been a tradition, but since the AST branch has now been merged into the trunk, other options are worth considering this year.  Several PEP implementations were suggested, including `PEP 343`_ ('with:'), `PEP 308`_ ('x if y else z'), `PEP 328`_ ('absolute/relative import'), and `PEP 341`_ ('unifying try/except and try/finally').
Suggestions to continue the AST theme were also made, including one of the "global variable speedup" PEPs, `Guido's instance variable speedup idea`_, using the new AST code to improve/extend/rewrite the optimization steps the compiler performs, or rewriting PyChecker to operate from the AST representation.
Phillip J. Eby also suggested working on the oft-mentioned bytes type.  All of these suggestions, as well as any others that are made, are being recorded on the `PythonCore sprint wiki`_. .. _sprint: 
http://wiki.python.org/moin/PyCon2006/Sprints .. _PEP 343: http://www.python.org/peps/pep-0343.html .. _PEP 308: 
http://www.python.org/peps/pep-0308.html .. _PEP 328: http://www.python.org/peps/pep-0328.html .. _PEP 341: 
http://www.python.org/peps/pep-0341.html .. _Guido's instance variable speedup idea: http://mail.python.org/pipermail/python-dev/2002-February/019854.html
 .. _PythonCore sprint wiki: http://wiki.python.org/moin/PyCon2006/Sprints/PythonCoreContributing threads:(13) - `python-dev sprint at PyCon <
http://mail.python.org/pipermail/python-dev/2005-November/057830.html>`__(1) - `PEP 328 - absolute imports (python-dev sprint at PyCon) <
http://mail.python.org/pipermail/python-dev/2005-November/057853.html>`__[TAM]--
Reminder: Python is now on Subversion!--Just a reminder to everyone that the Python source repository_ is now hosted on Subversion.  A few minor bugs were fixed, so you can make SVK mirrors of the repository successfully now.  Be sure to check out the newly revised Python Developers FAQ_ if you haven't already.
.. _repository: http://svn.python.org/projects/.. _FAQ: http://www.python.org/dev/devfaq.htmlContributing threads:
(4) - `Freezing the CVS on Oct 26 for SVN switchover `__
(1) - `svn checksum error `__(6) - `Problems with revision 4077 of new SVN repository <
http://mail.python.org/pipermail/python-dev/2005-November/057867.html>`__(4) - `No more problems with new SVN repository <
http://mail.python.org/pipermail/

Re: [Python-Dev] s/hotshot/lsprof

2005-11-22 Thread Armin Rigo 
Hi Brett,

On Mon, Nov 21, 2005 at 11:35:37PM -0800, Brett Cannon wrote:
> (any chance we can replace profile with a wrapper to lsprof
> without much issue?)

Yes.  In fact I am thinking about adding lsprof under the module name
'cProfile', to keep true to the (IMHO) good tradition of pickle/cPickle
and StringIO/cStringIO.

We could also just call it 'profile' and drop the existing profile.py,
but I'm not in favor of that.  Having pure Python equivalent of our
modules is good.  When I am in a good mood I am thinking that it would
instead be fun to rewrite profile.py to look exactly like lsprof.  Not
sure pstats would be that much fun, though, and I can't be bothered by
license issues too much.  However cares can probably derive a pstats
replacement from the Summer of Code project.


A bientot,

Armin.
___
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] Proposed additional keyword argument in logging calls

2005-11-22 Thread Vinay Sajip 
On numerous occasions, requests have been made for the ability to easily add
user-defined data to logging events. For example, a multi-threaded server
application may want to output specific information to a particular server
thread (e.g. the identity of the client, specific protocol options for the
client connection, etc.)

This is currently possible, but you have to subclass the Logger class and
override its makeRecord method to put custom attributes in the LogRecord.
These can then be output using a customised format string containing e.g.
"%(foo)s %(bar)d". The approach is usable but requires more work than
necessary.

I'd like to propose a simpler way of achieving the same result, which
requires use of an additional optional keyword argument in logging calls.
The signature of the (internal) Logger._log method would change from

  def _log(self, level, msg, args, exc_info=None)

to

  def _log(self, level, msg, args, exc_info=None, extra_info=None)

The extra_info argument will be passed to Logger.makeRecord, whose signature
will change from

  def makeRecord(self, name, level, fn, lno, msg, args, exc_info):

to

  def makeRecord(self, name, level, fn, lno, msg, args, exc_info,
extra_info)

makeRecord will, after doing what it does now, use the extra_info argument
as follows:

If type(extra_info) != types.DictType, it will be ignored.

Otherwise, any entries in extra_info whose keys are not already in the
LogRecord's __dict__ will be added to the LogRecord's __dict__.

Can anyone see any problems with this approach? If not, I propose to post
the approach on python-list and then if there are no strong objections,
check it in to the trunk. (Since it could break existing code, I'm assuming
(please correct me if I'm wrong) that it shouldn't go into the
release24-maint branch.)

Of course, if anyone can suggest a better way of doing it, I'm all ears :-)

Regards,


Vinay Sajip

___
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] ast status, memory leaks, etc

2005-11-22 Thread Neal Norwitz 
On 11/22/05, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Purify is not so difficult to use: just run and learn to read the output ;-)

Amaury,

Thank you for running Purify.

> 1 - Memory error in test_coding, while importing bad_coding.py :
> IPR: Invalid pointer read in tok_nextc {1 occurrence}

There is a patch for this on SourceForge.  It's pretty new.

> 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.

Great.  Thanks!

n
___
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] DRAFT: python-dev Summary for 2005-10-16 to 2005-10-31

2005-11-22 Thread Brett Cannon 
On 11/21/05, Simon Burton <[EMAIL PROTECTED]> wrote:
> On Thu, 17 Nov 2005 13:36:36 +1300
> Tony Meyer <[EMAIL PROTECTED]> wrote:
>
> >
> > --
> > AST for Python
> > --
> >
> > As of October 21st, Python's compiler now uses a real Abstract Syntax
> > Tree (AST)!  This should make experimenting with new syntax much
> > easier, as well as allowing some optimizations that were difficult
> > with the previous Concrete Syntax Tree (CST).
>
> > While there is no
> > Python interface to the AST yet, one is intended for the not-so-
> > distant future.
>
> OK, who is doing this ? I am mad keen to get this happening.
>

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.

-Brett
___
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] ast status, memory leaks, etc

2005-11-22 Thread Gustavo Sverzut Barbieri 
On 11/20/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> Thanks I was going to look into the resizing and forgot about it.
> Running without pymalloc confirmed that there weren't more serious
> problems.

At least with gentoo's Python 2.4.2, I get a bunch of errors from
invalid  reads and jumps/moves that depends on unitialized values in
PyObject_Free().

Running:

valgrind --leak-check=full --leak-resolution=high --show-reachable=yes
python -c "pass" 2> ~/python-2.4.2-valgrind.log

gives me the attached log file.

--
Gustavo Sverzut Barbieri
--
Computer Engineer 2001 - UNICAMP
Mobile: +55 (19) 9165 8010
 Phone:  +1 (347) 624 6296 @ sip.stanaphone.com
Jabber: [EMAIL PROTECTED]
  ICQ#: 17249123
   MSN: [EMAIL PROTECTED]
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net


python-2.4.2-valgrind.log.bz2
Description: BZip2 compressed data
___
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] ast status, memory leaks, etc

2005-11-22 Thread Fredrik Lundh 
Gustavo Sverzut Barbieri wrote:

> At least with gentoo's Python 2.4.2, I get a bunch of errors from
> invalid  reads and jumps/moves that depends on unitialized values in
> PyObject_Free().
>
> Running:
>
> valgrind --leak-check=full --leak-resolution=high --show-reachable=yes
> python -c "pass" 2> ~/python-2.4.2-valgrind.log


did you read the instructions ?

$ more Misc/README.valgrind

http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Misc/README.valgrind?view=markup

 



___
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] Proposed additional keyword argument in logging calls

2005-11-22 Thread Paul Moore 
On 11/22/05, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> makeRecord will, after doing what it does now, use the extra_info argument
> as follows:
>
> If type(extra_info) != types.DictType, it will be ignored.
>
> Otherwise, any entries in extra_info whose keys are not already in the
> LogRecord's __dict__ will be added to the LogRecord's __dict__.
>
> Can anyone see any problems with this approach?

I'd suggest that you raise an error if extra_info doesn't act like a
dictionary - probably, just try to add its entries and let any error
pass back to the caller. You definitely want to allow dict subclasses,
and anything that acts like a dictionary. And you want to catch errors
like

log(..., extra_info = "whatever")

with a format of "... %(extra_info)s..." (ie, assuming that extra_info
is a single value - it's what I expected you to propose when I started
reading).

The rest looks good (I don't have a need for it myself, but it looks
like a nice, clean solution to the problem you describe).

Paul.
___
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] something is wrong with test___all__

2005-11-22 Thread Reinhold Birkenfeld 
Hi,

on my machine, "make test" hangs at test_colorsys.

Careful investigation shows that when the bytecode is freshly generated
by "make all" (precisely in test___all__) the .pyc file is different from what a
direct call to "regrtest.py test_colorsys" produces.

Curiously, a call to "regrtest.py test___all__" instead of "make test" produces
the correct bytecode.

I can only suspect some AST bug here.

Reinhold

-- 
Mail address is perfectly valid!

___
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] DRAFT: python-dev Summary for 2005-10-16 to 2005-10-31

2005-11-22 Thread Simon Burton 
On Tue, 22 Nov 2005 11:31:34 -0800
Brett Cannon <[EMAIL PROTECTED]> wrote:

> 
> On 11/21/05, Simon Burton <[EMAIL PROTECTED]> wrote:
> > On Thu, 17 Nov 2005 13:36:36 +1300
> > Tony Meyer <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > --
> > > AST for Python
> > > --
> > >
> > > As of October 21st, Python's compiler now uses a real Abstract Syntax
> > > Tree (AST)!  This should make experimenting with new syntax much
> > > easier, as well as allowing some optimizations that were difficult
> > > with the previous Concrete Syntax Tree (CST).
> >
> > > While there is no
> > > Python interface to the AST yet, one is intended for the not-so-
> > > distant future.
> >
> > OK, who is doing this ? I am mad keen to get this happening.
> >
> 
> 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.
> 
> -Brett

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.

Simon.

-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 
___
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] a Python interface for the AST (WAS: DRAFT: python-dev...)

2005-11-22 Thread Steven Bethard 
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
[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] a Python interface for the AST (WAS: DRAFT: python-dev...)

2005-11-22 Thread Brett Cannon 
On 11/22/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> 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
>

All of the discussion has just been "we hope to have it some day" with
no real planning.  =)  There are two problems to this topic; how to
get the AST structs into Python objects and how to allow Python code
to modify the AST before bytecode emission (or perhaps even after for
in-place optimization).

To get the AST into Python objects, there are two options.  One is to
use the AST grammar to generate struct -> serialized form -> Python
objects and vice-versa.  There might be some rough code already there
in the form of emitting a string that looks like Scheme code that
represents the AST.  Then Python code could use that to make up
objects, manipulate, translate back into its serialized form, and then
back into the AST structs.  It sounds like a lot but with the grammar
right there it should be an automated generation of code to make.

The other option is to have all AST structs be contained in PyObjects.
 Neil suggested this for the whole memory problem since we could then
just do proper refcounting and we all know how to do that (supposedly
=) .  With that then all it is to get access is to pass the PyObject
of the root out and make sure that the proper attributes or accessor
methods (I prefer the former) are available.  Once again this can be
auto-generated from the AST grammar.

The second problem is where to give access to the AST from within
Python.  One place is the command-line.  One could be able to specify
the path to function objects (using import syntax, e.g.,
``optimizations.static.folding``) on the command-line that are always
applied to all generated bytecode.  Another possibility is to have an
iterable in sys that is iterated over everytime something has bytecode
generated.  Each call to the iterator would return a function that
took in an AST object and returned an AST object.  Another possibility
is to have a function (like ``ast()`` as a built-in)  to pass in a
code object and then have the AST returned for that code object.  If a
function was provided that took an AST and returned the bytecode then
selective AST access can be given instead of applying across the board
(this could allow for decorators that performed AST optimizations or
even hotshot stuff).

Obvously this is all pie-in-the-sky stuff.  Getting the memory leak
situation resolved is a bigger priority in my mind than any of this.
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.

-Brett
___
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] a Python interface for the AST (WAS: DRAFT: python-dev...)

2005-11-22 Thread Neal Norwitz 
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
[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] a Python interface for the AST (WAS: DRAFT: python-dev...)

2005-11-22 Thread Brett Cannon 
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
[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] a Python interface for the AST (WAS: DRAFT: python-dev...)

2005-11-22 Thread Phillip J. Eby 
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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com