Menu
▾
▴
docutils-develop
|
From: Vasko M. <va...@di...> - 2002-11-07 12:33:28
Attachments:
sk.unicode.diff.gz
|
hi, > bibliographic field lists. For those who would prefer to use English > directive names, a command-line option could be added. ok, I agree with this. command-line will be fine, but, *please*, make bibliographic fields optionally in english, too attached is diff for unicode version of sk.py with translated bibliographics fields, too thanks, miro |
|
From: Vasko M. <va...@di...> - 2002-11-12 08:01:08
|
> Could you translate docutils/parsers/rst/languages/en.py for us?
ok, tomorrow, it will be done
> > but, *please*, make bibliographic fields optionally in english, too
> I am of mixed feelings about this, but I will add it to the to-do
> list. If you really want it, a patch is the fastest way to get it
> implemented!
I can take a look at the code through weekend
> Thank you. May I ask you for updates in the future?
of course
> I noticed that the é (\u00e9) was removed from the end of the
> translation of "abstract" ("Abstraktne"). Should it be there?
it is correct as in actual version of CVS
miro
|
|
From: <eng...@ss...> - 2002-11-12 14:03:17
Attachments:
test_language.py
|
maybe some kind soul can have a look at it. it does get all docutils.languages (even en_US should work). but i would like to setup a testcase per language so the test is not broken by the first error. and this is my first try at unittest -- --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6410 Telfs Untermarkt 9 / Tel. ++43-5262-64727 ----+ |
|
From: David G. <go...@py...> - 2002-11-13 01:29:24
|
eng...@ss... wrote:
> maybe some kind soul can have a look at it.
Checked in your initial copy plus some extensive changes (see below).
Thanks!
> it does get all docutils.languages (even en_US should work).
Great, we can add US slang! How about ".. contents-y'all::"? ;)
(Yes, I know a directive can't have a "'" in its name.)
I don't know if we'll ever need country/dialect codes, but in PEP 258
I defined the language codes as case-insensitive, so the module name
should actually be "en_us.py" (lower case).
> but i would like to setup a testcase per language so the
> test is not broken by the first error.
What is needed here is a dynamic, data-driven test suite. Most of the
Docutils test modules use the test/DocutilsTestSupport.py module for
this. I've modified the test_language.py code to use this framework,
dynamically creating a test (a TestCase object) for each language and
method.
> and this is my first try at unittest
You chose a challenge to begin with. I suggest you look at
test_nodes.py, test_statemachine.py, or test_utils.py for more typical
examples.
General tip: at the top of script files, don't use::
#!/usr/bin/python
Please use this instead::
#! /usr/bin/env python
The former is hard-coded. For example, it finds Python 1.5.2 on
RedHat. The latter finds an executable called "python" on the user's
path. I've set up my environment so Python 2.2 is found first. Some
people will have their Python interpreter at /usr/local/bin/python or
non-standard places.
--
David Goodger <go...@py...> Open-source projects:
- Python Docutils: http://docutils.sourceforge.net/
(includes reStructuredText: http://docutils.sf.net/rst.html)
- The Go Tools Project: http://gotools.sourceforge.net/
|
|
From: Aahz <aa...@py...> - 2002-11-13 02:16:16
|
On Tue, Nov 12, 2002, David Goodger wrote: > > General tip: at the top of script files, don't use:: > > #!/usr/bin/python > > Please use this instead:: > > #! /usr/bin/env python Enh. Too many sysadmins I know decry this practice as a security risk. While I use the trick myself, I'm not at all comfortable pushing it as a solution for general scripts. It's not in PEP 8. -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ A: No. Q: Is top-posting okay? |
|
From: David G. <go...@py...> - 2002-11-13 06:22:26
|
> On Tue, Nov 12, 2002, David Goodger wrote: >> General tip: at the top of script files, don't use:: >> >> #!/usr/bin/python >> >> Please use this instead:: >> >> #! /usr/bin/env python Aahz wrote: > Enh. Too many sysadmins I know decry this practice as a security risk. Do you know of any good references? Genuinely curious. > While I use the trick myself, I'm not at all comfortable pushing it as a > solution for general scripts. I don't see how hard-coding a possibly-nonexistent, possibly-erroneous path is any better. It had me genuinely confused for a minute or two, wondering why the complaint about bad syntax on a "function(*args)"-type call. > It's not in PEP 8. PEP 8 doesn't mention hash-bangs or script execution at all; I don't get the point. -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
|
From: Aahz <aa...@py...> - 2002-11-14 03:53:48
|
On Wed, Nov 13, 2002, David Goodger wrote: > Aahz wrote: >> On Tue, Nov 12, 2002, David Goodger wrote: >>> >>> General tip: at the top of script files, don't use:: >>> >>> #!/usr/bin/python >>> >>> Please use this instead:: >>> >>> #! /usr/bin/env python >> >> Enh. Too many sysadmins I know decry this practice as a security risk. > > Do you know of any good references? Genuinely curious. No handy references, but IIRC, the primary worry is that someone could install a nasty shell script into your path named "python". Also, with the regular version increases in Python, I've seen more people recommend using a specific version number. As for myself, I usually call my scripts as "python script.py", which is guaranteed to work in Windoze. >> It's not in PEP 8. > > PEP 8 doesn't mention hash-bangs or script execution at all; I don't > get the point. The point was that you seemed to be pushing it as a "standard", and I was reminding you that it's not. -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ A: No. Q: Is top-posting okay? |
|
From: Richard J. <rj...@ek...> - 2002-11-13 03:16:33
|
On Wed, 13 Nov 2002 12:30 pm, David Goodger wrote:
> General tip: at the top of script files, don't use::
>
> #!/usr/bin/python
>
> Please use this instead::
>
> #! /usr/bin/env python
>
> The former is hard-coded. For example, it finds Python 1.5.2 on
> RedHat. The latter finds an executable called "python" on the user's
> path. I've set up my environment so Python 2.2 is found first. Some
> people will have their Python interpreter at /usr/local/bin/python or
> non-standard places.
A better scheme which is used in moinmoin and roundup setup.py installers is
to munge the #! line when the script is installed so that it is hard-coded to
use the same interpreter that ran the setup.py file. It also generates a .bat
wrapper on windows that does an analogous thing for windows.
As Aahz pointed out, some people are touchy about "/usr/bin/env python". Being
a sad little redhat user, even that line won't work for me because the real
python is called "python2" on my system. The above setup.py trick
automatically handles that situation.
Someone mentioned to me that distutils (possibly recent versions) does some
sort of automagic munging of that line itself, but I haven't had a chance to
look into it.
Richard
|
|
From: Michael H. <mw...@py...> - 2002-11-13 10:44:58
|
Richard Jones <rj...@ek...> writes: > Someone mentioned to me that distutils (possibly recent versions) does some > sort of automagic munging of that line itself, but I haven't had a chance to > look into it. Yeah, it does. Since 2.1 (I think). I remember hacking it to work when installing Python itself. Cheers, M. -- I saw `cout' being shifted "Hello world" times to the left and stopped right there. -- Steve Gonedes |
|
From: <eng...@ss...> - 2002-11-13 07:01:19
|
def test_directives(self): does not work, because::
func, msg = directives.directive(d, module, None)
does not raise an error. inserted::
if not func:
failures += "%s (%s)," % (d, "unknown directive")
therefore en should be tested too (but i failed at it).
--
BINGO: Green Flag
--- Engelbert Gruber -------+
SSG Fintl,Gruber,Lassnig /
A6410 Telfs Untermarkt 9 /
Tel. ++43-5262-64727 ----+
|
|
From: David G. <go...@py...> - 2002-11-14 02:34:34
|
eng...@ss... wrote: > therefore en should be tested too (but i failed at it). The en (English) module is being tested now. I also added a check for translations of all directives. -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
|
From: David G. <go...@py...> - 2002-11-08 00:38:09
|
[David]
>> For those who would prefer to use English directive names, a
>> command-line option could be added.
[Vasko]
> ok, I agree with this. command-line will be fine,
Could you translate docutils/parsers/rst/languages/en.py for us?
> but, *please*, make bibliographic fields optionally in english, too
I am of mixed feelings about this, but I will add it to the to-do
list. If you really want it, a patch is the fastest way to get it
implemented!
> attached is diff for unicode version of sk.py with translated
> bibliographics fields, too
Thank you. May I ask you for updates in the future?
I noticed that the é (\u00e9) was removed from the end of the
translation of "abstract" ("Abstraktne"). Should it be there?
--
David Goodger <go...@py...> Open-source projects:
- Python Docutils: http://docutils.sourceforge.net/
(includes reStructuredText: http://docutils.sf.net/rst.html)
- The Go Tools Project: http://gotools.sourceforge.net/
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X