Pyramid order of translation directories
Hi all, in my pyramid application i make use of additional translation directories provided by plugins to override messages defined in the default translation. So i have to rely on the order of translation directories. To make sure this can be relied upon, i looked through the pyramid code and found that in i18n.make_localizer the order of translation directories is reversed compared to the order i specified in my Configurator.add_translation_dirs call. It seems to get reversed in the queryUtility. I don't have a problem with this but wanted to know, whether this behaviour can be relied upon. best regards, robert -- 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: Pyramid order of translation directories
On Tue, 2011-06-21 at 23:41 -0700, Robert Forkel wrote:
Hi all,
in my pyramid application i make use of additional translation
directories provided by plugins to override messages defined in the
default translation. So i have to rely on the order of translation
directories. To make sure this can be relied upon, i looked through
the pyramid code and found that in i18n.make_localizer the order of
translation directories is reversed compared to the order i specified
in my Configurator.add_translation_dirs call. It seems to get reversed
in the queryUtility. I don't have a problem with this but wanted to
know, whether this behaviour can be relied upon.
Later calls to add_translation_dirs insert into the beginning of any
existing translation directories list (created presumably by earlier
calls), so as long as you expect that behavior, the answer is yes.
However I think you've found a bug when add_translation_dirs is called
with more than one directory (e.g. add_transation_dirs('foo', 'bar') as
opposed to add_translation_dirs('foo'), then
add_translation_dirs('bar')). We should probably preserve the ordering
of the directories provided when multiple directories are added to the
directories list during a single call; I should probably change that.
In the meantime, a (lame) way to make sure your code will be compatible
between releases is to always call add_translation_dirs with a single
directory argument, multiple times as necessary.
- 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: Pyramid order of translation directories
On Tue, 2011-06-21 at 23:41 -0700, Robert Forkel wrote: Hi all, in my pyramid application i make use of additional translation directories provided by plugins to override messages defined in the default translation. So i have to rely on the order of translation directories. To make sure this can be relied upon, i looked through the pyramid code and found that in i18n.make_localizer the order of translation directories is reversed compared to the order i specified in my Configurator.add_translation_dirs call. It seems to get reversed in the queryUtility. I don't have a problem with this but wanted to know, whether this behaviour can be relied upon. best regards, robert I've changed the behavior on the master branch (what will become 1.1) to add the directories in the order provided when multiple directories are fed to add_translation_dirs: https://github.com/Pylons/pyramid/commit/6ed33ec54b0dae6ae2a38a0c7a6d383e2ac1967e Definitely call add_translation_dirs multiple times to preserve forward compatibility as a result. Thanks! - 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: Pyramid order of translation directories
Hi Chris, I read your commit comment, and think it is a bit ambiguous. While it is true, that translation directories added later will be found earlier in i18n.make_localizer, this doesn't mean that messages defined in these will trump messages defined in translation directories added earlier (at least if i understand the add/merge methods of Translations in i18n correctly). It's probably less confusing, when the behaviour under the hood is just ignored, and the docs state: messages defined in translation dirs added earlier take precedence over the ones in catalogs added later. regards, robert On Wed, Jun 22, 2011 at 9:09 AM, Chris McDonough chr...@plope.com wrote: On Tue, 2011-06-21 at 23:41 -0700, Robert Forkel wrote: Hi all, in my pyramid application i make use of additional translation directories provided by plugins to override messages defined in the default translation. So i have to rely on the order of translation directories. To make sure this can be relied upon, i looked through the pyramid code and found that in i18n.make_localizer the order of translation directories is reversed compared to the order i specified in my Configurator.add_translation_dirs call. It seems to get reversed in the queryUtility. I don't have a problem with this but wanted to know, whether this behaviour can be relied upon. best regards, robert I've changed the behavior on the master branch (what will become 1.1) to add the directories in the order provided when multiple directories are fed to add_translation_dirs: https://github.com/Pylons/pyramid/commit/6ed33ec54b0dae6ae2a38a0c7a6d383e2ac1967e Definitely call add_translation_dirs multiple times to preserve forward compatibility as a result. Thanks! - 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: Pyramid order of translation directories
On Wed, 2011-06-22 at 09:28 +0200, Robert Forkel wrote: Hi Chris, I read your commit comment, and think it is a bit ambiguous. While it is true, that translation directories added later will be found earlier in i18n.make_localizer, this doesn't mean that messages defined in these will trump messages defined in translation directories added earlier (at least if i understand the add/merge methods of Translations in i18n correctly). It's probably less confusing, when the behaviour under the hood is just ignored, and the docs state: messages defined in translation dirs added earlier take precedence over the ones in catalogs added later. Thanks.. I've changed the changelog message based on this: https://github.com/Pylons/pyramid/commit/4f11dc142a1e515bce106a6ebf09e22433d0a845 regards, robert On Wed, Jun 22, 2011 at 9:09 AM, Chris McDonough chr...@plope.com wrote: On Tue, 2011-06-21 at 23:41 -0700, Robert Forkel wrote: Hi all, in my pyramid application i make use of additional translation directories provided by plugins to override messages defined in the default translation. So i have to rely on the order of translation directories. To make sure this can be relied upon, i looked through the pyramid code and found that in i18n.make_localizer the order of translation directories is reversed compared to the order i specified in my Configurator.add_translation_dirs call. It seems to get reversed in the queryUtility. I don't have a problem with this but wanted to know, whether this behaviour can be relied upon. best regards, robert I've changed the behavior on the master branch (what will become 1.1) to add the directories in the order provided when multiple directories are fed to add_translation_dirs: https://github.com/Pylons/pyramid/commit/6ed33ec54b0dae6ae2a38a0c7a6d383e2ac1967e Definitely call add_translation_dirs multiple times to preserve forward compatibility as a result. Thanks! - 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: Pyramid order of translation directories
On Wed, 2011-06-22 at 09:28 +0200, Robert Forkel wrote: Hi Chris, I read your commit comment, and think it is a bit ambiguous. While it is true, that translation directories added later will be found earlier in i18n.make_localizer, this doesn't mean that messages defined in these will trump messages defined in translation directories added earlier (at least if i understand the add/merge methods of Translations in i18n correctly). It's probably less confusing, when the behaviour under the hood is just ignored, and the docs state: messages defined in translation dirs added earlier take precedence over the ones in catalogs added later. Actually, I've decided to just leave it undefined, it's not relevant to the bug that was fixed. https://github.com/Pylons/pyramid/commit/b0c075ce8eeb7cb95188c1f41feca7af42bb46c7 regards, robert On Wed, Jun 22, 2011 at 9:09 AM, Chris McDonough chr...@plope.com wrote: On Tue, 2011-06-21 at 23:41 -0700, Robert Forkel wrote: Hi all, in my pyramid application i make use of additional translation directories provided by plugins to override messages defined in the default translation. So i have to rely on the order of translation directories. To make sure this can be relied upon, i looked through the pyramid code and found that in i18n.make_localizer the order of translation directories is reversed compared to the order i specified in my Configurator.add_translation_dirs call. It seems to get reversed in the queryUtility. I don't have a problem with this but wanted to know, whether this behaviour can be relied upon. best regards, robert I've changed the behavior on the master branch (what will become 1.1) to add the directories in the order provided when multiple directories are fed to add_translation_dirs: https://github.com/Pylons/pyramid/commit/6ed33ec54b0dae6ae2a38a0c7a6d383e2ac1967e Definitely call add_translation_dirs multiple times to preserve forward compatibility as a result. Thanks! - 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: Pyramid order of translation directories
true. It might be worth making the i18n documentation here http://docs.pylonsproject.org/projects/pyramid/1.1/narr/i18n.html#adding-a-translation-directory clearer, though. A message catalog in a translation directory added via add_translation_dirs() will be merged into translations from a message catalog added earlier if both translation directories contain translations for the same locale and translation domain. will be merged in the above doesn't mean, messages of the one added later will win, but the other way round. (At least that's the behaviour I'm seeing with 1.1a1 and multiple calls to add_translation_dirs now.) (great docs, by the way) regards, robert On Wed, Jun 22, 2011 at 9:33 AM, Chris McDonough chr...@plope.com wrote: On Wed, 2011-06-22 at 09:28 +0200, Robert Forkel wrote: Hi Chris, I read your commit comment, and think it is a bit ambiguous. While it is true, that translation directories added later will be found earlier in i18n.make_localizer, this doesn't mean that messages defined in these will trump messages defined in translation directories added earlier (at least if i understand the add/merge methods of Translations in i18n correctly). It's probably less confusing, when the behaviour under the hood is just ignored, and the docs state: messages defined in translation dirs added earlier take precedence over the ones in catalogs added later. Actually, I've decided to just leave it undefined, it's not relevant to the bug that was fixed. https://github.com/Pylons/pyramid/commit/b0c075ce8eeb7cb95188c1f41feca7af42bb46c7 regards, robert On Wed, Jun 22, 2011 at 9:09 AM, Chris McDonough chr...@plope.com wrote: On Tue, 2011-06-21 at 23:41 -0700, Robert Forkel wrote: Hi all, in my pyramid application i make use of additional translation directories provided by plugins to override messages defined in the default translation. So i have to rely on the order of translation directories. To make sure this can be relied upon, i looked through the pyramid code and found that in i18n.make_localizer the order of translation directories is reversed compared to the order i specified in my Configurator.add_translation_dirs call. It seems to get reversed in the queryUtility. I don't have a problem with this but wanted to know, whether this behaviour can be relied upon. best regards, robert I've changed the behavior on the master branch (what will become 1.1) to add the directories in the order provided when multiple directories are fed to add_translation_dirs: https://github.com/Pylons/pyramid/commit/6ed33ec54b0dae6ae2a38a0c7a6d383e2ac1967e Definitely call add_translation_dirs multiple times to preserve forward compatibility as a result. Thanks! - 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. -- 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: chameleon makes pyramid unfriendly
this is why i use mako. mako ftw. On Jun 21, 2:16 pm, Chris Withers ch...@simplistix.co.uk wrote: Hi All, I just wanted to check if this is just me. I'm working with Pyramid 1.0 and loving it, except when it comes to writing templates. I'm finding I hate this, and it's really slowing me down. Sure, we all make mistakes, but my feeling is that Chameleon's error messages are about as baroque and annoying as they get. Developing with them feels like a massive step back in developer productivity from Zope 2's ZPT implementation. Do others feel like this and, if so, what're we planning on doing about it? cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting -http://www.simplistix.co.uk -- 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: chameleon makes pyramid unfriendly
mako ,l like it 2011/6/22 Mengu whalb...@gmail.com this is why i use mako. mako ftw. On Jun 21, 2:16 pm, Chris Withers ch...@simplistix.co.uk wrote: Hi All, I just wanted to check if this is just me. I'm working with Pyramid 1.0 and loving it, except when it comes to writing templates. I'm finding I hate this, and it's really slowing me down. Sure, we all make mistakes, but my feeling is that Chameleon's error messages are about as baroque and annoying as they get. Developing with them feels like a massive step back in developer productivity from Zope 2's ZPT implementation. Do others feel like this and, if so, what're we planning on doing about it? cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting -http://www.simplistix.co.uk -- 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: chameleon makes pyramid unfriendly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adding to the discussion... I also use Mako - it's very easy, the Pyramid developers have a mako renderer built in already, you just have to specify the templates directory. Mengu whalb...@gmail.com writes: this is why i use mako. mako ftw. On Jun 21, 2:16 pm, Chris Withers ch...@simplistix.co.uk wrote: Hi All, I just wanted to check if this is just me. I'm working with Pyramid 1.0 and loving it, except when it comes to writing templates. I'm finding I hate this, and it's really slowing me down. Sure, we all make mistakes, but my feeling is that Chameleon's error messages are about as baroque and annoying as they get. Developing with them feels like a massive step back in developer productivity from Zope 2's ZPT implementation. Do others feel like this and, if so, what're we planning on doing about it? cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting -http://www.simplistix.co.uk - -- Parnell ixmatus Springmeyer (http://ixmat.us) -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJOAgqaAAoJEPvtlbpI1POLHB4H/0EkvaZoAadmdOqMGkrePrI6 Vh7Lgs4b8s5FpOBDaKlY0omNj8JGRBjX87nJZWQtlg0yKgkTw//o0f6AxZst36X2 VzSsQPCUBfWiEUYOmbHxJ7mCbaE+xrzSWxLGq+FauomGKlIwK9Yy3STGwgBrmyyL 4to64xi4O5HJsbP9WtketRsXfEg2aaG5vPTsAEENsudTS0/wy493UkQr9WYUUGOC CfYRkAyBZrfdHQSxckCiQCtOTQR9zmeKhYwcFX+5d+EEJVSD7kdbpQNwUZ12fMMI pLrPaAyCG1V/JKgdcDi40a2KIFUJyDN+km40Y8XDgcdNHMw/R3YNdTEMWnrUTJU= =rjHz -END PGP SIGNATURE- -- 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: chameleon makes pyramid unfriendly
On Tue, Jun 21, 2011 at 9:00 AM, Chris Withers ch...@simplistix.co.ukwrote: 1.x, I don't think Pyramid works with 2.x... The reason chameleon doesn't work with 2.x is because you're using deform, which is currently not compatible with 2.x (at least it's locked to 1.3). Pyramid isn't the issue here. -- Michael -- 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.
Deform and Mako
Is there a community project to port the templates in Deform to Mako? If so, is there a repo anywhere, and maybe I can help? I'm liking deform mostly, but I know that I will need to customize some of the layout a bit... and I'm a mako guy. It seems that if you're in for a penny, you're in for a pound on the template switch... ... so, is anybody already ¾ of the way there? This work by Mike Bayer for Pylons might be a good place to start: http://techspot.zzzeek.org/2008/07/01/better-form-generation-with-mako-and-pylons/ Failing all that, how have people's experiences been trying to do gross layout with forms with only CSS? The generated code from peppercorn is kinda crufty, so it might be rough. I'm going to give it a whack today, but was just wondering... -- Matt -- 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.
Looking for advice styling deform forms
Hi. I'm working with deform. I'm resisting the urge to make my own
templates, as my needs are not all that custom; I simply want to do simple
things like having radio choices side-by-side rather than stacked up, or
having some fields on the left column, some in the right. So, I'm looking at
the generated html and hoping to use css selectors to style my deform
output.
I'm having trouble finding out how to set class and id attributes, and I see
things like this in the code:
field.py:
self.oid = 'deformField%s' % self.order
hidden.pt:
input type=hidden name=${field.name}
value=${cstruct} id=${field.oid}/
This would seem to indicate that users of deform have no way to set the dom
id of a form element. Is this true? Having them enumerated as such means we
could look into the generated code and then make a style sheet, but this
would be super-brittle, especially if the forms were generated and the order
wasn't necessarily super predictable.
I do see that we can pass css_class to widgets, but this doesn't affect
the li or label or anything; it's not much use to only style the input
element.
Also, it doesn't seem like the templates actually lead to the expected
output... for example, here is textinput.pt:
span tal:omit-tag=
input type=text name=${field.name} value=${cstruct}
tal:attributes=size field.widget.size;
class field.widget.css_class
id=${field.oid}/
script tal:condition=field.widget.mask type=text/javascript
deform.addCallback(
'${field.oid}',
function (oid) {
$(# + oid).mask(${field.widget.mask},
{placeholder:${field.widget.mask_placeholder}});
});
/script
/span
And here is a textinput as rendered by form.render():
li title= id=item-deformField1
!-- mapping_item --
label class=desc title= for=deformField1Emailspan class=req
id=req-deformField1*/span
/label
input type=text name=email value=hi id=deformField1 /
!-- /mapping_item --
/li
What happened to the span? Where did the label come from? This may just be
me not understanding Chameleon templates...
What are some good strategies for working with styling deform output? Maybe
someone can point me to a post somewhere, or maybe just help?
Thanks.
--
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: Looking for advice styling deform forms
Hi Matt,
I've had similar problems with formatting the output of deform. When it comes
to just changing the styles of the widgets of deform, the task is pretty easy.
Take a look at
http://docs.pylonsproject.org/projects/deform/dev/widget.html#widget-templates
for information about overriding the default templates of the widgets.
As for changing oid, I've created a small patch that check to see whether a
colander schema contains an oid attribute or not and then assigns that oid to
the field directly. I don't know whether this is a good approach so I would
love to hear from some of the main maintainers of deform. You can take a look
at what I did here https://github.com/rob0t7/deform. I specifically created
this because I was creating widgets that are disabled/enabled via javascript on
the client side and I needed to be able to us oid more effectively.
Hope some of this helps.
RJ
On 2011-06-22, at 2:03 PM, Matt Feifarek wrote:
Hi. I'm working with deform. I'm resisting the urge to make my own templates,
as my needs are not all that custom; I simply want to do simple things like
having radio choices side-by-side rather than stacked up, or having some
fields on the left column, some in the right. So, I'm looking at the
generated html and hoping to use css selectors to style my deform output.
For the radio button task just redefine the radio widget template.
I'm having trouble finding out how to set class and id attributes, and I see
things like this in the code:
field.py:
self.oid = 'deformField%s' % self.order
hidden.pt:
input type=hidden name=${field.name} value=${cstruct}
id=${field.oid}/
This would seem to indicate that users of deform have no way to set the dom
id of a form element. Is this true? Having them enumerated as such means we
could look into the generated code and then make a style sheet, but this
would be super-brittle, especially if the forms were generated and the order
wasn't necessarily super predictable.
I do see that we can pass css_class to widgets, but this doesn't affect the
li or label or anything; it's not much use to only style the input
element.
Also, it doesn't seem like the templates actually lead to the expected
output... for example, here is textinput.pt:
span tal:omit-tag=
input type=text name=${field.name} value=${cstruct}
tal:attributes=size field.widget.size;
class field.widget.css_class
id=${field.oid}/
script tal:condition=field.widget.mask type=text/javascript
deform.addCallback(
'${field.oid}',
function (oid) {
$(# + oid).mask(${field.widget.mask},
{placeholder:${field.widget.mask_placeholder}});
});
/script
/span
And here is a textinput as rendered by form.render():
li title= id=item-deformField1
!-- mapping_item --
label class=desc title= for=deformField1Emailspan class=req
id=req-deformField1*/span
/label
input type=text name=email value=hi id=deformField1 /
!-- /mapping_item --
/li
What happened to the span? Where did the label come from? This may just be
me not understanding Chameleon templates...
What are some good strategies for working with styling deform output? Maybe
someone can point me to a post somewhere, or maybe just help?
Thanks.
--
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: chameleon makes pyramid unfriendly
Use mako -- Raviteja http://about.me/raviteja On Tue, Jun 21, 2011 at 4:46 PM, Chris Withers ch...@simplistix.co.ukwrote: Hi All, I just wanted to check if this is just me. I'm working with Pyramid 1.0 and loving it, except when it comes to writing templates. I'm finding I hate this, and it's really slowing me down. Sure, we all make mistakes, but my feeling is that Chameleon's error messages are about as baroque and annoying as they get. Developing with them feels like a massive step back in developer productivity from Zope 2's ZPT implementation. Do others feel like this and, if so, what're we planning on doing about it? cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- 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.**compylons-discuss@googlegroups.com . To unsubscribe from this group, send email to pylons-discuss+unsubscribe@* *googlegroups.com pylons-discuss%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/** group/pylons-discuss?hl=enhttp://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: webhelpers SCRIPT_NAME
Hi, On 21 June 2011 14:41, Mike Orr sluggos...@gmail.com wrote: ``url_for`` is deprecated. Are you maintaining an old Pylons 0.9.7 application? ``pylons.url`` (or ``url`` in templates) was introduced in Pylons 0.9.7, and url_for was retired in Pylons 1. Yes I am - I have plans to upgrade to Pylons 1.0, and then to pyramid, but I'm waiting for someone to make an ubuntu package for pyramid, or update the pylons package in ubuntu 11.04 to a later version of pylons. Does anyone have any idea when these things might happen? Cheers, -- 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.
Feedback to user
Perhaps a stupid question with an obvious answer -- my apologies in advance if that is the case. I have inherited a pylons project, wherein extremely lengthy calls to the controller are involved (i.e. typically, when a controller method is invoked, it may rin for as long as 8 hours, over millions of records.). Wondering what others here would recommend for giving the user feeback on the status of the processing until the new page is rendered, hours later. Any standard, pylons-ways of doing such? Thanks, RVince -- 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.
lengthy controller routines
Suppose I have a lengthy controller routine, lets say before it gets to rendering a page, the user invokes a different controller routine. Will the first controller routine be allowed to finish? Or does it abort, in favor of the latest controller routine. I suppose I am asking if multiple controller routines can be executed by the same client simulataneoulsy? Thanks, RVince -- 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: webhelpers SCRIPT_NAME
On Wed, Jun 22, 2011 at 2:24 PM, Thomi Richards tho...@gmail.com wrote: Yes I am - I have plans to upgrade to Pylons 1.0, and then to pyramid, but I'm waiting for someone to make an ubuntu package for pyramid, or update the pylons package in ubuntu 11.04 to a later version of pylons. I don't want to state the obvious here, or insult the benefits of using versions from your package manager, BUT, the state of python packaging with virtualenv is such that your development/deployment experience will be much much better, and you will get more current versions of software, if you do not rely on your system's version of python and your system's version of packages (which is usually fairly out of date for any project being actively developed). -- Michael -- 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: Feedback to user
On Jun 21, 2011, at 8:32 AM, RVince wrote: Perhaps a stupid question with an obvious answer -- my apologies in advance if that is the case. I have inherited a pylons project, wherein extremely lengthy calls to the controller are involved (i.e. typically, when a controller method is invoked, it may rin for as long as 8 hours, over millions of records.). Wondering what others here would recommend for giving the user feeback on the status of the processing until the new page is rendered, hours later. Any standard, pylons-ways of doing such? Thanks, RVince I have no idea what the standard way of doing this is. We have a similar process in our project in which users can create potentially enormous Excel files. Sometime the file generation can take hours. We accept the request and put it in a queue. There is a queue runner which takes requests fires off a separate process to handle them. We then email the user with the URL for download when the file is read and have a page which shows the status of all Excel generation processes and allows for download there as well. If there is an error in the process the user is notified by email and the developers get an email as well with the stack trace and information to replicate the error. John Harrison -- 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: lengthy controller routines
On Wed, Jun 22, 2011 at 2:42 PM, RVince rvinc...@gmail.com wrote: Will the first controller routine be allowed to finish? Or does it abort, in favor of the latest controller routine. I suppose I am asking if multiple controller routines can be executed by the same client simulataneoulsy? The framework itself does not stop the user from doing anything with any URL. If you want to prevent the user from executing 2 requests simultaneously then you need to track that yourself, and perform the appropriate checks at the start of each request. As far as the framework is concerned a request is anonymous until you treat it otherwise. -- Michael -- 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.
DEFORM: A SelectWidget that depends on another SelectWidget
I have a SelectWidget (dropdown list) which has a few items in it. When a user clicks an item from that list, I need to load up related items in a second SelectWidget below it. This could be done with Ajax or other means. I looked through the demo site and I was surprised to find no example of this (Unless I somehow missed it?) http://deformdemo.repoze.org Seems like a fairly obvious feature, how do I implement this with deform? Hope I don't have to dig too much into creating my own custom widgets. -- Thanks, Richie Ward -- 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.
Chameleon have template inheritance like mako?
I have used Mako with pylons, now I am trying to rap my head around chameleon for pyramid. How do we keep our templates DRY using chameleon? Does it support template inheritance? (Where you can have a base file and just include it into the other template files) -- -- Regards, Bruce Wade http://ca.linkedin.com/in/brucelwade http://www.wadecybertech.com http://www.warplydesigned.com http://www.fittraineronline.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: Chameleon have template inheritance like mako?
On Wed, 2011-06-22 at 14:13 -0700, Bruce Wade wrote: I have used Mako with pylons, now I am trying to rap my head around chameleon for pyramid. How do we keep our templates DRY using chameleon? Does it support template inheritance? (Where you can have a base file and just include it into the other template files) One option is to just use Mako: http://docs.pylonsproject.org/projects/pyramid/1.0/narr/templates.html#templating-with-mako-templates -- -- Regards, Bruce Wade http://ca.linkedin.com/in/brucelwade http://www.wadecybertech.com http://www.warplydesigned.com http://www.fittraineronline.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. -- 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: Chameleon have template inheritance like mako?
Is chameleon faster then mako? Is that why it is the default with pyramid? On Wed, Jun 22, 2011 at 2:19 PM, Joe Dallago jd.dall...@gmail.com wrote: You can use Mako with Pyramid, http://docs.pylonsproject.org/projects/pyramid/1.0/narr/templates.html#templating-with-mako-templates . You can also do inheritance in Chameleon, not sure how though off the top of my head. On Wed, Jun 22, 2011 at 4:13 PM, Bruce Wade bruce.w...@gmail.com wrote: I have used Mako with pylons, now I am trying to rap my head around chameleon for pyramid. How do we keep our templates DRY using chameleon? Does it support template inheritance? (Where you can have a base file and just include it into the other template files) -- -- Regards, Bruce Wade http://ca.linkedin.com/in/brucelwade http://www.wadecybertech.com http://www.warplydesigned.com http://www.fittraineronline.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. -- 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. -- -- Regards, Bruce Wade http://ca.linkedin.com/in/brucelwade http://www.wadecybertech.com http://www.warplydesigned.com http://www.fitnessfriendsfinder.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: Chameleon have template inheritance like mako?
On Wed, 2011-06-22 at 14:21 -0700, Bruce Wade wrote: Is chameleon faster then mako? Is that why it is the default with pyramid? Not really. There can only be one default; we chose Chameleon in the built-in scaffolds for hysterical documentation raisins. If you want a full-on Pylons experience (including Mako as the default templating language), use Akhet. See http://docs.pylonsproject.org/docs/pyramid.html On Wed, Jun 22, 2011 at 2:19 PM, Joe Dallago jd.dall...@gmail.com wrote: You can use Mako with Pyramid, http://docs.pylonsproject.org/projects/pyramid/1.0/narr/templates.html#templating-with-mako-templates. You can also do inheritance in Chameleon, not sure how though off the top of my head. On Wed, Jun 22, 2011 at 4:13 PM, Bruce Wade bruce.w...@gmail.com wrote: I have used Mako with pylons, now I am trying to rap my head around chameleon for pyramid. How do we keep our templates DRY using chameleon? Does it support template inheritance? (Where you can have a base file and just include it into the other template files) -- -- Regards, Bruce Wade http://ca.linkedin.com/in/brucelwade http://www.wadecybertech.com http://www.warplydesigned.com http://www.fittraineronline.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. -- 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. -- -- Regards, Bruce Wade http://ca.linkedin.com/in/brucelwade http://www.wadecybertech.com http://www.warplydesigned.com http://www.fitnessfriendsfinder.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. -- 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: Chameleon have template inheritance like mako?
Ok I will check out Akhet thanks. On Wed, Jun 22, 2011 at 2:23 PM, Chris McDonough chr...@plope.com wrote: On Wed, 2011-06-22 at 14:21 -0700, Bruce Wade wrote: Is chameleon faster then mako? Is that why it is the default with pyramid? Not really. There can only be one default; we chose Chameleon in the built-in scaffolds for hysterical documentation raisins. If you want a full-on Pylons experience (including Mako as the default templating language), use Akhet. See http://docs.pylonsproject.org/docs/pyramid.html On Wed, Jun 22, 2011 at 2:19 PM, Joe Dallago jd.dall...@gmail.com wrote: You can use Mako with Pyramid, http://docs.pylonsproject.org/projects/pyramid/1.0/narr/templates.html#templating-with-mako-templates . You can also do inheritance in Chameleon, not sure how though off the top of my head. On Wed, Jun 22, 2011 at 4:13 PM, Bruce Wade bruce.w...@gmail.com wrote: I have used Mako with pylons, now I am trying to rap my head around chameleon for pyramid. How do we keep our templates DRY using chameleon? Does it support template inheritance? (Where you can have a base file and just include it into the other template files) -- -- Regards, Bruce Wade http://ca.linkedin.com/in/brucelwade http://www.wadecybertech.com http://www.warplydesigned.com http://www.fittraineronline.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. -- 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. -- -- Regards, Bruce Wade http://ca.linkedin.com/in/brucelwade http://www.wadecybertech.com http://www.warplydesigned.com http://www.fitnessfriendsfinder.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. -- 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. -- -- Regards, Bruce Wade http://ca.linkedin.com/in/brucelwade http://www.wadecybertech.com http://www.warplydesigned.com http://www.fitnessfriendsfinder.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: Chameleon have template inheritance like mako?
There's a bug in the newly released pyramid 1.1 alpha 1. Temporary solution until 1.1 alpha 2 is out: easy_install pyramid==1.0 -- Michael -- 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: Chameleon have template inheritance like mako?
That works thanks On Wed, Jun 22, 2011 at 3:37 PM, Michael Merickel mmeri...@gmail.comwrote: There's a bug in the newly released pyramid 1.1 alpha 1. Temporary solution until 1.1 alpha 2 is out: easy_install pyramid==1.0 -- Michael -- 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. -- -- Regards, Bruce Wade http://ca.linkedin.com/in/brucelwade http://www.wadecybertech.com http://www.warplydesigned.com http://www.fitnessfriendsfinder.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.
Pyramid 1.1a2 released
The second alpha of Pyramid 1.1 (1.1a2) has been released. Here are the changes: Bug Fixes - - 1.1a1 broke Akhet by not providing a backwards compatibility import shim for ``pyramid.paster.PyramidTemplate``. Now one has been added, although a deprecation warning is emitted when Akhet imports it. - If multiple specs were provided in a single call to ``config.add_translation_dirs``, the directories were inserted into the beginning of the directory list in the wrong order: they were inserted in the reverse of the order they were provided in the ``*specs`` list (items later in the list were added before ones earlier in the list). This is now fixed. Backwards Incompatibilities --- - The pyramid Router attempted to set a value into the key ``environ['repoze.bfg.message']`` when it caught a view-related exception for backwards compatibility with applications written for ``repoze.bfg`` during error handling. It did this by using code that looked like so:: # why is an exception object try: msg = why[0] except: msg = '' environ['repoze.bfg.message'] = msg Use of the value ``environ['repoze.bfg.message']`` was docs-deprecated in Pyramid 1.0. Our standing policy is to not remove features after a deprecation for two full major releases, so this code was originally slated to be removed in Pyramid 1.2. However, computing the ``repoze.bfg.message`` value was the source of at least one bug found in the wild (https://github.com/Pylons/pyramid/issues/199), and there isn't a foolproof way to both preserve backwards compatibility and to fix the bug. Therefore, the code which sets the value has been removed in this release. Code in exception views which relies on this value's presence in the environment should now use the ``exception`` attribute of the request (e.g. ``request.exception[0]``) to retrieve the message instead of relying on ``request.environ['repoze.bfg.message']``. A What's New In Pyramid 1.1 document exists at http://docs.pylonsproject.org/projects/pyramid/1.1/whatsnew-1.1.html . You will be able to see the 1.1 release documentation (across all alphas and betas, as well as when it eventually gets to final release) at http://docs.pylonsproject.org/projects/pyramid/1.1/ . You can install it via PyPI: easy_install Pyramid==1.1a2 Enjoy, and please report any issues you find to the issue tracker at https://github.com/Pylons/pyramid/issues Thanks! - 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: Chameleon have template inheritance like mako?
FWIW alpha 2 is now released, so you can continue to use 1.1 if you would like. -- Michael -- 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: Pyramid 1.1a2 released
So I asked a few questions in #python, and there seemed to be some disagreement with trying to support 2.5-3.2 all in one code base without the use of 2to3 and 3to2. I wanted to know how you felt about it. Some of their main points were that it makes the code quite messy for both versions, and a lot of dirty hacks have to be used to support all the way back to 2.5. Here is most of the discussion http://pastebin.com/Y5QPJukD. Supporting Python 2 and 3 through code generation is a lot easier than I think you believe, you can extend lib2to3 to do pretty much everything you need, and distribute can run 2to3 or 3to2 on a system to make sure it gets the correct version of the codebase. Just check it out, b/c I do feel like I am really making changes that will have to ine day be deciphered again to fit Python 3 fully, which includes buying into Py3's way of doing things. On Wed, Jun 22, 2011 at 6:43 PM, Chris McDonough chr...@plope.com wrote: The second alpha of Pyramid 1.1 (1.1a2) has been released. Here are the changes: Bug Fixes - - 1.1a1 broke Akhet by not providing a backwards compatibility import shim for ``pyramid.paster.PyramidTemplate``. Now one has been added, although a deprecation warning is emitted when Akhet imports it. - If multiple specs were provided in a single call to ``config.add_translation_dirs``, the directories were inserted into the beginning of the directory list in the wrong order: they were inserted in the reverse of the order they were provided in the ``*specs`` list (items later in the list were added before ones earlier in the list). This is now fixed. Backwards Incompatibilities --- - The pyramid Router attempted to set a value into the key ``environ['repoze.bfg.message']`` when it caught a view-related exception for backwards compatibility with applications written for ``repoze.bfg`` during error handling. It did this by using code that looked like so:: # why is an exception object try: msg = why[0] except: msg = '' environ['repoze.bfg.message'] = msg Use of the value ``environ['repoze.bfg.message']`` was docs-deprecated in Pyramid 1.0. Our standing policy is to not remove features after a deprecation for two full major releases, so this code was originally slated to be removed in Pyramid 1.2. However, computing the ``repoze.bfg.message`` value was the source of at least one bug found in the wild (https://github.com/Pylons/pyramid/issues/199), and there isn't a foolproof way to both preserve backwards compatibility and to fix the bug. Therefore, the code which sets the value has been removed in this release. Code in exception views which relies on this value's presence in the environment should now use the ``exception`` attribute of the request (e.g. ``request.exception[0]``) to retrieve the message instead of relying on ``request.environ['repoze.bfg.message']``. A What's New In Pyramid 1.1 document exists at http://docs.pylonsproject.org/projects/pyramid/1.1/whatsnew-1.1.html . You will be able to see the 1.1 release documentation (across all alphas and betas, as well as when it eventually gets to final release) at http://docs.pylonsproject.org/projects/pyramid/1.1/ . You can install it via PyPI: easy_install Pyramid==1.1a2 Enjoy, and please report any issues you find to the issue tracker at https://github.com/Pylons/pyramid/issues Thanks! - 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: Pyramid 1.1a2 released
Did not mean to send that reply to pylons-discuss, doesn't really concern everyone XD. Sorry. On Jun 22, 11:06 pm, Joe Dallago jd.dall...@gmail.com wrote: So I asked a few questions in #python, and there seemed to be some disagreement with trying to support 2.5-3.2 all in one code base without the use of 2to3 and 3to2. I wanted to know how you felt about it. Some of their main points were that it makes the code quite messy for both versions, and a lot of dirty hacks have to be used to support all the way back to 2.5. Here is most of the discussionhttp://pastebin.com/Y5QPJukD. Supporting Python 2 and 3 through code generation is a lot easier than I think you believe, you can extend lib2to3 to do pretty much everything you need, and distribute can run 2to3 or 3to2 on a system to make sure it gets the correct version of the codebase. Just check it out, b/c I do feel like I am really making changes that will have to ine day be deciphered again to fit Python 3 fully, which includes buying into Py3's way of doing things. On Wed, Jun 22, 2011 at 6:43 PM, Chris McDonough chr...@plope.com wrote: The second alpha of Pyramid 1.1 (1.1a2) has been released. Here are the changes: Bug Fixes - - 1.1a1 broke Akhet by not providing a backwards compatibility import shim for ``pyramid.paster.PyramidTemplate``. Now one has been added, although a deprecation warning is emitted when Akhet imports it. - If multiple specs were provided in a single call to ``config.add_translation_dirs``, the directories were inserted into the beginning of the directory list in the wrong order: they were inserted in the reverse of the order they were provided in the ``*specs`` list (items later in the list were added before ones earlier in the list). This is now fixed. Backwards Incompatibilities --- - The pyramid Router attempted to set a value into the key ``environ['repoze.bfg.message']`` when it caught a view-related exception for backwards compatibility with applications written for ``repoze.bfg`` during error handling. It did this by using code that looked like so:: # why is an exception object try: msg = why[0] except: msg = '' environ['repoze.bfg.message'] = msg Use of the value ``environ['repoze.bfg.message']`` was docs-deprecated in Pyramid 1.0. Our standing policy is to not remove features after a deprecation for two full major releases, so this code was originally slated to be removed in Pyramid 1.2. However, computing the ``repoze.bfg.message`` value was the source of at least one bug found in the wild (https://github.com/Pylons/pyramid/issues/199), and there isn't a foolproof way to both preserve backwards compatibility and to fix the bug. Therefore, the code which sets the value has been removed in this release. Code in exception views which relies on this value's presence in the environment should now use the ``exception`` attribute of the request (e.g. ``request.exception[0]``) to retrieve the message instead of relying on ``request.environ['repoze.bfg.message']``. A What's New In Pyramid 1.1 document exists at http://docs.pylonsproject.org/projects/pyramid/1.1/whatsnew-1.1.html. You will be able to see the 1.1 release documentation (across all alphas and betas, as well as when it eventually gets to final release) athttp://docs.pylonsproject.org/projects/pyramid/1.1/. You can install it via PyPI: easy_install Pyramid==1.1a2 Enjoy, and please report any issues you find to the issue tracker at https://github.com/Pylons/pyramid/issues Thanks! - 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 athttp://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.
