Humberto Diogenes wrote:
>* _ = gettext.gettext; print _("my string") isn't very nice
If you don't like _, you're free to use something
else, e.g.
from gettext import gettext as i
i("This is a an i18m string")
which is not very far from an i prefix.
--
Greg
_
Hi, folks!!
This is my first post to python-3000. After Guido PEPs-deadline
announcement, I decided to discuss an old idea while it still has
some chance of being accepted. :)
No, I do not want i18n identifiers. What I'd like to propose is a
standard syntax for i18n strings. Something
On 10/04/2007, at 21:24, Greg Ewing wrote:
> Raymond Hettinger wrote:
>
>> Here's that I think might not need a PEP:
>>
>> * Eliminate implicit string concatenation: "abc" "def"
>> in favor of an explicit + operation.
>
> -0.707. I've used languages where the only way of
> splitting a string ov
Martin v. Löwis wrote:
> I'd like to submit the following PEP for Python 3.
>
> Regards,
> Martin
>
>
> PEP: xxx
> Title: Using UTF-8 as the default source encoding
> Version: $Revision $
> Last-Modified: $Date $
> Author: Martin v. Löwis <[EMAIL PROTECTED]>
> Status: Draft
> Type: Standards Tra
Can we move this thread out of the python-3000? This issue has already
been decided and is unlikely to be reopened.
On 4/16/07, Chris Rebert <[EMAIL PROTECTED]> wrote:
> Ah, that must have been it! Never mind then ;-).
>
> - Chris Rebert
>
> Mike Klaas wrote:
> > On 4/16/07, Chris Rebert <[EMAIL P
Ah, that must have been it! Never mind then ;-).
- Chris Rebert
Mike Klaas wrote:
> On 4/16/07, Chris Rebert <[EMAIL PROTECTED]> wrote:
>> I think someone has probably proposed this before, but why not use "{,}"
>> as the empty set literal?
>
> If you're sure, did you look for it first?
>
> htt
On 4/16/07, Chris Rebert <[EMAIL PROTECTED]> wrote:
> I think someone has probably proposed this before, but why not use "{,}"
> as the empty set literal?
If you're sure, did you look for it first?
http://mail.python.org/pipermail/python-3000/2006-April/001400.html
-Mike
I think someone has probably proposed this before, but why not use "{,}"
as the empty set literal? It's somewhat analogous to the 1-element tuple
syntax and fairly similar to the syntax that the original set PEP
proposed ("{-}"). From what I understand, {-} was nixed for being too
hard to parse
Eoghan Murray wrote:
> how about
> s[1, 2, 3, 4]
> for a set?
Already meaningful syntax. Try this:
d = {}
d[1, 2, 3, 4] = 'spam'
print d
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python
s[1] being a list index of the list 's'
s[1,] being a set literal with one element, '1'
On 17/04/07, Eoghan Murray <[EMAIL PROTECTED]> wrote:
I had another idea on this theme.. going by unicode and raw string
literals, how about
s[1, 2, 3, 4]
for a set?
Eoghan
On 17/04/07, Greg Ewing <[EMAIL
I had another idea on this theme.. going by unicode and raw string literals,
how about
s[1, 2, 3, 4]
for a set?
Eoghan
On 17/04/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
DillonCo wrote:
> Why not use "<>" for sets?
Some possible reasons:
* It would look ugly
* There could be visual confusi
DillonCo wrote:
> Why not use "<>" for sets?
Some possible reasons:
* It would look ugly
* There could be visual confusion with comparison operators
* There could be parsing difficulties distinguishing
nested set bracketing from << and >> operators
--
Greg
_
That would probably be very difficult to parse because it introduces
ambiguities. Take a look at this situation:
<8,True, 3>=4, 5 >
- Original Message -
From: "DillonCo" <[EMAIL PROTECTED]>
To:
Sent: Monday, April 16, 2007 7:08 PM
Subject: Re: [Python-3000] Empty set and empty dictiona
On Monday 16 April 2007, Neville Grech wrote:
> Since set literals will change to for example {1,2,3} from set([1,2,3])
> and set comprehensions will be specified inside {} I feel that {} will be
> more naturally associated with sets than dicts (or at least as much).
While the topic of set litera
On 4/16/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 4/16/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> Can we remove all the functions from the string module that are also
> existing methods on string? Then we can figure out what to do with
> what's left over?
+1
> I'm tempted to ask t
"Neville Grech" <[EMAIL PROTECTED]> wrote:
> This is just some syntax sugar:
>
> Since set literals will change to for example {1,2,3} from set([1,2,3])
> and set comprehensions will be specified inside {} I feel that {}
> will be more naturally associated with sets than dicts (or at least
> as
On 4/16/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> Can we remove all the functions from the string module that are also
> existing methods on string? Then we can figure out what to do with
> what's left over?
+1
> I'm tempted to ask the same thing about the types module.
+1
--
--Guido van
It's not stupid, but it's been brought up before (exactly like you
propose) and rejected, on the basis that dicts are still much more
common than sets in most code.
On 4/16/07, Neville Grech <[EMAIL PROTECTED]> wrote:
>
>
> This is just some syntax sugar:
>
> Since set literals will change to for
This is just some syntax sugar:
Since set literals will change to for example {1,2,3} from set([1,2,3]) and
set comprehensions will be specified inside {} I feel that {} will be more
naturally associated with sets than dicts (or at least as much).
What if the empty set literal is changed to {}
Can we remove all the functions from the string module that are also
existing methods on string? Then we can figure out what to do with
what's left over?
I'm tempted to ask the same thing about the types module.
TOOWTDI.
n
___
Python-3000 mailing list
20 matches
Mail list logo
