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 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] 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 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
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 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 [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 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
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 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
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. /F ___ 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(iClick 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 Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Apr 07 2006)
Python/Zope Consulting and Support ...
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] 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] 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
