Hi, There was a tense discussion about the flask.g object on #pocoo with the MoinMoin team earlier today. The point made by Thomas Waldmann was that one letter names should be abolished and that it should be renamed to "flask.flaskg" instead. Now my point here is that if someone does not like the name, they can still do something like "from flask import g as flaskg" and use whatever name they like. Even better, that import could go into an utility module in the application "from yourapplication import flaskg" My point against renaming it is: flaskg is a bad name and unless someone better is found I will not accept it. It requires changes in existing code for no real value and extensions that expect g will have to do a conditional import to switch between older Flask versions and Flask versions where g was renamed. Because unfortunately Thomas does not like mailinglists and is not happy with joining that discussion here, but I would like to get everybody involved into the discussion here what has been said so far: ThomasWaldmann: http://doodle.com/ky7zcvt93p6yy5ey ThomasWaldmann finds the flaskg option a bit boring and kind of redundant, but i could live with that also. almost everything's better than just g. mitsuhiko: i don't quite see the problem of doing "from flask import g as app_globals" ThomasWaldmann: but there are quite some people who dislike single letter mitsuhiko: and again, i don't see the problem with a single letter mitsuhiko: each editor has ways to search with word boundaries mitsuhiko: in vim it's a matter of hitting '*' mitsuhiko: grep does this too: mitsuhiko: $ grep '\bg\b' flask/*.py|wc mitsuhiko: 9 40 563 ThomasWaldmann: and the only change needed in flask is: flaskg = g = ... mitsuhiko: i am very conservative with changes regarding naming mitsuhiko: i will never introduce aliases unless for backwards compat mitsuhiko: i am fine with changing it, but it needs a broad acceptance mitsuhiko: and flaskg is a bad name mitsuhiko: and i don't see the advantage over import as at all mitsuhiko: you will only grep your own code anyways ThomasWaldmann: shall I pull some other style doc now that explains that single-letter is bad or do we all know that? mitsuhiko: and you can easily do "from flask import g as app_globals" : MoinMoin/utils.py mitsuhiko: and then do from MoinMoin.utils import app_globals mitsuhiko: ThomasWaldmann: bring it up on the mailinglist (or let someone else bring it up) and start a proper poll there ThomasWaldmann: so you think it is great if every flask user invents his own alias? mitsuhiko: which includes the vote for: don't change mitsuhiko: i especially will not change things just because one small part of the community wants something changed, for that there are too many users :) ThomasWaldmann: i won't discuss on ML This transcript is shortened, the full version can be found on the IRC archives on the Flask website / dev.pocoo.org Everybody who wants g to be renamed, please feel free to reply to this thread and provide some good alternative names an reasons for changing the name. I am happy to do this as long as we have the majority of the community behind it. And as this is a backwards incompatible change I would like to see 70% of the community behind it. Regards, Armin
On Tue, Aug 3, 2010 at 7:27 AM, Armin Ronacher <armin.ronacher@active-4.com> wrote: > Hi, > > > Everybody who wants g to be renamed, please feel free to reply to this > thread and provide some good alternative names an reasons for changing > the name. I am happy to do this as long as we have the majority of the > community behind it. And as this is a backwards incompatible change I > would like to see 70% of the community behind it. > This has been discussed many times in Pylons/TurboGears and from time to time someone comes up with the "single letter variables are evil" argument on the ML and/or IRC. At last Ben gave in and did the double naming thing and the old names are deprecated. IMO it is better to have the "long name internally" and the short name externally if you want it. That is in your flask app you will do something like from flash import app_globals as g The opposite is a little harder and people will probably not use it. That said this is going to come up several times. So bikeshedding it will be a nice sport. My personal opinion is that g is fine as long as everyone is ok with it.
Hi, There was a tense discussion about the flask.g object on #pocoo with the MoinMoin team earlier today. The point made by Thomas Waldmann was that one letter names should be abolished and that it should be renamed to "flask.flaskg" instead. Now my point here is that if someone does not like the name, they can still do something like "from flask import g as flaskg" and use whatever name they like. Even better, that import could go into an utility module in the application "from yourapplication import flaskg" My point against renaming it is: flaskg is a bad name and unless someone better is found I will not accept it. It requires changes in existing code for no real value and extensions that expect g will have to do a conditional import to switch between older Flask versions and Flask versions where g was renamed. Because unfortunately Thomas does not like mailinglists and is not happy with joining that discussion here, but I would like to get everybody involved into the discussion here what has been said so far: ThomasWaldmann: http://doodle.com/ky7zcvt93p6yy5ey ThomasWaldmann finds the flaskg option a bit boring and kind of redundant, but i could live with that also. almost everything's better than just g. mitsuhiko: i don't quite see the problem of doing "from flask import g as app_globals" ThomasWaldmann: but there are quite some people who dislike single letter mitsuhiko: and again, i don't see the problem with a single letter mitsuhiko: each editor has ways to search with word boundaries mitsuhiko: in vim it's a matter of hitting '*' mitsuhiko: grep does this too: mitsuhiko: $ grep '\bg\b' flask/*.py|wc mitsuhiko: 9 40 563 ThomasWaldmann: and the only change needed in flask is: flaskg = g = ... mitsuhiko: i am very conservative with changes regarding naming mitsuhiko: i will never introduce aliases unless for backwards compat mitsuhiko: i am fine with changing it, but it needs a broad acceptance mitsuhiko: and flaskg is a bad name mitsuhiko: and i don't see the advantage over import as at all mitsuhiko: you will only grep your own code anyways ThomasWaldmann: shall I pull some other style doc now that explains that single-letter is bad or do we all know that? mitsuhiko: and you can easily do "from flask import g as app_globals" : MoinMoin/utils.py mitsuhiko: and then do from MoinMoin.utils import app_globals mitsuhiko: ThomasWaldmann: bring it up on the mailinglist (or let someone else bring it up) and start a proper poll there ThomasWaldmann: so you think it is great if every flask user invents his own alias? mitsuhiko: which includes the vote for: don't change mitsuhiko: i especially will not change things just because one small part of the community wants something changed, for that there are too many users :) ThomasWaldmann: i won't discuss on ML This transcript is shortened, the full version can be found on the IRC archives on the Flask website / dev.pocoo.org Everybody who wants g to be renamed, please feel free to reply to this thread and provide some good alternative names an reasons for changing the name. I am happy to do this as long as we have the majority of the community behind it. And as this is a backwards incompatible change I would like to see 70% of the community behind it. Regards, Armin
Personally I don't have a problem with it, it's just a convention you get used to and it's convenient. If you had to name it something else, go with app_globals or global_data or something, anything but flaskg. On the subject of naming (and slightly OT): The variable _request_ctx_stack is underscored, as in private, and IMHO should be aliased as it frequently used (and documented) out of module scope : request_stack or request_context for example. I feel a bit uncomfortable using a private variable as that could be subject to internal design. On 3 August 2010 12:28, Armin Ronacher <armin.ronacher@active-4.com> wrote: > Hi, > > There was a tense discussion about the flask.g object on #pocoo with the > MoinMoin team earlier today. The point made by Thomas Waldmann was that > one letter names should be abolished and that it should be renamed to > "flask.flaskg" instead. > > Now my point here is that if someone does not like the name, they can > still do something like "from flask import g as flaskg" and use whatever > name they like. Even better, that import could go into an utility > module in the application "from yourapplication import flaskg" > > My point against renaming it is: flaskg is a bad name and unless someone > better is found I will not accept it. It requires changes in existing > code for no real value and extensions that expect g will have to do a > conditional import to switch between older Flask versions and Flask > versions where g was renamed. > > Because unfortunately Thomas does not like mailinglists and is not happy > with joining that discussion here, but I would like to get everybody > involved into the discussion here what has been said so far: > > ThomasWaldmann: http://doodle.com/ky7zcvt93p6yy5ey > ThomasWaldmann finds the flaskg option a bit boring and kind of > redundant, but i could live with that also. almost everything's better > than just g. > mitsuhiko: i don't quite see the problem of doing "from flask import g > as app_globals" > ThomasWaldmann: but there are quite some people who dislike single letter > mitsuhiko: and again, i don't see the problem with a single letter > mitsuhiko: each editor has ways to search with word boundaries > mitsuhiko: in vim it's a matter of hitting '*' > mitsuhiko: grep does this too: > mitsuhiko: $ grep '\bg\b' flask/*.py|wc > mitsuhiko: 9 40 563 > ThomasWaldmann: and the only change needed in flask is: flaskg = g = ... > mitsuhiko: i am very conservative with changes regarding naming > mitsuhiko: i will never introduce aliases unless for backwards compat > mitsuhiko: i am fine with changing it, but it needs a broad acceptance > mitsuhiko: and flaskg is a bad name > mitsuhiko: and i don't see the advantage over import as at all > mitsuhiko: you will only grep your own code anyways > ThomasWaldmann: shall I pull some other style doc now that explains that > single-letter is bad or do we all know that? > mitsuhiko: and you can easily do "from flask import g as app_globals" : > MoinMoin/utils.py > mitsuhiko: and then do from MoinMoin.utils import app_globals > mitsuhiko: ThomasWaldmann: bring it up on the mailinglist (or let > someone else bring it up) and start a proper poll there > ThomasWaldmann: so you think it is great if every flask user invents his > own alias? > mitsuhiko: which includes the vote for: don't change > mitsuhiko: i especially will not change things just because one small > part of the community wants something changed, for that there are too > many users :) > ThomasWaldmann: i won't discuss on ML > > This transcript is shortened, the full version can be found on the IRC > archives on the Flask website / dev.pocoo.org > > Everybody who wants g to be renamed, please feel free to reply to this > thread and provide some good alternative names an reasons for changing > the name. I am happy to do this as long as we have the majority of the > community behind it. And as this is a backwards incompatible change I > would like to see 70% of the community behind it. > > > Regards, > Armin >
Sorry internal design > internal change. On 3 August 2010 12:35, Dan Jacob <danjac354@gmail.com> wrote: > Personally I don't have a problem with it, it's just a convention you > get used to and it's convenient. > > If you had to name it something else, go with app_globals or > global_data or something, anything but flaskg. > > On the subject of naming (and slightly OT): > > The variable _request_ctx_stack is underscored, as in private, and > IMHO should be aliased as it frequently used (and documented) out of > module scope : request_stack or request_context for example. I feel a > bit uncomfortable using a private variable as that could be subject to > internal design. > > On 3 August 2010 12:28, Armin Ronacher <armin.ronacher@active-4.com> wrote: >> Hi, >> >> There was a tense discussion about the flask.g object on #pocoo with the >> MoinMoin team earlier today. The point made by Thomas Waldmann was that >> one letter names should be abolished and that it should be renamed to >> "flask.flaskg" instead. >> >> Now my point here is that if someone does not like the name, they can >> still do something like "from flask import g as flaskg" and use whatever >> name they like. Even better, that import could go into an utility >> module in the application "from yourapplication import flaskg" >> >> My point against renaming it is: flaskg is a bad name and unless someone >> better is found I will not accept it. It requires changes in existing >> code for no real value and extensions that expect g will have to do a >> conditional import to switch between older Flask versions and Flask >> versions where g was renamed. >> >> Because unfortunately Thomas does not like mailinglists and is not happy >> with joining that discussion here, but I would like to get everybody >> involved into the discussion here what has been said so far: >> >> ThomasWaldmann: http://doodle.com/ky7zcvt93p6yy5ey >> ThomasWaldmann finds the flaskg option a bit boring and kind of >> redundant, but i could live with that also. almost everything's better >> than just g. >> mitsuhiko: i don't quite see the problem of doing "from flask import g >> as app_globals" >> ThomasWaldmann: but there are quite some people who dislike single letter >> mitsuhiko: and again, i don't see the problem with a single letter >> mitsuhiko: each editor has ways to search with word boundaries >> mitsuhiko: in vim it's a matter of hitting '*' >> mitsuhiko: grep does this too: >> mitsuhiko: $ grep '\bg\b' flask/*.py|wc >> mitsuhiko: 9 40 563 >> ThomasWaldmann: and the only change needed in flask is: flaskg = g = ... >> mitsuhiko: i am very conservative with changes regarding naming >> mitsuhiko: i will never introduce aliases unless for backwards compat >> mitsuhiko: i am fine with changing it, but it needs a broad acceptance >> mitsuhiko: and flaskg is a bad name >> mitsuhiko: and i don't see the advantage over import as at all >> mitsuhiko: you will only grep your own code anyways >> ThomasWaldmann: shall I pull some other style doc now that explains that >> single-letter is bad or do we all know that? >> mitsuhiko: and you can easily do "from flask import g as app_globals" : >> MoinMoin/utils.py >> mitsuhiko: and then do from MoinMoin.utils import app_globals >> mitsuhiko: ThomasWaldmann: bring it up on the mailinglist (or let >> someone else bring it up) and start a proper poll there >> ThomasWaldmann: so you think it is great if every flask user invents his >> own alias? >> mitsuhiko: which includes the vote for: don't change >> mitsuhiko: i especially will not change things just because one small >> part of the community wants something changed, for that there are too >> many users :) >> ThomasWaldmann: i won't discuss on ML >> >> This transcript is shortened, the full version can be found on the IRC >> archives on the Flask website / dev.pocoo.org >> >> Everybody who wants g to be renamed, please feel free to reply to this >> thread and provide some good alternative names an reasons for changing >> the name. I am happy to do this as long as we have the majority of the >> community behind it. And as this is a backwards incompatible change I >> would like to see 70% of the community behind it. >> >> >> Regards, >> Armin >> >
I think g is fine. It would be a different story if flask had a handful of single letter variables outside of a for loop. Keep it g yo. -- Thadeus On Tue, Aug 3, 2010 at 6:36 AM, Dan Jacob <danjac354@gmail.com> wrote: > Sorry internal design > internal change. > > On 3 August 2010 12:35, Dan Jacob <danjac354@gmail.com> wrote: >> Personally I don't have a problem with it, it's just a convention you >> get used to and it's convenient. >> >> If you had to name it something else, go with app_globals or >> global_data or something, anything but flaskg. >> >> On the subject of naming (and slightly OT): >> >> The variable _request_ctx_stack is underscored, as in private, and >> IMHO should be aliased as it frequently used (and documented) out of >> module scope : request_stack or request_context for example. I feel a >> bit uncomfortable using a private variable as that could be subject to >> internal design. >> >> On 3 August 2010 12:28, Armin Ronacher <armin.ronacher@active-4.com> wrote: >>> Hi, >>> >>> There was a tense discussion about the flask.g object on #pocoo with the >>> MoinMoin team earlier today. The point made by Thomas Waldmann was that >>> one letter names should be abolished and that it should be renamed to >>> "flask.flaskg" instead. >>> >>> Now my point here is that if someone does not like the name, they can >>> still do something like "from flask import g as flaskg" and use whatever >>> name they like. Even better, that import could go into an utility >>> module in the application "from yourapplication import flaskg" >>> >>> My point against renaming it is: flaskg is a bad name and unless someone >>> better is found I will not accept it. It requires changes in existing >>> code for no real value and extensions that expect g will have to do a >>> conditional import to switch between older Flask versions and Flask >>> versions where g was renamed. >>> >>> Because unfortunately Thomas does not like mailinglists and is not happy >>> with joining that discussion here, but I would like to get everybody >>> involved into the discussion here what has been said so far: >>> >>> ThomasWaldmann: http://doodle.com/ky7zcvt93p6yy5ey >>> ThomasWaldmann finds the flaskg option a bit boring and kind of >>> redundant, but i could live with that also. almost everything's better >>> than just g. >>> mitsuhiko: i don't quite see the problem of doing "from flask import g >>> as app_globals" >>> ThomasWaldmann: but there are quite some people who dislike single letter >>> mitsuhiko: and again, i don't see the problem with a single letter >>> mitsuhiko: each editor has ways to search with word boundaries >>> mitsuhiko: in vim it's a matter of hitting '*' >>> mitsuhiko: grep does this too: >>> mitsuhiko: $ grep '\bg\b' flask/*.py|wc >>> mitsuhiko: 9 40 563 >>> ThomasWaldmann: and the only change needed in flask is: flaskg = g = ... >>> mitsuhiko: i am very conservative with changes regarding naming >>> mitsuhiko: i will never introduce aliases unless for backwards compat >>> mitsuhiko: i am fine with changing it, but it needs a broad acceptance >>> mitsuhiko: and flaskg is a bad name >>> mitsuhiko: and i don't see the advantage over import as at all >>> mitsuhiko: you will only grep your own code anyways >>> ThomasWaldmann: shall I pull some other style doc now that explains that >>> single-letter is bad or do we all know that? >>> mitsuhiko: and you can easily do "from flask import g as app_globals" : >>> MoinMoin/utils.py >>> mitsuhiko: and then do from MoinMoin.utils import app_globals >>> mitsuhiko: ThomasWaldmann: bring it up on the mailinglist (or let >>> someone else bring it up) and start a proper poll there >>> ThomasWaldmann: so you think it is great if every flask user invents his >>> own alias? >>> mitsuhiko: which includes the vote for: don't change >>> mitsuhiko: i especially will not change things just because one small >>> part of the community wants something changed, for that there are too >>> many users :) >>> ThomasWaldmann: i won't discuss on ML >>> >>> This transcript is shortened, the full version can be found on the IRC >>> archives on the Flask website / dev.pocoo.org >>> >>> Everybody who wants g to be renamed, please feel free to reply to this >>> thread and provide some good alternative names an reasons for changing >>> the name. I am happy to do this as long as we have the majority of the >>> community behind it. And as this is a backwards incompatible change I >>> would like to see 70% of the community behind it. >>> >>> >>> Regards, >>> Armin >>> >> >
>>> ... It requires changes in existing >>> code for no real value and extensions that expect g will have to do a >>> conditional import to switch between older Flask versions and Flask >>> versions where g was renamed. +100 As long as flask doesn't sprout any more single letter global variables, I think it should stay. Mayowa. On Tue, Aug 3, 2010 at 2:13 PM, Thadeus Burgess <thadeusb@thadeusb.com>wrote: > I think g is fine. It would be a different story if flask had a > handful of single letter variables outside of a for loop. > > Keep it g yo. > > -- > Thadeus > > > > > > On Tue, Aug 3, 2010 at 6:36 AM, Dan Jacob <danjac354@gmail.com> wrote: > > Sorry internal design > internal change. > > > > On 3 August 2010 12:35, Dan Jacob <danjac354@gmail.com> wrote: > >> Personally I don't have a problem with it, it's just a convention you > >> get used to and it's convenient. > >> > >> If you had to name it something else, go with app_globals or > >> global_data or something, anything but flaskg. > >> > >> On the subject of naming (and slightly OT): > >> > >> The variable _request_ctx_stack is underscored, as in private, and > >> IMHO should be aliased as it frequently used (and documented) out of > >> module scope : request_stack or request_context for example. I feel a > >> bit uncomfortable using a private variable as that could be subject to > >> internal design. > >> > >> On 3 August 2010 12:28, Armin Ronacher <armin.ronacher@active-4.com> > wrote: > >>> Hi, > >>> > >>> There was a tense discussion about the flask.g object on #pocoo with > the > >>> MoinMoin team earlier today. The point made by Thomas Waldmann was > that > >>> one letter names should be abolished and that it should be renamed to > >>> "flask.flaskg" instead. > >>> > >>> Now my point here is that if someone does not like the name, they can > >>> still do something like "from flask import g as flaskg" and use > whatever > >>> name they like. Even better, that import could go into an utility > >>> module in the application "from yourapplication import flaskg" > >>> > >>> My point against renaming it is: flaskg is a bad name and unless > someone > >>> better is found I will not accept it. It requires changes in existing > >>> code for no real value and extensions that expect g will have to do a > >>> conditional import to switch between older Flask versions and Flask > >>> versions where g was renamed. > >>> > >>> Because unfortunately Thomas does not like mailinglists and is not > happy > >>> with joining that discussion here, but I would like to get everybody > >>> involved into the discussion here what has been said so far: > >>> > >>> ThomasWaldmann: http://doodle.com/ky7zcvt93p6yy5ey > >>> ThomasWaldmann finds the flaskg option a bit boring and kind of > >>> redundant, but i could live with that also. almost everything's better > >>> than just g. > >>> mitsuhiko: i don't quite see the problem of doing "from flask import g > >>> as app_globals" > >>> ThomasWaldmann: but there are quite some people who dislike single > letter > >>> mitsuhiko: and again, i don't see the problem with a single letter > >>> mitsuhiko: each editor has ways to search with word boundaries > >>> mitsuhiko: in vim it's a matter of hitting '*' > >>> mitsuhiko: grep does this too: > >>> mitsuhiko: $ grep '\bg\b' flask/*.py|wc > >>> mitsuhiko: 9 40 563 > >>> ThomasWaldmann: and the only change needed in flask is: flaskg = g = > ... > >>> mitsuhiko: i am very conservative with changes regarding naming > >>> mitsuhiko: i will never introduce aliases unless for backwards compat > >>> mitsuhiko: i am fine with changing it, but it needs a broad acceptance > >>> mitsuhiko: and flaskg is a bad name > >>> mitsuhiko: and i don't see the advantage over import as at all > >>> mitsuhiko: you will only grep your own code anyways > >>> ThomasWaldmann: shall I pull some other style doc now that explains > that > >>> single-letter is bad or do we all know that? > >>> mitsuhiko: and you can easily do "from flask import g as app_globals" : > >>> MoinMoin/utils.py > >>> mitsuhiko: and then do from MoinMoin.utils import app_globals > >>> mitsuhiko: ThomasWaldmann: bring it up on the mailinglist (or let > >>> someone else bring it up) and start a proper poll there > >>> ThomasWaldmann: so you think it is great if every flask user invents > his > >>> own alias? > >>> mitsuhiko: which includes the vote for: don't change > >>> mitsuhiko: i especially will not change things just because one small > >>> part of the community wants something changed, for that there are too > >>> many users :) > >>> ThomasWaldmann: i won't discuss on ML > >>> > >>> This transcript is shortened, the full version can be found on the IRC > >>> archives on the Flask website / dev.pocoo.org > >>> > >>> Everybody who wants g to be renamed, please feel free to reply to this > >>> thread and provide some good alternative names an reasons for changing > >>> the name. I am happy to do this as long as we have the majority of the > >>> community behind it. And as this is a backwards incompatible change I > >>> would like to see 70% of the community behind it. > >>> > >>> > >>> Regards, > >>> Armin > >>> > >> > > >
2010/8/3 Mayowa Akinyemi <mayowa@gmail.com>: >>>> ... It requires changes in existing >>>> code for no real value and extensions that expect g will have to do a >>>> conditional import to switch between older Flask versions and Flask >>>> versions where g was renamed. > +100 > > As long as flask doesn't sprout any more single letter global variables, I > think it should stay. +1 Cheers, Pascal
Hi, On 8/3/10 3:34 PM, Mayowa Akinyemi wrote: > As long as flask doesn't sprout any more single letter global variables, > I think it should stay. g usually contains attributes you want to have everywhere. like g.db / g.user etc. Because the attribute on that is the interesting thing it has a special role. I don't see any reasons why I should implement other one-letter variables. g is special because the attribute counts. and context_global.user is not exactly any clearer than just g.user. Regards, Armin
On 08/03/2010 04:05 PM, Armin Ronacher wrote: > Hi, > > On 8/3/10 3:34 PM, Mayowa Akinyemi wrote: >> As long as flask doesn't sprout any more single letter global variables, >> I think it should stay. > g usually contains attributes you want to have everywhere. like g.db / > g.user etc. Because the attribute on that is the interesting thing it > has a special role. I don't see any reasons why I should implement > other one-letter variables. > > g is special because the attribute counts. and context_global.user is > not exactly any clearer than just g.user. > > > Regards, > Armin I'm agree with Mayowa Akinyemi. "As long as flask doesn't sprout any more single letter global variables, I think it should stay." +1 for keeping g, g is the abbreviation of 'global', but 'global' is a python keyword ! use an other name won't be useful, g is very simple and KISS. I don't want to make a brainstorming to remember the name of a variable. g is a good choice ! Regards
> g usually contains attributes you want to have everywhere. like g.db / > g.user etc. Because the attribute on that is the interesting thing it > has a special role. I don't see any reasons why I should implement > other one-letter variables. I kinda see it as "g." being a "sigil", like @foo for instance variables in Ruby; in Flask we have g.foo for request variables. :) Many one-letters would be confusing and hurt readability, but "the g object" is a concept, an idiom, something established and recognisable.
+1 for keeping g Alex On Tue, Aug 3, 2010 at 4:05 PM, Armin Ronacher <armin.ronacher@active-4.com> wrote: > Hi, > > On 8/3/10 3:34 PM, Mayowa Akinyemi wrote: >> As long as flask doesn't sprout any more single letter global variables, >> I think it should stay. > g usually contains attributes you want to have everywhere. like g.db / > g.user etc. Because the attribute on that is the interesting thing it > has a special role. I don't see any reasons why I should implement > other one-letter variables. > > g is special because the attribute counts. and context_global.user is > not exactly any clearer than just g.user. > > > Regards, > Armin >
As long as no one will mind me importing g as whatever_i_like, then I don't mind. Ali On 3 August 2010 16:13, Alex <thinkpragmatic@gmail.com> wrote: > +1 > for keeping g > > Alex > > On Tue, Aug 3, 2010 at 4:05 PM, Armin Ronacher > <armin.ronacher@active-4.com> wrote: >> Hi, >> >> On 8/3/10 3:34 PM, Mayowa Akinyemi wrote: >>> As long as flask doesn't sprout any more single letter global variables, >>> I think it should stay. >> g usually contains attributes you want to have everywhere. like g.db / >> g.user etc. Because the attribute on that is the interesting thing it >> has a special role. I don't see any reasons why I should implement >> other one-letter variables. >> >> g is special because the attribute counts. and context_global.user is >> not exactly any clearer than just g.user. >> >> >> Regards, >> Armin >> >
Although I'm new and didn't work too much with flask yet I find ThomasWaldmann's arguments not very convincing since it boils down to 'one letter variables are evil'. If there aren't too much single letter variable names and if they are *frequently* used (like 'g') then I they are not necessarily evil. On Tue, Aug 3, 2010 at 3:34 PM, Mayowa Akinyemi <mayowa@gmail.com> wrote: >>>> ... It requires changes in existing >>>> code for no real value and extensions that expect g will have to do a >>>> conditional import to switch between older Flask versions and Flask >>>> versions where g was renamed. > +100 > > As long as flask doesn't sprout any more single letter global variables, I > think it should stay. > > Mayowa. > > On Tue, Aug 3, 2010 at 2:13 PM, Thadeus Burgess <thadeusb@thadeusb.com> > wrote: >> >> I think g is fine. It would be a different story if flask had a >> handful of single letter variables outside of a for loop. >> >> Keep it g yo. >> >> -- >> Thadeus >> >> >> >> >> >> On Tue, Aug 3, 2010 at 6:36 AM, Dan Jacob <danjac354@gmail.com> wrote: >> > Sorry internal design > internal change. >> > >> > On 3 August 2010 12:35, Dan Jacob <danjac354@gmail.com> wrote: >> >> Personally I don't have a problem with it, it's just a convention you >> >> get used to and it's convenient. >> >> >> >> If you had to name it something else, go with app_globals or >> >> global_data or something, anything but flaskg. >> >> >> >> On the subject of naming (and slightly OT): >> >> >> >> The variable _request_ctx_stack is underscored, as in private, and >> >> IMHO should be aliased as it frequently used (and documented) out of >> >> module scope : request_stack or request_context for example. I feel a >> >> bit uncomfortable using a private variable as that could be subject to >> >> internal design. >> >> >> >> On 3 August 2010 12:28, Armin Ronacher <armin.ronacher@active-4.com> >> >> wrote: >> >>> Hi, >> >>> >> >>> There was a tense discussion about the flask.g object on #pocoo with >> >>> the >> >>> MoinMoin team earlier today. The point made by Thomas Waldmann was >> >>> that >> >>> one letter names should be abolished and that it should be renamed to >> >>> "flask.flaskg" instead. >> >>> >> >>> Now my point here is that if someone does not like the name, they can >> >>> still do something like "from flask import g as flaskg" and use >> >>> whatever >> >>> name they like. Even better, that import could go into an utility >> >>> module in the application "from yourapplication import flaskg" >> >>> >> >>> My point against renaming it is: flaskg is a bad name and unless >> >>> someone >> >>> better is found I will not accept it. It requires changes in existing >> >>> code for no real value and extensions that expect g will have to do a >> >>> conditional import to switch between older Flask versions and Flask >> >>> versions where g was renamed. >> >>> >> >>> Because unfortunately Thomas does not like mailinglists and is not >> >>> happy >> >>> with joining that discussion here, but I would like to get everybody >> >>> involved into the discussion here what has been said so far: >> >>> >> >>> ThomasWaldmann: http://doodle.com/ky7zcvt93p6yy5ey >> >>> ThomasWaldmann finds the flaskg option a bit boring and kind of >> >>> redundant, but i could live with that also. almost everything's better >> >>> than just g. >> >>> mitsuhiko: i don't quite see the problem of doing "from flask import g >> >>> as app_globals" >> >>> ThomasWaldmann: but there are quite some people who dislike single >> >>> letter >> >>> mitsuhiko: and again, i don't see the problem with a single letter >> >>> mitsuhiko: each editor has ways to search with word boundaries >> >>> mitsuhiko: in vim it's a matter of hitting '*' >> >>> mitsuhiko: grep does this too: >> >>> mitsuhiko: $ grep '\bg\b' flask/*.py|wc >> >>> mitsuhiko: 9 40 563 >> >>> ThomasWaldmann: and the only change needed in flask is: flaskg = g = >> >>> ... >> >>> mitsuhiko: i am very conservative with changes regarding naming >> >>> mitsuhiko: i will never introduce aliases unless for backwards compat >> >>> mitsuhiko: i am fine with changing it, but it needs a broad acceptance >> >>> mitsuhiko: and flaskg is a bad name >> >>> mitsuhiko: and i don't see the advantage over import as at all >> >>> mitsuhiko: you will only grep your own code anyways >> >>> ThomasWaldmann: shall I pull some other style doc now that explains >> >>> that >> >>> single-letter is bad or do we all know that? >> >>> mitsuhiko: and you can easily do "from flask import g as app_globals" >> >>> : >> >>> MoinMoin/utils.py >> >>> mitsuhiko: and then do from MoinMoin.utils import app_globals >> >>> mitsuhiko: ThomasWaldmann: bring it up on the mailinglist (or let >> >>> someone else bring it up) and start a proper poll there >> >>> ThomasWaldmann: so you think it is great if every flask user invents >> >>> his >> >>> own alias? >> >>> mitsuhiko: which includes the vote for: don't change >> >>> mitsuhiko: i especially will not change things just because one small >> >>> part of the community wants something changed, for that there are too >> >>> many users :) >> >>> ThomasWaldmann: i won't discuss on ML >> >>> >> >>> This transcript is shortened, the full version can be found on the IRC >> >>> archives on the Flask website / dev.pocoo.org >> >>> >> >>> Everybody who wants g to be renamed, please feel free to reply to this >> >>> thread and provide some good alternative names an reasons for changing >> >>> the name. I am happy to do this as long as we have the majority of >> >>> the >> >>> community behind it. And as this is a backwards incompatible change I >> >>> would like to see 70% of the community behind it. >> >>> >> >>> >> >>> Regards, >> >>> Armin >> >>> >> >> >> > > >
I think it should stay. Pylons has app_globals aliased a 'g' too. It's not thread safe but there maybe something that you want to have living between requests, for read only operations. Cheers Nick On 3 Aug 2010, at 14:45, Eugen Kiss wrote: > Although I'm new and didn't work too much with flask yet I find > ThomasWaldmann's arguments not very convincing since it boils down to > 'one letter variables are evil'. If there aren't too much single > letter variable names and if they are *frequently* used (like 'g') > then I they are not necessarily evil. > > On Tue, Aug 3, 2010 at 3:34 PM, Mayowa Akinyemi <mayowa@gmail.com> wrote: >>>>> ... It requires changes in existing >>>>> code for no real value and extensions that expect g will have to do a >>>>> conditional import to switch between older Flask versions and Flask >>>>> versions where g was renamed. >> +100 >> >> As long as flask doesn't sprout any more single letter global variables, I >> think it should stay. >> >> Mayowa. >> >> On Tue, Aug 3, 2010 at 2:13 PM, Thadeus Burgess <thadeusb@thadeusb.com> >> wrote: >>> >>> I think g is fine. It would be a different story if flask had a >>> handful of single letter variables outside of a for loop. >>> >>> Keep it g yo. >>> >>> -- >>> Thadeus >>> >>> >>> >>> >>> >>> On Tue, Aug 3, 2010 at 6:36 AM, Dan Jacob <danjac354@gmail.com> wrote: >>>> Sorry internal design > internal change. >>>> >>>> On 3 August 2010 12:35, Dan Jacob <danjac354@gmail.com> wrote: >>>>> Personally I don't have a problem with it, it's just a convention you >>>>> get used to and it's convenient. >>>>> >>>>> If you had to name it something else, go with app_globals or >>>>> global_data or something, anything but flaskg. >>>>> >>>>> On the subject of naming (and slightly OT): >>>>> >>>>> The variable _request_ctx_stack is underscored, as in private, and >>>>> IMHO should be aliased as it frequently used (and documented) out of >>>>> module scope : request_stack or request_context for example. I feel a >>>>> bit uncomfortable using a private variable as that could be subject to >>>>> internal design. >>>>> >>>>> On 3 August 2010 12:28, Armin Ronacher <armin.ronacher@active-4.com> >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> There was a tense discussion about the flask.g object on #pocoo with >>>>>> the >>>>>> MoinMoin team earlier today. The point made by Thomas Waldmann was >>>>>> that >>>>>> one letter names should be abolished and that it should be renamed to >>>>>> "flask.flaskg" instead. >>>>>> >>>>>> Now my point here is that if someone does not like the name, they can >>>>>> still do something like "from flask import g as flaskg" and use >>>>>> whatever >>>>>> name they like. Even better, that import could go into an utility >>>>>> module in the application "from yourapplication import flaskg" >>>>>> >>>>>> My point against renaming it is: flaskg is a bad name and unless >>>>>> someone >>>>>> better is found I will not accept it. It requires changes in existing >>>>>> code for no real value and extensions that expect g will have to do a >>>>>> conditional import to switch between older Flask versions and Flask >>>>>> versions where g was renamed. >>>>>> >>>>>> Because unfortunately Thomas does not like mailinglists and is not >>>>>> happy >>>>>> with joining that discussion here, but I would like to get everybody >>>>>> involved into the discussion here what has been said so far: >>>>>> >>>>>> ThomasWaldmann: http://doodle.com/ky7zcvt93p6yy5ey >>>>>> ThomasWaldmann finds the flaskg option a bit boring and kind of >>>>>> redundant, but i could live with that also. almost everything's better >>>>>> than just g. >>>>>> mitsuhiko: i don't quite see the problem of doing "from flask import g >>>>>> as app_globals" >>>>>> ThomasWaldmann: but there are quite some people who dislike single >>>>>> letter >>>>>> mitsuhiko: and again, i don't see the problem with a single letter >>>>>> mitsuhiko: each editor has ways to search with word boundaries >>>>>> mitsuhiko: in vim it's a matter of hitting '*' >>>>>> mitsuhiko: grep does this too: >>>>>> mitsuhiko: $ grep '\bg\b' flask/*.py|wc >>>>>> mitsuhiko: 9 40 563 >>>>>> ThomasWaldmann: and the only change needed in flask is: flaskg = g = >>>>>> ... >>>>>> mitsuhiko: i am very conservative with changes regarding naming >>>>>> mitsuhiko: i will never introduce aliases unless for backwards compat >>>>>> mitsuhiko: i am fine with changing it, but it needs a broad acceptance >>>>>> mitsuhiko: and flaskg is a bad name >>>>>> mitsuhiko: and i don't see the advantage over import as at all >>>>>> mitsuhiko: you will only grep your own code anyways >>>>>> ThomasWaldmann: shall I pull some other style doc now that explains >>>>>> that >>>>>> single-letter is bad or do we all know that? >>>>>> mitsuhiko: and you can easily do "from flask import g as app_globals" >>>>>> : >>>>>> MoinMoin/utils.py >>>>>> mitsuhiko: and then do from MoinMoin.utils import app_globals >>>>>> mitsuhiko: ThomasWaldmann: bring it up on the mailinglist (or let >>>>>> someone else bring it up) and start a proper poll there >>>>>> ThomasWaldmann: so you think it is great if every flask user invents >>>>>> his >>>>>> own alias? >>>>>> mitsuhiko: which includes the vote for: don't change >>>>>> mitsuhiko: i especially will not change things just because one small >>>>>> part of the community wants something changed, for that there are too >>>>>> many users :) >>>>>> ThomasWaldmann: i won't discuss on ML >>>>>> >>>>>> This transcript is shortened, the full version can be found on the IRC >>>>>> archives on the Flask website / dev.pocoo.org >>>>>> >>>>>> Everybody who wants g to be renamed, please feel free to reply to this >>>>>> thread and provide some good alternative names an reasons for changing >>>>>> the name. I am happy to do this as long as we have the majority of >>>>>> the >>>>>> community behind it. And as this is a backwards incompatible change I >>>>>> would like to see 70% of the community behind it. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Armin >>>>>> >>>>> >>>> >> >>
> It's not thread safe but there maybe something that you want to have
living between requests, for read only operations.
Are you talking about flask.g? It certainly *is* thread safe; that's the
point of it - a context-local "request global" namespace.
He's referring to the Pylons g (app_globals). The equivalent to g in Pylons is c (as in "context"). On 3 August 2010 17:59, Dag Odenhall <dag.odenhall@gmail.com> wrote: >> It's not thread safe but there maybe something that you want to have living between requests, for read only operations. > > Are you talking about flask.g? It certainly *is* thread safe; that's the > point of it - a context-local "request global" namespace. > >
Ah yes, sorry, it's a werkzeug.LocalProxy object. On 3 Aug 2010, at 18:28, Dan Jacob wrote: > He's referring to the Pylons g (app_globals). The equivalent to g in > Pylons is c (as in "context"). > > On 3 August 2010 17:59, Dag Odenhall <dag.odenhall@gmail.com> wrote: >>> It's not thread safe but there maybe something that you want to have living between requests, for read only operations. >> >> Are you talking about flask.g? It certainly *is* thread safe; that's the >> point of it - a context-local "request global" namespace. >> >>
>As long as flask doesn't sprout any more single letter global variables, I think it should stay. I completely agree. Anthony Ford, ford.anthonyj@gmail.com On Tue, Aug 3, 2010 at 09:34, Mayowa Akinyemi <mayowa@gmail.com> wrote: > >>> ... It requires changes in existing > > >>> code for no real value and extensions that expect g will have to do a > >>> conditional import to switch between older Flask versions and Flask > >>> versions where g was renamed. > +100 > > As long as flask doesn't sprout any more single letter global variables, I > think it should stay. > > Mayowa. > > > On Tue, Aug 3, 2010 at 2:13 PM, Thadeus Burgess <thadeusb@thadeusb.com>wrote: > >> I think g is fine. It would be a different story if flask had a >> handful of single letter variables outside of a for loop. >> >> Keep it g yo. >> >> -- >> Thadeus >> >> >> >> >> >> On Tue, Aug 3, 2010 at 6:36 AM, Dan Jacob <danjac354@gmail.com> wrote: >> > Sorry internal design > internal change. >> > >> > On 3 August 2010 12:35, Dan Jacob <danjac354@gmail.com> wrote: >> >> Personally I don't have a problem with it, it's just a convention you >> >> get used to and it's convenient. >> >> >> >> If you had to name it something else, go with app_globals or >> >> global_data or something, anything but flaskg. >> >> >> >> On the subject of naming (and slightly OT): >> >> >> >> The variable _request_ctx_stack is underscored, as in private, and >> >> IMHO should be aliased as it frequently used (and documented) out of >> >> module scope : request_stack or request_context for example. I feel a >> >> bit uncomfortable using a private variable as that could be subject to >> >> internal design. >> >> >> >> On 3 August 2010 12:28, Armin Ronacher <armin.ronacher@active-4.com> >> wrote: >> >>> Hi, >> >>> >> >>> There was a tense discussion about the flask.g object on #pocoo with >> the >> >>> MoinMoin team earlier today. The point made by Thomas Waldmann was >> that >> >>> one letter names should be abolished and that it should be renamed to >> >>> "flask.flaskg" instead. >> >>> >> >>> Now my point here is that if someone does not like the name, they can >> >>> still do something like "from flask import g as flaskg" and use >> whatever >> >>> name they like. Even better, that import could go into an utility >> >>> module in the application "from yourapplication import flaskg" >> >>> >> >>> My point against renaming it is: flaskg is a bad name and unless >> someone >> >>> better is found I will not accept it. It requires changes in existing >> >>> code for no real value and extensions that expect g will have to do a >> >>> conditional import to switch between older Flask versions and Flask >> >>> versions where g was renamed. >> >>> >> >>> Because unfortunately Thomas does not like mailinglists and is not >> happy >> >>> with joining that discussion here, but I would like to get everybody >> >>> involved into the discussion here what has been said so far: >> >>> >> >>> ThomasWaldmann: http://doodle.com/ky7zcvt93p6yy5ey >> >>> ThomasWaldmann finds the flaskg option a bit boring and kind of >> >>> redundant, but i could live with that also. almost everything's better >> >>> than just g. >> >>> mitsuhiko: i don't quite see the problem of doing "from flask import g >> >>> as app_globals" >> >>> ThomasWaldmann: but there are quite some people who dislike single >> letter >> >>> mitsuhiko: and again, i don't see the problem with a single letter >> >>> mitsuhiko: each editor has ways to search with word boundaries >> >>> mitsuhiko: in vim it's a matter of hitting '*' >> >>> mitsuhiko: grep does this too: >> >>> mitsuhiko: $ grep '\bg\b' flask/*.py|wc >> >>> mitsuhiko: 9 40 563 >> >>> ThomasWaldmann: and the only change needed in flask is: flaskg = g = >> ... >> >>> mitsuhiko: i am very conservative with changes regarding naming >> >>> mitsuhiko: i will never introduce aliases unless for backwards compat >> >>> mitsuhiko: i am fine with changing it, but it needs a broad acceptance >> >>> mitsuhiko: and flaskg is a bad name >> >>> mitsuhiko: and i don't see the advantage over import as at all >> >>> mitsuhiko: you will only grep your own code anyways >> >>> ThomasWaldmann: shall I pull some other style doc now that explains >> that >> >>> single-letter is bad or do we all know that? >> >>> mitsuhiko: and you can easily do "from flask import g as app_globals" >> : >> >>> MoinMoin/utils.py >> >>> mitsuhiko: and then do from MoinMoin.utils import app_globals >> >>> mitsuhiko: ThomasWaldmann: bring it up on the mailinglist (or let >> >>> someone else bring it up) and start a proper poll there >> >>> ThomasWaldmann: so you think it is great if every flask user invents >> his >> >>> own alias? >> >>> mitsuhiko: which includes the vote for: don't change >> >>> mitsuhiko: i especially will not change things just because one small >> >>> part of the community wants something changed, for that there are too >> >>> many users :) >> >>> ThomasWaldmann: i won't discuss on ML >> >>> >> >>> This transcript is shortened, the full version can be found on the IRC >> >>> archives on the Flask website / dev.pocoo.org >> >>> >> >>> Everybody who wants g to be renamed, please feel free to reply to this >> >>> thread and provide some good alternative names an reasons for changing >> >>> the name. I am happy to do this as long as we have the majority of >> the >> >>> community behind it. And as this is a backwards incompatible change I >> >>> would like to see 70% of the community behind it. >> >>> >> >>> >> >>> Regards, >> >>> Armin >> >>> >> >> >> > >> > >