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
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 {}
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
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
"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, 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
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
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
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
_
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
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
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
[email protected]
http://mail.python.org/mailman/listinfo/python
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
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
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
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
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
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
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
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
_
20 matches
Mail list logo
