Jorgen Grahn wrote:
> I reuse names though, mostly because I don't want to invent additional
> names which would feel "overburdened". I like this example better:
>
>months = range(1, 13)
># do something with the months-as-numbers list,
># and then:
>months = [ monthname(x) for x
On Fri, 01 Aug 2008 22:47:04 -0400, Mel <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
>> I'm writing Python as if it were strongly typed, never recycling a
>> name to hold a type other than the original type.
>>
>> Is this good software engineering practice, or am I missing something
>>
On Fri, Aug 01, 2008 at 03:57:10PM +, Alan Franzoni wrote:
> [EMAIL PROTECTED] was kind enough to say:
>
> > I'm writing Python as if it were strongly typed, never recycling a
> > name to hold a type other than the original type.
[...]
> Python *is* strongly typed.
That's debatable. It depen
[EMAIL PROTECTED] schrieb:
I'm writing Python as if it were strongly typed, never recycling a
name to hold a type other than the original type.
Is this good software engineering practice, or am I missing something
Pythonic?
Others pointed out the wrong wording.
As often, this is not a questio
On Fri, 01 Aug 2008 22:47:04 -0400
Mel <[EMAIL PROTECTED]> wrote:
> middle_name = raw_input ('Name?')
> middle_name = middle_name.split()
> middle_name = middle_name[1]
>
> It works, but I don't like it enough to actually use it.
Especially since this works better anyway:
middle_name = raw_input
[EMAIL PROTECTED] wrote:
> I'm writing Python as if it were strongly typed, never recycling a
> name to hold a type other than the original type.
>
> Is this good software engineering practice, or am I missing something
> Pythonic?
Nothing wrong with what you're doing. I've never come up with a
[EMAIL PROTECTED] wrote:
I'm writing Python as if it were strongly typed, never recycling a
name to hold a type other than the original type.
Names are bound to objects with types.
Is this good software engineering practice,
If you expand 'type' to 'category', then yes.
or am I missing
On Aug 1, 8:31 am, [EMAIL PROTECTED] wrote:
> I'm writing Python as if it were strongly typed, never recycling a
> name to hold a type other than the original type.
>
> Is this good software engineering practice, or am I missing something
> Pythonic?
Reusing names for no reason can make debugging
On Aug 1, 11:31 am, [EMAIL PROTECTED] wrote:
> I'm writing Python as if it were strongly typed, never recycling a
> name to hold a type other than the original type.
>
> Is this good software engineering practice, or am I missing something
> Pythonic?
I don't think you should go about gratuitously
[EMAIL PROTECTED] schrieb:
I'm writing Python as if it were strongly typed, never recycling a
name to hold a type other than the original type.
If it buys you anything? Maybe for shedskin or some future
"to-native-code" compiler?
Is this good software engineering practice, or am I missing som
Le Friday 01 August 2008 17:31:25 [EMAIL PROTECTED], vous avez écrit :
> I'm writing Python as if it were strongly typed, never recycling a
> name to hold a type other than the original type.
>
> Is this good software engineering practice, or am I missing something
> Pythonic?
As already stated by
[EMAIL PROTECTED] was kind enough to say:
> I'm writing Python as if it were strongly typed, never recycling a
> name to hold a type other than the original type.
>
> Is this good software engineering practice, or am I missing something
> Pythonic?
Python *is* strongly typed.
You're talking abo
On Aug 1, 5:31 pm, [EMAIL PROTECTED] wrote:
> I'm writing Python as if it were strongly typed, never recycling a
> name to hold a type other than the original type.
>
> Is this good software engineering practice, or am I missing something
> Pythonic?
I'm not sure you've got the terminology 100% ri
I'm writing Python as if it were strongly typed, never recycling a
name to hold a type other than the original type.
Is this good software engineering practice, or am I missing something
Pythonic?
--
http://mail.python.org/mailman/listinfo/python-list
14 matches
Mail list logo