Re: best ways to deal with bool values in config ?

2009-01-23 Thread Mike Orr

On Thu, Jan 22, 2009 at 9:43 PM, Tycon adie...@gmail.com wrote:

 Python is so messed up, the only explanation is that the people making
 it up are blindly following misguided principles.

Since it's so easy to make a web framework in Python, why don't you
make your own and then you won't have to suffer the egregious mistakes
of such braindead developers.  You can also design your own
programming language while you're at it.

-- 
Mike Orr sluggos...@gmail.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: best ways to deal with bool values in config ?

2009-01-23 Thread Tycon

I was just responding to other people's posts, and I'm not the only
person to ever criticize python (while still acknoledging its
strengths).

On Jan 23, 1:45 am, Alberto Valverde albe...@toscat.net wrote:
 Mike Orr wrote:
  On Thu, Jan 22, 2009 at 9:43 PM, Tycon adie...@gmail.com wrote:

  Python is so messed up, the only explanation is that the people making
  it up are blindly following misguided principles.

  Since it's so easy to make a web framework in Python, why don't you
  make your own and then you won't have to suffer the egregious mistakes
  of such braindead developers.  You can also design your own
  programming language while you're at it.

 As his/her google groups profile [1] clearly shows (anonymous nickname,
 high trolling/signal ratio in a short posting history, bold claims with
 little or no backing, anonymous gmail account created for the only
 purpose of displaying behavior that his/her mother wouldn't be proud
 of...) we're in front of yet another mailing list troll. Unfortunately,
 it has just recently begun spreading to other Python webdev mailing lists...

 I believe it's better to stop feeding his/her trollish posts (I for one
 find it quite hard) and instead focus on the posts where he/she adds
 some value; or just plainly ignore them. To put casual lurkers on the
 right track when they reach the archives through a search engine,
 trollish posts can be answered with something like:

 This post remains unanswered not because the claims made are not
 disputable but because this individual is known to occasionally display
 trollish behaviour: link to his post history. Please refrain from
 feeding, it'll get stronger.

 Just an idea.

 Alberto

 [1]http://groups.google.com/groups/profile?enc_user=ldNXFBEvm8YnL9Uo...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: best ways to deal with bool values in config ?

2009-01-22 Thread Mike Orr

On Wed, Jan 21, 2009 at 4:30 PM, Jonathan Vanasco jonat...@findmeon.com wrote:

 i store a lot of stuff in config, much of which is 'framework' related
 across modules.

 the current way i deal with bools is this ( by storing things in
 app_globals during init )

g.enable_feature_x= False
if 'org.opensn.pylons.enable_feature_x' in config:
g.opensn_pylons.enable_feature_x = bool(int(config
 ['org.opensn.pylons.enable_feature_x']))

 is there a better way ?

I have a custom function in load_environment that chnages the config
var types and aborts if it can't, checks for required vars, and sets
defaults for optional ones.  However, it has since occurred to me that
this would be a good job for a FormEncode schema, although you'd need
some workaround for the dotted variable names, and meaningful error
messages (variable X in the [app] section of /a/b/c/development.ini
must be numeric).

I do think this should all be done in load_environment rather than ad
hoc whenever the value is used, because not only does that keep
parsing all in one place, but it prevents the application from
crashing in possibly obscure situations.

-- 
Mike Orr sluggos...@gmail.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: best ways to deal with bool values in config ?

2009-01-22 Thread Tycon

This is another example of the flawed, broken code known as Paste.
Pylons should decouple itself from Paste

On Jan 22, 12:11 pm, Mike Orr sluggos...@gmail.com wrote:
 On Wed, Jan 21, 2009 at 4:30 PM, Jonathan Vanasco jonat...@findmeon.com 
 wrote:

  i store a lot of stuff in config, much of which is 'framework' related
  across modules.

  the current way i deal with bools is this ( by storing things in
  app_globals during init )

         g.enable_feature_x= False
         if 'org.opensn.pylons.enable_feature_x' in config:
             g.opensn_pylons.enable_feature_x = bool(int(config
  ['org.opensn.pylons.enable_feature_x']))

  is there a better way ?

 I have a custom function in load_environment that chnages the config
 var types and aborts if it can't, checks for required vars, and sets
 defaults for optional ones.  However, it has since occurred to me that
 this would be a good job for a FormEncode schema, although you'd need
 some workaround for the dotted variable names, and meaningful error
 messages (variable X in the [app] section of /a/b/c/development.ini
 must be numeric).

 I do think this should all be done in load_environment rather than ad
 hoc whenever the value is used, because not only does that keep
 parsing all in one place, but it prevents the application from
 crashing in possibly obscure situations.

 --
 Mike Orr sluggos...@gmail.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: best ways to deal with bool values in config ?

2009-01-22 Thread Wyatt Baldwin

On Jan 22, 1:14 pm, Tycon adie...@gmail.com wrote:
 This is another example of the flawed, broken code known as Paste.
 Pylons should decouple itself from Paste

But Pylons, as you've pointed out, is flawed in numerous ways as well.
Let's throw it *all* away!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: best ways to deal with bool values in config ?

2009-01-22 Thread Tycon

I would gladly throw python away if only ruby matched its performance.

On Jan 22, 3:48 pm, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote:
 On Jan 22, 1:14 pm, Tycon adie...@gmail.com wrote:

  This is another example of the flawed, broken code known as Paste.
  Pylons should decouple itself from Paste

 But Pylons, as you've pointed out, is flawed in numerous ways as well.
 Let's throw it *all* away!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: best ways to deal with bool values in config ?

2009-01-22 Thread Wyatt Baldwin

On Jan 22, 8:21 pm, Tycon adie...@gmail.com wrote:
 I would gladly throw python away if only ruby matched its performance.

There's another option you may be interested, in case you haven't
heard of it: C. It's *very* fast.


 On Jan 22, 3:48 pm, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote:

  On Jan 22, 1:14 pm, Tycon adie...@gmail.com wrote:

   This is another example of the flawed, broken code known as Paste.
   Pylons should decouple itself from Paste

  But Pylons, as you've pointed out, is flawed in numerous ways as well.
  Let's throw it *all* away!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: best ways to deal with bool values in config ?

2009-01-22 Thread Tycon

C is my expertise, but it can't match the productivity of python or
Ruby
Fortnately for C, it will always retain the performance crownm so it
will always have its uses

The same thing cannot be said for python. Once its performance is once
its performance is matched by a
better language such as Ruby, python will be history.

Python is so messed up, the only explanation is that the people making
it up are blindly following misguided principles.
The biggest lie/joke is that there is only one way to  do something
in python


On Jan 22, 9:21 pm, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote:
 On Jan 22, 8:21 pm, Tycon adie...@gmail.com wrote:

  I would gladly throw python away if only ruby matched its performance.

 There's another option you may be interested, in case you haven't
 heard of it: C. It's *very* fast.

  On Jan 22, 3:48 pm, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote:

   On Jan 22, 1:14 pm, Tycon adie...@gmail.com wrote:

This is another example of the flawed, broken code known as Paste.
Pylons should decouple itself from Paste

   But Pylons, as you've pointed out, is flawed in numerous ways as well.
   Let's throw it *all* away!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: best ways to deal with bool values in config ?

2009-01-22 Thread Wyatt Baldwin

On Jan 22, 9:43 pm, Tycon adie...@gmail.com wrote:
 C is my expertise, but it can't match the productivity of python or
 Ruby
 Fortnately for C, it will always retain the performance crownm so it
 will always have its uses

 The same thing cannot be said for python. Once its performance is once
 its performance is matched by a
 better language such as Ruby, python will be history.

 Python is so messed up, the only explanation is that the people making
 it up are blindly following misguided principles.
 The biggest lie/joke is that there is only one way to  do something
 in python

Hey! You can't talk about Python that way! Seriously, though, where'd
you find that quote?


 On Jan 22, 9:21 pm, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote:

  On Jan 22, 8:21 pm, Tycon adie...@gmail.com wrote:

   I would gladly throw python away if only ruby matched its performance.

  There's another option you may be interested, in case you haven't
  heard of it: C. It's *very* fast.

   On Jan 22, 3:48 pm, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote:

On Jan 22, 1:14 pm, Tycon adie...@gmail.com wrote:

 This is another example of the flawed, broken code known as Paste.
 Pylons should decouple itself from Paste

But Pylons, as you've pointed out, is flawed in numerous ways as well.
Let's throw it *all* away!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



best ways to deal with bool values in config ?

2009-01-21 Thread Jonathan Vanasco

i store a lot of stuff in config, much of which is 'framework' related
across modules.

the current way i deal with bools is this ( by storing things in
app_globals during init )

g.enable_feature_x= False
if 'org.opensn.pylons.enable_feature_x' in config:
g.opensn_pylons.enable_feature_x = bool(int(config
['org.opensn.pylons.enable_feature_x']))

is there a better way ?


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: best ways to deal with bool values in config ?

2009-01-21 Thread Gael Pasgrimaud

If you mean what is the best practise to convert bools, PasteDeploy
provide a few helpers:

from paste.deploy.converters import asbool

I also have this in helpers.py (don't know why I can't find something
similar in the paste namespace):

class Params(dict):
def __getattr__(self, attr):
return self[attr]
def __setattr__(self, attr, value):
self[attr] = value

def params_from_config(key):
params = Params()
for k, v in config['app_conf'].items():
if k.startswith(key):
params[k.replace(key, '')] = v
return params

You can set all keys found to asbool(v) and change the __getattr__ to
return false by default

Then you can do:

params = h.params_from_config('org.pensn.pylons.')

and check if the feature is available: if params.enable_feature_x:

On Thu, Jan 22, 2009 at 1:30 AM, Jonathan Vanasco jonat...@findmeon.com wrote:

 i store a lot of stuff in config, much of which is 'framework' related
 across modules.

 the current way i deal with bools is this ( by storing things in
 app_globals during init )

g.enable_feature_x= False
if 'org.opensn.pylons.enable_feature_x' in config:
g.opensn_pylons.enable_feature_x = bool(int(config
 ['org.opensn.pylons.enable_feature_x']))

 is there a better way ?


 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---