[Python-Dev] CHM filename (was Released: Python 2.6.6)
> The question really is whether there is any chance that they will get > released, in some form. There won't be further binary releases (at least > not from python.org), so there definitely won't be a CHM release. Speaking about the CHM, why does it include the version number in it's filename? Why isn't it named python.chm instead of python266.chm, just like we have python.exe and not python266.exe? I have shortcut links in the QuickLaunch area to the documentation for quick access and in a different launcher program. Each time I upgrade Python I must update them because of the embedded version number. Regards, Adal ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Released: Python 2.6.6
> The question really is whether there is any chance that they will get > released, in some form. There won't be further binary releases (at least > not from python.org), so there definitely won't be a CHM release. I think that the most important release is docs.python.org/2.6, regardless of python.org/OS-specific downloadable doc packages. If people do like haypo and use the most recent docs instead of the version-specific ones, there’s indeed no need to bother with porting doc fixes and improvements. If people use docs.py.org/2.6 as a reference for some years while 2.7 is not on their systems, it may be worthwhile to keep updating those docs. Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Released: Python 2.6.6
Le 08/25/2010 05:32 PM, Éric Araujo a écrit : > I think that the most important release is docs.python.org/2.6, > regardless of python.org/OS-specific downloadable doc packages. > > If people do like haypo and use the most recent docs instead of the > version-specific ones, there’s indeed no need to bother with porting doc > fixes and improvements. If people use docs.py.org/2.6 as a reference for > some years while 2.7 is not on their systems, it may be worthwhile to > keep updating those docs. We can also, recommend to always rely on the last version somewhere, if it's the best way to go. This way, we can avoid those questions in the future. I like how the django project present their documentation: there is a little informational text at the head of each doc, saying that "you're not browsing the most up-to-date documentation, you can find the last one here"; maybe can we do a similar thing for the python doc ? Regards, Alexis ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'hasattr' is broken by design
At 12:10 PM 8/25/2010 +1200, Greg Ewing wrote: Consider an object that is trying to be a transparent proxy for another object, and behave as much as possible as though it really were the other object. Should an attribute statically defined on the proxied object be considered dynamically defined on the proxy? If so, then the proxy isn't as transparent as some people may want. Yep. That's why the proposed addition to inspect is a bad idea. If we encourage that sort of static thinking, it will lead to people creating all sorts of breakage with respect to more dynamic code. AFAICT, the whole "avoid running code" thing only makes sense for a debugging tool -- at which point, you can always use the trace facility and throw an error when any Python code runs that's not part of your debugging tool. Something like: def exists(ob, attr): __running__ = True # ... set trace function here try: try: getattr(ob, attr) return True except AttributeError: return False except CodeRanError: return True # or False if you prefer finally: __running__ = False # restore old tracing here Where the trace function is just something that throws CodeRanError if it detects a "call" event and the __running__ flag is True. This would stop any Python code from actually executing. (It'd need to keep the same trace function for c_call events, since that might lead to nested non-C calls .) Of course, a debugger's object inspection tool would probably actually want to return either the attribute value, or a special value to mean "dyanmic calculation needed". ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'hasattr' is broken by design
On 25/08/2010 19:27, P.J. Eby wrote: At 12:10 PM 8/25/2010 +1200, Greg Ewing wrote: Consider an object that is trying to be a transparent proxy for another object, and behave as much as possible as though it really were the other object. Should an attribute statically defined on the proxied object be considered dynamically defined on the proxy? If so, then the proxy isn't as transparent as some people may want. Yep. That's why the proposed addition to inspect is a bad idea. If we encourage that sort of static thinking, it will lead to people creating all sorts of breakage with respect to more dynamic code. AFAICT, the whole "avoid running code" thing only makes sense for a debugging tool I mentioned another use case - pulling out docstrings. IDEs or other tools that work with live objects may have many such use cases. For proxying objects you can't use the __getattr__ approach for the "magic methods" which aren't looked up through the dynamic attribute 'faking' process. Several proxy libraries I've seen get round this by providing *every* magic method on the proxy class and delegating. This still breaks certain types of duck typing. For example with Python 2.6: >>> class x(object): ... @property ... def __call__(self): ... raise AttributeError ... >>> a = x() >>> callable(a) True If your proxy class defines __call__ then callable returns True, even if the delegation to the proxied object would cause an AttributeError to be raised. A *better* approach (IMO), for both the magic methods and the normal attributes / methods, is to dynamically generate a class that mimics the proxied object (caching generated classes for proxying objects of the same type if you are worried about overhead). This would also work with the suggested "passive introspection" function. All the best, Michael Foord -- at which point, you can always use the trace facility and throw an error when any Python code runs that's not part of your debugging tool. Something like: def exists(ob, attr): __running__ = True # ... set trace function here try: try: getattr(ob, attr) return True except AttributeError: return False except CodeRanError: return True # or False if you prefer finally: __running__ = False # restore old tracing here Where the trace function is just something that throws CodeRanError if it detects a "call" event and the __running__ flag is True. This would stop any Python code from actually executing. (It'd need to keep the same trace function for c_call events, since that might lead to nested non-C calls .) Of course, a debugger's object inspection tool would probably actually want to return either the attribute value, or a special value to mean "dyanmic calculation needed". ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: i18n
To those beginners in programming that are not English speakers there are 3 problems to be solved: 1) the logic (this is unavoidable) 2) the programming language (hard but quite simple) 3) the messages (hard and not simple) Those who could not cope with (1) could not be programmers (2) difficult but not the main (so a 2nd step) (3) the worst but more treatable and more largely useful The i18n of (2) is mainly to be used in initial stages and could not be generally applicable (maybe just some European languages). This probably could require to rewrote the scanner (or maybe only the grammar, I haven't gone so deep yet) so it's not that big of a problem, it hardly affects the parser and interpreter, that are the more complex tasks. If (3) could enter the main trunk it would be a great help by itself. In this case access to international help is useless due the original difficulties with the language, remember I'm talking about kids mainly, and 1st stage to programming for youngsters. There are two main ways to do this, one is using codes as indicated, but I prefer using the more generally accepted and used, with messages catalogs using gettext and the like. Any way thanks for your comments. Alcino 2010/8/17 Anders Sandvig > > On Sat, Aug 14, 2010 at 10:18 AM, Jeroen Ruigrok van der Werven > wrote: > > I doubt you will be able to localize much with regard to the interpreter. > > The only thing that really comes to mind are the error and exception > > messages, but you will never be able to localize the errors themselves. The > > problem there is that if they seek help on international fora for Python, > > other people might have no clue what the (error) message even means. > > I think one way to solve this might be to include the original > (English) error message as well as the translation. I've noticed this > is how error messages are handled in localized versions of Oracle, and > although I'm personally annoyed by it, I can see how some people might > find it useful. > > For example: > > >>> cause.error() > Traceback (most recent call last): > File "", line 1, in > NameError: name 'cause' is not defined > > localized to Norwegian, could become: > > >>> cause.error() > Tilbakesporing (nyeste kall sist): > Fil "", linje 1, i > NameError: navn 'cause' er ikke definert (name 'cause' is not defined) > > I think translating the actual error text would make sense, but I'm > not so sure about localizing the traceback output itself... > > > Anders ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: i18n
On Wed, Aug 25, 2010 at 10:59 AM, Alcino Dall'Igna Jr wrote: > To those beginners in programming that are not English speakers there > are 3 problems to be solved: > 1) the logic (this is unavoidable) > 2) the programming language (hard but quite simple) > 3) the messages (hard and not simple) > > Those who could not cope with (1) could not be programmers > > (2) difficult but not the main (so a 2nd step) > > (3) the worst but more treatable and more largely useful > > The i18n of (2) is mainly to be used in initial stages and could not > be generally applicable (maybe just some European languages). This > probably could require to rewrote the scanner (or maybe only the > grammar, I haven't gone so deep yet) so it's not that big of a > problem, it hardly affects the parser and interpreter, that are the > more complex tasks. IMO (2) is a bad idea. You'd have to translate not just the keywords but also the builtins and the standard library. Or else your users would still live in a mixed-world and the benefit would be minimal. But translating the stdlib is too much work. (It can't be fully automated, due to things like getattr(x, 'foo').) There's also the danger that users would write code in their local dialect and expect to share it with others in another locale. Let them read and write broken English, it's unavoidable anyway! (Probably they know more broken English than you think. After all they are using computers already. :-) > If (3) could enter the main trunk it would be a great help by itself. > In this case access to international help is useless due the original > difficulties with the language, remember I'm talking about kids > mainly, and 1st stage to programming for youngsters. There are two > main ways to do this, one is using codes as indicated, but I prefer > using the more generally accepted and used, with messages catalogs > using gettext and the like. That sounds painful, but in general I am okay with the idea of translating messages. I think the system messages (those that go with IOError and OSError) may already be translated. How to do it without off-putting the core developers may end up being a research problem. :-) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: i18n
On 25/08/2010 21:26, Guido van Rossum wrote: [snip...] If (3) could enter the main trunk it would be a great help by itself. In this case access to international help is useless due the original difficulties with the language, remember I'm talking about kids mainly, and 1st stage to programming for youngsters. There are two main ways to do this, one is using codes as indicated, but I prefer using the more generally accepted and used, with messages catalogs using gettext and the like. That sounds painful, but in general I am okay with the idea of translating messages. I think the system messages (those that go with IOError and OSError) may already be translated. How to do it without off-putting the core developers may end up being a research problem. :-) +1 - a difficult problem to solve (socially and architecturally but not technologically) but users are likely to appreciate it. A downside (from experience with .NET which takes this approach - logic and class names are all English but error messages are localized) is that you then get bug reports with localized error messages. It makes frequent visits to google translate unavoidable... All the best, Michael -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'hasattr' is broken by design
At 08:58 PM 8/25/2010 +0300, Michael Foord wrote: If your proxy class defines __call__ then callable returns True, even if the delegation to the proxied object would cause an AttributeError to be raised. Nope. You just have to use delegate via __getattribute__ (since 2.2) instead of __getattr__: >>> from peak.util.proxies import ObjectProxy >>> o=ObjectProxy(lambda:1) >>> o() 1 >>> o.__call__ >>> o=ObjectProxy(1) >>> o() Traceback (most recent call last): File "", line 1, in File "c:\cygwin\home\pje\projects\proxytypes\peak\util\proxies.py", line 6, in __call__ return self.__subject__(*args,**kw) TypeError: 'int' object is not callable >>> o.__call__ Traceback (most recent call last): File "", line 1, in File "c:\cygwin\home\pje\projects\proxytypes\peak\util\proxies.py", line 12, i n __getattribute__ return getattr(subject,attr) AttributeError: 'int' object has no attribute '__call__' As you can see, the __call__ attribute in each case is whatever the proxied object's __call__ attribute is, even though the proxy itself has a __call__ method, that is invoked when the proxy is called. This is actually pretty straightforward stuff since the introduction of __getattribute__. (The code is at http://pypi.python.org/pypi/ProxyTypes, btw.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: i18n
On 8/25/2010 2:31 PM, Michael Foord wrote: On 25/08/2010 21:26, Guido van Rossum wrote: [snip...] That sounds painful, but in general I am okay with the idea of translating messages. I think the system messages (those that go with IOError and OSError) may already be translated. How to do it without off-putting the core developers may end up being a research problem. :-) +1 - a difficult problem to solve (socially and architecturally but not technologically) but users are likely to appreciate it. A downside (from experience with .NET which takes this approach - logic and class names are all English but error messages are localized) is that you then get bug reports with localized error messages. It makes frequent visits to google translate unavoidable... Localized messages should be in addition to rather than a replacement for the English version. I thought we had this discussion somewhere -- here? ideas? maybe a tracker issue? -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: i18n
On Thu, Aug 26, 2010 at 6:26 AM, Terry Reedy wrote: > On 8/25/2010 2:31 PM, Michael Foord wrote: >> A downside (from experience with .NET which takes this approach - logic >> and class names are all English but error messages are localized) is >> that you then get bug reports with localized error messages. It makes >> frequent visits to google translate unavoidable... > > Localized messages should be in addition to rather than a replacement for > the English version. I thought we had this discussion somewhere -- here? > ideas? maybe a tracker issue? I remember the same discussion, and yeah, the final position was that including the original English text along with the localised text made the most sense. The idea didn't really go anywhere after that though, since it is still a *lot* of work. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] CHM filename (was Released: Python 2.6.6)
Am 25.08.2010 17:03, schrieb Adal Chiriliuc: >> The question really is whether there is any chance that they will get >> released, in some form. There won't be further binary releases (at least >> not from python.org), so there definitely won't be a CHM release. > > Speaking about the CHM, why does it include the version number in it's > filename? Wrt. software, any "why" question is tricky. It's in the file name because the generator that generates it puts it there. Now, why does it put it there? Because it does so for any other distribution format of the documentation. It used to be python26.chm (i.e. without the micro version), and was deliberately changed - primarily for consistency, AFAIK. Now, why do the other formats have a version number in them? So that you can have them all in the same directory, and they won't overwrite each other. And so that if you downloaded one of them, you'd still know what it is that you downloaded afterwards. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Released: Python 2.6.6
> I like how the django project present their documentation: there is > a little informational text at the head of each doc, saying that > "you're not browsing the most up-to-date documentation, you can > find the last one here"; maybe can we do a similar thing for the python > doc ? In principle, yes. However, it is really tricky to say what the "last one" is: is 3.1 more recent that 2.7, or not? When 3.2 is released: should the 2.6 documentation point to 2.7, or 3.2? If you would now propose to merely have a link from the 2.6 version to both 2.7 and 3.2: that link is already there. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] CHM filename (was Released: Python 2.6.6)
On Thu, Aug 26, 2010 at 1:08 AM, "Martin v. Löwis" wrote: > Now, why do the other formats have a version number in them? So that you > can have them all in the same directory, and they won't overwrite each > other. And so that if you downloaded one of them, you'd still know what > it is that you downloaded afterwards. The one deployed with the binaries installer could still be renamed to python.chm. When you start the CHM file, the first thing hitting you is a huge "Python v2.6.5 documentation" header, so I don't think anybody would be confused. And there doesn't seem to be a link to download the CHM files (the last I could find on python.org is for Python 2.6.2). Anyway, this is not a big issue. Regards, Adal ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: i18n
On 8/25/2010 5:41 PM, Nick Coghlan wrote: On Thu, Aug 26, 2010 at 6:26 AM, Terry Reedy wrote: On 8/25/2010 2:31 PM, Michael Foord wrote: A downside (from experience with .NET which takes this approach - logic and class names are all English but error messages are localized) is that you then get bug reports with localized error messages. It makes frequent visits to google translate unavoidable... Localized messages should be in addition to rather than a replacement for the English version. I thought we had this discussion somewhere -- here? ideas? maybe a tracker issue? I remember the same discussion, and yeah, the final position was that including the original English text along with the localised text made the most sense. The idea didn't really go anywhere after that though, since it is still a *lot* of work. Just after posting, I went to python-list, and read a response from OP asked to paste the traceback for his problem: ... File "C:\Python26\lib\socket.py", line 406, in readline data = self._sock.recv(self._rbufsize) socket.error: [Errno 10054] A lÚtez§ kapcsolatot a tßvoli ßllomßs kÚnyszerÝtette n bezßrta Fortunately, the OP could translate back well enough to "So this message is meaning that the remote station forced close the existing connection." and get additional help from other respondents. So the idea, at least, of giving both versions would be a good one ;-). -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: i18n
Terry Reedy:
> File "C:\Python26\lib\socket.py", line 406, in readline
> data = self._sock.recv(self._rbufsize)
> socket.error: [Errno 10054] A lÚtez§ kapcsolatot a tßvoli ßllomßs
> kÚnyszerÝtette n bezßrta
That is pretty good mojibake. One of the problems of providing
localized error messages is that the messages may be messed up at
different stages. The original text was
A létező kapcsolatot a távoli állomás kényszerítetten bezárta.
It was printed in iso8859_2 (ISO standard for Eastern European)
then those bytes were pasted in as if they were cp852 (MS-DOS Eastern
European).
text = "A létező kapcsolatot a távoli állomás kényszerítetten bezárta."
print(str(text.encode('iso8859_2'), 'cp852'))
Neil
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: i18n
On 8/25/2010 9:06 PM, Neil Hodgson wrote:
Terry Reedy:
File "C:\Python26\lib\socket.py", line 406, in readline
data = self._sock.recv(self._rbufsize)
socket.error: [Errno 10054] A lÚtez§ kapcsolatot a tßvoli ßllomßs
kÚnyszerÝtette n bezßrta
That is pretty good mojibake. One of the problems of providing
localized error messages is that the messages may be messed up at
different stages. The original text was
A létező kapcsolatot a távoli állomás kényszerítetten bezárta.
It was printed in iso8859_2 (ISO standard for Eastern European)
then those bytes were pasted in as if they were cp852 (MS-DOS Eastern
European).
text = "A létező kapcsolatot a távoli állomás kényszerítetten bezárta."
print(str(text.encode('iso8859_2'), 'cp852'))
Which is to say that pasting the 'message' into a translator would not
work to well ;-)
Which is to say that the original *really* should be included.
--
Terry Jan Reedy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: i18n
>That is pretty good mojibake. One of the problems of providing > localized error messages is that the messages may be messed up at > different stages. The original text was > A létező kapcsolatot a távoli állomás kényszerítetten bezárta. >It was printed in iso8859_2 (ISO standard for Eastern European) > then those bytes were pasted in as if they were cp852 (MS-DOS Eastern > European). That's an old Python 2.x bug. The message was probably printed in a terminal Window, yet Python did not recode it from what Windows provided (and indeed, it couldn't, because it couldn't know what encoding the exception string was in when it printed it). I believe this is fixed in Python 3, which uses a Unicode string for the text. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: i18n
Am 26.08.2010 08:18, schrieb Terry Reedy: > On 8/25/2010 9:06 PM, Neil Hodgson wrote: >> Terry Reedy: >> >>> File "C:\Python26\lib\socket.py", line 406, in readline >>> data = self._sock.recv(self._rbufsize) >>> socket.error: [Errno 10054] A lÚtez§ kapcsolatot a tßvoli ßllomßs >>> kÚnyszerÝtette n bezßrta >> > Which is to say that the original *really* should be included. And indeed, the original message *was* included: [Errno 10054] JGFI, and out comes "An existing connection was forcibly closed by the remote host", commonly known as "Connection reset by peer". Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] CHM filename (was Released: Python 2.6.6)
Am 26.08.2010 01:28, schrieb Adal Chiriliuc: > And there doesn't seem to be a link to > download the CHM files (the last I could find on python.org is for > Python 2.6.2). Thanks for pointing that out; there is now. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
