>
> This code MUST be executed. There is no way to import it because
> request.client only exist when the request arrives and we do not want
> to re import modules on every request.
Flask accomplishes this perfectly by placing the request in a context
thread local. It only exists the the thread local when a request
actually arrives.
So from flask import request will fail if there is actually no request!
I am learning more about thread locals at the moment, but it seems
reasonable enough and it works.
--
Thadeus
On Thu, Jun 10, 2010 at 4:53 PM, mdipierro <mdipie...@cs.depaul.edu> wrote:
> The conclusion is right but it is more complicated than that. This is
> not a syntactical issue.
>
> Let' say in a model we have:
>
> db.define_table('a',Field('b',default=request.client))
>
> This code MUST be executed. There is no way to import it because
> request.client only exist when the request arrives and we do not want
> to re import modules on every request.
>
> The easiness comes from the fact that you can code assuming there is a
> client while in other frameworks you need to be careful and wrap
> everything into functions that eventually will be called when the
> request arrives and the request is passed around explicitly. In all
> other frameworks, the imports are resolved before an http request
> arrives, not after. This is why for example, they have issue with
> multiple database connections, client dependent database connections,
> real time migrations, etc. Moreover, as a result they need to monitor
> py files for changes are reload them when changes occur. This
> mechanism works ONLY for pure-python web servers and not with apache
> for example. Moreover this is subject to all the reload caveats
> http://docs.python.org/library/functions.html about old global
> variables being retained on reload in the module __dict__ (this may
> cause memory leaks and data leaking from one session to another thus
> causing security issues). We make a clean exec for every request and
> we have no memory leaks and no data pollution as well a clean syntax.
>
> There will be no import of models in web2py or it will not be web2py
> any more.
>
> This can be reassessed in web3py but as I stated before: IF there is a
> web3py for me to be interesting it has to be completely different. It
> may not even be in Python. Perhaps we should look into Cobra (http://
> cobra-language.com/).
>
> Massimo
>
>
> On Jun 10, 3:44 pm, Thadeus Burgess <thade...@thadeusb.com> wrote:
>> This is what I desire from this
>>
>> Web2py applications to be importable python modules
>> Along with [A] your models immediately become python modules that you
>> can import. This solves my need to share models between web2py apps.'
>>
>> Web2py has a Top down approach, where other frameworks use a down-up
>> approach. Meaning, web2py executes the models THEN looks at the
>> request, determines the controller and executes it, then executes the
>> view. Everyone else does the down-top approach, where the request
>> comes in, it goes to the controller, the controller decides what
>> models to IMPORT and then executes itself and even decides what view
>> to return if any!
>>
>> This is what the discussion has turned into, a design pattern, web2py
>> can never satisfy the down-top approach because of backwards
>> compatibility. Perhaps web3py.
>>
>> --
>> Thadeus
>>
>> On Thu, Jun 10, 2010 at 3:24 PM, Yarko Tymciurak
>>
>> <resultsinsoftw...@gmail.com> wrote:
>> > On Jun 10, 1:17 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>> >> If we are going to work on this we may as well solve a different
>> >> problem.
>>
>> >> Executing models take time. If you have 500 tables each defined it its
>> >> own file, it takes lots of time. Yet not all actions need all tables
>> >> so we may want to implement a dependency not just among models but
>> >> among actions and models so that not-needed models are not executed.
>>
>> >> If the dependencies are expressed in the model files themselves they
>>
>> > ... I assume you meant to say "...in controller files..."
>>
>> >> still needs to be executed (or at least bytceode compiled) to be
>> >> resolved and that defies the purpose.
>> >> Moreover this would be similar to the python import mechanism (from a
>> >> user prospective) and thus an example of reinventing the wheel.
>>
>> > ... if I am following you, then why do we not just import the needed
>> > models? I mean, really, seriously - why the need to exec?
>>
>> > It seems like that is a question on the table.
>>
>> >> Having a centralized place where these dependencies are expressed has
>> >> advantages:
>> >> - sets us a apart from everybody and we do not need to reinvent the
>> >> wheel
>>
>> > Global variables in FORTRAN had proponents too - but the need to
>> > manage complexity drove a different structure in programming.
>> > (That is to say, I am not seeing, am challenging that there are _any_
>> > REAL advantages to centralized dependency management;)
>>
>> > ==> "set us apart" is not any kind of advantage, if it does not
>> > provide tangible benefit. (that is, benefit may drive what sets
>> > web2py apart, but making "set apart" a motive is not beneficial in and
>> > of itself - this should be very clear).
>>
>> > If there is a current wheel that is useful, use it.
>>
>> > $ python
>> >>>> import this
>>
>> > one way is better; if there is something that currently solves the
>> > problem, use it (don't 'reinvent the wheel'; _and_ don't look for
>> > problems as an excuse to invent a wheel)
>>
>> >> - it will make the structure of the application easier to read in a
>> >> single place
>>
>> > ... I don't agree, don't see this as beneficial; harder to maintain;
>> > related information scattered;
>>
>> >> - it will make the app faster
>>
>> > ... this is not a benefit - it is a goal; you are implying that
>> > centralized models are the only way to make an app faster; I'm not
>> > buying; I don't think that's true at all.
>>
>> >> - it will be easier to implement without breaking backward
>> >> compatibility (and there it will get done)
>>
>> > .... simplicity of implementation is a benefit to _you_; but (while
>> > that may be important to you), simplicity to implement applications
>> > (since it happens more frequently) is first in line; _then_
>> > simplicity of implementation, practicality;
>>
>> > .... I don't see this as a benefit of central place;
>>
>> >> - it will open the possibility for dependencies to be auto-discovered
>> >> and therefore the config-file auto-generated
>>
>> > ... actually, you could generate (if that were the most practical way)
>> > a central dependency list from local declarations (which is how
>> > Windows Registry works);
>>
>> > I don't see this is a benefit of "central place", rather a practical
>> > consideration.
>>
>> > ... this is beginning to feel like an old tet-a-tet.
>>
>> > ...
>
