headers
Greg Ewing | 1 Mar 2004 01:27
Picon
Picon
Favicon

Re: Re: new syntax for wrapping (PEP 318)

Paul Prescod <paul <at> prescod.net>:

> def foo(self) <classmethod, hiddenmethod>:
> 	pass

Because it looks unspeakably ugly!

-1.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg <at> cosc.canterbury.ac.nz	   +--------------------------------------+

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Greg Ewing | 1 Mar 2004 02:08
Picon
Picon
Favicon

Re: other uses for "as" [was Re: new syntax for wrapping (PEP 318)]

"Phillip J. Eby" <pje <at> telecommunity.com>:

> "as" looks like syntax that should be reserved 
> for adaptation at a future time.  :)

I'd also like to see "as" reserved for possible future use
to specify a metaclass in class declarations, which is relevant
if we want class decorators with the same syntax as function
decorators.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg <at> cosc.canterbury.ac.nz	   +--------------------------------------+

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Greg Ewing | 1 Mar 2004 05:06
Picon
Picon
Favicon

Re: Re: Optional separatorargument for file.writelines() and StringIO.writelines()

Vernon Cole <kf7xm <at> netscape.net>:

> Only in *nix does a linefeed charactor equate to the end of a line in
> a text file.  So, in every output line of every program I must pretend
> to be a C programmer and append a '\n' so that the runtime system can
> replace it with the actual End-of-Line used by my operating system.

Seems to me the 'n' in '\n' is meant to stand for "newline",
not "linefeed". So it's already named in an OS-independent
way.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg <at> cosc.canterbury.ac.nz	   +--------------------------------------+

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Michael Hudson | 1 Mar 2004 11:52
Favicon

Re: Idea for a fast calling convention

Christian Tismer <tismer <at> stackless.com> writes:

> p.s.: I believe some automatic source analysis and rewrite might pay
> off in other areas as well. Grepping through the sources, there are
> still very many similar patterns of PyArg_ParseTupleXXX calls, which
> could be replaced by less general, optimized versions.  This would
> even *not* cause code bloat, since all those calling sequences would
> be smaller than now.

Well, yes.  C sucks seriously for things like this, though.  It's
frankly embarassing that *every* time, say, ''.split() is called, some
silly string is being parsed.  Unclear what to do about this (excpet
PyPy, I guess).

Cheers,
mwh

--

-- 
  I have a feeling that any simple problem can be made arbitrarily
  difficult by imposing a suitably heavy administrative process
  around the development.       -- Joe Armstrong, comp.lang.functional

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 4 comments |
headers
Bob Ippolito | 1 Mar 2004 13:01
Gravatar

Re: Idea for a fast calling convention


On Mar 1, 2004, at 5:52 AM, Michael Hudson wrote:

> Christian Tismer <tismer <at> stackless.com> writes:
>
>> p.s.: I believe some automatic source analysis and rewrite might pay
>> off in other areas as well. Grepping through the sources, there are
>> still very many similar patterns of PyArg_ParseTupleXXX calls, which
>> could be replaced by less general, optimized versions.  This would
>> even *not* cause code bloat, since all those calling sequences would
>> be smaller than now.
>
> Well, yes.  C sucks seriously for things like this, though.  It's
> frankly embarassing that *every* time, say, ''.split() is called, some
> silly string is being parsed.  Unclear what to do about this (excpet
> PyPy, I guess).

Surely there's other reasonable options.  For example, we could start 
using something like Pyrex that could be modified to generate whatever 
gnarly C code needs to happen for optimal runtime performance with 
minimal input ugliness :)

-bob

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Hudson | 1 Mar 2004 13:15
Favicon

Re: Idea for a fast calling convention

Bob Ippolito <bob <at> redivi.com> writes:

> On Mar 1, 2004, at 5:52 AM, Michael Hudson wrote:
>
>> Well, yes.  C sucks seriously for things like this, though.  It's
>> frankly embarassing that *every* time, say, ''.split() is called, some
>> silly string is being parsed.  Unclear what to do about this (excpet
>> PyPy, I guess).
>
> Surely there's other reasonable options.  For example, we could start
> using something like Pyrex that could be modified to generate whatever
> gnarly C code needs to happen for optimal runtime performance with
> minimal input ugliness :)

Hmm, yes, I hadn't thought of pyrex.

It also hadn't occured to me that pyrex might be desirable because the
result might be more efficient, but I guess that's not so surprising.

Cheers,
mwh

--

-- 
  Guido (like us!) is a bit schizophrenic here: he wants to be a
  benevolent dictator, but also wants to treat people like
  grownups. This probably worked better before Python got a large
  American audience <0.9 wink>.             -- Tim Peters, 10 Feb 2000

_______________________________________________
Python-Dev mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Tismer | 1 Mar 2004 14:04
Gravatar

Re: Idea for a fast calling convention

Michael Hudson wrote:

> Christian Tismer <tismer <at> stackless.com> writes:
> 
> 
>>p.s.: I believe some automatic source analysis and rewrite might pay
>>off in other areas as well. Grepping through the sources, there are
>>still very many similar patterns of PyArg_ParseTupleXXX calls, which
>>could be replaced by less general, optimized versions.  This would
>>even *not* cause code bloat, since all those calling sequences would
>>be smaller than now.
> 
> 
> Well, yes.  C sucks seriously for things like this, though.  It's
> frankly embarassing that *every* time, say, ''.split() is called, some
> silly string is being parsed.  Unclear what to do about this (excpet
> PyPy, I guess).

Why not a switch over the arg tuple size?
Or do you mean, this happens in so many different places that
it would be tedious to change that by hand.
Sure, we should not try to morph Pytho into PyPy in the first
place.
But maybe some runtime analysis with a modified version
of PyArg_Parse... things, we could see how often which
format string appears, and how often which optional paths
are used, as a hint for hand optimisation.

I could do that with Stackless, btw. For Win32, I have a few
introspection tools which can do C stack analysis from
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeremy Hylton | 1 Mar 2004 15:53
Picon
Favicon

Re: How to debug pyexpat SIGSEGV with GDB?

On Fri, 2004-02-27 at 18:00, Brad Clements wrote:
> So, how can I figure out where in the Python source the function call is coming from 
> using gdb? I'm sure it involves "print" and some casts.. I couldn't find a howto on 
> python.org

First, make sure that the code from Misc/gdbinit is in your .gdbinit
file.  Get the stack trace in gdb and move up/down until you get to an
eval_frame() frame.  Then call the function pyframe.  It will print the
filename, function name, and line number of the current frame.  The
lineno usually points to the first line of the function.

Jeremy

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 4 comments |
headers
Skip Montanaro | 1 Mar 2004 16:09
Picon
Favicon

Re: How to debug pyexpat SIGSEGV with GDB?


    >> So, how can I figure out where in the Python source the function call
    >> is coming from using gdb? I'm sure it involves "print" and some
    >> casts.. I couldn't find a howto on python.org

    Jeremy> First, make sure that the code from Misc/gdbinit is in your
    Jeremy> .gdbinit file.  Get the stack trace in gdb and move up/down
    Jeremy> until you get to an eval_frame() frame.  Then call the function
    Jeremy> pyframe.  It will print the filename, function name, and line
    Jeremy> number of the current frame.  The lineno usually points to the
    Jeremy> first line of the function.

I have this in my .gdbinit file:

    define ppystack
        while $pc < Py_Main || $pc > Py_GetArgcArgv
            if $pc > eval_frame && $pc < PyEval_EvalCodeEx
                set $__fn = PyString_AsString(co->co_filename)
                set $__n = PyString_AsString(co->co_name)
                printf "%s (%d): %s\n",  $__fn, f->f_lineno, $__n
            end
            up-silently 1
        end
        select-frame 0
    end

Skip

_______________________________________________
Python-Dev mailing list
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jeremy Hylton | 1 Mar 2004 16:16
Picon
Favicon

Re: How to debug pyexpat SIGSEGV with GDB?

On Mon, 2004-03-01 at 10:09, Skip Montanaro wrote:
>     >> So, how can I figure out where in the Python source the function call
>     >> is coming from using gdb? I'm sure it involves "print" and some
>     >> casts.. I couldn't find a howto on python.org
> 
>     Jeremy> First, make sure that the code from Misc/gdbinit is in your
>     Jeremy> .gdbinit file.  Get the stack trace in gdb and move up/down
>     Jeremy> until you get to an eval_frame() frame.  Then call the function
>     Jeremy> pyframe.  It will print the filename, function name, and line
>     Jeremy> number of the current frame.  The lineno usually points to the
>     Jeremy> first line of the function.
> 
> I have this in my .gdbinit file:
> 
>     define ppystack
>         while $pc < Py_Main || $pc > Py_GetArgcArgv
>             if $pc > eval_frame && $pc < PyEval_EvalCodeEx
>                 set $__fn = PyString_AsString(co->co_filename)
>                 set $__n = PyString_AsString(co->co_name)
>                 printf "%s (%d): %s\n",  $__fn, f->f_lineno, $__n
>             end
>             up-silently 1
>         end
>         select-frame 0
>     end

That's nice!  I never learned how to write real programs in gdb.
You should add a copy to gdbinit.

Jeremy
(Continue reading)

Permalink | Reply | 2 comments |

Gmane