Greg Ewing wrote:
> Maybe backquotes could be repurposed in Py3k for interpolated
> string literals?
backquotes are a PITA to type on many non-US keyboards.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
Greg> Stephen J. Turnbull wrote:
>> IMO strings that are being printf'd can probably be assumed to
>> be human readable, and therefore candidates for translation.
>> This
Greg> That's a dangerous assumption to make, I thi
Stephen J. Turnbull wrote:
> IMO strings that are being printf'd can probably be assumed to be
> human readable, and therefore candidates for translation. This
That's a dangerous assumption to make, I think.
I'd be uncomfortable with having some strings in
my program translated automatically
Michael Chermside wrote:
> In my opinion, YES -- it's worth seriously considering it. A single,
> well-designed solution for string interpolation (with syntactic support
> if needed to make it very easy to use) is FAR better than having one
> good solution and another legacy solution.
Maybe backq
On 9/8/05, Tony Meyer <[EMAIL PROTECTED]> wrote:
> [finding Tools/i18n/pygettext.py]
> > You're right, I think Tools is probably a bad place for
> > anything. If it's not part of the stdlib, I'll likely never
> > find it.
>
> Agreed. Maybe with the introduction of -m in Python 2.4, some of the T
[finding Tools/i18n/pygettext.py]
> You're right, I think Tools is probably a bad place for
> anything. If it's not part of the stdlib, I'll likely never
> find it.
Agreed. Maybe with the introduction of -m in Python 2.4, some of the Tools/
scripts could be put in __main__ sections of appropria
On Thu, Sep 08, 2005 at 12:41:39PM -0600, Mike Brown wrote:
> [EMAIL PROTECTED] wrote:
> > According to RFC 2396[1] section 5.2:
>
> RFC 2396 is obsolete. It was superseded by RFC 3986 / STD 66 early this year.
Thanks for the correction.
Jeff
pgpFDXgf6EeqZ.pgp
Description: PGP signature
__
* Lisandro Dalcin <[EMAIL PROTECTED]> [2005-09-08 13:56:07 -0300]:
> Yes, you are right. But this way, you are making explicit a behavior
> that will be implicit in the future.
>
> For example, we could also do:
>
> two = float(4)/float(2)
>
> instead of
>
> from __future__ import div
Josiah Carlson wrote:
> Fernando Perez <[EMAIL PROTECTED]> wrote:
>> Would you care to elaborate on the reasons behind the 'ick'? I'm a big fan
>> of weave.inline and have used it very successfully for my own needs, so I'm
>> genuinely curious (as I tend to teach its use, I like to know of poten
[EMAIL PROTECTED] wrote:
> According to RFC 2396[1] section 5.2:
RFC 2396 is obsolete. It was superseded by RFC 3986 / STD 66 early this year.
In particular, the procedure for removing dot-segments from the path component
of a URI reference -- a procedure that is only supposed to be done when
'
Fernando Perez <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Here's a perspective "from the trenches" as it were.
> >
> > I've been writing quite a bit of code, initially all in Python (27k
> > lines in the last year or so). It worked reasonably well and fast. It
> > wasn't fast enough.
Josiah Carlson wrote:
> Here's a perspective "from the trenches" as it were.
>
> I've been writing quite a bit of code, initially all in Python (27k
> lines in the last year or so). It worked reasonably well and fast. It
> wasn't fast enough. I needed a 25x increase in performance, which would
>
On Sep 8, 2005, at 5:42 AM, Barry Warsaw wrote:
> On Wed, 2005-09-07 at 15:07, Bob Ippolito wrote:
>
>
>> I was also able to easily automate the process of extracting strings
>> to create that spreadsheet. I wrote a simple script that parsed the
>> Python modules and looked for function calls of
Michael Chermside writes:
| Guido writes:
| > Is it worth doing this and completely dropping the %-based formats in
| > Py3k? (Just asking -- it might be if we can get people to get over the
| > shock of $ becoming first class ;-).
|
| In my opinion, YES -- it's worth seriously considering it. A s
On 9/8/05, Aahz <[EMAIL PROTECTED]> wrote:
>
> You can already do
>
> __metaclass__ = type
>
> within each module
>
Yes, you are right. But this way, you are making explicit a behavior
that will be implicit in the future.
For example, we could also do:
two = float(4)/float(2)
instead of
On 9/6/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/5/05, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > There is a lot of debate over this issue, obviously. Now, I think
> > getting rid of the print statement can lead to ugly code, because a
> > write function would be called as an expre
On Thu, Sep 08, 2005, Lisandro Dalcin wrote:
>
> Any possibility to add something like
>
> from __future__ import new_style_classes
>
> to have newly defined classes implicitly derive from 'object' (I
> understand this will be the implicit behavior when classic classes go
> away in Py3.0).
You
> "Antoine" == Antoine Pitrou <[EMAIL PROTECTED]> writes:
Antoine> Le jeudi 08 septembre 2005 à 19:12 +0900, Stephen
Antoine> J. Turnbull a écrit :
>> It would be nice to be able to lose the "_()" calls to
>> gettext(). The function would look to see if a message catalog
PEP 3000 - Core language says
(http://www.python.org/peps/pep-3000.html#core-language) :
- Support only new-style classes; classic classes will be gone
Any possibility to add something like
from __future__ import new_style_classes
to have newly defined classes implicitly derive from 'object' (I
Barry Warsaw wrote:
> On Wed, 2005-09-07 at 08:55, Nick Coghlan wrote:
>
>
>>The leading 'p' (for 'positional') is necessary to get around the fact that
>>$1
>>is currently an illegal identifier in a Template
>
>
> That should be fixable. Ideally, $1 is better than $p1.
I also looked into th
Barry Warsaw wrote:
> On Wed, 2005-09-07 at 08:55, Nick Coghlan wrote:
>
>
>>The leading 'p' (for 'positional') is necessary to get around the fact that
>>$1
>>is currently an illegal identifier in a Template
>
>
> That should be fixable. Ideally, $1 is better than $p1.
Oh, I know. I just di
On Thu, 2005-09-08 at 07:48, Antoine Pitrou wrote:
> As I said Python needs an operator or function that does string
> formatting using a simple template, *without* doing output at the same
> time. The current syntax is the '%' operator, it could change, but it
> shouldn't be removed in favor of a
On Wed, 2005-09-07 at 15:07, Bob Ippolito wrote:
> I was also able to easily automate the process of extracting strings
> to create that spreadsheet. I wrote a simple script that parsed the
> Python modules and looked for function calls of "_" whose only
> argument was a constant string. W
On Wed, 2005-09-07 at 08:55, Nick Coghlan wrote:
> The leading 'p' (for 'positional') is necessary to get around the fact that
> $1
> is currently an illegal identifier in a Template
That should be fixable. Ideally, $1 is better than $p1.
-Barry
signature.asc
Description: This is a digitall
Guido writes:
> Is it worth doing this and completely dropping the %-based formats in
> Py3k? (Just asking -- it might be if we can get people to get over the
> shock of $ becoming first class ;-).
In my opinion, YES -- it's worth seriously considering it. A single,
well-designed solution for stri
Hi,
Le jeudi 08 septembre 2005 à 19:12 +0900, Stephen J. Turnbull a écrit :
> It would be
> nice to be able to lose the "_()" calls to gettext(). The function
> would look to see if a message catalog was available for the current
> output stream, and if not, do no translation.
That doesn't so
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
Guido> I certainly didn't mean to rule that out.
Speaking for myself, that's all I really wanted to hear at this time.
As Bob Ippolito said, currently it's straightforward to
internationalize an application, and well worth the mini
(sorry for the delayed reply; vacation)
On Aug 14, 2005, at 12:27 PM, Guido van Rossum wrote:
On 8/14/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
Wilfredo Sánchez Vega <[EMAIL PROTECTED]> writes:
I'm curious about why Python lacks FileNotFoundError,
PermissionError and the like as su
28 matches
Mail list logo
