[issue9659] frozenset, when subclassed will yield warning upon call to super(...).__init__(iterable)
New submission from Carsten Klein : Example class a(frozenset): def __init__(self, iterable): super(a, self).__init__(iterable) i = a([1,2,3]) > __main__:3: DeprecationWarning: object.__init__() takes no parameters > a([1, 2, 3]) This might be due to the fact that the frozenset type structure does not initialize the tp_init field in setobject.c, thus inheriting the original __init__ from object. Subclassing set will not issue that warning as it actually defines the tp_init field to (initroc)set_init. This holds true also for the Python 2.7 release and maybe also later releases. Expected behaviour: do not output that warning message and provide an initproc for the tp_field. -- components: None messages: 114676 nosy: carsten.kl...@axn-software.de priority: normal severity: normal status: open title: frozenset, when subclassed will yield warning upon call to super(...).__init__(iterable) type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue9659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9659] frozenset, when subclassed will yield warning upon call to super(...).__init__(iterable)
Carsten Klein added the comment: Thanks for the information. Where is this documented? I cannot find it in the official Python docs... TIA. -- ___ Python tracker <http://bugs.python.org/issue9659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9680] Add in declaration order support for the dictionary passed in to the meta class __init__ and __new__ methods
New submission from Carsten Klein : Example class Meta(type): def __new__(cls, name, bases, locals): print repr(locals.keys()) class Test(object): __metaclass__ = Meta A = 1 B = 2 C = 3 D = 4 E = 5 The above will yield the keys in a somewhat random order, everytime you start up the Python interpreter: ['__module__', 'E', 'C', 'D', 'B', '__metaclass__', 'A'] While the above example is far from complete, it shows the basic dilemma when having some concept that relies on the order in which the elements have been declared and in the order by which they have been processed during the parse phase and ast traversal phase. In the aforementioned first two phases one can rely on the declaration order, but as soon as we enter the __new__ method, the order becomes irrelevant and is completely lost. For a framework of mine, I would like the locals dict that is being passed as an argument to the __new__ method to give out references to the keys in the order in which they have been declared in the dict. Thus, the above example would yield ['__metaclass__', '__module__', 'A', 'B', 'C', 'D', 'E'] The basic reason is that I find it more intuitive to class A(object): __metaclass__ = Meta A = 5 Z = 9 than class A(object): __metaclass__ = Meta __fields__ = ((A,5), (Z,9)) As you might easily guesses, the main application for the above is a new enum type I am currently developing, where the order is important as every new instance of that class must always yield the same ordinals for the individual constants declared. This should not break with the overall contract of the dict, which defines that keys returned are in no specific order. Thus, adding a specific order to keys in the above locals dict for class instantiation purposes only, would not break with existing code and should be both backwards and forwards compatible. -- components: Interpreter Core messages: 114890 nosy: carsten.kl...@axn-software.de priority: normal severity: normal status: open title: Add in declaration order support for the dictionary passed in to the meta class __init__ and __new__ methods type: feature request versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue9680> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Carsten Klein added the comment:
Guess you are right...
I did overlook the quoted-string reference in the RFC:
av-pair = attr ["=" value]; optional value
attr= token
value = word
word= token | quoted-string
The actual production rules for quoted-string are not specified, so I guess
that anything resembling unicode data would be allowed in that string provided
that:
[...] from RFC 2109
10.1.3 Punctuation
In Netscape's original proposal, the values in attribute-value pairs
did not accept "-quoted strings. Origin servers should be cautious
about sending values that require quotes unless they know the
receiving user agent understands them (i.e., "new" cookies). A
("new") user agent should only use quotes around values in Cookie
headers when the cookie's version(s) is (are) all compliant with this
specification or later.
in RFC 2965 there is no such notice...
However, and this is important, the cookie values not matching token must be
quoted by the origin server upon setting and the client must return these as
quoted strings as well.
--
___
Python tracker
<http://bugs.python.org/issue2193>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Carsten Klein added the comment:
Ups forgot to also mention the production rule for token, which is defined in
the HTTP RFC RFC2616:
token = 1*
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
and here it clearly states that a value that is not a quoted string
must not contain colons, and other characters as is specified by separators.
--
___
Python tracker
<http://bugs.python.org/issue2193>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Carsten Klein added the comment: Perhaps the best solution would be for the Python cookie module to gracefully adapt to servers not quoting cookie values as is required by the RFCs and make these quoted-strings instead? -- ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11774] Issue tracker sends notification mails twice...
New submission from Carsten Klein : Currently I am receiving duplicates of the notification mails by your issue tracker. -- messages: 133062 nosy: carsten.kl...@axn-software.de priority: normal severity: normal status: open title: Issue tracker sends notification mails twice... ___ Python tracker <http://bugs.python.org/issue11774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11774] Issue tracker sends notification mails twice...
Carsten Klein added the comment: It seems that it only happens when commenting upon an existing issue. -- ___ Python tracker <http://bugs.python.org/issue11774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11774] Issue tracker sends notification mails twice...
Carsten Klein added the comment: Nope, it only happens on issue [issue2193] Cookie Colon Name Bug but not for this one. -- ___ Python tracker <http://bugs.python.org/issue11774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11774] Issue tracker sends notification mails twice...
Carsten Klein added the comment: Ah, I see, thanks for the input. Will close this then. -- ___ Python tracker <http://bugs.python.org/issue11774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11774] Issue tracker sends notification mails twice...
Carsten Klein added the comment: I wonder how this happened... Thanks for the finding! -- ___ Python tracker <http://bugs.python.org/issue11774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Changes by Carsten Klein : -- nosy: +carsten.klein -carsten.kl...@axn-software.de ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11774] Issue tracker sends notification mails twice...
Carsten Klein added the comment: Actually I logged in using carsten.kl...@axn-software.de and the tracker changed my login name to that... Will issue a bug against the tracker... -- nosy: +carsten.klein ___ Python tracker <http://bugs.python.org/issue11774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11774] Issue tracker sends notification mails twice...
Changes by Carsten Klein : -- nosy: -carsten.kl...@axn-software.de ___ Python tracker <http://bugs.python.org/issue11774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11788] Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
New submission from Carsten Klein : Scenario: class deco(object): def __init__(self, optional = False): self._optional = optional def __call__(self, decorated): decorated.optional = self._optional return decorated @deco class y(object): pass will fail decorating the class since y is passed in as the first parameter to deco.__init__, and deco.__call__ will never be called. @deco(optional = True) class y(object): pass will succeed. I wonder why there is a distinction between decorator class w/ arguments and decorator class w/o arguments? Guessing that one would like to have a decorator class decorating another class and also acting as a kind of proxy by implementing a __call__ method, this could also be achieved by further indirection, provided that it will not break existing code. A working alternative would be a decorator function like this: def deco(_decorated = None, optional = False): def _wrapped(decorated): decorated.optional = optional return decorated if _decorated is not None: return _wrapped(decorated) return _wrapped Is there a chance that the behavior of the decorator class will be fixed in a future release? Expected behavior for the decorator class would be: if formal parameter list has optional parameters and actual parameter list is empty and there are no formal mandatory parameters: if decorator class is callable: deco = decorator class () decor.__call__(decorated) else: fall back to old behaviour, requiring the decorator class __init__ method to have one mandatory parameter else: deco = decorator class(actual parameters...) deco.__call__(decorated) TIA -- components: Interpreter Core messages: 133171 nosy: carsten.klein priority: normal severity: normal status: open title: Decorator class with optional arguments and a __call__ method gets not called when there are no arguments type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue11788> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11788] Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
Carsten Klein added the comment: will fail decorating the class since y... actually means that instead of an instance of class y, an instance of the decorator class will be returned, with y being lost along the way... -- ___ Python tracker <http://bugs.python.org/issue11788> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11789] Extend upon metaclass/type class documentation, here: zope.interface and usage of instances of classes as base classes
New submission from Carsten Klein : In zope.interface, you have something the following construct: class InterfaceBase: pass Interface = InterfaceBase() Using the above Interface as a derivation base for your own classes, will make that instance a type derived class: class IFoo(Interface): pass type(IFoo) -> Interface type(Interface) -> type I wonder why this behavior is not documented in the official documentation, or at least, I was unable to find it there... -- assignee: docs@python components: Documentation messages: 133173 nosy: carsten.klein, docs@python priority: normal severity: normal status: open title: Extend upon metaclass/type class documentation, here: zope.interface and usage of instances of classes as base classes type: feature request versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue11789> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11788] Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
Carsten Klein added the comment: I think it is, actually, considering @foo @bar class A: pass with foo and bar being both decorator classes, the chained call foo(bar(A)) will return and instance of foo instead of A With decorator classes you need to actually do this: foo()(bar()(A)) which will give you the "required" result, an instance of class A. -- ___ Python tracker <http://bugs.python.org/issue11788> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11788] Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
Carsten Klein added the comment: Ok, looks like a valid work around to me. However, IMO it is not the same as with decorator functions. These will be called and will return the correct result, whereas the decorator class will instead return an instance of self instead of being called when no parameters are given. -- ___ Python tracker <http://bugs.python.org/issue11788> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Carsten Klein added the comment: Personally I believe that this is WONTFIX. Why? Because, the original RFC states that the colon is part of the unwanted characters, regardless of whether Perl or other similar implementations ignore the standard. Besides that, and most important: The cookies are always set by the server or application thereof. Therefore, the server must behave just like what is stated in the original RFC. And it must also expect existing browsers to behave just like what is requested in the RFC. IMO, the original requester and supporters, both here and over on the trac issue tracker are simply not able to figure out a proper cookie tracking mechanism for marketing or whatever purposes. Or, perhaps, they want to exploit some unwanted behaviour in existing user agents, who knows. Besides that, if the original poster and follow up requesters supporting the issue persist on using a non standard implementation of the cookie library, hey, who cares. Let them figure out how to patch or rewrite the existing library, and how to include it with their favourite server/user agent exploiting implementation. And the same is true for the request on the trac issue tracker. Since the cookies are set by the server, there is no need to actually weaken the existing pseudo standard by incorporating ways to hierarchically define a cookie name other than what is already present in the scheme or could be accomplished using different characters other than those blacklisted. -- nosy: +carsten.klein ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Carsten Klein added the comment:
One more: if you look closer at the accepted patch by CMLENZ over @ t.e.o., you
will find:
if self.req.headers_in.has_key('Cookie'):
-self.incookie.load(self.req.headers_in['Cookie'])
+#self.incookie.load(self.req.headers_in['Cookie'])
+cookie = self.req.headers_in['Cookie']
+old_set = self.incookie._BaseCookie__set
+bad_cookies = []
+def safe_set(key, real_value, coded_value):
+try:
+old_set(key, real_value, coded_value)
+except CookieError:
+bad_cookies.append(key)
+dict.__setitem__(self.incookie, key, None)
+# override Cookie.set to ignore cookies with parse errors
+self.incookie._BaseCookie__set = safe_set
+ # load the cookie values
+self.incookie.load(cookie)
+# clean up the Cookie.set overriding
+self.incookie._BaseCookie__set = old_set
+for key in bad_cookies:
+del self.incookie[key]
+
which will eventually delete all cookies that do not match the original
production rule.
Besides that, the original poster of the issue forgot to properly limit the
cookies set by the other site to just a single host path, so these invalid
cookies got routed to the trac instance running on some different host.
--
___
Python tracker
<http://bugs.python.org/issue2193>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Carsten Klein added the comment: if you'd take a close look at the following lines accepted as part of the patch for stripping out unwanted/non standard cookies over trac: +try: +old_set(key, real_value, coded_value) +except CookieError: +bad_cookies.append(key) then you will find that trac actually behaves just like what is requested in the "original" RFC, namely that the colon is part of the reserved or special characters not meant for inclusion with the cookie name or, as it was stated in the referred rfc, the token. Please do not fix. -- nosy: +carsten.kl...@axn-software.de ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Carsten Klein added the comment: Besides that, BM is wrong in the assumption that *who ever he is* Davi M. Kristol states that the colon is a valid character. There is no such notion in the article. In fact, DMK repeats the definition found in the original RFC on cookies, which also was referred to in the follow up RFC and then again referred to in the current RFC which seeks to get rid of the set-cookie2 directive, combining the two RFCs into a single RFC/pseudo standard. -- ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12370] Use of super overwrites use of __class__ in class namespace
Carsten Klein added the comment: The change was introduced in r30 (Python/symtable.c @ near where it reads /* Special-case super: it counts as a use of __class__ */) which now enforces that a class that calls super on init will have the correct class information present. I do not think that this is a bug and that it should be fixed. Instead it enforces both type safety in respect to classes deriving from a given class hierarchy being forced to report their actual class instead of some fabricated and customly induced one. If you require such behaviour then you should implement your own meta class that will then override the __class__ property. And, yes, I do think that Python < 3.0 was wrong in the assumption that one could build up class hierarchies and then break out of that class hierarchy by simply providing a __class__ property that would return a different value as what one would expected. What do the others think? -- nosy: +carsten.kl...@axn-software.de ___ Python tracker <http://bugs.python.org/issue12370> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 for multiline string expressions resembling docstrings
New submission from Carsten Klein:
Given an input module such as
class klass(object):
"""multi line comment
continued on this line
"""
"""single line comment"""
"""
Another multi
line
comment"""
and implementing a custom ast.NodeVisitor such as
import as
class CustomVisitor(ast.NodeVisitor):
def visit_ClassDef(self, node):
for childNode in node.body:
self.visit(childNode)
def visit_Expr(self, node):
print(node.col_offset)
print(node.value.col_offset)
and feeding it the compiled ast from the module above
f = open('./module.py')
source = f.read()
node = ast.parse(source, mode = 'exec')
visitor = CustomVisitor()
visitor.visit(node)
should yield -1/-1 for the docstring that is the first
child node expression of the classdef body.
it will, however, yield the correct col_offset of 4/4 for
the single line docstring following the first one.
the multi line docstring following that will again
yield a -1/-1 col_offset.
It believe that this behaviour is not correct and instead
the col_offset should be 4 for both the expression node
and its str value.
--
components: Interpreter Core
messages: 178444
nosy: carsten.kl...@axn-software.de
priority: normal
severity: normal
status: open
title: col_offset is -1 for multiline string expressions resembling docstrings
type: enhancement
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue16806>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 for multiline string expressions resembling docstrings
Carsten Klein added the comment: Please note that, regardless of the indent level, the col_offset for multi line str expressions will always be -1. -- ___ Python tracker <http://bugs.python.org/issue16806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 for multiline string expressions resembling docstrings
Carsten Klein added the comment: In addition, the reported lineno will be set to the last line of the multi line string instead of the first line where parsing the parse began parsing the string. -- ___ Python tracker <http://bugs.python.org/issue16806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 for multiline string expressions resembling docstrings
Carsten Klein added the comment: Please see the attached patch that will resolve the issue. It also includes a test case in test_ast.py. What the patch does is as follows: - tok_state is extended by two fields, namely first_lineno and multi_line_start - first_lineno will be set by tok_get as soon as the beginning of a STRING is detected and it will be set to the current line tok->lineno. - multi_line_start is the beginning of the first line of a string - in parsetok we now distinguish between STRING nodes and other nodes. in case of STRING nodes, we will use the values of the above fields for determining the actual lineno and the col_offset, otherwise tok->col_offset and tok->lineno will be used when creating the token. The included test case ensures that the col_offset and lineno of multi line strings is calculated correctly. -- keywords: +patch Added file: http://bugs.python.org/file28477/issue1680.diff ___ Python tracker <http://bugs.python.org/issue16806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 and lineno is wrong for multiline string expressions
Changes by Carsten Klein : -- title: col_offset is -1 for multiline string expressions resembling docstrings -> col_offset is -1 and lineno is wrong for multiline string expressions ___ Python tracker <http://bugs.python.org/issue16806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 and lineno is wrong for multiline string expressions
Changes by Carsten Klein : Removed file: http://bugs.python.org/file28477/issue1680.diff ___ Python tracker <http://bugs.python.org/issue16806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 and lineno is wrong for multiline string expressions
Changes by Carsten Klein : Added file: http://bugs.python.org/file28478/issue16806.diff ___ Python tracker <http://bugs.python.org/issue16806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16801] Preserve original representation for integers / floats in docstrings
Carsten Klein added the comment: The problem with this is that at the time that pydoc gets the information via inspect, the numbers have already been parsed as long or double and the original notation is no longer available. This is due to the fact that during build of the AST node for the NUMBER type, the value will already be deserialized into its machine representation, which is either long or double. The only way to preserve that information would be to extend the NUM_type with an additional 's' field which then would preserve its original notation and which can be retrieved from the AST. pydoc, however, would still fail as it does not use the AST. In order to restore the original information, pydoc must then source the original file or source of the function or class method and parse it using the AST. A much simpler approach would be to simply get the function or method source and extract its formal parameter list using for example a regular expression. However, preserving the original notation in the runtime is not required and shouldn't be done. -- nosy: +carsten.kl...@axn-software.de ___ Python tracker <http://bugs.python.org/issue16801> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16801] Preserve original representation for integers / floats in docstrings
Carsten Klein added the comment: Here are some links into the sources: Python/ast.c, ast_for_atom(), line 1872ff. Python/ast.c, parsenumber(), line 3632ff. -- ___ Python tracker <http://bugs.python.org/issue16801> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16801] Preserve original representation for integers / floats in docstrings
Carsten Klein added the comment: However, hinting inspect to use a different format when serializing the default values for existing keyword parameters of methods or functions seems to be a good idea and +1 by me for that. Personally, I'd rather have the decorator based solution than having to manually add additional fields to a given method or function. -- ___ Python tracker <http://bugs.python.org/issue16801> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 and lineno is wrong for multiline string expressions
Carsten Klein added the comment: I have created a patch for Python 2.7.3 that fixes the issue for that release, too. -- Added file: http://bugs.python.org/file28499/python2.7.3.diff ___ Python tracker <http://bugs.python.org/issue16806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17067] Examples in documentation for 3.x in 23.1.3.4. Deferred translations are rather weak
New submission from Carsten Klein:
The examples for the topic presented are rather weak. In fact, they merely
present do nothing replacements for an actually working, deferred localization
mechanism or some sort of prototypical implementation thereof.
As such I propose that they be replaced with something more meaningful,
for example such as
class DeferredTranslation(object):
def __init__(self, message, ...):
self.message = message
def __str__(self):
return gettext.translation(...).lgettext(self.message)
def _(message, ...):
return DeferredTranslation(message, ...)
MSG = _('localized message')
Or something else along that way other than the currently presented examples :D
--
assignee: docs@python
components: Documentation
messages: 180882
nosy: carsten.kl...@axn-software.de, docs@python
priority: normal
severity: normal
status: open
title: Examples in documentation for 3.x in 23.1.3.4. Deferred translations are
rather weak
type: enhancement
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue17067>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
