from:"Tom Lazar"

Re: [pylons-discuss] [off-topic] The Case Against Python 3

2016-11-24 Thread Tom Lazar

I can literally +1 *all* of the previous replies. 

Sent from a phone, please excuse the brevity.

> On 24 Nov 2016, at 15:08, John Anderson  wrote:
> 
> For the last 2 years every project I've worked on has been Python3 only. At 
> SurveyMonkey we had ~60 different services and ported all shared code between 
> them to Python3 four years ago and started shipping production Python3 two 
> years ago. 
> 
> It is a much better language and it really annoys me working on Python2 these 
> days.  I think it is ridiculous to even discuss the transition these days. 
> Yes, it was horrible but at this point every important library has been 
> ported and it is no longer an issue to use Python3.
> 
> 
>> On Thu, Nov 24, 2016 at 9:40 AM, Chris Rossi  wrote:
>> Transition could have been better handled, but Python 3 is great once you 
>> get over.
>> 
>> Chris
>> 
>>> On Thu, Nov 24, 2016 at 8:25 AM, Thierry Florac  wrote:
>>> Perfectly agree with previous comments!
>>> I can't estimate the theory behind Turing machines and so on. But on a 
>>> practical point of view, I worked for a long time with Python 2 and Zope 3 
>>> and had to upgrade all my private packages to use them with Python 3 
>>> (starting with Python 3.) and Pyramid: the result is according to me much 
>>> cleaner and simpler than it was before, especially for many strings 
>>> management concerns!
>>> Finally I prefer using Python 3 today, and as all major libraries have now 
>>> been ported to it, compatibility is no more a major concern with it.
>>> 
>>> Regards,
>>> Thierry
>>> 
>>> 2016-11-24 13:03 GMT+01:00 Christoph Zwerschke :
 Has the same taste as the recent election campaign. Start with 
 extraordinary and alarming, but totally false and uneducated claims 
 ("Python 3 is not Turing complete", "you can't run Python 2 and Python 3 
 along with each other" etc.) and conclude that we should revert everything 
 and do things in the old ways. Same spirit as "climate change is a hoax, 
 let's continue to burn fossil fuel" or "who needs diversity, let's 
 continue to make politics for straight white male people only as we did in 
 the good old 1950s."
 
 My personal experiences with Python 3 are very positive, I do not perceive 
 things as "broken", but moving into the right direction. Many mistakes 
 that have been made in the beginning of the transition have already been 
 fixed. And I see Python 3.6 as another great step forward. Evolution is 
 good, don't worry, don't be stagnant.
 
 -- Christoph
 
 
> Am 24.11.2016 um 12:03 schrieb Vinicius Assef:
> Hey guys.
> 
> As Pyramid was the first framework supporting Python 3, what do you
> think about this position?
> 
> https://learnpythonthehardway.org/book/nopython3.html
> 
> What are your experiences regarding Python 3 as broken?
> 
> --
> Vinicius Assef
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 "pylons-discuss" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to pylons-discuss+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-discuss@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/pylons-discuss/cce59e52-512c-9fcd-cbb9-832113a6b2c0%40online.de.
 
 For more options, visit https://groups.google.com/d/optout.
>>> 
>>> 
>>> 
>>> -- 
>>> http://www.imagesdusport.com -- http://www.ztfy.org
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "pylons-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to pylons-discuss+unsubscr...@googlegroups.com.
>>> To post to this group, send email to pylons-discuss@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/pylons-discuss/CAPX_VWAnt%3DGuuS2Vnyh_mybhXb-pscyQqXX9mcJ4ANGfzsShdQ%40mail.gmail.com.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "pylons-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to pylons-discuss+unsubscr...@googlegroups.com.
>> To post to this group, send email to pylons-discuss@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/pylons-discuss/CAGZ7LV8Cow5%3DFvKU3BR2kgpsKqraxzy_P%2Bgaq7W11Zg1QH0s%2BA%40mail.gmail.com.
>> 
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to

Re: [pylons-discuss] what is the ideal way to connect to postgresql using alchemy scaffold

2015-12-14 Thread Tom Lazar


> On 14 Dec 2015, at 04:40, kk  wrote:
> 
> Hello all,
> I am going to use Postgresql in my Pyramid REST ap[app.
> I wish to know what is the most ideal way of securing my database?

there is nothing pyramid specific in securing your database connection.

> What I wish to know is which is the best way to connect?

> should it be trusted or md5?
> Unix Domain Socket or tcp?

that depends entirely on your specific setup., there is no single best practice.

i for example keep my postgres databases in a separate freebsd jail with a 
private network and firewall and therefore have to luxury to forego any further 
authentication restrictions on the application layer, because my deployment 
setup already takes care of that.

> Kindly explain the entire steps that I should take.

i don’t mean to be snarky, but may i humbly suggest one of your first steps to 
include reading the relevant documentation?

http://www.postgresql.org/docs/9.4/static/auth-methods.html

> Happy hacking.
> Krishnakant.
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to pylons-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> Visit this group at https://groups.google.com/group/pylons-discuss.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [pylons-discuss] pyramid or repoze.who for auth auth middleware?

2015-07-16 Thread Tom Lazar

FWIW in a current project we’ve abandoned the initial oauth based approach for 
a home-grown SSO solution based on JWT and eight lines of pyramid glue code.

as author of the various consumers of this construct i’m very happy about how 
straightforward this all turned out to be and will definitely consider using a 
JWT plus custom AuthenticationPolicy approach again in the future.

hope that helps,

tom

 On 16 Jul 2015, at 21:34, Iain Duncan iainduncanli...@gmail.com wrote:
 
 Hi folks, just getting back into Pyramid and Python after a long absence of 
 being an Angular dev. I'm going to be putting together an app stack where we 
 have multiple separate apps with separate databases but we want a shared auth 
 system. I think this means I want WSGI Middleware taking care of my authauth 
 so the inner apps just get auth tokens off the wsgi env and use those for 
 their ACL management. My questions, having been out of the loop for a while, 
 are:
 
 - is this still a good way to go?
 - should I use repoze.who/what for the wsgi middleware or just a separate app 
 that imports Pyramids auth guts?
 - any comments or gotchas anyone cares to share on the above plan?
 
 thanks so much!
 Iain
 
 --
 You received this message because you are subscribed to the Google Groups 
 pylons-discuss group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to pylons-discuss+unsubscr...@googlegroups.com 
 mailto:pylons-discuss+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-discuss@googlegroups.com 
 mailto:pylons-discuss@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-discuss 
 http://groups.google.com/group/pylons-discuss.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [pylons-discuss] Re: what's replaced colander/deform/etc

2015-06-15 Thread Tom Lazar

FTR same here. although for a next project i will give wichert’s toolkit a 
spin. it looks cleaner and with less moving parts. cornice sometimes seems to 
get a bit in the way. but otherwise we’re happy with it, too.

hth,

tom

 On 14 Jun 2015, at 20:50, Vincent Catalano vinc...@vincentcatalano.com 
 wrote:
 
 Hello Chris,
 
 Blaise is right. If you are planning on going the ReactJS route, you 
 shouldn't need much (or anything) for HTML on the back-end. For my REST 
 applications, I use Colander with the REST framework Cornice 
 https://cornice.readthedocs.org/en/latest/.
 
 -Vincent
 
 On Sun, Jun 14, 2015 at 8:57 AM, Blaise Laflamme bla...@laflamme.org 
 mailto:bla...@laflamme.org wrote:
 Hi Chris,
 
 if you're going to do ReactJS-ish things colander just works fine, you won't 
 need any HTML thingies from the backend. You would also want to look at doing 
 REST by yourself or use the excellent rest_toolkit from Wiggy. You can also 
 use one of the multiple available form tools from the React world, these days 
 I'm using tcomb-form coupled with reflux for Flux approach.
 
 
 On Friday, June 12, 2015 at 2:10:38 AM UTC-4, Chris Withers wrote:
 Hi All,
 
 It looks like work on deform, colander and friends stopped development
 at the back end of 2013.
 
 Are they just stable and complete or has focus moved to another set of
 form libraries?
 I'm probably going to end up wanting to do ReactJS-ish things, so where
 am I best to start on the server side?
 
 cheers,
 
 Chris
 
 --
 You received this message because you are subscribed to the Google Groups 
 pylons-discuss group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to pylons-discuss+unsubscr...@googlegroups.com 
 mailto:pylons-discuss+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-discuss@googlegroups.com 
 mailto:pylons-discuss@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-discuss 
 http://groups.google.com/group/pylons-discuss.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.
 
 
 
 --
 Vincent Catalano
 Software Engineer and Web Developer,
 (520).603.8944
 
 --
 You received this message because you are subscribed to the Google Groups 
 pylons-discuss group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to pylons-discuss+unsubscr...@googlegroups.com 
 mailto:pylons-discuss+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-discuss@googlegroups.com 
 mailto:pylons-discuss@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-discuss 
 http://groups.google.com/group/pylons-discuss.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [pylons-discuss] manage.py equivalent?

2015-06-01 Thread Tom Lazar

i heartily second that suggestion. click is a joy to work with!

 On 01 Jun 2015, at 14:00, Oliver dief...@gmail.com wrote:
 
 If you want a really easy framework for managing script options and so on, I 
 recommend http://click.pocoo.org
 
 On 01.06.2015 12:08, Chris Withers wrote:
 On 01/06/2015 08:11, Thierry Florac wrote:
 Hi,
 Do you want to create new management commands or do you just want to get 
 access to the shell?
 
 Yes, I'm wondering if there's a framework for adding in new commands.
 
 Chris
 
 
 --
 You received this message because you are subscribed to the Google Groups 
 pylons-discuss group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to pylons-discuss+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-discuss@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-discuss.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [pylons-discuss] Webtest NoSectionError

2015-05-29 Thread Tom Lazar

i’m not sure why or how you would want to run your tests using “python 
tests.py”.

i can suggest a) using pytest and b) taking a peek at our own setup here:

https://github.com/pyfidelity/rest-seed 
https://github.com/pyfidelity/rest-seed

and in particular:

https://github.com/pyfidelity/rest-seed/blob/master/backend/backrest/testing.py 
https://github.com/pyfidelity/rest-seed/blob/master/backend/backrest/testing.py

our approach there is to not feed the tests with an ini file but simply pass it 
a dictionary where we mirror the minimal required set of settings to run the 
tests.

hth,

tom


 On 29 May 2015, at 16:47, Brian Looker look...@uwosh.edu 
 mailto:look...@uwosh.edu wrote:
 
 I've encountered a NoSectionError while trying to test my Pyramid project, 
 and I haven't been able to figure out why. I have successfully used 
 ConfigParser with the interpreter to read my .ini file without error.
 
 I've pasted in my code and the stack trace below, and I would greatly 
 appreciate any suggestions. I suspect I'm not setting something up right in 
 my tests.py file, which goes:
 
 import unittest
 from pyramid.paster import get_app
 from webtest import TestApp
 
 class AllTests(unittest.TestCase):
 def test_login(self):
 app = get_app('testing.ini')
 test_app = TestApp(app)
 resp = test_app.get('/login')
 self.assertEqual(resp.status_code, 200)
 
 if __name__ == '__main__':
 unittest.main()
 
 I call my tests with: python tests.py. Then I get the following error.
 
 ERROR: test_login (__main__.AllTests)
 --
 Traceback (most recent call last):
   File tests.py, line 7, in test_login
 app = get_app('testing.ini')
   File 
 /home/brian/Documents/JobWork/pyramid-tutorial/local/lib/python2.7/site-packages/pyramid/paster.py,
  line 31, in get_app
 global_conf=options)
   File 
 /home/brian/Documents/JobWork/pyramid-tutorial/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py,
  line 247, in loadapp
 return loadobj(APP, uri, name=name, **kw)
   File 
 /home/brian/Documents/JobWork/pyramid-tutorial/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py,
  line 272, in loadobj
 return context.create()
   File 
 /home/brian/Documents/JobWork/pyramid-tutorial/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py,
  line 710, in create
 return self.object_type.invoke(self)
   File 
 /home/brian/Documents/JobWork/pyramid-tutorial/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py,
  line 146, in invoke
 return fix_call(context.object, context.global_conf, **context.local_conf)
   File 
 /home/brian/Documents/JobWork/pyramid-tutorial/local/lib/python2.7/site-packages/paste/deploy/util.py,
  line 55, in fix_call
 val = callable(*args, **kw)
   File 
 /home/brian/Documents/JobWork/pyramid-tutorial/camtasia_request/camtasia_request/__init__.py,
  line 29, in main
 config.scan()
   File 
 /home/brian/Documents/JobWork/pyramid-tutorial/local/lib/python2.7/site-packages/pyramid/config/__init__.py,
  line 930, in scan
 ignore=ignore)
   File 
 /home/brian/Documents/JobWork/pyramid-tutorial/local/lib/python2.7/site-packages/venusian/__init__.py,
  line 205, in scan
 __import__(modname)
   File 
 /home/brian/Documents/JobWork/pyramid-tutorial/camtasia_request/camtasia_request/views.py,
  line 28, in module
 appContext = d2lauth.fashion_app_context(app_id=parser.get('app:main', 
 'APP_ID'),
   File /usr/lib/python2.7/ConfigParser.py, line 607, in get
 raise NoSectionError(section)
 NoSectionError: No section: 'app:main'
 
 Thank you for any time you spend puzzling over this.
 Peace,
 Brian
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 pylons-discuss group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to pylons-discuss+unsubscr...@googlegroups.com 
 mailto:pylons-discuss+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-discuss@googlegroups.com 
 mailto:pylons-discuss@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-discuss 
 http://groups.google.com/group/pylons-discuss.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] Re: Connection issue with redis_session

2015-05-16 Thread Tom Lazar

FWIW we've been using 'regular' cookies with content encrypted by 
http://pythonhosted.org/itsdangerous/ for many projects now. Works like a 
charm. 

Sent from a phone, please excuse the brevity.

 On 16.05.2015, at 01:58, Jonathan Vanasco jonat...@findmeon.com wrote:
 
 Sorry a bit confused about the types/locations of data you're talking about.
 
 Also I checked and pyramid does not have encrypted cookies.  Sorry. I thought 
 I read that someone had released a package; maybe it was a 3rd party plugin.
 
 Anyways...
 
 If your session has some sort of abstract 'account identifier' in it, and 
 that matches up with some sort of database or hardcoded user info, you should 
 be fine with a signed cookie.
 If your session has some sort of 'credentials' in it that the API needs to 
 work (like a login/password), I would encrypt that payload.  I would also 
 prefer to route it through https if the encryption is not very strong.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 pylons-discuss group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to pylons-discuss+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-discuss@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-discuss.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] Re: trypyramid.com and python 2.x

2015-05-10 Thread Tom Lazar

Great explanation! We should include it on the site...

Sent from a phone, please excuse the brevity.

 On 10.05.2015, at 02:45, Tres Seaver tsea...@palladion.com wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 05/09/2015 08:02 PM, Mike Orr wrote:
 I don't know what by artisans is supposed to mean. It sounds like
 a vacuous phrase, especially in regard to web development. We use
 better oil paints? More intricate decorations? Not mass produced?
 
 I read it as:
 
 - - Craftsmanship
 - - Seriousness of purpose
 - - High committment to quality
 - - Avoiding shortcuts which trade that quality away for mass appeal
 
 
 Tres.
 - -- 
 ===
 Tres Seaver  +1 540-429-0999  tsea...@palladion.com
 Palladion Software   Excellence by Designhttp://palladion.com
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIcBAEBAgAGBQJVTqolAAoJEPKpaDSJE9HYmwsP/2Cw0Y6JgXLYqWTjVusvcaa1
 rQsggEuHMhgN04/4HNdXF8qHwuTZfj8AZa4LkRGvEz2a7mtLRXIxOCTN3Qqgr/Yl
 rzSyEKtp8jj758ZJE7zN8xDSPJSnkkl7N99+ntS34HZrdOHWvWtmEVbMhcWc6zXw
 /MdfF29OUb77tliR6Br+AXaG3qolbZi+TSOL5ZlFXU6pUs2qzRmFZzU/zUGSCCmS
 ITipTACj7Nh3Tx9Kj+OwsQGoF0enIVV/k/JEMywplmLijC2DC11hqenh4g1v9VXO
 cxEZnKJ9afG2jkgq5rZLzt7AyomZE2a8+Ep32D8LSCn3xCy62WCbhrIhn2sllJ94
 K/k7LTDDu9x/2Iu6HH0Yjnj3vo89OlreX7r7T7/Eb6Bd54lC+ESRKVJB8AYuxo1d
 iddMHshMMKYcuDqlJIoNLTQ248oVss8o69veATJwCFyOhGyRDxia0SOPlGaaGjyj
 AXy789N5RMZ2PJQan2pz6qXWJD2PDNubH1aCnGPztZXdT3aLvysUFeBYAw3ZrU7Q
 uGiJfLcDDJyzxr8KdCBkmbWbfYwEWYUqLSsWQE6+kgiQnHKUUJc+gjLUZmR6FM4k
 RU6F50/N4oHT8r4JTQHRa1PM40T8eKHoKPp3AjD/Qr/741TSgu9Jx22w7d2ajfxy
 Pt4BdsfCBqt/nXEIijKt
 =Oz4j
 -END PGP SIGNATURE-
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 pylons-discuss group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to pylons-discuss+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-discuss@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-discuss.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] WebTest functional testing

2015-02-11 Thread Tom Lazar

have you looked into pytest’s parametrize feature? sounds like it could apply 
to your case…

http://pytest.org/latest/parametrize.html 
http://pytest.org/latest/parametrize.html

hth,

tom

 On 11 Feb 2015, at 21:12, Robert Daniels robertdaniels2...@gmail.com wrote:
 
 
 I am testing some code and want to call a single test function numerous times.
 
 Ideally I would iterate a list of parameters, and call the test function for 
 each test param, but I would like to see a test result for each.
 
 Not sure this is possible with WebTest, treat each iteration as an individual 
 success-fail, instead of writing 20 separate tests for the 20 different 
 parameters.
 
 This also opens the door for 'feeding' a text-script type file where the test 
 parameters would be in an external file, and the python code just loads and 
 iterates the list.
 
 --
 You received this message because you are subscribed to the Google Groups 
 pylons-discuss group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to pylons-discuss+unsubscr...@googlegroups.com 
 mailto:pylons-discuss+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-discuss@googlegroups.com 
 mailto:pylons-discuss@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-discuss 
 http://groups.google.com/group/pylons-discuss.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [pylons-discuss] Dynamically-generated PDF to download

2015-01-30 Thread Tom Lazar

Fyi  I've had good experiences using phantomjs

Sent from a phone, please excuse the brevity.

 On 25.01.2015, at 18:17, Wichert Akkerman wich...@wiggy.net wrote:
 
 
 On 25 Jan 2015, at 14:40, Adam Morris adam.mor...@igbis.edu.my wrote:
 
 Okay, I get that bit now, and coded it up, but when I go to render it, I use 
 the pyramid.renderers.render object but obviously it ends up downloading a 
 corrupted file because it's not even in PDF format. 
 
 You are still rendering a .pt file, so I’m guessing you are generating HTML, 
 not PDF. If you want to generate PDF you will need to use a PDF library.
 
 So does reportlab have something to take that html/css and paint it to a 
 Canvas or something?
 
 I use z3c.rml, which uses RML as input to generate PDF. If you want to use 
 HTML  CSS you’ll need to find a library that can convert HTML to PDF.
 
 Wichert.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 pylons-discuss group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to pylons-discuss+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-discuss@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-discuss.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] Verifying user password

2015-01-13 Thread Tom Lazar

just as a general guide line i would always try to implement as much as 
possible via roles and permissions.

in this case i would suggest a role of perhaps Authenticated, Verified and 
Anyonmous and then assign permissions to the views as your business logic seems 
fit.

this reduces the problem scope to assigning the Verified role, perhaps in a 
custom callback.

just a quick thought, hope it helps.

cheers,

tom

 On 12 Jan 2015, at 22:33, Theron Luhn the...@luhn.com wrote:
 
 I'm working on authorization+authentication for my webapp.  The login has a 
 remember feature so users don't have to log in each visit.  As best 
 practice, any sensitive features (password changing, user management, 
 billing, etc.) should require a user to verify their password before 
 continuing.  That way a malicious individual couldn't wreak too much havoc if 
 a user clicks remember me on a public terminal, for example.
 
 I'm trying to figure out a way to implement this with Pyramid's 
 authentication+authorization mechanisms.  A simple custom authentication 
 policy is sufficient to declare a user as verified or unverified, and the 
 ACL authorization policy can limit access to the sensitive features to 
 verified users.  However, I can't figure out how to take the appropriate 
 action when access is denied.  Depending on the state of the session, I need 
 to do one of three things:
 No authenticated session — Redirect user to login form
 Unverified session and attempting to access sensitive feature — Redirect 
 user to verify password form
 Everything else — Show a 403 Forbidden error page.
 Any ideas on how I could achieve this?
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 pylons-discuss group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to pylons-discuss+unsubscr...@googlegroups.com 
 mailto:pylons-discuss+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-discuss@googlegroups.com 
 mailto:pylons-discuss@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-discuss 
 http://groups.google.com/group/pylons-discuss.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Re: stable and security upgrade

2013-08-05 Thread Tom Lazar

Basically there are two popular approaches: either pip + requirements.txt or 
buildout + versions.cfg. 

Googling those should give you a good starting point :-)

Sent from a phone, please excuse the brevity.

On 05.08.2013, at 16:11, wilk w...@flibuste.net wrote:

 Hi,
 
 I'm testing pyramid with success and now would like to deploy it in 
 production. To now i only used debian apt to install and upgrade my 
 packages, i wonder how it works with virtualenv ?
 
 I mean, how to make an upgrade just for security, without taking the 
 risk of a non compatible upgrade of one package ?
 
 In the source of pyramid i see that the packages required are =, but 
 what will append if one of them release a new version not compatible 
 with the current pyramid ?
 
 Thanks to give me some keys... Sorry that it's not directly related to 
 pyramid.
 
 -- 
 William Dodé
 Informaticien Indépendant
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 pylons-discuss group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to pylons-discuss+unsubscr...@googlegroups.com.
 To post to this group, send email to pylons-discuss@googlegroups.com.
 Visit this group at http://groups.google.com/group/pylons-discuss.
 For more options, visit https://groups.google.com/groups/opt_out.
 
 

-- 
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Storing settings on module level -- bad idea?

2012-02-01 Thread Tom Lazar

Amen, brother!

Sent from a phone, please excuse the brevity.

On 01.02.2012, at 09:03, Rob Miller r...@kalistra.com wrote:

 These are reasonable points to make. But Pyramid is explicitly not trying to 
 be the same thing that either Django or Rails is trying to be. Those are what 
 we call opinionated frameworks, which make things easier on less 
 experienced developers by making many choices for them. This usually comes at 
 a cost; you lose flexibility, and you have to wrestle w/ the framework when 
 you realize that the choice you want to make isn't in fact the one your tool 
 has made.
 
 Pyramid has some opinions, sure, but far fewer of them. It's intended to 
 strike the right balance between flexibility, performance, and ease of use 
 for more experienced developers. Some people complain about certain features 
 b/c I'm never gonna need this, and it confuses me, can't we just rip it 
 out? But in every case that feature is there b/c SOMEone had to solve a hard 
 problem and that was the best way to do it. Ripping it out would make those 
 hard problems harder to solve. But Pyramid targets those hard problems, and 
 thus the features stay.
 
 This case w/ globals is similar, although slightly inverted. In many cases 
 module-level global settings are fine; they make the developers life a little 
 bit easier, and they don't cause any problems. But in some cases they *do* 
 cause problems. Real, honest to god developer pain. Django and Pylons have 
 both hit this in the real world. For Django it's fine, it's a trade-off that 
 makes sense given their philosophy and their target audience. For Pyramid it 
 doesn't, b/c Pyramid is just as interested in reducing developer friction in 
 the hard cases as it is the easy cases, and so they make a different set of 
 trade-offs.
 
 Does this mean that Pyramid will never be as widely used as Django? Probably. 
 Does that matter? Nope.
 
 -r
 
 On 1/31/12 8:16 PM, Jonathan Vanasco wrote:
 my .02¢ is this:
 
 App Developers like features like 'Globals'. It's something that is
 familiar-from, and present-in many other frameworks.
 
 Granted, pyramid is a low-level framework - and one that a more
 'webmonkey' friendly framework might be built upon itself. But those
 frameworks are likely to end up implementing those features
 themselves... both in bad ways, and in many numerous different ways. If
 pyramid can find a way to pull it off correctly, it would be great.
 
 Rails didn't succeed because it was a great framework, its success is
 largely do to it being usable-by and appealing-to really bad developers
 ( i mean really awful ones ). PHP got to be ubiquitous and installed on
 every platform, by just doing a shoddy job implementing everything, so
 even the worst developers flocked to it. People I've been introduced to
 by recruiters as Top Django Pros! commanding 160k salaries, have been
 robots that barely know python.
 
 I loved pylons, I love pyramid. I only get to code about 20% of my time,
 and love being able to work in them, because they're implemented in a
 way that really resonates with how I like to work. The problem though,
 is that I'm usually running operations, tech or product at a company --
 not implementing it. Having to source people to execute on goals is a pain.
 
 I understand why technically some things might not be right or ideal,
 and why they shouldn't be done -- but sometimes the best route for
 adoption and continued health isn't to do the right thing.
 
 sorry for ranting on this.
 /j
 
 
 
 
 --
 You received this message because you are subscribed to the Google
 Groups pylons-discuss group.
 To view this discussion on the web visit
 https://groups.google.com/d/msg/pylons-discuss/-/ddSQnMKjZZ4J.
 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.
 
 -- 
 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.
 

-- 
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: Storing settings on module level -- bad idea?

2012-01-31 Thread Tom Lazar

On 31.01.2012, at 05:48, Chris McDonough wrote:

 I think it might be significantly better to just create a settings.py
 module in your app and put stuff in there instead of in your config file

hm, i don't want to *maintain* the settings in python code, just have easy 
access. or else i end up with duplicate entries that i need to keep in sync.

 if you want globals, because this is effectively a monkeypatch, and
 makes bootstrap code very timing-dependent.

right.

  Or you could do something
 like what's suggested in
 http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/configuration.html#django-style-settings-py-configuration

wow, that approach seems almost ridiculous :) following it you end up with 
having to pass in/configure the location of the ini file *twice*  and parse the 
whole thing manually *again*. i don't think i'll go down that road.

 I personally find that global settings makes my test code much more brittle, 
 because it means I have to clean up the settings after changing them within 
 test code instead of just saying request.settings = {}. But at the end of 
 the day, it's really up to you.

ah, i just give each test a new instance of the settings, so there's no need to 
clean up.

i really would like to have a clean, convenient and supported way to access 
global settings. i guess, the answer is that pyramid currently doesn't have 
this on offer.

generically exposing the settings that were used to invoke a pyramid instance 
on module level would be nice, but i infer from what you've said the the 
convenience that would add would be outweighed by the stuff that could possibly 
go wrong. correct?

maybe i could just mock get_current_registry() in my test harness and simply 
use that in the few places of my code that does not have convenient access to a 
request.

sorry for rambling, i guess, i'm (ab-)using the list for rubberducking... :)

tom

 
 - C
 
 
 -- 
 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.
 

-- 
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: Storing settings on module level -- bad idea?

2012-01-31 Thread Tom Lazar

On Jan 31, 2012, at 1:43 PM, Robert Forkel wrote:

fwiw: when I started using pyramid I was also reluctant to pass around
the request all the time. But it turned out to be the right (and
transparent) thing to do. In my case this is because I often need
request-specific information like the locale name basically
everywhere. Once you get used to this (and to creating DummyRequests
all the time for tests), you will come to like the registry as the
place to go for global settings.

thanks robert, that was helpful. since posting the original message to this
list i've also realized that my real problem is that i'm partially trying to do
the right things at the wrong places.

for example, by splitting the setting (a filesystem path) into a root part
(deployment specific) and the remaining relative path (application specific)
the whole problem vanished.

thanks for the feedback,

tom

regards
robert

On Tue, Jan 31, 2012 at 12:30 PM, Tom Lazar t...@pyfidelity.com wrote:
On 31.01.2012, at 05:48, Chris McDonough wrote:

I think it might be significantly better to just create a settings.py
module in your app and put stuff in there instead of in your config file

hm, i don't want to *maintain* the settings in python code, just have easy
access. or else i end up with duplicate entries that i need to keep in sync.

if you want globals, because this is effectively a monkeypatch, and
makes bootstrap code very timing-dependent.

right.

Or you could do something
like what's suggested in
http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/configuration.html#django-style-settings-py-configuration

wow, that approach seems almost ridiculous :) following it you end up with
having to pass in/configure the location of the ini file *twice* and parse
the whole thing manually *again*. i don't think i'll go down that road.

I personally find that global settings makes my test code much more
brittle, because it means I have to clean up the settings after changing
them within test code instead of just saying request.settings = {}. But
at the end of the day, it's really up to you.

ah, i just give each test a new instance of the settings, so there's no need
to clean up.

i really would like to have a clean, convenient and supported way to access
global settings. i guess, the answer is that pyramid currently doesn't have
this on offer.

generically exposing the settings that were used to invoke a pyramid
instance on module level would be nice, but i infer from what you've said
the the convenience that would add would be outweighed by the stuff that
could possibly go wrong. correct?

maybe i could just mock get_current_registry() in my test harness and simply
use that in the few places of my code that does not have convenient access
to a request.

sorry for rambling, i guess, i'm (ab-)using the list for rubberducking... :)

tom

- C

--
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: Storing settings on module level -- bad idea?

2012-01-31 Thread Tom Lazar

On Jan 31, 2012, at 2:59 PM, Chris McDonough wrote:

 If you did what that thing suggested you'd likely write a small wrapper
 to run your app instead of using paster serve, so there'd be no twice.
 Or at least you can arrange to do that with enough imagination.

true. 
 
 I personally find that global settings makes my test code much more 
 brittle, because it means I have to clean up the settings after changing 
 them within test code instead of just saying request.settings = {}. But 
 at the end of the day, it's really up to you.
 
 ah, i just give each test a new instance of the settings, so there's no need 
 to clean up.
 
 i really would like to have a clean, convenient and supported way to access 
 global settings. i guess, the answer is that pyramid currently doesn't have 
 this on offer.
 
 No, it doesn't, or at least it leaves it up to you.  Individuals can
 always make nonglobal things global, but a framework can't make things
 nonglobal once it makes them global.

makes sense.
 
 generically exposing the settings that were used to invoke a pyramid 
 instance on module level would be nice, but i infer from what you've said 
 the the convenience that would add would be outweighed by the stuff that 
 could possibly go wrong. correct?
 
 The Django core devs I've heard always lament using global settings.
 The zope.testing.setUp stuff that clears a module scope registry is
 another antipattern.
 
 maybe i could just mock get_current_registry() in my test harness and simply 
 use that in the few places of my code that does not have convenient access 
 to a request.
 
 I dunno.  If you want global stuff it's easy enough to make things
 global if you use a little thought.  Or just pass the request around.

like i mentioned, i've meanwhile realized that my problem was in poor (or no) 
design of what needs to be done where. once i re-arranged the furniture, the 
problem went away.

passing the request around seems the right thing™ to do. at least now i know 
*why* instead of just blindly cargo-culting :)

cheers,

tom

 
 - C
 
 
 -- 
 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.
 

-- 
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: Storing settings on module level -- bad idea?

2012-01-31 Thread Tom Lazar

On Jan 31, 2012, at 3:27 PM, Malthe Borch wrote:

 Another option – in terms of the right thing – is to derive an
 object that carries just to things you need from the request, e.g.
 locale and logged in user, so that you don't pass around an HTTP
 request everywhere (and hence need to stub it out in tests).

FWIW that's what i ended up with, actually. the view extracts the filesystem 
root setting from the request and then just passes that particular setting to 
the helper methods that require it. in my testing i create a sandbox and pass 
*its* location to the helpers. presto, no request involved, no wsgi app 
instantiated!

 That object might be an environment in which code executes.

in my case that's an instance of a 'dropbox' class that receives a root path in 
its init.

i'm actually rather happy with how it turned out :)

tom

 
 \malthe
 
 -- 
 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.
 

-- 
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.

Storing settings on module level -- bad idea?

2012-01-30 Thread Tom Lazar

hi there,

i was getting tired of either a) having to pass in the request all over the 
place (mainly from views down to helper methods) in order for the latter to 
have access to the settings via request.settings or b) having to call 
get_current_registry() all the time (which would mean my tests require some 
additional setup foo) so i tried this in the myapp/__init__.py:

from pyramid.config import Configurator
settings = dict()


def main(global_config, **_settings):
   config = Configurator(settings=_settings)
   import myapp
   myapp.settings = _settings
   config.scan()
   return config.make_wsgi_app()

and henceforth wherever i need access to the settings:

from myapp import settings
...

settings['myapp.foo']

is this a bad idea? it seems 'dirty' but it would keep my tests and code 
significantly leaner...

any opinions?

cheers,

tom

-- 
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: [pylons-discuss] [off-topic] The Case Against Python 3

Re: [pylons-discuss] what is the ideal way to connect to postgresql using alchemy scaffold

Re: [pylons-discuss] pyramid or repoze.who for auth auth middleware?

Re: [pylons-discuss] Re: what's replaced colander/deform/etc

Re: [pylons-discuss] manage.py equivalent?

Re: [pylons-discuss] Webtest NoSectionError

Re: [pylons-discuss] Re: Connection issue with redis_session

Re: [pylons-discuss] Re: trypyramid.com and python 2.x

Re: [pylons-discuss] WebTest functional testing

Re: [pylons-discuss] Dynamically-generated PDF to download

Re: [pylons-discuss] Verifying user password

Re: stable and security upgrade

Re: Storing settings on module level -- bad idea?

Re: Storing settings on module level -- bad idea?

Re: Storing settings on module level -- bad idea?

Re: Storing settings on module level -- bad idea?

Re: Storing settings on module level -- bad idea?

Storing settings on module level -- bad idea?

18 matches

Site Navigation

Mail list logo

Footer information