Re: [Python-Dev] packaging/bootstrap issue
Anthony Baxter wrote: > 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. this is closely related to www.python.org/sf/1393109 except that in the latter case, the system have a perfectly working Python 2.1 which chokes on the new-style constructs used in the generator script. fwiw, that bug report (from december) says iirc, various solutions to this were discussed on python-dev, but nobody seems to have done anything about it. so it's about time someone did something about it... explicitly touching the files should be good enough. ___ 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] elementtree in stdlib
On 4/7/06, Greg Ewing <[EMAIL PROTECTED]> wrote: Trent Mick wrote:> try:> import xml.etree.ElementTree as ET # in python >=2.5> except ImportError: >... etc ad nauseamFor 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 ETThat does look cute (note that you can use parentheses rather than newline-escaping to continue the line.) I assume it should come with: from (xml.etree.cElementTree or xml.etree.ElementTree or elementtree.cElementTree or elementtree.ElementTree or lxml.etree) import ElementTree as ET(Parentheses there are currently illegal.) But should it also come with:from xml.etree import (cElementTree or ElementTree) as ElementTreeand combined:from xml.etree or elementtree import cElementTree or ElementTree as ElementTree and of course combined with explicit-relative imports:from .custometree or xml.etree or elementtree import cElementTree or ElementTree as ETor is that all going too far? :)-- Thomas Wouters < [EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] The "i" string-prefix: I18n'ed strings
Martin Blais wrote:
> 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.
This has been discussed a few times before, see e.g.
http://mail.python.org/pipermail/python-list/2000-January/020346.html
In summary, the following points were made in the various
discussions (this is from memory, so I may have forgotten
a few points):
* the string literal modifiers r"" and u"" are really only a cludge
which should not be extended to other uses
* being able to register such modifiers would result in unreadable
and unmaintainable code, since the purpose of the used modifiers
wouldn't be clear to the reader of a code snippet
* writing i"" instead of _("") saves two key-strokes - not really
enough to warrant the change
* if you want to do it right, you'd also have to add iu"",
ir"" for completeness
* internationalization requires a lot more than just calling
a function: context and domains are very important when it
comes to translating strings in i18n efforts; these can
easily be added to a function call as parameter, but not
to a string modifier
* there are lots of tools to do string extraction using the
_("") notation (which also works in C); for i"" such tools
would have to be rewritten
> 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
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/mal%40egenix.com
--
Marc-Andre L
Re: [Python-Dev] The "i" string-prefix: I18n'ed strings
On Thu, 6 Apr 2006 20:35:51 -0400, Martin Blais wrote: > 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?). Have you thought about simply writing _ = lambda x:x instead of N_ ...? By doing that, you just need to care about one function (of course _ doesn't translate in that case and you might need to del _ afterwards). Kind regards, Alexander ___ 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] module aliasing
[EMAIL PROTECTED] wrote: > 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. Something that has occasionally bugged me is the verbosity of trying an import, failing with an ImportError, then trying again. For instance, to be Py3k friendly, the simple: from StringIO import StringIO would have to become: try: from stringio import StringIO except ImportError: from StringIO import StringIO And if I wanted to check for cStringIO as well (assuming Py3k was clever enough to supply the C version if it was available), it would be: try: from stringio import StringIO except ImportError: try: from cStringIO import StringIO except ImportError: from StringIO import StringIO It would be nice if this chain could instead be written as: from stringio or cStringIO or StringIO import StringIO Similar to PEP 341, this could be pure syntactic sugar, with the actual try-except statements generated in the AST. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] elementtree in stdlib
Greg Ewing wrote: > 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 Suppose I wanted to implement that, what would be the best strategy to follow: - change handling of IMPORT_NAME and IMPORT_FROM in ceval.c - emit different bytecodes in compile.c - directly create TryExcept AST nodes in ast.c ? 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] module aliasing
On 4/7/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: It would be nice if this chain could instead be written as: from stringio or cStringIO or StringIO import StringIOSimilar to PEP 341, this could be pure syntactic sugar, with the actualtry-except statements generated in the AST. It could, but it's probably easier to make the IMPORT_NAME (and possibly IMPORT_FROM) opcodes take more names from the stack, and do it all in the C code for the opcodes. And __import__ could be changed to accept a sequence of modules (it takes keyword arguments now, anyway. ;) -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] elementtree in stdlib
Georg Brandl wrote: > Greg Ewing wrote: >> 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 > > Suppose I wanted to implement that, what would be the best strategy > to follow: > - change handling of IMPORT_NAME and IMPORT_FROM in ceval.c > - emit different bytecodes in compile.c > - directly create TryExcept AST nodes in ast.c Definitely option 3, since you only have to modify the parser and the AST compiler. To change it in compile.c, you have to first modify the parser, the AST definition and the AST compiler in order to get the info to the bytecode compiler. To change it in ceval.c, you have to first modify the parser, the AST definition, the AST compiler and the bytecode compiler in order to get the info to the eval loop. Given that import statements aren't supposed to be in time critical code, go for the easy option :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] The "i" string-prefix: I18n'ed strings
On 4/7/06, Alexander Schremmer <[EMAIL PROTECTED]> wrote: > On Thu, 6 Apr 2006 20:35:51 -0400, Martin Blais wrote: > > > 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?). > > Have you thought about simply writing _ = lambda x:x instead of N_ ...? > By doing that, you just need to care about one function (of course _ > doesn't translate in that case and you might need to del _ afterwards). There are cases where you need N_() after initialization, so you need both, really. See the link I sent to Alex earlier (to the GNU manual example). ___ 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] The "i" string-prefix: I18n'ed strings
On 4/7/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Martin Blais wrote:
> > 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.
>
> This has been discussed a few times before, see e.g.
>
> http://mail.python.org/pipermail/python-list/2000-January/020346.html
Oh, wow, thanks!
> In summary, the following points were made in the various
> discussions (this is from memory, so I may have forgotten
> a few points):
>
> * the string literal modifiers r"" and u"" are really only a cludge
> which should not be extended to other uses
>
> * being able to register such modifiers would result in unreadable
> and unmaintainable code, since the purpose of the used modifiers
> wouldn't be clear to the reader of a code snippet
>
> * writing i"" instead of _("") saves two key-strokes - not really
> enough to warrant the change
>
> * if you want to do it right, you'd also have to add iu"",
> ir"" for completeness
Good points. Thanks for summarizing. It's certainly true that adding
a general mechanism to hook custom calls into strings initialization
may cause confusion if people define them differently.
> * internationalization requires a lot more than just calling
> a function: context and domains are very important when it
> comes to translating strings in i18n efforts; these can
> easily be added to a function call as parameter, but not
> to a string modifier
Sure, but the simple case covers 99% the great majority of the uses.
> * there are lots of tools to do string extraction using the
> _("") notation (which also works in C); for i"" such tools
> would have to be rewritten
(I don't really see this as a problem.)
___
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] The "i" string-prefix: I18n'ed strings
On 4/7/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> 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?
Hmmm thinking about this more, I think you're right, I do want to i18n
all the strings passed in to HTML builder classes as positional
arguments, and so I should make all the HTML tags keywords for
pygettext, this would cover the majority of strings in my application.
I'm not sure all the cases are handled, but for those which aren't I
can't see why I couldn't hack the pygettext parser to make it do what
I want, e.g. is the case were the function contains multiple strings
handled? ::
P(A_("Status: ", get_balance(), "dollars", href=" ")
(No need to answer to list, this is getting slightly OT, I'll check it
out in more detail.)
___
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] The "i" string-prefix: I18n'ed strings
On Fri, 7 Apr 2006 10:07:26 -0400, Martin Blais wrote: > There are cases where you need N_() after initialization, so you need > both, really. See the link I sent to Alex earlier (to the GNU manual > example). On the page you were referring to, I cannot find a particular use case that does not work with the idea sketched above. Kind regards, Alexader ___ 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] elementtree in stdlib
On 4/6/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Bob Ippolito wrote: > > > > 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. > > > > It would be nice to have new code be PEP 8 compliant.. > > it's not new code, and having *different* module names for the same > well-established library isn't very nice to anyone. (It's not new code, but it is new code to the stdlib.) How about doing a rename but creating some kind of alias for the current names? That would serve everyone. (I also find the current naming to be unfortunate and stumble over it every time.) ___ 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] The "i" string-prefix: I18n'ed strings
On 4/7/06, Alexander Schremmer <[EMAIL PROTECTED]> wrote:
> On Fri, 7 Apr 2006 10:07:26 -0400, Martin Blais wrote:
>
> > There are cases where you need N_() after initialization, so you need
> > both, really. See the link I sent to Alex earlier (to the GNU manual
> > example).
>
> On the page you were referring to, I cannot find a particular use case that
> does not work with the idea sketched above.
Okie. Here's one example from actual code:
class EventEdit(EventEditPages):
def handle( self, ctxt ):
...
# Render special activate/deactivate button.
if ctxt.event.state == 'a':
future_state = u's'
actstr = N_('Deactivate')
else:
future_state = u'a'
actstr = N_('Activate')
values = {'state': future_state}
rdrbutton = HoutFormRenderer(form__state_set, values)
page.append(rdrbutton.render(submit=actstr))
HoutFormRenderer.render() expects non-translated strings, and it
performs the gettext lookup itself (this is a general library-wide
policy for all widget labels).
(This is just one example. I have many other use cases like this.)
___
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] Patch or feature? Tix.Grid working for 2.5
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Christos Georgiou wrote: >> I would like to know if supplying a patch for it sometime in the next >> couple >> of weeks would be considered a patch (since the widget currently is not >> working at all, its class in Tix.py contains just a pass statement) or a >> feature (ie extra functionality) for the 2.5 branch... > > I wouldn't object to including it before beta 1. Just in case the auto-assignment email still does not work, I have submitted the patch since March 31. OTOH, if I need to review 5 bugs/patches, I'll try to find some time to do that. ___ 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] New-style icons, .desktop file
Georg Brandl wrote: > Nick Coghlan wrote: > > Georg Brandl wrote: > >> 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. . . [snip] > 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? Other than that I love the new icons and I can't wait until Python 2.5 has them? ;-) Steve -- Grammar am for people who can't think for myself. --- Bucky Katt, Get Fuzzy ___ 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] The "i" string-prefix: I18n'ed strings
On Thu, 2006-04-06 at 11:48 -0400, Martin Blais wrote: > - This implies that we would have to introduce some way for these > strings to call a custom function at runtime. Yes, definitely. For example, in Mailman we bind _() not to gettext's _() but to a special one that looks up the translation context, find the string's translation, then does the substitutions. So this is one difficult sticking point with the idea. -Barry signature.asc Description: This is a digitally signed message part ___ 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] The "i" string-prefix: I18n'ed strings
On Fri, 2006-04-07 at 13:29 +0200, Alexander Schremmer wrote: > Have you thought about simply writing _ = lambda x:x instead of N_ ...? > By doing that, you just need to care about one function (of course _ > doesn't translate in that case and you might need to del _ afterwards). That's essentially what I do in Mailman, although I use def _(s): return s same-difference-ly y'rs, -Barry signature.asc Description: This is a digitally signed message part ___ 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] elementtree in stdlib
[Thomas Wouters suggested "import ... or" syntax] > or is that all going too far? :) Yes. It is overkill. The number of different ways to import ElementTree is perhaps unfortunate but it is a mostly isolated incident: effbot providing pure and c versions, it being popular and hence having other implementations *and* quickly getting into the core. The original issue was that the various import paths to ElementTree are a little confusing. Adding "or" syntax doesn't change that. Trent -- Trent Mick [EMAIL PROTECTED] ___ 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] elementtree in stdlib
Nick Coghlan wrote: > Georg Brandl wrote: >> Greg Ewing wrote: >>> 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 >> >> Suppose I wanted to implement that, what would be the best strategy >> to follow: >> - change handling of IMPORT_NAME and IMPORT_FROM in ceval.c >> - emit different bytecodes in compile.c >> - directly create TryExcept AST nodes in ast.c > > Definitely option 3, since you only have to modify the parser and the AST > compiler. > > To change it in compile.c, you have to first modify the parser, the AST > definition and the AST compiler in order to get the info to the bytecode > compiler. > > To change it in ceval.c, you have to first modify the parser, the AST > definition, the AST compiler and the bytecode compiler in order to get the > info to the eval loop. > > Given that import statements aren't supposed to be in time critical code, go > for the easy option :) Well, if there's an encouraging word from more developers, I can try it. 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] New-style icons, .desktop file
Also, a while ago a Kevin T. Gadd posted some Python icons he had made. http://mail.python.org/pipermail/python-dev/2004-August/048273.html -- - Ian D. Bollinger ___ 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] The "i" string-prefix: I18n'ed strings
Martin Blais wrote:
> I'm not sure all the cases are handled, but for those which aren't I
> can't see why I couldn't hack the pygettext parser to make it do what
> I want, e.g. is the case were the function contains multiple strings
> handled? ::
>
> P(A_("Status: ", get_balance(), "dollars", href=" ")
>
>
> (No need to answer to list, this is getting slightly OT, I'll check it
> out in more detail.)
I'll answer it anyway, because this is important enough for anybody to
understand :-)
*Never* try to do i18n that way. Don't combine fragments through
concatenation. Instead, always use placeholders. IOW, the
msgid should be
"Status: %s dollars"
or, if you have multiple placeholders
"Status: %(balance)s placeholders"
If you have many fragments, the translator gets the challenge of
translating "dollars". Now, this might need to be translated differently
in different contexts (and perhaps even depending on the value of
balance); the translator must always get the complete message
as a single piece.
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] packaging/bootstrap issue
Fredrik Lundh wrote: > this is closely related to > > www.python.org/sf/1393109 > > except that in the latter case, the system have a perfectly working > Python 2.1 which chokes on the new-style constructs used in the > generator script. > > fwiw, that bug report (from december) says > > iirc, various solutions to this were discussed on python-dev, > but nobody seems to have done anything about it. > > so it's about time someone did something about it... explicitly touching > the files should be good enough. Maybe I'm misunderstanding, but I doubt that Anthony's touching the files on his exported tree would help with #1393109 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] The "i" string-prefix: I18n'ed strings
On Sat, 2006-04-08 at 00:45 +0200, "Martin v. Löwis" wrote: > *Never* try to do i18n that way. Don't combine fragments through > concatenation. Instead, always use placeholders. Martin is of course absolutely right! > If you have many fragments, the translator gets the challenge of > translating "dollars". Now, this might need to be translated differently > in different contexts (and perhaps even depending on the value of > balance); the translator must always get the complete message > as a single piece. Plus, if you have multiple placeholders, the order may change in some translations. -Barry signature.asc Description: This is a digitally signed message part ___ 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] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 391 open ( +2) / 3142 closed (+25) / 3533 total (+27) Bugs: 898 open ( -3) / 5731 closed (+44) / 6629 total (+41) RFE : 215 open ( +1) / 207 closed ( +1) / 422 total ( +2) New / Reopened Patches __ give round() kwargs (mostly for PFAs) (2006-03-28) CLOSED http://python.org/sf/1460496 opened by Wesley J. Chun Improved PySet C API (2006-03-25) CLOSED http://python.org/sf/1458476 reopened by bwarsaw "const int" was truncated to "char" (2006-03-31) http://python.org/sf/1461822 opened by Hirokazu Yamamoto ssl build fails due to undefined NETLINK_ stuff (2006-03-31) CLOSED http://python.org/sf/1462080 opened by Arkadiusz Miskiewicz Patch for 1115886 - splitext incorrectly handles filenames l (2006-03-31) http://python.org/sf/1462106 opened by Mike Foord Functioning Tix.Grid (2006-03-31) http://python.org/sf/146 opened by Christos Georgiou fdopen(..., "a") (2006-03-31) CLOSED http://python.org/sf/1462227 opened by Ralf Schmitt custom comparison function for bisect module (2006-03-31) http://python.org/sf/1462228 opened by splitscreen Fix for #1250170 (2006-03-31) CLOSED http://python.org/sf/1462230 opened by Kuba KoÅczyk Fix of "disgusting hack" in Misc.after (2006-03-31) CLOSED http://python.org/sf/1462235 opened by Christos Georgiou fdopen(..., "a") (2006-03-31) CLOSED http://python.org/sf/1462245 opened by Ralf Schmitt Fix for bug #1445068 getpass.getpass query on stderr (2006-03-31) CLOSED http://python.org/sf/1462298 reopened by splitscreen Fix for bug #1445068 getpass.getpass query on stderr (2006-03-31) CLOSED http://python.org/sf/1462298 opened by splitscreen Pickle protocol 2 fails on private slots (2006-03-31) CLOSED http://python.org/sf/1462313 opened by iga Seilnacht upgrade pyexpat to expat 2.0.0 (2006-03-31) http://python.org/sf/1462338 opened by Trent Mick Possible fix to #1334662 (int() wrong answers) (2006-03-31) http://python.org/sf/1462361 opened by Ivan Vilata i Balaguer Patch for bug #1458017 Log._log needs to be more forgiving (2006-03-31) CLOSED http://python.org/sf/1462414 opened by splitscreen Patch for bug #931877 Segfault in object_reduce_ex (2006-04-01) http://python.org/sf/1462488 opened by iga Seilnacht Spelling correction in libsignal.tex (2006-03-31) CLOSED http://python.org/sf/1462496 opened by lmllc bug #1452246 and patch #1087808; sgmllib entities (2006-03-31) CLOSED http://python.org/sf/1462498 opened by Rares Vernica URI parsing library (2006-04-01) http://python.org/sf/1462525 opened by Paul Jimenez replace md5 impl. with one having a more free license (2005-02-07) CLOSED http://python.org/sf/1117961 reopened by doko urllib2.ProxyHandler broken recently for non-userinfo case (2006-04-01) CLOSED http://python.org/sf/1462790 opened by John J Lee Save the hash value of tuples (2006-04-01) CLOSED http://python.org/sf/1462796 opened by Noam Raphael Remove broken code from urllib2 (2006-04-02) CLOSED http://python.org/sf/1463012 opened by John J Lee Bugfix for #847665 (XMLGenerator dies in namespace mode) (2006-04-02) http://python.org/sf/1463026 opened by Nikolai Grigoriev clean up new calendar locale usage (2006-04-02) http://python.org/sf/1463288 opened by Neal Norwitz Add .format() method to str and unicode (2006-04-03) CLOSED http://python.org/sf/1463370 opened by crutcher Improved generator finalization (2006-04-03) http://python.org/sf/1463867 opened by Phillip J. Eby Simple test for os.startfile (2006-04-04) CLOSED http://python.org/sf/1464062 reopened by loewis Simple test for os.startfile (2006-04-04) CLOSED http://python.org/sf/1464062 opened by Thomas Heller fixed handling of nested comments in mail addresses (2006-04-05) http://python.org/sf/1464708 opened by William McVey Patches Closed __ give round() kwargs (mostly for PFAs) (2006-03-29) http://python.org/sf/1460496 closed by gbrandl Install PKG-INFO with packages (2006-03-27) http://python.org/sf/1459476 closed by pje Support different GPG keys in upload --sign (2006-03-23) http://python.org/sf/1457316 closed by pje Improved PySet C API (2006-03-25) http://python.org/sf/1458476 closed by bwarsaw ssl build fails due to undefined NETLINK_ stuff (2006-03-31) http://python.org/sf/1462080 closed by loewis fdopen(..., "a") (2006-03-31) http://python.org/sf/1462227 closed by gbrandl Fix for #1250170 (2006-03-31) http://python.org/sf/1462230 closed by gbrandl Fix of "disgusting hack" in Misc.after (2006-03-31) http://python.org/sf/1462235 closed by gbrandl fdopen(..., "a") (2006-03-31) http://python.org/sf/1462245 deleted by titty Fix for bug #1445068 getpass.getpass query on stderr (2006-03-31) ht
[Python-Dev] Who understands _ssl.c on Windows?
An "impossible problem" showed up on Bug Day, which got more impossible the more I looked at it: http://www.python.org/sf/1462352 See that for details. The short course is that socketmodule.c and _ssl.c disagree about the offset at which the sock_timeout member of a PySocketSockObject struct lives. As a result, timeouts set on a socket "change by magic" when _ssl.c looks at them. This is certainly the case on the trunk under Windows on my box. No idea about other platforms or Python versions. When someone figures out the cause, those should be obvious ;-) _Perhaps_ it's the case that doubles are aligned to an 8-byte boundary when socketmodule.c is compiled, but (for some unknown reason) only to a 4-byte boundary when _ssl.c is compiled. Although that seems to match the details in the bug report, I have no theory for how that could happen (I don't see any MS packing pragmas anywhere). ___ 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
