Re: [Python-Dev] Locale-specific formatting
> Comments? How do you implement that? In particular, how do you retrieve information for different locales in a single program? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r87188 - python/branches/py3k/Doc/library/test.rst
I'd rather keep this a note. We don't want to use warnings except for cases where there is a possibility of security implications or crashes. Georg Am 12.12.2010 19:25, schrieb antoine.pitrou: > Author: antoine.pitrou > Date: Sun Dec 12 19:25:25 2010 > New Revision: 87188 > > Log: > Make this a warning and fix indentation > > > > Modified: >python/branches/py3k/Doc/library/test.rst > > Modified: python/branches/py3k/Doc/library/test.rst > == > --- python/branches/py3k/Doc/library/test.rst (original) > +++ python/branches/py3k/Doc/library/test.rst Sun Dec 12 19:25:25 2010 > @@ -5,12 +5,12 @@ > :synopsis: Regression tests package containing the testing suite for > Python. > .. sectionauthor:: Brett Cannon > > -.. note:: > -The :mod:`test` package is meant for internal use by Python only. It is > -documented for the benefit of the core developers of Python. Any use of > -this package outside of Python's standard library is discouraged as code > -mentioned here can change or be removed without notice between releases > of > -Python. > +.. warning:: > + The :mod:`test` package is meant for internal use by Python only. It is > + documented for the benefit of the core developers of Python. Any use of > + this package outside of Python's standard library is discouraged as code > + mentioned here can change or be removed without notice between releases of > + Python. > > > The :mod:`test` package contains all regression tests for Python as well as > the ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r87188 - python/branches/py3k/Doc/library/test.rst
On Sat, 18 Dec 2010 12:37:09 +0100 Georg Brandl wrote: > I'd rather keep this a note. We don't want to use warnings except for cases > where there is a possibility of security implications or crashes. Well, there'll be a crash as soon as someone relies on an API we decide to change or remove :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r87188 - python/branches/py3k/Doc/library/test.rst
Am 18.12.2010 13:07, schrieb Antoine Pitrou: > On Sat, 18 Dec 2010 12:37:09 +0100 > Georg Brandl wrote: >> I'd rather keep this a note. We don't want to use warnings except for cases >> where there is a possibility of security implications or crashes. > > Well, there'll be a crash as soon as someone relies on an API we decide > to change or remove :) Ah, but I meant a real crash, not an exception. Think marshal or ctypes. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] nonlocal x = value
Am 17.12.2010 17:52, schrieb Laurens Van Houtven: > +1 for throwing it out of the PEP. Assignment is a thing, > nonlocal/global is a thing, don't mix them up :) (That in addition to > the grammar cleanliness argument Stephan already made) The trouble is what to make of nonlocal x = 3, y Is it two nonlocal declarations or one with a tuple assignment? Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
Am 18.12.2010 01:55, schrieb Victor Stinner: > Hi, > > In 2008, I proposed a patch to raise a Python exception on SIGSEVG > signal. In some cases, it's possible to catch the exception, log it, and > continue the execution. But because in some cases, the Python internal > state is corrupted, the idea was rejected (see the issue #3999). > > Someone asked me to display the Python backtrace on SIGSEGV, instead of > raising an exception. I implemented this idea in issue #8863. After 9 > versions, I think that the patch is ready for inclusion. It catchs > SIGSEGV, SIGFPE, SIGBUS and SIGILL signals, and also display the Python > backtrace on fatal errors. Because some operating systems have their own > fault handler (eg. Ubuntu with apport), Dave Malcolm asked me to add an > option disable the Python handler. That's why I added the > PYTHONNOFAULTHANDLER environment variable (we all love long variable > names!). For an OS vendor, it looks like an environment variable is more > practical than a command line option. Eg. Mandriva sets > PYTHONDONTWRITEBYTECODE for the whole system. > > Raymond Hettinger asked me on IRC to write an email about the new > environment variable, so here is the question: do you agree to add the > new variable? I very much like having a traceback on (some) segmentation faults, but it's clear there needs to be a way to turn it off. An environment variable seems to be the obvious choice (for the reasons you stated for PYTHONDONTWRITEBYTECODE). Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r87188 - python/branches/py3k/Doc/library/test.rst
On Sat, 18 Dec 2010 13:11:09 +0100 Georg Brandl wrote: > Am 18.12.2010 13:07, schrieb Antoine Pitrou: > > On Sat, 18 Dec 2010 12:37:09 +0100 > > Georg Brandl wrote: > >> I'd rather keep this a note. We don't want to use warnings except for > >> cases > >> where there is a possibility of security implications or crashes. > > > > Well, there'll be a crash as soon as someone relies on an API we decide > > to change or remove :) > > Ah, but I meant a real crash, not an exception. Think marshal or ctypes. We can add one if necessary ;) Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
On Dec 17, 2010, at 7:55 PM, Victor Stinner wrote: > Hi, > > In 2008, I proposed a patch to raise a Python exception on SIGSEVG signal. In > some cases, it's possible to catch the exception, log it, and continue the > execution. But because in some cases, the Python internal state is corrupted, > the idea was rejected (see the issue #3999). > > Someone asked me to display the Python backtrace on SIGSEGV, instead of > raising an exception. I implemented this idea in issue #8863. After 9 > versions, I think that the patch is ready for inclusion. It catchs SIGSEGV, > SIGFPE, SIGBUS and SIGILL signals, and also display the Python backtrace on > fatal errors. Because some operating systems have their own fault handler > (eg. Ubuntu with apport), Dave Malcolm asked me to add an option disable the > Python handler. I think instead of calling abort() to kill the process, you should: - install the signal handler with SA_NODEFER|SA_RESETHAND (or if sigaction is not present, explicitly reset the action to SIG_DFL and unblock first thing upon entering the handler), and then, - at the end of the handler, kill(getpid(), orig_signal) in order to abort the process. This has two advantages: 1) the process's exit code will actually show the correct signal, 2) it might let the OS fault handlers work properly as well -- I'm not sure. If it does, you may want to experiment with whether having or omitting SA_NODEFER gives a better backtrace (from the OS mechanism) in that case. If #2 actually works, you may not even need the env var, which would be nice. James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
Le 18/12/2010 13:21, Georg Brandl a écrit : I very much like having a traceback on (some) segmentation faults, Why do you say "some" segmentation faults? but it's clear there needs to be a way to turn it off. An environment variable seems to be the obvious choice (for the reasons you stated for PYTHONDONTWRITEBYTECODE). Amaury proposed a new function sys.setsegfaultenabled(). Such function can be used in a customized site module. I think that I will implement it in my next patch, before commiting the new feature. I suppose that we also need a function to get the status of the fault handler. I just don't like the name. I would prefer sys.setfaulthandlerenabled(), I maybe just sys.setfaulthandler(). As this feature is specific to CPython, should it be protected function? So: * sys._setfaulthandler(bool): enable/disable the fault handler * sys._getfaulthandler()->bool: get the status (enabled/disabled) of the fault handler Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Locale-specific formatting
On Sat, Dec 18, 2010 at 12:08:47AM +, MRAB wrote: > This makes it harder to use more than one locale at a time This is quite a known problem, not specific to Python. Locale settings are global for a process, and this is one of the thousands reasons why locale is considered so horrible. ICU is perhaps the only way around the problem. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
Am 18.12.2010 14:57, schrieb Victor Stinner: > Le 18/12/2010 13:21, Georg Brandl a écrit : >> I very much like having a traceback on (some) segmentation faults, > Why do you say "some" segmentation faults? Well, without a closer I assume that for some crashes it's just not possible anymore for the Python interpreter to even print out the traceback? Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
Am 18.12.2010 14:57, schrieb Victor Stinner: > Le 18/12/2010 13:21, Georg Brandl a écrit : >> I very much like having a traceback on (some) segmentation faults, > Why do you say "some" segmentation faults? >> but it's clear there needs to be a way to turn it off. An environment >> variable >> seems to be the obvious choice (for the reasons you stated for >> PYTHONDONTWRITEBYTECODE). > Amaury proposed a new function sys.setsegfaultenabled(). Such function > can be used in a customized site module. I think that I will implement > it in my next patch, before commiting the new feature. I suppose that we > also need a function to get the status of the fault handler. > > I just don't like the name. I would prefer sys.setfaulthandlerenabled(), > I maybe just sys.setfaulthandler(). As this feature is specific to > CPython, should it be protected function? So: > * sys._setfaulthandler(bool): enable/disable the fault handler > * sys._getfaulthandler()->bool: get the status (enabled/disabled) of > the fault handler In any case, this is coming pretty late; beta 2 is scheduled for this weekend, and even if this is something that only kicks in when all hope is lost anyway, it is a new feature. I should like to hear approval from a few more devs before I will let this go into 3.2. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
On Sat, 18 Dec 2010 17:50:38 +0100 Georg Brandl wrote: > Am 18.12.2010 14:57, schrieb Victor Stinner: > > Le 18/12/2010 13:21, Georg Brandl a écrit : > >> I very much like having a traceback on (some) segmentation faults, > > Why do you say "some" segmentation faults? > >> but it's clear there needs to be a way to turn it off. An environment > >> variable > >> seems to be the obvious choice (for the reasons you stated for > >> PYTHONDONTWRITEBYTECODE). > > Amaury proposed a new function sys.setsegfaultenabled(). Such function > > can be used in a customized site module. I think that I will implement > > it in my next patch, before commiting the new feature. I suppose that we > > also need a function to get the status of the fault handler. > > > > I just don't like the name. I would prefer sys.setfaulthandlerenabled(), > > I maybe just sys.setfaulthandler(). As this feature is specific to > > CPython, should it be protected function? So: > > * sys._setfaulthandler(bool): enable/disable the fault handler > > * sys._getfaulthandler()->bool: get the status (enabled/disabled) of > > the fault handler > > In any case, this is coming pretty late; beta 2 is scheduled for this > weekend, and even if this is something that only kicks in when all hope > is lost anyway, it is a new feature. I should like to hear approval > from a few more devs before I will let this go into 3.2. I'm +1 on Victor's patch, although I don't think the sys function is useful at all. The env var is enough IMO. (I would even be for backporting it to the bugfix branches if there's no downside) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Locale-specific formatting
On 18/12/2010 09:26, "Martin v. Löwis" wrote:
Comments?
How do you implement that? In particular, how do you retrieve
information for different locales in a single program?
The locale module would be able to return a named locale dict:
>>> loc = locale.getnamedlocale('en_UK')
or:
>>> loc = locale.namedlocales['en_UK']
The dict would be like what locale.localeconv() returns.
The str.format method would then be able to use that dict.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
On Sat, Dec 18, 2010 at 11:50 AM, Georg Brandl wrote: .. > In any case, this is coming pretty late; beta 2 is scheduled for this > weekend, and even if this is something that only kicks in when all hope > is lost anyway, it is a new feature. I should like to hear approval > from a few more devs before I will let this go into 3.2. > I am -1 on the feature as written. I would be -0 if it did not install signal handlers by default and even better was implemented in a separate module, not in core. This feature is similar to the one that is implemented by R and with R, it was always a problem when R was embedded as a library. It has always been a welcome feature of Python that its core did not mess with the application global state. Before this is approved, I would like to see a discussion of the consequences for embedded Python and particularly for the case when there are multiple interpreters in the same process. I think it would be best to start with this feature as an library module or even as a 3rd party add-on and see how useful it will be found in the wild. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
Am 18.12.2010 19:55, schrieb Alexander Belopolsky: > On Sat, Dec 18, 2010 at 11:50 AM, Georg Brandl wrote: > .. >> In any case, this is coming pretty late; beta 2 is scheduled for this >> weekend, and even if this is something that only kicks in when all hope >> is lost anyway, it is a new feature. I should like to hear approval >> from a few more devs before I will let this go into 3.2. >> > > I am -1 on the feature as written. I would be -0 if it did not > install signal handlers by default and even better was implemented in > a separate module, not in core. This is also what I think. Installing a signal handler is a fairly drastic action, and I don't think the code has been sufficiently reviewed yet. So I'd rather see this deferred until after 3.2, to allow for additional reviews (e.g. if some of the Twisted guys would approve it - that would be convincing). I also share Alexander's concern that Python just shouldn't mess with signal handlers at all, ideally. So some trade-off has to be found to address that concern (e.g. by making the signal handlers only active for the executable interpreter, but not in the embedded case). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
On Sat, 18 Dec 2010 20:36:50 +0100 "Martin v. Löwis" wrote: > Am 18.12.2010 19:55, schrieb Alexander Belopolsky: > > On Sat, Dec 18, 2010 at 11:50 AM, Georg Brandl wrote: > > .. > >> In any case, this is coming pretty late; beta 2 is scheduled for this > >> weekend, and even if this is something that only kicks in when all hope > >> is lost anyway, it is a new feature. I should like to hear approval > >> from a few more devs before I will let this go into 3.2. > >> > > > > I am -1 on the feature as written. I would be -0 if it did not > > install signal handlers by default and even better was implemented in > > a separate module, not in core. > > This is also what I think. Installing a signal handler is a fairly > drastic action, and I don't think the code has been sufficiently > reviewed yet. How much more review should it receive? > I also share Alexander's concern that Python just shouldn't mess with > signal handlers at all, ideally. So some trade-off has to be found to > address that concern (e.g. by making the signal handlers only active > for the executable interpreter, but not in the embedded case). Well, Python already does (and also apparently messes with other things such as FPU state), so that's a separate issue altogether. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On Sat, 18 Dec 2010 21:00:04 +0100 (CET) ezio.melotti wrote: > Author: ezio.melotti > Date: Sat Dec 18 21:00:04 2010 > New Revision: 87389 > > Log: > #10573: use actual/expected consistently in unittest methods. IMHO, this should be reverted. The API currently doesn't treat these arguments differently, so they should really be labeled "first" and "second". Otherwise, the user will wrongly assume that the signature is asymmetric and that they should be careful about which order they pass the arguments in. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
Am 13.12.2010 21:08, schrieb Glenn Linderman: > On 12/13/2010 11:39 AM, Mark Dickinson wrote: >> my_thing = Thing( >> foo = Foo(arg1, arg2, ...), >> bar = Bar(arg3, arg4, ...), >> ... >> ) >> >> and I've found the trailing comma very convenient during refactoring >> and API experimentation. (There's still good fun to be had arguing >> about the indentation of that closing parenthesis, though.) > > > Clearly it needs to be indented one level, because it is a continuation > of the prior line, just like the foo and bar and ... lines are > continuations and therefore indented. Clearly Emacs is superior to Vim because (insert some random fact here). Clearly the only thing that is clear about coding style details (even if we all more or less agree on PEP 8) is that it is a matter of personal taste. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On 12/18/2010 1:04 PM, Georg Brandl wrote: Am 13.12.2010 21:08, schrieb Glenn Linderman: On 12/13/2010 11:39 AM, Mark Dickinson wrote: my_thing = Thing( foo = Foo(arg1, arg2, ...), bar = Bar(arg3, arg4, ...), ... ) and I've found the trailing comma very convenient during refactoring and API experimentation. (There's still good fun to be had arguing about the indentation of that closing parenthesis, though.) Clearly it needs to be indented one level, because it is a continuation of the prior line, just like the foo and bar and ... lines are continuations and therefore indented. Clearly Emacs is superior to Vim because (insert some random fact here). Sure you have that right. Clearly the only thing that is clear about coding style details (even if we all more or less agree on PEP 8) is that it is a matter of personal taste. And this too. But apparently you missed the fact that Mark wanted some good fun arguing about the indentation of the closing parenthesis... and didn't quote my "Enjoy!" that implied that that was all I was giving him. But then, you are release manager, which would make it very difficult, but hopefully you can still have a Merry Christmas! (or whatever end-of-year holiday suits your fancy) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On 12/18/2010 3:48 PM, Antoine Pitrou wrote: On Sat, 18 Dec 2010 21:00:04 +0100 (CET) ezio.melotti wrote: Author: ezio.melotti Date: Sat Dec 18 21:00:04 2010 New Revision: 87389 Log: #10573: use actual/expected consistently in unittest methods. Change was requested by M. Foord and R. Hettinger (and G.Brandl for b2). IMHO, this should be reverted. The API currently doesn't treat these arguments differently, so they should really be labeled "first" and "second". Otherwise, the user will wrongly assume that the signature is asymmetric and that they should be careful about which order they pass the arguments in. The error report on assert failure *is* often asymmetrical ;=). From Michael's post: "This is particularly relevant for the methods that produce 'diffed' output on failure - as the order determines whether mismatched items are missing from the expected or additional to the expected." This change struck me as a nice bit of polishing. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Locale-specific formatting
On 12/18/2010 10:33 AM, Oleg Broytman wrote: This is quite a known problem, not specific to Python. Locale settings are global for a process, and this is one of the thousands reasons why locale is considered so horrible. ICU is perhaps the only way around the problem. This is about the third mention of 'ICU' in the last few weeks, so I looked it up: International Components for Unicode http://site.icu-project.org/ Several libraries (C/C++,Java), including prebuilt binaries for Windows (and some others). There is already a Python .cpp wrapper (but no Windows binaries, which limits usefulness) http://pyicu.osafoundation.org/ http://pypi.python.org/pypi/PyICU/1.0.1 -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [feature request] add .svgz to mimetypes.suffix_map
Hi. I've created bug on bugtracker, and then I was told there that I should post this on this mailing list for discussion. Here is link to bug: http://bugs.python.org/issue10730 Please add '.svgz': '.svg.gz' map to mimetypes.suffix_map -- Grygoriy Fuchedzhy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Locale-specific formatting
Am 18.12.2010 19:26, schrieb MRAB:
> On 18/12/2010 09:26, "Martin v. Löwis" wrote:
>>> Comments?
>>
>> How do you implement that? In particular, how do you retrieve
>> information for different locales in a single program?
>>
> The locale module would be able to return a named locale dict:
>
loc = locale.getnamedlocale('en_UK')
Ok, so, in turn: how do you implement *that* (what C API
specifically do you use to implement that getnamedlocale function)?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Locale-specific formatting
On 19/12/2010 00:31, "Martin v. Löwis" wrote:
Am 18.12.2010 19:26, schrieb MRAB:
On 18/12/2010 09:26, "Martin v. Löwis" wrote:
Comments?
How do you implement that? In particular, how do you retrieve
information for different locales in a single program?
The locale module would be able to return a named locale dict:
loc = locale.getnamedlocale('en_UK')
Ok, so, in turn: how do you implement *that* (what C API
specifically do you use to implement that getnamedlocale function)?
I suppose there could be some sort of locale database. A downloadable,
up-to-date copy of the database could be maintained on the Python
website.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [feature request] add .svgz to mimetypes.suffix_map
On 12/18/2010 4:37 PM, Grygoriy Fuchedzhy wrote: Hi. I've created bug on bugtracker, and then I was told there that I should post this on this mailing list for discussion. Here is link to bug: http://bugs.python.org/issue10730 Please add'.svgz':'.svg.gz' map to mimetypes.suffix_map This issue is actually a request to add .svg to the types map and the the abbreviation .svgz for .svg.gx to the suffix_map. I believe Scalable Vector Graphics are well on the way to becoming *the* standard vector graphics format for the web, especially with upcoming IE9 support. https://secure.wikimedia.org/wikipedia/en/wiki/Svg It (they) are already supported by the other major browsers. In addition, "Google announced on 31 August 2010 that it had begun to index SVG content on the web, whether it is in standalone files or embedded in HTML." So it might be sensible to add these now rather than two years from now. But if it is too late for 3.2, then I expect addition for 3.3 will be obvious. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
I may be unique, but I fear there is no great answer. On the one hand I almost always code it as e.g. assertEqual(actual, expected), which matches my preference for e.g. "if x == 5:" rather than "if 5 == x:". On the other hand in those assert* functions that show a nice diff of two lists, when reading such a diff my expectation is that "old, new" corresponds to "expected, actual". Which then freaks me out until I realize that I coded it as "actual, expected"... And yet "expected, actual" still looks weird to me. :-( On Sat, Dec 18, 2010 at 2:46 PM, Terry Reedy wrote: > On 12/18/2010 3:48 PM, Antoine Pitrou wrote: >> >> On Sat, 18 Dec 2010 21:00:04 +0100 (CET) >> ezio.melotti wrote: >>> >>> Author: ezio.melotti >>> Date: Sat Dec 18 21:00:04 2010 >>> New Revision: 87389 >>> >>> Log: >>> #10573: use actual/expected consistently in unittest methods. > > Change was requested by M. Foord and R. Hettinger (and G.Brandl for b2). > >> IMHO, this should be reverted. The API currently doesn't treat these >> arguments differently, so they should really be labeled "first" and >> "second". Otherwise, the user will wrongly assume that the signature is >> asymmetric and that they should be careful about which order they pass >> the arguments in. > > The error report on assert failure *is* often asymmetrical ;=). > From Michael's post: > "This is particularly relevant for the methods that produce 'diffed' output > on failure - as the order determines whether mismatched items are missing > from the expected or additional to the expected." > > This change struck me as a nice bit of polishing. > > -- > Terry Jan Reedy > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On Sat, 18 Dec 2010 20:23:49 -0800, Guido van Rossum wrote: > I may be unique, but I fear there is no great answer. On the one hand > I almost always code it as e.g. assertEqual(actual, expected), which > matches my preference for e.g. "if x =3D=3D 5:" rather than "if 5 =3D=3D x:= > ". > On the other hand in those assert* functions that show a nice diff of > two lists, when reading such a diff my expectation is that "old, new" > corresponds to "expected, actual". Which then freaks me out until I > realize that I coded it as "actual, expected"... And yet "expected, > actual" still looks weird to me. :-( You aren't unique, I feel the same way. But it seems to me that the most important thing is to be consistent, so that I don't freak out for long. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
