#pyramid

yap

a hello world or something

ok

i put return Response('OK')

just to make sure everything works.

but i need to return the whole .pt page instead.

in flask would be something like: return render_template('home.html')

what templating language are you using, and did you install its pyramid bindings?

i think so.

Flask includes Jinja, I think. Pyramid includes none out of the box

actually im not using any

ya, flask uses jinja

return render_template('home.html')

in pyramid you can do the same

you might want to install Jinja2, or mako, or chameleon, or none, or write your own, down the road

quick pyramid explanation: you start by creating Configurator object, then either configure it explicitly via include, add_view, add_route, etc methods, or use scan method to scan source files for @add_route and such decorators. then you call make_wsgi_app to grab real app and serve it via your server/adapter of choice.

i'd prefer to use jinja.

your views can generate responses by themselves (via Response class) or return some data which will be wrapped by preconfigure template (with any templating engine of your choice. or few.)

for jinja install pyramid_jinja2

if you are using .pt as a template extension, you might have been using chameleon

well...

i wanna use .html

.pt make me cry.

you can configure the extension

config.include('pyramid_jinja2'); config.add_jinja_renderer('.html')

.mybadassextension

sounds better.

python-jinja2 - small but fast and easy to use stand-alone template engine

?

that's the package.

is that some apt?

ya

then it's Jinja2 package

as in https://pypi.python.org/pypi/Jinja2

ill use pip

pyramid_jinja2 adds glue between pyramid and jinja2 and also pulls jinja2 as dependency

done.

config.add_jinja_renderer('.html')

doesnt exist.

config.include('pyramid_jinja2') first

this will add jinja2 methods to configurator

config.include('pyramid_jinja2')

config.add_jinja_renderer('.html')

also add_jinja2_renderer

AttributeError: add_jinja_renderer

lal.

lemme check then

sorry ;D

ok seems to work.

let's see if i can change some path to make it more like the original one

\o/

everything is great now.

Thank you guys for the moment! i'll work on this part and ill be back once i've done ;)

im back.

i've been doing all the layout with jinja, now seems reasonable.

how can i put a route to a link now?

usually when i type http://0.0.0.0:6543/home should be redirected to the home page.

but it seems that only accept / in the a href

Paradisee, you need to register a view that relates '/home' path to that method that renders this jinja

ok, done.

Paradisee, well I wasn't very precise on my answer. using view registers (like view_config decorators) you relate routes with methods and that's route that defines path for routes.

Paradisee, but I'm glad you find your way ;)

\o/ :D

sontek: isn’t https://github.com/hynek/attrs/issues/19 what you asked for? :)

hynek: does attr support typing?

Charlie_X: what do you mean by typing? whether comparison is type-sensitive (and not bullshit like namedtuple)?

Of attributes

Charlie_X: it does validators and comes with validators for types and zope.interface

it does it only on __init__ though. monkey patching setattr was a bridge to far for my taste

Charlie_X: https://attrs.readthedocs.org/en/stable/example...

Wise. It would also make things dog slow.

Just got to that.

So you're not using the descriptor protocol?

Charlie_X: *but* attrs is built with extendability in mind: https://attrs.readthedocs.org/en/stable/extendi... so if someone wants that (ppl asked), they just can do it themselves.

yeah I don’t b/c something didn’t work with it but I forgot what

also pretty sure this approach is faster

That may depend upon memory use. Are you using __slots__?

no, that’s the only downside

slots has to be defined on the body; can’t do it later :(

oh, you mean the retrospective stuff based on the __init__ signature?

what I mean is that doing cl.__slots__ in the decorator won’t work (I think, been a while)

if there’s some trick I’m all ears

I think it's possible. I spent some time at PyCon discussing it with Raymond

__init__ doesn’t do a lot FWIW, it’s precompiled according to the attr settings. so it does vroom vroom real good

Yes, because you can inspect when the class is built

isn't this a textbook example where you would want to use a metaclass?

It's where I use a metaclass

I think one of the problems was that I’m transforming class attributes into instance attributes and class attributes are immutable in slots

I don’t touch metaclasses. but I also don’t sub-class FWIW.

(usually)

wiggy: I think they want something more dynamic

The library seems clearly aimed towards convenience and wrapping rather than domain-specific, where Metaclasses make more sense. I think.

Charlie_X: kind of. mainly it’s to help ppl to use proper classes without adding rubbish to their inheritance tree/add magic pixie dust. :)

I'm not sure if I'm convinced by that argument but I can see it being relevant in certain contexts.

The toy syntax would infuriate me.

But horses for courses

I think Python could provide better support for this kind of need.

is there a real need is what I'm wondering

For attr in particular?

Charlie_X: it has non-toy synonyms: @attributes and attr()

hynek: I know.

Personal preference not a real criticism

wiggy: I suspect the use case is where people are creating lots of classes to represent objects.

…as they should. tuples are pdb hell and namedtuples are the devil

why the hate for namedtuples ?

The syntax for creating namedtuples is far from ideal. They work fine.

they behave like tuples (namedtuple("A", "a")(1) == namedtuple("B", "b")(1) == (1,)

I don't see that as a problem.

and if you want to add methods you have to fumble with __new__. it’s a hack. I just wanna regular classes. :)

how does the overhead compare ?