Greg Ewing wrote:
> Andrew Clover wrote:
>
>
>>Here's another syntax off the top of my head - put the first case in the
>>switch statement?
>>
>> switch biscuit.type if 'digestive':
>> ...
>> elif in 'jammy_dodger', 'garibaldi':
>> ...
>> else:
>> ...
>
>
> Ugly.
s
On 7/6/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
Plus, what is wrong with passing on object to a type/class' constructor: ``str(42)``? Not redundant and it's still clean, obvious, and does not require new syntax.
And you can already have multiple 'constructor-from-data' methods that way, like d
Guido van Rossum wrote:
> The
> combination of the first and second suggests a functional programming
> mindset which somehow makes the third less likely.
You seem to be conflating "nested functions" and
"functional programming", which doesn't make sense
to me.
> Your suggestion also makes it ha
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>>The
>>combination of the first and second suggests a functional programming
>>mindset which somehow makes the third less likely.
>
> You seem to be conflating "nested functions" and
> "functional programming", which doesn't make sense
> to me.
>
>>
Ka-Ping Yee wrote:
> On Wed, 5 Jul 2006, Guido van Rossum wrote:
>> So, my proposal is to give up on static, accept PEP 3103 with the
>> following options:
>> - Syntax alternative 2+B (unindented cases, 'case in ...' for
>> multiple cases).
>> - Semantics option 3 (def-time freezing)
>>
>>
On Wed, 5 Jul 2006, Guido van Rossum wrote:
> So, my proposal is to give up on static, accept PEP 3103 with the
> following options:
> - Syntax alternative 2+B (unindented cases, 'case in ...' for
> multiple cases).
> - Semantics option 3 (def-time freezing)
>
> Do we need any more discussi
[EMAIL PROTECTED] wrote:
> (If you look up "modular" at dictionary.com you will
> see the first definition is exactly what we are trying to say..
> 'Of, relating to, or based on a module...")
I'd say that dictionary is wrong. I've only ever
seen "modular" used to mean "organised in the form
of mo
Hm... I'd rather not break my head over this right now. I've got a
feeling that we have bigger fish to fry, and I'd like to focus on
important things first. I'm also not convinced this is all that
broken.
--Guido
On 7/6/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> as you may remember, i suggest
On 7/7/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Ka-Ping Yee wrote:
> > On Wed, 5 Jul 2006, Guido van Rossum wrote:
> >> So, my proposal is to give up on static, accept PEP 3103 with the
> >> following options:
> >> - Syntax alternative 2+B (unindented cases, 'case in ...' for
> >> multip
i had this idea -- since quoted literals can be prefixed by a letter
that alters their meaning, why not use the same semantics
with curly braces?
"hello" -- byte string literal
r"hello" -- unescaped byte string literal
u"hello" -- unicode string literal
{1:2, 3:4, 5:6} -- dict literal
s{1, 2, 3}
> i had this idea -- since quoted literals can be prefixed by a letter
> that alters their meaning, why not use the same semantics
> with curly braces?
String literals are always strings, no matter what kind of string as
defined by the prefix. On the other hand, dictionaries and sets seems
differe
str and unicode are *distinct* types. they may be related, but not in
the sense that type("hello") and type(r"hello") both return str.
moreover, you can say a set is a "kind of" a keys-only dict. in fact,
the first implementation of set used a dict, where the keys where the
elements of the set, an
-1.
On 7/7/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> i had this idea -- since quoted literals can be prefixed by a letter
> that alters their meaning, why not use the same semantics
> with curly braces?
>
> "hello" -- byte string literal
> r"hello" -- unescaped byte string literal
> u"hello" -
On 7/7/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > The
> > combination of the first and second suggests a functional programming
> > mindset which somehow makes the third less likely.
>
> You seem to be conflating "nested functions" and
> "functional programming", whic
On 7/7/06, Talin <[EMAIL PROTECTED]> wrote:
> I'm in agreement with Greg here - his version sounds easier to
> understand, with less hidden gotchas. I would rather have "it always
> works with the same semantics, but some cases are slower than others",
> than "it only works in some cases".
I think
15 matches
Mail list logo
