Re: [Python-Dev] Possible issue with 2.5a1 Win32 binary
On 4/6/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > What happens when you run > > D:\Apps\Python25\python.exe -Wi D:\Apps\Python25\Lib\compileall.py -f -x > badsyntax D:\Apps\Python25\Lib > > and look at the status of the program? I think also excluding bad_coding > might already help. Status was 1. With -x "bad.*" it's zero, so it looks like that's the issue. I guess that means the pywin32 problem is unrelated - I'll raise that as a separate bug. Thanks for the help with this! Paul. ___ 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] elementtree in stdlib
Fredrik Lundh wrote: > it's not new code, and having *different* module names for the same > well-established library isn't very nice to anyone. > > > Modules should have short, lowercase names, without underscores. But if we don't start becoming stricter about the naming of things added to the stdlib, consistency of naming is never going to improve. Or should this wait for Py3k? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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] Possible issue with 2.5a1 Win32 binary
Paul Moore wrote: > On 4/6/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> What happens when you run >> >> D:\Apps\Python25\python.exe -Wi D:\Apps\Python25\Lib\compileall.py -f -x >> badsyntax D:\Apps\Python25\Lib >> >> and look at the status of the program? I think also excluding bad_coding >> might already help. > > Status was 1. With -x "bad.*" it's zero, so it looks like that's the issue. FWIW, this breaks for me too and the output of: C:\Python25\python.exe -Wi -m compileall -f C:\Python25\Lib includes the expected SyntaxErrors from the bad_coding and badsyntax test modules. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Don Beaudry
Does anyone have a current email address for Don? I've had a bounce from dvcorp.com and I need to get in touch with him. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd www.holdenweb.com Love me, love my blog holdenweb.blogspot.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] elementtree in stdlib
On Thu, Apr 06, 2006, Greg Ewing wrote: > Fredrik Lundh wrote: >> >> it's not new code, and having *different* module names for the same >> well-established library isn't very nice to anyone. >> >>> Modules should have short, lowercase names, without underscores. > > But if we don't start becoming stricter about the naming of things > added to the stdlib, consistency of naming is never going to improve. > > Or should this wait for Py3k? For contributions that are also maintained separately from Python, I think compatibility with the external code has to have some importance. I vote we wait for Py3k. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Look, it's your affair if you want to play with five people, but don't go calling it doubles." --John Cleese anticipates Usenet ___ 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] Default Locale, was; Re: strftime/strptime locale funnies...
On Wed, 2006-04-05 at 12:13 -0700, Brett Cannon wrote: > On 4/5/06, Donovan Baarda <[EMAIL PROTECTED]> wrote: > > G'day, > > > > Just noticed on Debian (testing), Ubuntu (warty?), and RedHat (old) > > based systems Python's time.strptime() seems to ignore the environment's > > Locale and just uses "C". [...] > Beats me. This could be a locale thing. If I remember correctly > Python assumes the C locale on some things. I suspect the reason for > this is in the locale module or libc. But you can't even find the > word 'locale' or 'Locale' in timemodule.c nor do I know of any calls > that mess with the locale, so I doubt 'time' is at fault for this. OK, I've found and confirmed what it is with a quick C program. The default Locale for lib C is 'C'. It is up the program to set its locale to match the environment using; setlocale(LC_ALL,""); The Python locale module documents this, and recommends putting; import locale locale.setlocale(locale.LC_ALL, '') At the top of programs to make them use your locale as specified in your environment. Note that locale.resetlocale() is documented as "resets the locale to the default settings", where the default is determined by locale.getdefaultlocale(), which uses the environment. So the "default" is determined from your environment, but "C" is used by default... nice and confusing :-) Should Python do setlocale(LC_ALL,"") on startup so that the "default" locale is used by default? -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ ___ 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] The "i" string-prefix: I18n'ed strings
Hi all
I got an evil idea for Python this morning -- Guido: no, it's not
about linked lists :-) -- , and I'd like to bounce it here. But
first, a bit of context.
In the context of writing i18n apps, programmers have to "mark"
strings that may be internationalized in a way that
- a special hook gets called at runtime to perform the lookup in a
catalog of translations setup for a specific language;
- they can be extracted by an external tool to produce the keys of all
the catalogs, so that translators can update the list of keys to
translate and produce the values in the target languages.
Usually, you bind a function to a short name, like _() and N_(), and
it looks kind-of like this::
_("My string to translate.")
or
N_("This is marked for translation") # N_() is a noop.
pygettext does the work of extracting those patterns from the files,
doing all the parsing manually, i..e it does not use runtime Python
introspection to do this at all, it is simply a simple text parsing
algorithm (which works pretty well). I'm simplifying things a bit,
but that is the jist of how it works, for those not familiar with
i18n.
This morning I woke up staring at the ceiling and the only thing in my
mind was "my web app code is ugly". I had visions of LISP parentheses
with constructs like
...
A(P(_("Click here to forget"), href="...
...
(In my example, I built a library not unlike stan for creating HTML,
which is where classes A and P come from.) I find the i18n markup a
bit annoying, especially when there are many i18n strings close
together. My point is: adding parentheses around almost all strings
gets tiresome and "charges" the otherwise divine esthetics of Python
source code.
(Okie, that's enough for context.)
So I had the following idea: would it not be nice if there existed a
string-prefix 'i' -- a string prefix like for the raw (r'...') and
unicode (u'...') strings -- that would mark the string as being for
i18n? Something like this (reusing my example above)::
A(P(i"Click here to forget", href="...
Notes:
- We could then use the spiffy new AST to build a better parser to
extract those strings from the source code as well.
- We could also have a prefix "I" for strings to be marked but not
runtime-translated, to replace the N_() strings.
- This implies that we would have to introduce some way for these
strings to call a custom function at runtime.
- My impression is that this process of i18n is common enough that it
does not "move" very much, and that there aren't 18 ways to go about
it either, so that it would be reasonable to consider adding it to the
language. This may be completely wrong, I am by no means an i18n
expert, please show if this is not the case.
- Potential issue: do we still need other prefixes when 'i' is used,
and if so, how do we combine them...
Okay, let's push it further a bit: how about if there was some kind
of generic mechanism built-in in Python for adding new string-prefixes
which invoke callbacks when the string with the prefix is evaluated?
This could be used to implement what I'm suggesting above, and beyond.
Something like this::
import i18n
i18n.register_string_prefix('i', _)
i18n.register_string_prefix('I', N_)
I'm not sure what else we might be able to do with this, you may have
other useful ideas.
Any comments welcome.
cheers,
___
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] dis module and new-style classes
Hi, dis.dis currently handles new-style classes stepmotherly: given class C(object): def Cm(): pass class D(object): def Dm(): pass dis.dis(C) doesn't touch D, and dis.dis(C()) doesn't touch anything. Should it be fixed? It may need some reworking in dis.dis. Georg ___ 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] The "i" string-prefix: I18n'ed strings
On 4/6/06, Martin Blais <[EMAIL PROTECTED]> wrote:
...
> So I had the following idea: would it not be nice if there existed a
> string-prefix 'i' -- a string prefix like for the raw (r'...') and
> unicode (u'...') strings -- that would mark the string as being for
> i18n? Something like this (reusing my example above)::
+1: having helped out with substantial amounts of i18n work over the
years, I agree with you 100% that this addition would give substantial
benefits.
> - We could also have a prefix "I" for strings to be marked but not
> runtime-translated, to replace the N_() strings.
I'm more dubious about this one, because I don't really see the point.
Expand pls? With a couple of use cases, maybe?
> - My impression is that this process of i18n is common enough that it
> does not "move" very much, and that there aren't 18 ways to go about
> it either, so that it would be reasonable to consider adding it to the
> language. This may be completely wrong, I am by no means an i18n
> expert, please show if this is not the case.
My experience agrees with your assessment regarding the first half of
the proposal (but I don't get the second half, I think).
> Okay, let's push it further a bit: how about if there was some kind
> of generic mechanism built-in in Python for adding new string-prefixes
> which invoke callbacks when the string with the prefix is evaluated?
I think this one is an idea for Python 3000: you should probably post
it to that mailing list.
> This could be used to implement what I'm suggesting above, and beyond.
> Something like this::
>
>import i18n
>i18n.register_string_prefix('i', _)
>i18n.register_string_prefix('I', N_)
>
> I'm not sure what else we might be able to do with this, you may have
> other useful ideas.
Oh, plenty of things, such as d'123.45' as a syntax for "decimal
literals" (or viceversa for binary floats, if decimals become the Py3k
default), q'123/54' for rationals (today's gmpy.mpq('123/54') or other
implementations), etc. Ideas which have little to do with i18n,
mostly. It's exactly because of the broad impact of such a mechanism
(and, inevitably, the possibility of abuse and overuse) that I think
it's Py3k material, not 2.* stuff.
Alex
___
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] module aliasing
Modules should have short, lowercase names, without underscores. >> >> But if we don't start becoming stricter about the naming of things >> added to the stdlib, consistency of naming is never going to improve. >> >> Or should this wait for Py3k? aahz> For contributions that are also maintained separately from Python, aahz> I think compatibility with the external code has to have some aahz> importance. I vote we wait for Py3k. Why not implement some sort of user-controlled module aliasing? That way in 2.x you might have StringIO and stringio available at the same time. The user could enable or disable one or both names for testing and backward compatibility. This of course presumes that the api of the module doesn't change, just its name. Skip ___ 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] dis module and new-style classes
I think it's fine as it is. I don't think making it walk the inheritance tree is helpful; the output would be too large. Also, an instance doesn't have any code and that's fine too. (Didn't you mean "dis.dis(D) doesn't touch C"?) --Guido On 4/6/06, Georg Brandl <[EMAIL PROTECTED]> wrote: > Hi, > > dis.dis currently handles new-style classes stepmotherly: given > > class C(object): > def Cm(): pass > class D(object): > def Dm(): pass > > dis.dis(C) doesn't touch D, and > dis.dis(C()) doesn't touch anything. > > Should it be fixed? It may need some reworking in dis.dis. > > Georg > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.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] elementtree in stdlib
Alex Martelli wrote: > On Apr 5, 2006, at 8:30 PM, Greg Ewing wrote: > > >>A while ago there was some discussion about including >>elementtree in the std lib. I can't remember what the >>conclusion about that was, but if it does go ahead, >>I'd like to suggest that it be reorganised a bit. >> >>I've just started playing with it, and having a >>package called elementtree containing a module >>called ElementTree containing a class called >>ElementTree is just too confusing for words! > > > Try the 2.5 alpha 1 just released, and you'll see that the toplevel > package is now xml.etree. The module and class are still called > ElementTree, though. Note that lxml (which implements an ElementTree compatible API on top of libxml2) was using the 'etree' as a *module* (not a package name) before this move of ElementTree in the core. I had some discussions with Fredrik about making ElementTree in the Python core consistent with lxml, but no luck there. I.e., this in ElementTree: from elementtree.ElementTree import Element is this in lxml: from lxml.etree import Element and I believe in python 2.5 it's now: from xml.etree.ElementTree import Element which is not good in my opinion... (though also not a disaster) Regards, Martijn ___ 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] elementtree in stdlib
[Martijn Faassen wrote]
> I.e., this in ElementTree:
> ...
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/475126
import ElementTree from everywhere
try:
import xml.etree.ElementTree as ET # in python >=2.5
except ImportError:
try:
import cElementTree as ET # effbot's C module
except ImportError:
try:
import elementtree.ElementTree as ET # effbot's pure Python
module
except ImportError:
try:
import lxml.etree as ET # ElementTree API using libxml2
except ImportError:
import warnings
warning.warn("could not import ElementTree "
"(http://effbot.org/zone/element-index.htm)")
# Or you might just want to raise an ImportError here.
# Use ET.Element, ET.ElementTree, etc...
That is the current state.
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
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] dis module and new-style classes
Guido van Rossum wrote: > I think it's fine as it is. I don't think making it walk the > inheritance tree is helpful; the output would be too large. Also, an > instance doesn't have any code and that's fine too. Inheritance has nothing to do with that. > (Didn't you mean "dis.dis(D) doesn't touch C"?) No. > On 4/6/06, Georg Brandl <[EMAIL PROTECTED]> wrote: >> Hi, >> >> dis.dis currently handles new-style classes stepmotherly: given >> >> class C(object): >> def Cm(): pass >> class D(object): >> def Dm(): pass >> >> dis.dis(C) doesn't touch D, and >> dis.dis(C()) doesn't touch anything. >> >> Should it be fixed? It may need some reworking in dis.dis. Here is an example transcript to make clearer what I mean: Python 2.4.2 (#1, Mar 12 2006, 00:14:41) >>> import dis >>> class C: ... def Cm(): pass ... class D: ... def Dm(): pass ... >>> dis.dis(C) Disassembly of Cm: 2 0 LOAD_CONST 0 (None) 3 RETURN_VALUE Disassembly of D: Disassembly of Dm: 4 0 LOAD_CONST 0 (None) 3 RETURN_VALUE >>> dis.dis(C()) Disassembly of Cm: 2 0 LOAD_CONST 0 (None) 3 RETURN_VALUE Disassembly of D: Disassembly of Dm: 4 0 LOAD_CONST 0 (None) 3 RETURN_VALUE >>> class Co(object): ... def Cm(): pass ... class Do(object): ... def Dm(): pass ... >>> dis.dis(Co) Disassembly of Cm: 2 0 LOAD_CONST 0 (None) 3 RETURN_VALUE >>> dis.dis(Co()) >>> ___ 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] elementtree in stdlib
Trent Mick wrote:
> That is the current state.
which reminds that maybe it's time to add an import helper to
the standard library, so you can do
stringio = import_search("cStringIO", "StringIO")
ET = import_search("lxml.etree", "cElementTree", "xml.etree.cElementTree")
db = import_search("superdb", "sqlite3", "fancydb", "dumbdb")
etc. without having to type in
for mod in ("cStringIO", "StringIO"):
try:
m = __import__(mod)
for p in mod.split(".")[1:]:
m = getattr(m, p, None)
if m is None:
raise ImportError
return m
except ImportError:
pass
else:
raise ImportError(mod)
all the time (or create those horridly nested try-except constructs).
or perhaps
try:
import cStringIO as stringio
retry ImportError:
import StringIO as stringio
except ImportError:
print "didn't work!"
would be a solution (sorry, wrong list).
___
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] elementtree in stdlib
[Fredrik Lundh wrote]
> Trent Mick wrote:
>
> > That is the current state.
>
> which reminds that maybe it's time to add an import helper to
> the standard library, so you can do
>
> stringio = import_search("cStringIO", "StringIO")
> ET = import_search("lxml.etree", "cElementTree", "xml.etree.cElementTree")
> db = import_search("superdb", "sqlite3", "fancydb", "dumbdb")
To the 'imp' module? Hrm, would then maybe want to change the docs from:
3.21 imp -- Access the import internals
to
3.21 imp -- Access the import internals and some other useful importing
stuff
:)
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
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] dis module and new-style classes
Sorry, I missed the fact that this was about nested classes. Still, I don't think it's worth fixing. --Guido On 4/6/06, Georg Brandl <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > I think it's fine as it is. I don't think making it walk the > > inheritance tree is helpful; the output would be too large. Also, an > > instance doesn't have any code and that's fine too. > > Inheritance has nothing to do with that. > > > (Didn't you mean "dis.dis(D) doesn't touch C"?) > > No. > > > On 4/6/06, Georg Brandl <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> dis.dis currently handles new-style classes stepmotherly: given > >> > >> class C(object): > >> def Cm(): pass > >> class D(object): > >> def Dm(): pass > >> > >> dis.dis(C) doesn't touch D, and > >> dis.dis(C()) doesn't touch anything. > >> > >> Should it be fixed? It may need some reworking in dis.dis. > > Here is an example transcript to make clearer what I mean: > > Python 2.4.2 (#1, Mar 12 2006, 00:14:41) > >>> import dis > >>> class C: > ... def Cm(): pass > ... class D: > ... def Dm(): pass > ... > >>> dis.dis(C) > Disassembly of Cm: > 2 0 LOAD_CONST 0 (None) > 3 RETURN_VALUE > > Disassembly of D: > Disassembly of Dm: > 4 0 LOAD_CONST 0 (None) > 3 RETURN_VALUE > > > >>> dis.dis(C()) > Disassembly of Cm: > 2 0 LOAD_CONST 0 (None) > 3 RETURN_VALUE > > Disassembly of D: > Disassembly of Dm: > 4 0 LOAD_CONST 0 (None) > 3 RETURN_VALUE > > > >>> class Co(object): > ... def Cm(): pass > ... class Do(object): > ... def Dm(): pass > ... > >>> dis.dis(Co) > Disassembly of Cm: > 2 0 LOAD_CONST 0 (None) > 3 RETURN_VALUE > > >>> dis.dis(Co()) > >>> > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.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
[Python-Dev] str.partition?
Hi, a while ago, Raymond proposed str.partition, and I guess the reaction was positive. So what about including it now? Georg ___ 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] The "i" string-prefix: I18n'ed strings
Martin Blais wrote:
>...
>A(P(_("Click here to forget"), href="...
>...
I assume that this should be
P(A(_("Click here to forget"), href="...
instead (i.e. href is a parameter to A, not to P)
>
> (In my example, I built a library not unlike stan for creating HTML,
> which is where classes A and P come from.) I find the i18n markup a
> bit annoying, especially when there are many i18n strings close
> together. My point is: adding parentheses around almost all strings
> gets tiresome and "charges" the otherwise divine esthetics of Python
> source code.
There is a simple solution to that: write it as
P(a("Click here to forget", href="...
and define
def a(content, **kw):
return A(_(content), **kw)
You could it also write as
P(A_("Click here to forget", href="...
to make it a little more obvious to the reader that there is a
gettext lookup here.
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] str.partition?
> a while ago, Raymond proposed str.partition, and I guess the reaction > was positive. So what about including it now? Neal approved this for going into the second alpha. Will do it this month. Raymond ___ 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] subprocess maintenance - SVN write access
Hi everyone. I've been away from Python dev for a while, but I've noticed that I'm assigned to quite many subprocess bugs (14 or so) that needs some care. The first question is: Am I the right person to take care of these? I do have some ideas for some of the bugs and. OTOH, I don't have time to read python-dev anymore. In case I should do some subprocess work, I need svn write access. I've read section 1.2.8 in the FAQ, but to who should I send my SSH key? Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 LinköpingPhone: +46-13-21 46 00___ 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] The "i" string-prefix: I18n'ed strings
On 4/6/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Martin Blais wrote:
> >...
> >A(P(_("Click here to forget"), href="...
> >...
>
> I assume that this should be
>
> P(A(_("Click here to forget"), href="...
>
> instead (i.e. href is a parameter to A, not to P)
Yeah, that's right, sorry. (You know, you get up with an idea, you're
all excited, whip out the laptop, scramble to spit your message...
Thanks for the correction)
> > (In my example, I built a library not unlike stan for creating HTML,
> > which is where classes A and P come from.) I find the i18n markup a
> > bit annoying, especially when there are many i18n strings close
> > together. My point is: adding parentheses around almost all strings
> > gets tiresome and "charges" the otherwise divine esthetics of Python
> > source code.
>
> There is a simple solution to that: write it as
>
> P(a("Click here to forget", href="...
>
> and define
>
> def a(content, **kw):
> return A(_(content), **kw)
No. That's not going to work: pygettext needs to be able to extract
the string for the catalogs. No markup, no extraction. (This is how
you enter strings that are not meant to be translated.)
>
> You could it also write as
>
> P(A_("Click here to forget", href="...
>
> to make it a little more obvious to the reader that there is a
> gettext lookup here.
This is not generic enough, HTML is too flexible to hard-code all
cases. This only would help slightly.
___
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] subprocess maintenance - SVN write access
On 4/6/06, Peter Åstrand <[EMAIL PROTECTED]> wrote: > > Hi everyone. I've been away from Python dev for a while, but I've noticed > that I'm assigned to quite many subprocess bugs (14 or so) that needs some > care. > > The first question is: Am I the right person to take care of these? I do > have some ideas for some of the bugs and. OTOH, I don't have time to read > python-dev anymore. > I say if you are up for fixing them, then yes you are the right person. > In case I should do some subprocess work, I need svn write access. I've > read section 1.2.8 in the FAQ, but to who should I send my SSH key? > I think Martin usually does it, but you can just send it as a reply to your own email. -Brett ___ 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] The "i" string-prefix: I18n'ed strings
On 4/6/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> On 4/6/06, Martin Blais <[EMAIL PROTECTED]> wrote:
>
> > - We could also have a prefix "I" for strings to be marked but not
> > runtime-translated, to replace the N_() strings.
>
> I'm more dubious about this one, because I don't really see the point.
> Expand pls? With a couple of use cases, maybe?
N_() is used for marking up strings to be extracted for the catalogs,
but that will get expanded programmatically later on, explicitly using
_(variable) syntax or with a call to gettext().
For example, using my web forms library (wink, wink, open source at
http://furius.ca/atocha/), I declare forms at module-level, and so
this gets evaluated only once at import time, when the i18n
environment is not determined yet::
form1 = Form(
'test-form',
StringField('name', N_("Person's Name")),
...
The point of declaring these at module or class level is that once the
apache child is loaded, none of the forms ever need be rebuilt, i.e.
it's fast.
N_() is a no-op (i.e. lambda x: x). Later on, when a request is
processed (when we've setup the i18n target environment), the label
gets translated when used (i.e. from the Atocha code)::
def _get_label( self, field ):
"""
Returns a printable label for the given field.
"""
return (field.label and _(field.label) # <-- translate the
label here
or field.name.capitalize().decode('ascii'))
In summary: sometimes you need to mark-for-translate AND translate a
piece of string, two separate tasks handled by the _() function, and
sometimes you just need to mark-for-translate, handled by the N_()
function, under the assumption that you will be a good boy and not
forget to take care of it yourself later :-) This is pretty standard
getttext stuff, if you used _() a lot I'm surprised you don't have a
need for N_(), I always needed it when I used i18n (or maybe I
misunderstood your question?). It wouldn't make sense to me to add
i'' and not I'' (or equivalents).
There is another example in gloriously verbose C code version from the
GNU manual:
http://www.gnu.org/software/gettext/manual/html_node/gettext_19.html#SEC19
cheers,
___
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] elementtree in stdlib
Trent Mick wrote: > try: > import xml.etree.ElementTree as ET # in python >=2.5 > except ImportError: >... etc ad nauseam For situations like this I've thought it might be handy to be able to say import xml.etree.ElementTree or cElementTree or \ elementtree.ElementTree or lxml.etree as ET -- Greg ___ 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] base64 module
On Thu, Apr 06, 2006, Sanghyeon Seo wrote:
>
> base64 module documentation for b64decode function says, "TypeError is
> raised if s were incorrectly padded or if there are non-alphabet
> characters present in the string." But this doesn't seem to be the
> case. Testcase:
>
> import base64
> base64.b64decode('%')
>
> Since % is a non-alphabet character, this should raise TypeError (btw,
> shouldn't this be ValueError instead?), but Python 2.4.3 silently
> ignores.
Please submit a bug report on SourceForge and report back the ID.
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/
"Look, it's your affair if you want to play with five people, but don't
go calling it doubles." --John Cleese anticipates Usenet
___
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] str.partition?
On Thursday 06 April 2006 18:09, Georg Brandl wrote: > a while ago, Raymond proposed str.partition, and I guess the reaction > was positive. So what about including it now? +1 -Fred -- Fred L. Drake, Jr. ___ 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] packaging/bootstrap issue
This is from bug www.python.org/sf/1465408 Because the Python.asdl and the generated Python-ast.[ch] get checked into svn in the same revision, the svn export I use to build the tarballs sets them all to the same timestamp on disk (the timestamp of the checkin). "make" then attempts to rebuild the ast files - this requires a python executable. Can you see the bootstrap problem? To "fix" this, I'm going to make the "welease" script that does the releases touch the ast files to set their timestamps newer than that of Python.asdl. It's not an ideal solution, but it should fix the problem. The other option would be some special Makefile magic that detects this case and doesn't rebuild the files if no "python" binary can be found. I have no idea how you'd do this in a portable way. Anyone got other options? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] base64 module
2006/4/7, Aahz <[EMAIL PROTECTED]>: > > Please submit a bug report on SourceForge and report back the ID. http://python.org/sf/1466065 Seo Sanghyeon ___ 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] The "i" string-prefix: I18n'ed strings
Martin Blais wrote:
>> P(a("Click here to forget", href="...
>
> No. That's not going to work: pygettext needs to be able to extract
> the string for the catalogs. No markup, no extraction. (This is how
> you enter strings that are not meant to be translated.)
I know; I wrote pygettext. You can pass the set of functions that count
as marker with -k/--keyword arguments.
>> You could it also write as
>>
>> P(A_("Click here to forget", href="...
>>
>> to make it a little more obvious to the reader that there is a
>> gettext lookup here.
>
> This is not generic enough, HTML is too flexible to hard-code all
> cases. This only would help slightly.
I don't understand. What case that you would like to express
couldn't be expressed?
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] subprocess maintenance - SVN write access
Peter Åstrand wrote: > In case I should do some subprocess work, I need svn write access. I've > read section 1.2.8 in the FAQ, but to who should I send my SSH key? Yes, please send it to me, along with the preferred spelling of your name (I'd assume peter.astrand). 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] packaging/bootstrap issue
Anthony Baxter wrote: > Because the Python.asdl and the generated Python-ast.[ch] get checked > into svn in the same revision, the svn export I use to build the > tarballs sets them all to the same timestamp on disk (the timestamp > of the checkin). Actually, the generated c file often has a newer checkin, because it gets the version of Python.asdl embedded - but only after Python.asdl gets its $Revision$ updated (i.e. after the checkin). Still, the .h file will have the same revision, or even an older one if the AST change doesn't affect the header file (not sure if this can ever happen). > To "fix" this, I'm going to make the "welease" script that does the > releases touch the ast files to set their timestamps newer than that > of Python.asdl. It's not an ideal solution, but it should fix the > problem. The other option would be some special Makefile magic that > detects this case and doesn't rebuild the files if no "python" binary > can be found. I have no idea how you'd do this in a portable way. The common approach would be to use autoconf for that. Let autoconf search for a Python binary, and fall back to /bin/true if you don't find any. > Anyone got other options? This strategy (of specifically touching the files for the release) is quite common. Alternatively, you could also force a commit for Python-ast.[ch] if they have the same revision as the .asdl file. As the AST doesn't change that often, this dummy commit would only be rarely needed (and, as I suggested, only on the .h file). 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] elementtree in stdlib
Greg Ewing <[EMAIL PROTECTED]> wrote: >> try: >> import xml.etree.ElementTree as ET # in python >=2.5 >> except ImportError: > >... etc ad nauseam > > For situations like this I've thought it might > be handy to be able to say > >import xml.etree.ElementTree or cElementTree or \ > elementtree.ElementTree or lxml.etree as ET Astonishingly cute. +1. Giovanni Bajo ___ 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] New-style icons, .desktop file
Nick Coghlan wrote: > Georg Brandl wrote: >> Hi, >> >> some time ago, someone posted in python-list about icons using the Python >> logo from the new site design [1]. IMO they are looking great and would >> be a good replacement for the old non-scaling snakes on Windows in 2.5. > > Those are *really* pretty. And the self-referential PIL source code and > disassembly is just plain brilliant. . . > > You could even use a similar style for a Python egg icon by placing the > plus-Python logo in front of a file folder picture. > > However, the concerns raised on python-list about the similarities between > the > .exe and .pyc icons are valid, IMO. I also agree with Andrew Clover's own > comment that having the Windows shortcut symbol cover the Python logo on the > .exe is a bad thing. I've now got back an email from Andrew. About licensing, he says """Whatever licence is easiest, I'm not too worried about it.""" He'll make some tweaks to the images, then I think they'll be ready. Now, are there any other opinions? Georg ___ 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] [IronPython] base64 module
Well, CPython at least still enforces the padding, even if it's ignoring the
invalid characters.
Here's Seo's repro 'simplified' to go straight to binascii (just to get to the
root API):
>>> import binascii
>>> binascii.a2b_base64('%')
''
And then sending a valid character, invalid padding:
>>> binascii.a2b_base64('A')
Traceback (most recent call last):
File "", line 1, in ?
binascii.Error: Incorrect padding
and then throwing in random invalid characters, and CPython ignores the invalid
characters:
>>> binascii.a2b_base64('ABC=')
'\x00\x10'
>>> binascii.a2b_base64('%%ABC=')
'\x00\x10'
>>> binascii.a2b_base64('[EMAIL PROTECTED]')
'\x00\x10'
>>> binascii.a2b_base64('[EMAIL PROTECTED]()')
'\x00\x10'
The documentation for binascii.a2b_base64 doesn't specify if it throws for
anything either.
I would suspect that there's a reason why CPython is ignoring the invalid
characters here. If this is the expected behavior then I'm happy to make
IronPython match this. And at the very least we HAVE to fix the exception that
gets thrown - I'm with Seo that it should be a ValueError but line between
ValueError and TypeError is blurry at times anyway, and TypeError is what's
documented.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo
Sent: Wednesday, April 05, 2006 10:45 PM
To: [email protected]; [email protected]
Subject: [IronPython] base64 module
Hello,
base64 module documentation for b64decode function says, "TypeError is
raised if s were incorrectly padded or if there are non-alphabet
characters present in the string." But this doesn't seem to be the
case. Testcase:
import base64
base64.b64decode('%')
Since % is a non-alphabet character, this should raise TypeError (btw,
shouldn't this be ValueError instead?), but Python 2.4.3 silently
ignores.
I found this while experimenting with IronPython. IronPython 1.0 Beta 5 gives:
Traceback (most recent call last):
File base64, line unknown, in b64decode
SystemError: cannot decode byte: '%'
It's not TypeError, but it doesn't silently ignore either.
Seo Sanghyeon
___
users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.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] base64 module
Hello,
base64 module documentation for b64decode function says, "TypeError is
raised if s were incorrectly padded or if there are non-alphabet
characters present in the string." But this doesn't seem to be the
case. Testcase:
import base64
base64.b64decode('%')
Since % is a non-alphabet character, this should raise TypeError (btw,
shouldn't this be ValueError instead?), but Python 2.4.3 silently
ignores.
I found this while experimenting with IronPython. IronPython 1.0 Beta 5 gives:
Traceback (most recent call last):
File base64, line unknown, in b64decode
SystemError: cannot decode byte: '%'
It's not TypeError, but it doesn't silently ignore either.
Seo Sanghyeon
___
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
