patch pumpkin

[Aaron Swartz]

I know, as usual, I've been lagging on applying patches to web.py.
That's why I've named Anand as patch pumpkin. He now has commit access
to the repository and permission to commit any uncontrovertial patches
sent to the list.

If this works well, perhaps more people can get commit access. Also,
perhaps Anand can develop a new version that uses return codes instead
of print statements and other good stuff.

[Tim Riley]

As indicated in other threads replacing print with return codes is not what the entire community wants. If we're talking about getting rid of print in favor of return values then I am 100% against it. I don't think changing web.py's design to appease a certain percentage of developers is a wise choice.

[Tom Berger]

On 12/19/06, Tim Riley <ril...@gmail.com> wrote:

As indicated in other threads replacing print with return codes is not what the entire community wants.

It should be possible to have both.

In ZOPE we used to have a special variable called 'printed' that holds the accumulated stuff from print statements, so you could, for example, write:

print 'this'
print 'that'
return transform(printed)

In addition to that, we could use 'printed' if the function hasn't returned anything (so that existing code doesn't break and those users who like the print idiom better than return aren't dissapointed).

Tom

b.t.w Good Luck, Anand, and thank you Aaron for servicing the community so well.



--
http://intellectronica.net/

[David Terrell]

On Tue, Dec 19, 2006 at 04:38:29PM +0000, Tom Berger wrote:
> On 12/19/06, Tim Riley <ril...@gmail.com> wrote:
> >
> > As indicated in other threads replacing print with return codes is not
> > what the entire community wants.
> >
>
> It should be possible to have both.
>
> In ZOPE we used to have a special variable called 'printed' that holds the
> accumulated stuff from print statements, so you could, for example, write:
>
> print 'this'
> print 'that'
> return transform(printed)
>
> In addition to that, we could use 'printed' if the function hasn't returned
> anything (so that existing code doesn't break and those users who like the
> print idiom better than return aren't dissapointed).

No offense, but I don't want to have to think about stuff like that --
that's why I use something transparent like webpy. If I want rich and
complex, I'll use something else -- web.py doesn't have to be everything
to everybody, that's what is great about having 700 python web frameworks.

> b.t.w Good Luck, Anand, and thank you Aaron for servicing the community so
> well.

Indeed. Many hands make light work.

--
David Terrell
d...@meat.net
((meatspace)) http://meat.net/

[Tom Berger]

On 12/19/06, David Terrell <d...@meat.net> wrote:

> It should be possible to have both.
>

> .. a special variable called 'printed' that holds the accumulated stuff from print statements ...
> In addition to that, we could use 'printed' if the function hasn't returned anything ...

I don't want to have to think about stuff like that

Yes, but the point of this proposal is that you wont have to change the way you think - things will exactly the way they used to - return will simply be an additional new feature.

Tom



--
http://intellectronica.net/

[Anand]

On 19-Dec-06, at 10:08 PM, Tom Berger wrote:

On 12/19/06, Tim Riley <ril...@gmail.com> wrote:

As indicated in other threads replacing print with return codes is not what the entire community wants.

It should be possible to have both.

In ZOPE we used to have a special variable called 'printed' that holds the accumulated stuff from print statements, so you could, for example, write:

print 'this'
print 'that'
return transform(printed)

In addition to that, we could use 'printed' if the function hasn't returned anything (so that existing code doesn't break and those users who like the print idiom better than return aren't dissapointed). 

I think having both of them is not very nice. 

I am happy to use either if both gives the functionality i want. But the problem with prints is it doesnt allow me to reuse/pipeline the code.

Also `print >> web.debug` is painful. We can use print for debug.

If returns is a better way, then i think its okay to break the backward compatability, as it happend before[1].

[1]: http://webpy.infogami.com/v2_CHANGELOG

b.t.w Good Luck, Anand, and thank you Aaron for servicing the community so well.

Thanks.

[Tom Berger]

On 12/19/06, Anand <anand...@gmail.com> wrote:

I think having both [print and return] is not very nice. 

Well, that's a matter of taste, of course. The point is that you never have to use both of them. Is your objection more from a maintainer's point-of-view, or do you think that providing more than one way of doing things is unpythonic?

I am happy to use either if both gives the functionality i want. But the problem with prints is it doesnt allow me to reuse/pipeline the code.

I agree that return is overall a nicer way of doing things. I would almost certainly choose to use return if it was available. In fact i find myself doing tricks to work that way with the current framework already.

If returns is a better way, then i think its okay to break the backward compatability, as it happend before[1].

I think that as web.py gains more users it becomes less and less responsible to do that (especially if you don't keep maintaining older branches). I, for example, have several large-ish projects using web.py to maintain and I'd hate to have to change the program whenever I want to upgrade web.py (to benefit from a bug-fix or a new useful feature, for example).

[1]: http://webpy.infogami.com/v2_CHANGELOG

Upgrading to v2 was somewhat painful, to be honest, and none of the changes were as big as this one.

Finally, the print idiom is not necessarily a bad one in cases where the only other option would be string concatenation or accumulation.

My choice would be, in order of preference:
1. print + return
2. return
3. print
4. ruby on rails :)


Tom

--
http://intellectronica.net/

[Anand]

On 19-Dec-06, at 11:26 PM, Tom Berger wrote:

On 12/19/06, Anand <anand...@gmail.com> wrote:

I think having both [print and return] is not very nice. 

Well, that's a matter of taste, of course. The point is that you never have to use both of them. Is your objection more from a maintainer's point-of-view, or do you think that providing more than one way of doing things is unpythonic?

may be.

I think that as web.py gains more users it becomes less and less responsible to do that (especially if you don't keep maintaining older branches). I, for example, have several large-ish projects using web.py to maintain and I'd hate to have to change the program whenever I want to upgrade web.py (to benefit from a bug-fix or a new useful feature, for example).

I agree. we should make sure migration to new version is not painful.

It can be done is two ways.

1. as you suggested keep both print and return

2. print is supported if you set web.config.enable_print or something like that. (here print is supported just for backward compatibility)

[1]: http://webpy.infogami.com/v2_CHANGELOG

Upgrading to v2 was somewhat painful, to be honest, and none of the changes were as big as this one.

upvars was a big change.

Finally, the print idiom is not necessarily a bad one in cases where the only other option would be string concatenation or accumulation.

You can use yield as well.

My choice would be, in order of preference:
1. print + return
2. return
3. print
4. ruby on rails :)

This is my choice:

1 . return

2. print + return

3. print 

[krypton]

2. print + return
2. print + return
2. print + return

[Tom Berger]

On 12/20/06, Anand <anand...@gmail.com> wrote:

Finally, the print idiom is not necessarily a bad one in cases where the only other option would be string concatenation or accumulation.

You can use yield as well.

Interesting - I'm not sure I understand how you want to use it. Are you suggesting that request handlers become some kind of line generators?

Tom



--
http://intellectronica.net/

[Tom Berger]

On 12/19/06, Tom Berger <tom.b...@gmail.com> wrote:

In ZOPE we used to have a special variable called 'printed' that holds the accumulated stuff from print statements

But that's, of course, only possible thanks to code manipulation at the AST level, and that's much more magic than I'd like to have in a library :-/

Tom



--
http://intellectronica.net/

[Jonathan Ballet]

On 19 déc, 03:48, "Aaron Swartz" <m...@aaronsw.com> wrote:
> That's why I've named Anand as patch pumpkin. He now has commit access
> to the repository and permission to commit any uncontrovertial patches
> sent to the list.

Anand, you may have a look at this too :
http://groups-beta.google.com/group/webpy/browse_thread/thread/e69acd5722a30708/3152d5145e0d181e?lnk=gst&rnum=1#3152d5145e0d181e