On Mon, 23 Jul 2018 14:39:56 +0300, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> Lambda calculus has the concept of a binding operator, which is
>> effectively an assignment operator: it takes a variable and a value and
>> binds the value to the variable, changing a free variable to a bound
>>
On Mon, Jul 23, 2018 at 9:39 PM, Steven D'Aprano
wrote:
> [1] The CPython interpreter uses pointers; the Jython interpreter uses
> whatever kind of memory indirection the JVM provides; when I emulate a
> Python interpreter using pencil and paper, there's not a pointer in sight
> but a lot of copyi
On Mon, 23 Jul 2018 09:22:55 +0300, Marko Rauhamaa wrote:
> Dennis Lee Bieber :
[...]
>> In my world, Java and Python are the ones that are not "common".
>
> Yes, "boxed" is a Java term. However, the programming pattern of using
> dynamic memory and pointers is ubiquitous and ancient:
Not t
Steven D'Aprano :
> Lambda calculus has the concept of a binding operator, which is
> effectively an assignment operator: it takes a variable and a value
> and binds the value to the variable, changing a free variable to a
> bound variable. In other words, it assigns the value to the variable,
> j
On Mon, 23 Jul 2018 11:49:37 +0300, Marko Rauhamaa wrote:
> People new to Python are unnecessarily confused by talking about names
> and binding when it's really just ordinary variables and assignment.
It really isn't, not to those people who expect ordinary variables and
assignment to be the sa
Mark Lawrence writes:
> On 22/07/18 14:51, Abdur-Rahmaan Janhangeer wrote:
>> except local vars
>>
>> Abdur-Rahmaan Janhangeer
>> https://github.com/Abdur-rahmaanJ
>> Mauritius
>>
>
> Python doesn't have variables, it has names.
I think we should cut beginners (and probably everyone) some slack
On Mon, 23 Jul 2018 20:24:30 +1200, Gregory Ewing wrote:
> Steven D'Aprano wrote:
>> So let me see if I understand your argument...
>>
>> - we should stop using the term "binding", because it means
>> nothing different from assignment;
>> - binding (a.k.a. "assignment") comes from lambda calcul
"Marko Rauhamaa" wrote in message news:87zhyitjz2@elektro.pacujo.net...
People new to Python are unnecessarily confused by talking about names
and binding when it's really just ordinary variables and assignment. It
seems to be mostly some sort of marketing lingo that seeks to create an
air
Ben Finney :
> Gregory Ewing writes:
>
>> Marko is asking us to stop using the word "binding" to refer to
>> assignment because of the potential confusion with this other meaning.
>
> That's about as reasonable as my request that we stop using the term
> “variable” for what is, in Python, an un-ty
Gregory Ewing writes:
> Marko is asking us to stop using the word "binding" to refer to
> assignment because of the potential confusion with this other meaning.
That's about as reasonable as my request that we stop using the term
“variable” for what is, in Python, an un-typed reference to an obj
Steven D'Aprano wrote:
So let me see if I understand your argument...
- we should stop using the term "binding", because it means
nothing different from assignment;
- binding (a.k.a. "assignment") comes from lambda calculus;
- which has no assignment (a.k.a. "binding").
No, that's not what
Dennis Lee Bieber :
> On Mon, 23 Jul 2018 00:08:00 +0300, Marko Rauhamaa
> declaimed the following:
>
>>I Java terms, all Python values are boxed. That's a very usual pattern
>>in virtually all programming languages (apart from FORTRAN).
>
> FORTRAN, C, COBOL, BASIC, Pascal, ALGOL, BCPL, REX
variables here refers to the user experience of a var
np, just a link to the thread/s would mark the end of it
Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
Mauritius
--
https://mail.python.org/mailman/listinfo/python-list
On 22/07/18 14:51, Abdur-Rahmaan Janhangeer wrote:
except local vars
Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
Mauritius
Python doesn't have variables, it has names. Please can we avoid a long
meaningless thread on this subject as it's been discussed a trillion
times befor
On Sun, 22 Jul 2018 17:50:06 -0400, Dennis Lee Bieber wrote:
> On Mon, 23 Jul 2018 00:08:00 +0300, Marko Rauhamaa
> declaimed the following:
>
>>I Java terms, all Python values are boxed. That's a very usual pattern
>>in virtually all programming languages (apart from FORTRAN).
>>
>>
> FOR
On Mon, 23 Jul 2018 00:08:00 +0300, Marko Rauhamaa wrote:
> Would you call it binding in this case:
>
>X[0]["z"] = getit()
>X[3]["q"] = X[0]["z"]
>X[0]["z"].changeit()
It is a binding, but it is not a *name* binding. Since we are talking
about name bindings, and comparing/contrastin
On Sun, 22 Jul 2018 22:50:52 +0300, Marko Rauhamaa wrote:
> I wish people stopped talking about "name binding" and "rebinding,"
> which are simply posh synonyms for variable assignment. Properly, the
> term "binding" comes from lambda calculus, whose semantics is defined
> using "bound" and "free"
Richard Damon :
>> On Jul 22, 2018, at 3:50 PM, Marko Rauhamaa wrote:
>> I wish people stopped talking about "name binding" and "rebinding,"
>> which are simply posh synonyms for variable assignment. Properly, the
>> term "binding" comes from lambda calculus, whose semantics is defined
>> using "
On Mon, Jul 23, 2018 at 6:14 AM, Marko Rauhamaa wrote:
> While FORTRAN or C couldn't operate on functions like this, an assembly
> language program could easily. Simply compose a CPU instruction sequence
> on the fly, mark it executable and use the "CALL" opcode to transfer
> control to your const
Bart :
> If you did need one of those others to be variable, then you just assign
> it to a variable the rare times you need to do that. For example:
>
> def fn1(): pass
> def fn2(): pass
>
> fn = fn1 if cond else fn2
>
> fn1, fn2 will always be functions. fn will always be a variable, but on
> On Jul 22, 2018, at 3:50 PM, Marko Rauhamaa wrote:
> I wish people stopped talking about "name binding" and "rebinding,"
> which are simply posh synonyms for variable assignment. Properly, the
> term "binding" comes from lambda calculus, whose semantics is defined
> using "bound" and "free" var
r...@zedat.fu-berlin.de (Stefan Ram):
>>Rebinding names is near-universal in programming, but usually names
>>that are intended to be rebound, such as variables.
>
> To someone like me who has grown up with a LISP 1
> this is completely natural.
>
> |>( SETQ A ( LAMBDA () 'ALPHA ))
> |(LAMBDA (
On 2018-07-22 09:36:13 -0400, Richard Damon wrote:
> > On Jul 22, 2018, at 8:48 AM, Sharan Basappa
> > wrote:
> >
> > In other programming languages (e.g. C, C++), as a good practice,
> > variables are declared right at the start of the program,
There is no "start of the program" in C or C++. I
except local vars
Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
Mauritius
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, Jul 22, 2018 at 10:48 PM, Sharan Basappa
wrote:
> In other programming languages (e.g. C, C++), as a good practice, variables
> are declared right at the start of the program, irrespective of where it is
> normally used. What is the practice in Python?
>
> I see that, most of the code, d
> On Jul 22, 2018, at 8:48 AM, Sharan Basappa wrote:
>
> In other programming languages (e.g. C, C++), as a good practice, variables
> are declared right at the start of the program, irrespective of where it is
> normally used. What is the practice in Python?
>
> I see that, most of the code
On 28/10/17 19:42, Στέφανος Σωφρονίου wrote:
Greetings everyone.
I have noticed that in many if conditions the following syntax is used:
a) if (variable == NULL) { ... }
b) if (variable == -1) { ... }
c) if (variable != NULL) { ... }
What I wanted to ask is, is there a particular reason for no
On Monday, October 30, 2017 at 2:35:13 AM UTC+2, ROGER GRAYDON CHRISTMAN wrote:
> NOTE: The case in question was never comparing to True; it was comparing to
> NULL.
>
> There is no "No: if x == None" below, because None is not Boolean.
> Similarly comparing a pointer to NULL is not the same as
NOTE: The case in question was never comparing to True; it was comparing to
NULL.
There is no "No: if x == None" below, because None is not Boolean.
Similarly comparing a pointer to NULL is not the same as comparing it to a
Boolean.
So I would favor the "Explicit is better than Implicit" in th
On Mon, Oct 30, 2017 at 12:47 AM, Stefan Ram wrote:
> =?UTF-8?B?zqPPhM6tz4bOsc69zr/PgiDOo8+Jz4bPgc6/zr3Or86/z4U=?=
> writes:
>>I guess the following parts from "Zen of Python" apply to this case:
>
> If we would agree to apply Python rules to C,
> then we could also use this excerpt from PEP
On Sunday, October 29, 2017 at 4:00:59 AM UTC-5, Στέφανος Σωφρονίου wrote:
[...]
> I guess the following parts from "Zen of Python" apply to this case:
>
> - Beautiful is better than ugly.
> - Explicit is better than implicit.
> - Simple is better than complex.
> - Readability counts.
Now go
On Sunday, October 29, 2017 at 4:18:38 AM UTC+2, Dan Sommers wrote:
> On Sat, 28 Oct 2017 16:20:54 -0700, Στέφανος Σωφρονίου wrote:
>
> > I do believe though that if (!d) is a lot clearer than if (d == NULL)
> > as it is safer than falsely assigning NULL in d, by pure mistake.
>
> Having made my
On Sat, 28 Oct 2017 16:20:54 -0700, Στέφανος Σωφρονίου wrote:
> I do believe though that if (!d) is a lot clearer than if (d == NULL)
> as it is safer than falsely assigning NULL in d, by pure mistake.
Having made my living writing C code for a very long time, I always
found if (!d) *harder* to r
On Saturday, October 28, 2017 at 9:54:30 PM UTC+3, bartc wrote:
> On 28/10/2017 19:42, Στέφανος Σωφρονίου wrote:
> > Greetings everyone.
> >
> > I have noticed that in many if conditions the following syntax is used:
> >
> > a) if (variable == NULL) { ... }
> > b) if (variable == -1) { ... }
> >
On 10/28/17 4:26 PM, Stefan Ram wrote:
Ned Batchelder writes:
On 10/28/17 3:00 PM, Stefan Ram wrote:
=?UTF-8?B?zqPPhM6tz4bOsc69zr/PgiDOo8+Jz4bPgc6/zr3Or86/z4U=?=
writes:
What I wanted to ask is, is there a particular reason for not choosing
definition of »NULL«. »NULL« is not part of the
On 10/28/17 3:00 PM, Stefan Ram wrote:
=?UTF-8?B?zqPPhM6tz4bOsc69zr/PgiDOo8+Jz4bPgc6/zr3Or86/z4U=?=
writes:
What I wanted to ask is, is there a particular reason for not choosing
I am not a CPython developer, but here are my 2 cents about
the possibilities:
if (variable == NULL) { ...
On Sun, Oct 29, 2017 at 5:42 AM, Στέφανος Σωφρονίου
wrote:
> Greetings everyone.
>
> I have noticed that in many if conditions the following syntax is used:
>
> a) if (variable == NULL) { ... }
> b) if (variable == -1) { ... }
> c) if (variable != NULL) { ... }
>
> What I wanted to ask is, is ther
On 28/10/2017 19:42, Στέφανος Σωφρονίου wrote:
Greetings everyone.
I have noticed that in many if conditions the following syntax is used:
a) if (variable == NULL) { ... }
b) if (variable == -1) { ... }
c) if (variable != NULL) { ... }
What I wanted to ask is, is there a particular reason for
I'm glad I asked :)
Thanks all who posted for your replies, the else-statement is a nice
option.
Python again comes through to deal with those pesky feelings that
something could be better :)
Ross.
Chris Rebert wrote:
Yes. try-except-*else*.
try:
do_something_1()
do_something
RGK wrote:
> Any input appreciated :)
How about:
import logging
try:
# run your function
some_function()
except Exception:
# except only the exceptions you *really* want to catch
# at most you should except "Exception" since it doesn't
# catch KeyboardInterrupt and SystemExit
l
RGK wrote:
I'm still learning, so eager to see if there is some community wisdom
about use of the try/except structures in this situation
try:
do something 1
do something 2
do something 3
do something 4
...
do something 25
except:
print "Oops something didn't
Steve Holden wrote:
> RGK wrote:
>>
>> I'm still learning, so eager to see if there is some community wisdom
>> about use of the try/except structures in this situation.
>>
>> I find myself with some potentially risky stuff and wrap it in a
>> try/except structure with good functional results, t
On Wed, Feb 25, 2009 at 9:36 AM, RGK wrote:
>
> I'm still learning, so eager to see if there is some community wisdom about
> use of the try/except structures in this situation.
>
> I find myself with some potentially risky stuff and wrap it in a try/except
> structure with good functional results
RGK wrote:
>
> I'm still learning, so eager to see if there is some community wisdom
> about use of the try/except structures in this situation.
>
> I find myself with some potentially risky stuff and wrap it in a
> try/except structure with good functional results, though my code leaves
> me a b
[EMAIL PROTECTED] writes:
> > To my eyes, that's less readable than, and has no benefit over,
> > the following:
> >
> > def foo(thing):
> > if thing:
> > result = thing+1
> > else:
> > result = -1
> > return result
I chose this to more clearly
> To my eyes, that's less readable than, and has no benefit over, the
> following:
>
> def foo(thing):
> if thing:
> result = thing+1
> else:
> result = -1
> return result
I wouldn't discount:
def foo(thing):
result = -1
if thing:
Pete Forman <[EMAIL PROTECTED]> writes:
> Ben Finney <[EMAIL PROTECTED]> writes:
>
> > Why not ensure that there is one return point from the function,
> > so the reader doesn't have to remind themselves to look for hidden
> > return points?
>
> There will always be more potential return points in
Ben Finney <[EMAIL PROTECTED]> writes:
> Why not ensure that there is one return point from the function, so
> the reader doesn't have to remind themselves to look for hidden
> return points?
There will always be more potential return points in languages that
support exceptions.
--
Pete Forma
"Carl Banks" <[EMAIL PROTECTED]> writes:
> Ben Finney wrote:
> > "Carl Banks" <[EMAIL PROTECTED]> writes:
> > > def foo(thing):
> > > if thing:
> > > return thing+1
> > > else:
> > > return -1
> > > assert False
> >
> > To my eyes, that's less readable than, and has no
Steve Holden wrote:
> Carl Banks wrote:
> [...]
> > However, I have rare cases where I do choose to use the else (ususally
> > in the midst of a complicated piece of logic, where it's be more
> > distracting than concise). In that case, I'd do something like this:
> >
> > def foo(thing):
> >
Ben Finney wrote:
> "Carl Banks" <[EMAIL PROTECTED]> writes:
>
> > However, I have rare cases where I do choose to use the else
> > (ususally in the midst of a complicated piece of logic, where it's
> > be more distracting than concise). In that case, I'd do something
> > like this:
> >
> > def f
Tal Einat wrote:
> I meant to say that:
>
> (thing and [thing+1] or [-1])[0]
>
> is more readable (IMO) than:
>
> thing != -1 and (thing and thing+1 or -1) or 0
Neither is particularly readable, though I agree that the latter is
worse since it has to have the third option ("0") on the end. But I'
At Wednesday 30/8/2006 04:47, Tal Einat wrote:
I meant to say that:
(thing and [thing+1] or [-1])[0]
is more readable (IMO) than:
thing != -1 and (thing and thing+1 or -1) or 0
Interesting to find how different persons feel "readability" - for
me, the later is rather clear (but definitivel
Sybren Stuvel wrote:
> Tal Einat enlightened us with:
> > Actually, the common work-around for this is:
> >
> > (thing and [thing+1] or [-1])[0]
> >
> > This works since non-empty lists are always considered true in
> > conditional context. This is more generic, and IMO more readable.
>
> I think
"Carl Banks" <[EMAIL PROTECTED]> writes:
> However, I have rare cases where I do choose to use the else
> (ususally in the midst of a complicated piece of logic, where it's
> be more distracting than concise). In that case, I'd do something
> like this:
>
> def foo(thing):
> if thing:
>
Carl Banks wrote:
[...]
> However, I have rare cases where I do choose to use the else (ususally
> in the midst of a complicated piece of logic, where it's be more
> distracting than concise). In that case, I'd do something like this:
>
> def foo(thing):
> if thing:
> return thing+1
>
tobiah wrote:
> def foo(thing):
> if thing:
> return thing + 1
> else:
> return -1
>
> def foo(thing):
> if thing:
> return thing + 1
> return -1
>
> Obviously both do the same thing. The first is
> possibly clearer, while the secon
Bruno Desthuilliers wrote:
> Sam Pointon a écrit :
> > Bruno Desthuilliers wrote:
> >
> >>foo = lambda thing: thing and thing + 1 or -1
> >
> >
> > The and ... or trick is buggy (what if thing == -1?)
>
> Yes, true - Should be:
> foo2 = lambda t: t != -1 and (t and t+1 or -1) or 0
>
Actually, the
Sam Pointon a écrit :
> Bruno Desthuilliers wrote:
>
>>foo = lambda thing: thing and thing + 1 or -1
>
>
> The and ... or trick is buggy (what if thing == -1?)
Yes, true - Should be:
foo2 = lambda t: t != -1 and (t and t+1 or -1) or 0
> and bad style.
Lol. Well, so what about:
foo = lambda
tobiah wrote:
> def foo(thing):
>
> if thing:
> return thing + 1
> else:
> return -1
>
> def foo(thing):
>
> if thing:
> return thing + 1
> return -1
>
> Obviously both do the same thing. The first is
> possibly clearer, while the s
Bruno Desthuilliers wrote:
> foo = lambda thing: thing and thing + 1 or -1
The and ... or trick is buggy (what if thing == -1?) and bad style. If
you -do- want a conditional expression, 2.5 provides one:
thing + 1 if thing else -1
No subtle logical bugs, and a good deal more obvious.
On the top
tobiah a écrit :
> def foo(thing):
>
> if thing:
> return thing + 1
> else:
> return -1
>
> def foo(thing):
>
> if thing:
> return thing + 1
> return -1
>
> Obviously both do the same thing. The first is
> possibly clearer, while the second is more conci
On 8/28/06, tobiah <[EMAIL PROTECTED]> wrote:
> def foo(thing):
>
> if thing:
> return thing + 1
> else:
> return -1
>
> def foo(thing):
>
> if thing:
> return thing + 1
> return -1
>
> Obviously both do the same thing.
On 2006-07-25 17:59:22, Antoon Pardon wrote:
>> My view is: I ask for help on a public forum. I get what I get... and if
>> I consider that someone who responded with something that's not
>> immediately helpful has a potential to help me better, I try to get in
>> a dialog and address what has bee
On 2006-07-23, Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
> On 2006-07-23 06:24:09, Antoon Pardon wrote:
>
>>> In general, I'd say that in this case the example was not well-chosen.
>>> After such a "shudder removal", a poster should IMO review what caused
>>> the shudder, and rephrase the original
On 2006-07-23 06:24:09, Antoon Pardon wrote:
>> In general, I'd say that in this case the example was not well-chosen.
>> After such a "shudder removal", a poster should IMO review what caused
>> the shudder, and rephrase the original problem without the shudder.
>
> The shudder is not with the p
On 2006-07-21, Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
> On 2006-07-21 09:00:43, Antoon Pardon wrote:
>
>> So we have code with certain shudder characteristics. And instead
>> of trying to help the OP with his problem, some people react
>> to the shudder and come with all sort of comments that m
On 2006-07-21, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On 21 Jul 2006 12:00:43 GMT, Antoon Pardon <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>> So we have code with certain shudder characteristics. And instead
>> of trying to help the OP with his problem, some peopl
Lawrence D'Oliveiro a écrit :
> In message <[EMAIL PROTECTED]>, Georg Brandl wrote:
>
>
(snip)
>>Other than in PHP, Python has clear rules when an object of a builtin type
>>is considered false (i.e. when it's empty). So why not take advantage of
>>this?
>
> Because the clearest rule of all is
On 2006-07-21 09:00:43, Antoon Pardon wrote:
> So we have code with certain shudder characteristics. And instead
> of trying to help the OP with his problem, some people react
> to the shudder and come with all sort of comments that might be
> true if the code as shown was production code, but whi
On 2006-07-20, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On 20 Jul 2006 08:50:44 GMT, Antoon Pardon <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>>
>> Suppose I have the following kind of code:
>>
>> while True:
>> try:
>> if len(result) > 0:
>> foo()
>>
In article <[EMAIL PROTECTED]>,
Antoon Pardon <[EMAIL PROTECTED]> wrote:
> On 2006-07-19, Donn Cave <[EMAIL PROTECTED]> wrote:
...
> > http://groups.google.com/group/comp.lang.python/msg/2de5e1c8384c0360
> >
> > It's lengthy but very readable, and for me it has that quality of
> > exposition where
Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Bruno Desthuilliers
> wrote:
>
>
>>Lawrence D'Oliveiro wrote:
>>
>>>In message <[EMAIL PROTECTED]>, Bob Greschke
>>>wrote:
>>>
>>>
>>>
I'd go even one step further. Turn it into English (or your favorite
non-computer language):
On 2006-07-19, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On 19 Jul 2006 12:27:39 GMT, Antoon Pardon <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>
>>
>> I once had a producer consumer code. When the client asked whether new
>> items were available the function could re
On 2006-07-19, Donn Cave <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Lawrence D'Oliveiro wrote:
>
>> > One of my rules is, always program like the language actually has a Boolean
>> > type, even if it doesn't. That means, never assume t
On 2006-07-19, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>>> Other than in PHP, Python has clear rules when an object of a builtin type
>>> is considered false (i.e. when it's empty). So why not take advantage of
>>> this?
>>
>> Because it doesn't always do what I want.
>>
In message <[EMAIL PROTECTED]>, Georg Brandl wrote:
> Lawrence D'Oliveiro wrote:
>> In message <[EMAIL PROTECTED]>, Bob Greschke
>> wrote:
>>
>>> I'd go even one step further. Turn it into English (or your favorite
>>> non-computer language):
>>>
>>> 1. While list, pop.
>>>
>>> 2. While the le
Terry Reedy wrote:
>
> > Carl Banks wrote:
> >> def process_values(lst):
> >> if not lst:
> >> return
> >> do_expensive_initialization_step()
> >> for item in lst:
> >> do_something_with(item)
> >> do_expensive_finalization_step()
>
> Give
In article <[EMAIL PROTECTED]>,
Georg Brandl <[EMAIL PROTECTED]> wrote:
> Lawrence D'Oliveiro wrote:
> > One of my rules is, always program like the language actually has a Boolean
> > type, even if it doesn't. That means, never assume that arbitrary values
> > can be interpreted as true or false
Patrick Maupin wrote:
> The original post did not say "this function is iterating twice over
> the same data." It only said that there might be a significant
> computational cost on an empty iterator, and wished that the code would
> somehow throw an exception to alert the programmer to this cost
Antoon Pardon wrote:
>> Other than in PHP, Python has clear rules when an object of a builtin type
>> is considered false (i.e. when it's empty). So why not take advantage of
>> this?
>
> Because it doesn't always do what I want.
>
> I once had a producer consumer code. When the client asked whe
Christophe wrote:
> > The perverse wish, expressed in the specific example, that SOME piece
> > of code SOMEWHERE should PLEASE throw an exception because some idiot
> > passed a generator expression rather than a list into a function, is
> > not apt to be well received by an audience which strive
In <[EMAIL PROTECTED]>, Boris Borcic wrote:
>> And I don't find `list(False)` to return an empty list be very obvious.
>
> What would be your choice ?
``list()`` or ``[]`` for empty lists and a `TypeError` for
``list(False)``. Just like it is right now.
Ciao,
Marc 'BlackJack' Rintsch
--
On 2006-07-19, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Lawrence D'Oliveiro wrote:
>> In message <[EMAIL PROTECTED]>, Bob Greschke wrote:
>>
>>> I'd go even one step further. Turn it into English (or your favorite
>>> non-computer language):
>>>
>>> 1. While list, pop.
>>>
>>> 2. While the len
Marc 'BlackJack' Rintsch wrote:
> In <[EMAIL PROTECTED]>, Boris Borcic wrote:
>
>> Bruno Desthuilliers wrote:
>>> empty_list = []
>>> bool(empty_list) is False
>>> => True
>> it's just a pity that the symmetric expression
>>
>> list(False) is []
>>
>> doesn't hold.
>
> You want the empty list to
Christophe wrote:
> ... you haven't beed using enouth generator expressions ...
You should get yourself to the doctors about that cold dude. :-)
--
http://mail.python.org/mailman/listinfo/python-list
In <[EMAIL PROTECTED]>, Boris Borcic wrote:
> Bruno Desthuilliers wrote:
>>
>> empty_list = []
>> bool(empty_list) is False
>> => True
>
> it's just a pity that the symmetric expression
>
> list(False) is []
>
> doesn't hold.
You want the empty list to be a singleton!? And I don't find
`list
Patrick Maupin a écrit :
> The perverse wish, expressed in the specific example, that SOME piece
> of code SOMEWHERE should PLEASE throw an exception because some idiot
> passed a generator expression rather than a list into a function, is
> not apt to be well received by an audience which strives
Bruno Desthuilliers wrote:
>
> empty_list = []
> bool(empty_list) is False
> => True
it's just a pity that the symmetric expression
list(False) is []
doesn't hold.
I guess the problem is that if list(False) was thus defined, it would be
difficult not to define list(True). And then the zen of
PTY wrote:
> Which is better?
>
> lst = [1,2,3,4,5]
>
> while lst:
> lst.pop()
>
> OR
>
> while len(lst) > 0:
> lst.pop()
>
allways that either-or stuff ! And why did you not consider
while len(lst) : list.pop()
a neat middle ground, wouldn't you say ?
Cheers, BB
--
666 ?? - 666 ~ .666
Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Bob Greschke wrote:
>
>> I'd go even one step further. Turn it into English (or your favorite
>> non-computer language):
>>
>> 1. While list, pop.
>>
>> 2. While the length of the list is greater than 0, pop.
>>
>> Which one makes mo
In message <[EMAIL PROTECTED]>, Bruno Desthuilliers
wrote:
> Lawrence D'Oliveiro wrote:
>> In message <[EMAIL PROTECTED]>, Bob Greschke
>> wrote:
>>
>>
>>>I'd go even one step further. Turn it into English (or your favorite
>>>non-computer language):
>>>
>>>1. While list, pop.
>>>
>>>2. While t
Jorge Godoy wrote:
> "Carl Banks" <[EMAIL PROTECTED]> writes:
>
> > Well, I certainly can agree with that, except for the last point. :) I
> > certainly wouldn't want to keep that unfortunate behavior around just I
> > have something to use as an argument using len to test emptiness.
>
> On the o
"Patrick Maupin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Carl Banks wrote:
>> def process_values(lst):
>> if not lst:
>> return
>> do_expensive_initialization_step()
>> for item in lst:
>> do_something_with(item)
>>
"Carl Banks" <[EMAIL PROTECTED]> writes:
> Well, I certainly can agree with that, except for the last point. :) I
> certainly wouldn't want to keep that unfortunate behavior around just I
> have something to use as an argument using len to test emptiness.
On the other hand, having this behavior
Bruno Desthuilliers wrote:
> Carl Banks a écrit :
> > Bruno Desthuilliers wrote:
> >
> >>There are less risk of a typo with "if a:" than with "if len(a) > 0".
> >
> >
> > So, it's more important to protect against typos than subtle bugs?
> >
>
> People making smart points are really annoying... !-
Carl Banks a écrit :
> Bruno Desthuilliers wrote:
>
>>There are less risk of a typo with "if a:" than with "if len(a) > 0".
>
>
> So, it's more important to protect against typos than subtle bugs?
>
People making smart points are really annoying... !-)
wrt/ to the "subtle bug" point, MHO is t
Bruno Desthuilliers wrote:
> There are less risk of a typo with "if a:" than with "if len(a) > 0".
So, it's more important to protect against typos than subtle bugs?
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Bruno Desthuilliers wrote:
> "Irrelevant" may not be the best expression of my thought here - it's
> just that Carl's assertion is kind of a tautology and doesn't add
> anything to the discussion. If Python had been designed as statically
> typed (with declarative typing), the rules would be differ
Volker Grabsch a écrit :
> Bruno Desthuilliers <[EMAIL PROTECTED]> schrieb:
>
>>Carl Banks wrote:
>>
>>>Bruno Desthuilliers wrote:
>>>
>>>I'm well aware of Python's semantics, and it's irrelvant to my
>>>argument.
>
> [...]
>
>>>If the language
>>>were designed differently, then the rules would
1 - 100 of 165 matches
Mail list logo
