Re: [pylons-devel] Probelms with wairtress in Python 2.7.7
Am 04.06.2014 12:58, schrieb Tjelvar: Yesterday we encountered a problem with Waitress when using the newly released Python 2.7.7 (on windows). I can confirm this issue on Python 2.7.7. It is obviously caused by the patch for http://bugs.python.org/issue15207 after which some mime types are returned as unicode instead of str under Windows. -- Christoph -- You received this message because you are subscribed to the Google Groups pylons-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.
Re: Pyramid debug toolbar and non-ascii errors
Am 25.10.2011 23:22, schrieb Christoph Zwerschke: Ok, I'll try to work out a full patch with unit tests tomorrow. Just wanted to know if anybody already stumbled over that problem. It's here now: https://github.com/Pylons/pyramid_debugtoolbar/pull/43 -- Christoph -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Pyramid debug toolbar and non-ascii errors
The Pyramid debug toolbar is a real blessing. I think we need to rip it
for use with TurboGears, too ;-)
However, I have experienced some issues with exceptions when they have a
non-ascii error message (I remember there were similar problems with the
Pylons weberror module). For instance, PostgreSQL creates error messages
in latin-1 or utf-8 depending on how it is configured. The debug toolbar
assumes that error messages are always ascii strings or unicode and
crashes with a UnicodeDecodeError on such exceptions.
Is this a known problem?
My solution was to wrap exceptions and tracebacks in text_() calls, e.g.
in render_summary, render_full and generate_plaintext_traceback.
This avoids the crashes, but utf-8 messages will look odd because
text_() assumes latin-1 encoding by default. My suggestion is to replace
the latin-1 default with utf-8 and fall back to latin-1 only in case the
text is not decodable as utf-8. Like this:
def text_(s, encoding=None, errors='strict'):
if isinstance(s, binary_type):
if not encoding:
try:
return s.decode('utf-8')
except UnicodeDecodeError:
encoding = 'latin-1'
return s.decode(encoding, errors)
return s # pragma: no cover
This has been working nicely for me. Thougts?
If you think that makes sense, I can submit a patch on github.
-- Christoph
--
You received this message because you are subscribed to the Google Groups
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
Bug tracker for the (old) Pylons framework
Just noticed that the former Trac for the Pylons framework that used to live under http://pylonshq.com/project/pylonshq/ is no more. I found a new tracker at https://github.com/Pylons/pylons/issues, but it has only a handful of tickets. What happened to all the old Pylons tickets? -- Christoph -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
Am 04.03.2011 09:11 schrieb mjmein: In my mind we still need something that works on Django level, with more constraints imposed, but I am expecting that the new version of TurboGears based on Pyramid would address that. That's also my understanding. Our experience with the TG project is also that users really dislike if you force them to make choices. For instance, when TG2 was still young, it was difficult to choose between the more mature TG1 or the upcoming TG2. And then you also had the choice between SQLObject and SQLAlchemy, between Kid and Genshi, etc. The choice between traversal and dispatch presents a similar difficulty to new Pyramid users. Newbies hate such choices because when they start using a framework, they don't have enough experience to make an educated decision and they fear that they will waste a lot of time if they make the wrong choice in the beginning. That's why I think it's a good idea to build an opinionated framework on top of Pyramid where those choices have been made for you that will work best in the majority of cases. Regarding documentation, Donald Knuth's technique of simplifying things in the first chapters and mentioning the exceptions and alternatives only later may be helfpful for newbies: (From the TeXbook: Another noteworthy characteristic of this manual is that it doesn't always tell the truth ... The author feels that this technique of deliberate lying will actually make it easier for you to learn the ideas. Once you understand the simple but false rule, it will not be hard to supplement that rule with its exceptions.) -- Christoph -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Raw MySQL with SQLAlchemy using Pyramid framework
Am 20.02.2011 10:58 schrieb AwaisMuzaffar: My main reason for using raw is that I have spent so much time learning MySQL, to me it seems counter productive to learn SQLALchemy methodologies from scratch. Ok, so maybe manually executing CREATE is not a great idea, but what about performing queries with pure MySQL, is that fine? Good knowledge of SQL is needed anyway even if you're using SQLAlchemy. Just as you should know HTML if you create web sites, even if you're using higher level or wysiwyg tools. And even if you don't want to use ORM part of SQLAlchemy, you should still use the lower level SQLAlchemy. For instance, SQLAlchemy provides proper connection pooling and a SQL expression language that helps you create queries working with different databases (e.g. PostgreSQL instead of MySQL) and not susceptible to SQL hacking. -- Christoph -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Pyramid status update...
Am 12.01.2011 10:03, schrieb Chris McDonough: - Figure out how to slim the herd of paster templates. You can use http://pythonpaste.org/tempita/ to make case distinctions in the paster templates, so you don't need to create separate templates for every subfeature or option that involves only minor tweaks. TurboGears is doing it that way and it works very well, the templates do not get too complicated. -- Christoph -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Pyramid status update...
Am 12.01.2011 11:30, schrieb Chris McDonough: I'm not a big fan of conditionalized templates, as they're even harder to test than non-conditionalized ones (we don't even yet have automated tests for the non-conditionalized ones). As these would be integration or system tests anyway, I don't see how these tests would be fundamentally different. I would simply create the project in a temp dir with paster quickstart and different combination of options, and then run the functional tests of the created project. Will check how this works if I find some time this weekend. -- Christoph -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Pyramid status update...
Am 12.01.2011 12:02, schrieb Chris McDonough: The intent is to have only one non-conditional paster template in the core distribution, but this work might be useful to other paster template developers. Ok, maybe these templates could go into a supplementary package then. TurboGears 2 has them in a separate package, too (tg2dev instead of tg2). The core package would then keep only the core templates. -- Christoph -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: pyramid terminology: model-resource
Am 17.12.2010 15:42 schrieb Graham Higgins: For example, model graph (used in the Pyramid docs) suffers from the same difficulty as does little baby. It unnecessarily complicates the narrative with a tautological conceptual entity. This btw is another reason why I don't like the term model. Some people seem to use it for the whole graph or database scheme, others seem to use it for a single node or entity. This always confuses me. The terms resource or location do not have this problem. -- Christoph -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: pyramid terminology: model-resource
Am 16.12.2010 09:59 schrieb Andrey Popp: How about term location? I think it's more suitable: This sounds reasonable to me as somebody who has not yet used Pyramid and is not yet aquainted with its functionality. I don't like the term model because it is confusing for people coming from other frameworks where it is associated with the ORM, and because the word model bears no association with the notion of traversal. The term location is much better in this regard. -- Christoph -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Pyramid application templates
Am 11.11.2010 05:05 schrieb Mike Orr: I think we need to think strategically about Pyramid's application templates. There are already eight of them, with overlapping functionality and inconsistent names. There will probably be more templates coming, both bundled with Pyramid and separate. ChrisM has said he doesn't like conditional templates (i.e., templates with questions), but they've worked well in Pylons and they would allow a streamlining of the current and future templates. That's also what I was thinking when I tried out Pyramid. Having a template for every combination of options is really not maintainable and extendable. But in paster templates you can use a small templating language, so conditional templates are easy to implement: http://pythonpaste.org/tempita/modules/tempita.html. TurboGears has used this, too, in order to add options such as authorization or switch SQLobject against SQLAlchemy or Genshi against Malo. (For historical reasons TG used Cheetah here, but nowadays Tempita is a better choice because it's already included in Paste.) -- Christoph -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: pylons future plans?
Kyle VanderBeek schrieb: Fixing the Contributing link might help others clone the official repo and start sending in patches: I've already reported this several times, but nobody cared. This was indeed not very encouraging for me. It's also unclear which of the related/sub projects (webhelpers etc.) have their own repos, where they are, where to report errros for these, send in patches etc. -- Christoph --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en -~--~~~~--~~--~--~---
Unicode problems with weberror
At http://trac.turbogears.org/ticket/2238 I have reported a problem that is caused by the weberror package (0.10.1 and current tip). Is the Pylons trac the proper place to report such problems? If yes, it would be nice to have weberror selectable as component when creating a ticket. It is somewhat difficult to find the maintainers and repository of weberror on the Pylons website. Also, the link Code - Contributing in the main menu of the website seems to be broken. -- Christoph --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en -~--~~~~--~~--~--~---
