Re: coding style - where to declare variables

[Steven D'Aprano]

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
>> variable. In other words, it assigns the value to the variable, just
>> like assignment does.
> 
> In traditional Lambda Calculus semantics, there are no values at all.

It is more common to say "pure lambda calculus" rather than 
"traditional", and it is not correct to say there are no values at all. 
Rather, all values are functions (and all functions are values).

http://scienceblogs.com/goodmath/2006/08/29/a-lambda-calculus-rerun-1/

and:

"As this suggests, functions are just ordinary values, and can
be the results of functions or passed as arguments to functions
(even to themselves!).  Thus, in the lambda calculus, functions are
first-class values.  Lambda terms serve both as functions and data."

http://www.cs.cornell.edu/courses/cs6110/2013sp/lectures/lec02-sp13.pdf

And from the same notes:

"So, what is a value?  In the pure lambda calculus, any abstraction
is a value.  Remember, an abstraction λx:e is a function; in the
pure lambda calculus, the only values are functions. In an applied
lambda calculus with integers and arithmetic operations, values
also include integers.  Intuitively, a value is an expression
that can not be reduced/executed/simplified any further."



[...]
> The lambda calculus comment is just an aside. The main point is that you
> shouldn't lead people to believe that Python has variables that are any
> different than, say, Pascal's variables (even if you, for whatever
> reason, want to call them "names"). They are memory slots that hold
> values until you assign new values to them.

Nevertheless, they are still different.

My computer has an ethernet slot and a USB slot, and while they are both 
slots that hold a cable and transmit information in and out of the 
computer, they are nevertheless different. The differences are just as 
important as the similarities.


> It *is* true that Python has a more limited data model than Pascal (all
> of Python's values are objects in the heap and only accessible through
> pointers).

Calling it "more limited" is an inaccurate and pejorative way of putting 
it. Rather, I would say it is a more minimalist, *elegant* data model:

* a single kind of variable (objects in the heap where the interpreter
  manages the lifetime of objects for you)

as opposed to Pascal's more complex and more difficult model:

* two kinds of variables:

  - first-class variables that the compiler manages for you 
(allocating and deallocating them on the stack)

  - second-class variables that the programmer has to manage
manually (declaring pointers, allocating memory by hand,
tracking the lifetime of the memory block yourself,
deallocating it when you are done, and carefully avoiding
accessing the pointed-to memory block after deallocation).


At least more modern languages with both value-types and reference-types 
(such as Java, C#, Objective C, Swift) manage to elevate their reference-
type variables to first-class citizenship.


> Also, unlike Pascal, variables can hold (pointers to) values
> of any type. IOW, Python has the data model of Lisp.
> 
> Lisp talks about binding and rebinding variables as well:
> 
>https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node79.html>
> 
> which might be Lambda Calculus legacy, but at least they are not shy to
> talk about variables and assignment.




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Chris Angelico]

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 copying of values and crossing them out. ("Copy on access"
> perhaps?) A Python interpreter emulated by a Turing machine would use
> dots on a long paper tape, and an analog computer emulating Python would
> use I-have-no-idea. Clockwork? Hydraulics?

I've been known to implement a linked list using a deck of cards, with
tetrapod "one teaspoon of sugar" packets for the Next markers, and
pens for externally-accessible references (the head of the list, the
current node, etc). This therefore proves that a pointer IS a teaspoon
of sugar, and vice versa.

Would you like your tea with one pointer or two?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Steven D'Aprano]

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 that ancient -- the first version(s) of Fortran didn't have dynamic 
memory allocation or pointers. (Admittedly, Lisp did follow not long 
afterwards.) But it is certainly not ubiquitous: many languages don't 
have pointers at all.


> FILE *f = fopen("xyz", "r");
> 
> where f holds a pointer, fopen() returns a pointer, and "xyz" and "r"
> evaluate to pointer values.
> 
> In Python, every expression evaluates to a pointer and every variable
> holds a pointer.

Within the semantics of the Python language, there are no pointer values, 
no way to get a pointer to a memory location or a pointer to an object. 
No expression in Python evaluates to a pointer, no variables hold 
pointers in Python. The Python language is defined in terms of objects: 
expressions evaluate to objects, and variables are names bound to objects.

If you don't believe me, believe the interpreter:

# Marko expects a pointer, but unfortunately he gets an int
py> type(1 + 2) 


Marko is making a similar category error as those who insist that Python 
uses "call by reference" or "call by value" for parameter passing. He 
mistakes an irrelevant implementation detail used by *some* but not all 
Python interpreters[1] for entities which exist in the Python computation 
model. As Fredrick puts it:

"Joe, I think our son might be lost in the woods"
"Don't worry, I have his social security number"

http://effbot.org/zone/call-by-object.htm

(The *pointer to an object* used in the implementation is not the same as 
the object itself.)

Evaluating 1 + 2 gives the value (an object) 3, not a pointer to the 
value 3. Pointers are not merely "not first-class citizens" of Python, 
they aren't citizens at all: there is nothing we can do in pure Python to 
get hold of pointers, manipulate pointers, or dereference pointers.

https://en.wikipedia.org/wiki/First-class_citizen

Pointers are merely one convenient, useful mechanism to implement 
Python's model of computation in an efficient manner on a digital 
computer. They are not part of the computation model, and pointers are 
not values available to the Python programmer[2].







[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 copying of values and crossing them out. ("Copy on access" 
perhaps?) A Python interpreter emulated by a Turing machine would use 
dots on a long paper tape, and an analog computer emulating Python would 
use I-have-no-idea. Clockwork? Hydraulics?

https://en.wikipedia.org/wiki/MONIAC
https://makezine.com/2012/01/24/early-russian-hydraulic-computer/


[2] Except by dropping into ctypes or some other interface to the 
implementation, and even then the pointers have to be converted to and 
from int objects as they cross the boundary between the Python realm and 
the implementation realm.




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Marko Rauhamaa]

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,
> just like assignment does.

In traditional Lambda Calculus semantics, there are no values at all.
There are only well-formatted formulas and syntactic transformation
rules. You could view it as a macro preprocessing system where you keep
transforming the formula until no transformation rule applies.

Yes, λ can be viewed as a binding operator although classically, it is
simply a dead symbol just like '(', '.' and 'z'.

> Especially in this case. Anyone who understands lambda calculus is
> unlikely to be confused by Python using the same terms to mean
> something *almost identical* to what they mean in lambda calculus.
> (The only difference I can see is that lambda calculus treats
> variables as abstract mathematical entities, while Python and other
> programming languages vivify them and give them a concrete
> implementation.)
>
> If one in ten thousand programmers are even aware of the existence of
> lambda calculus, I would be surprised. To give up using perfectly
> good, accurate terminology in favour of worse, less accurate
> terminology in order to avoid unlikely and transient confusion among a
> minuscule subset of programmers seems a poor tradeoff to me.

The lambda calculus comment is just an aside. The main point is that
you shouldn't lead people to believe that Python has variables that are
any different than, say, Pascal's variables (even if you, for whatever
reason, want to call them "names"). They are memory slots that hold
values until you assign new values to them.

It *is* true that Python has a more limited data model than Pascal (all
of Python's values are objects in the heap and only accessible through
pointers). Also, unlike Pascal, variables can hold (pointers to) values
of any type. IOW, Python has the data model of Lisp.

Lisp talks about binding and rebinding variables as well:

   https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node79.html>

which might be Lambda Calculus legacy, but at least they are not shy to
talk about variables and assignment.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Steven D'Aprano]

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 same as that of C, C++, C#, Objective C, Swift, 
Pascal, Java, Go etc.

There are at least two common models for the association between symbolic 
names and values in programming: 

1. variables are named boxes at a statically-allocated, fixed 
   location in memory, usually on the stack ("value types");

2. variables are names that refer to dynamically-allocated
   objects in the heap, often movable ("reference types").

It is absolutely true that both are "variables" of a kind, and that "name 
binding" is abstract enough to refer to both models. But in *practice*, 
the influence of Algol, C and BASIC especially is so great that many 
people think of variables and assignment exclusively in the first sense. 
Since Python uses the second sense, having a distinct name to contrast 
the two is desirable, and "name binding" seems to fit that need.

I no longer believe that we should actively avoid the word "variable" 
when referring to Python. I think that's an extreme position which isn't 
justified. But "name binding" is an accurate technical term and not that 
hard to understand (on a scale of 0 to "monad", it's about 1) and I think 
it is elitist to claim that "people new to Python"[1] will necessarily be 
confused and we therefore ought to avoid the term.

There are lots of confusing terms and concepts in Python. People learn 
them. Name binding is no different.






[1] What, all of them? Even those with a comp sci PhD and 40 years 
programming experience in two dozen different languages?


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Ben Bacarisse]

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 about
this.  I don't know if work is underway to purge the term from the
Python documentation, but until that is done people can be forgiven for
thinking that the term is acceptable.

For example, https://docs.python.org/3/tutorial/classes.html says

  "The global statement can be used to indicate that particular
  variables live in the global scope and should be rebound there; the
  nonlocal statement indicates that particular variables live in an
  enclosing scope and should be rebound there."

and https://www.python.org/dev/peps/pep-0526/ is titled "Syntax for
Variable Annotations".  It describes:

  "This PEP aims at adding syntax to Python for annotating the types of
  variables (including class variables and instance variables), instead
  of expressing them through comments"

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Steven D'Aprano]

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 calculus;
>> - which has no assignment (a.k.a. "binding").
> 
> No, that's not what Marko is saying at all. He's pointing out that the
> term "binding" means something completely different in lambda calculus.

Well done in reading Marko's intent. Unfortunately, I'm not as good as 
inferring meaning as you seem to be, consequently I had to judge by what 
he wrote, not what he meant.

When a writer fails to communicate their intent, that's usually the 
failure of the writer, not the reader. We aren't mind-readers and writers 
should not blame the reader when they fail to communicate their intended 
meaning.


> The terms "bound variable" and "free variable" in lambda calculus mean
> what in Python we would call a "local variable" vs. a "non-local
> variable".

Actually, no, they are called "bound variable" and "free variable" in 
Python too.

https://docs.python.org/3/reference/executionmodel.html

See also: http://effbot.org/zone/closure.htm

Alas, I don't think Fredrik Lundh got it *quite* right. I think that 
globals (and builtins) in Python are "open free variables", as opposed to 
nonlocals which are closed. And sadly, the Python glossary currently 
doesn't define free variables nor bound variables, or even name binding.


> They have nothing to do with assignment at all.

That's not quite correct either.

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, just like 
assignment does.

In Python terms, = is a binary binding operator: it takes a left hand 
operand, the variable (a name, for the sake of simplicity) and a right 
hand operand (a value) and binds the value to the name.

 
> Marko is asking us to stop using the word "binding" to refer to
> assignment because of the potential confusion with this other meaning.

Marko has some idiosyncratic beliefs about Python (and apparently other 
languages as well) that are difficult to justify.

Especially in this case. Anyone who understands lambda calculus is 
unlikely to be confused by Python using the same terms to mean something 
*almost identical* to what they mean in lambda calculus. (The only 
difference I can see is that lambda calculus treats variables as abstract 
mathematical entities, while Python and other programming languages 
vivify them and give them a concrete implementation.)

If one in ten thousand programmers are even aware of the existence of 
lambda calculus, I would be surprised. To give up using perfectly good, 
accurate terminology in favour of worse, less accurate terminology in 
order to avoid unlikely and transient confusion among a minuscule subset 
of programmers seems a poor tradeoff to me.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Frank Millman]

"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 of mystique around Python.



I don't think that is a fair comment.

I am not qualified to enter the debate itself, but as an 'outsider' I can 
offer two thoughts -


1. It seems that, whatever terminology we come up with, some other language 
will use similar terminology, but with a subtly different meaning. Newcomers 
to Python coming from that other language often get confused because they 
make certain assumptions, based on their other experience, which turn out to 
be unfounded in Python.


2. My 'aha' moment came early on when I read somewhere that Python objects 
have 3 attributes - a type, a value, and a unique id. One thing that they do 
*not* have is a name. Once I understood that, a lot of things became 
clearer.


Frank Millman


--
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Marko Rauhamaa]

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-typed reference to an object.
>
> I expect both of these requests to meet with little satisfaction.

I'm actually not asking, only wishing.

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 of mystique around Python.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[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-typed reference to an object.

I expect both of these requests to meet with little satisfaction.

-- 
 \ “We are all agreed that your theory is crazy. The question that |
  `\  divides us is whether it is crazy enough to have a chance of |
_o__)being correct.” —Niels Bohr (to Wolfgang Pauli), 1958 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Gregory Ewing]

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 Marko is saying at all. He's pointing
out that the term "binding" means something completely
different in lambda calculus.

The terms "bound variable" and "free variable" in lambda
calculus mean what in Python we would call a "local
variable" vs. a "non-local variable". They have nothing
to do with assignment at all.

Marko is asking us to stop using the word "binding" to
refer to assignment because of the potential confusion
with this other meaning.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Marko Rauhamaa]

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, REXX, VMS DCL, probably
> R, Matlab, APL.
>
>   I never encountered the term "boxed" until trying to read some of the
> O'Reilly books on Java.
>
>   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:

FILE *f = fopen("xyz", "r");

where f holds a pointer, fopen() returns a pointer, and "xyz" and "r"
evaluate to pointer values.

In Python, every expression evaluates to a pointer and every variable
holds a pointer.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Abdur-Rahmaan Janhangeer]

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

Re: coding style - where to declare variables

[Mark Lawrence]

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 before.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Steven D'Aprano]

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).
>>
>>
>   FORTRAN, C, COBOL, BASIC, Pascal, ALGOL, BCPL, REXX, VMS DCL, 
> probably R, Matlab, APL.
> 
>   I never encountered the term "boxed" until trying to read some of 
> the O'Reilly books on Java.
> 
>   In my world, Java and Python are the ones that are not "common".

Indeed. Its not just older languages from the 60s and 70s with value-type 
variables. Newer languages intended as systems languages, like Rust and 
Go, do the same.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Steven D'Aprano]

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/contrasting them to variable 
assignment in classical languages, I don't think that binding to slots in 
hash tables or arrays is relevant except to muddy the waters and make 
things more complicated than they need be.


> I think what you are talking about is more usually called "referencing."

I don't think so. Its certainly not a term I've ever heard in this 
context before.


>> With a language with more ‘classical’ variable, the assignment of Y = X
>> would normal make a copy of that object, so the value Y does not get
>> changed by X.changeit().
> 
> I Java terms, all Python values are boxed. 

Correct. 

Java mixes two different models of variable assignment: it uses classical 
C- and Pascal-like variable assignment for primitive values, and Lisp- 
and Smalltalk-like name binding for boxed values (objects), leading to 
two distinct sets of behaviour. That makes Java a good lesson in why it 
is useful to distinguish between two models of name binding.

Java is not the only language with the distinction between "value 
types" (primitive values usually stored on the stack) and "reference 
types" (usually objects stored in the heap). C# and other .Net languages 
often make that distinction:

http://net-informations.com/faq/general/valuetype-referencetype.htm

Swift is another such language.

Other languages which use primarily or exclusively value-types (i.e. the 
"variables are a named box at a fixed memory location" model) include 
Algol, Pascal, Modula-3, C, C++, C#, Objective C, D, Swift, COBOL, Forth, 
Ada, PL/I, Rust and many others.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Steven D'Aprano]

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" variables. Lambda calculus doesn't have
> assignment.

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").

Which leads us to the conclusion that lambda calculus both has and 
doesn't have binding a.k.a. assignment at the same time. Perhaps it is a 
quantum phenomenon.

Are you happy with the contradiction inherent in your statements, or 
would you prefer to reword your argument?




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Marko Rauhamaa]

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 "bound" and "free" variables. Lambda calculus doesn't have
>> assignment.
>
> Marko, I think the term binding makes sense in python due to how names
> work. In python and the following code:
>
> X = getit()
> Y = X
> X.changeit()
>
> In python, presuming getit() returns some form of object (so it has a
> changeit() member) then X and Y are bound to the same object, and
> changeit() will thus also affect the object that we see at Y.

Would you call it binding in this case:

   X[0]["z"] = getit()
   X[3]["q"] = X[0]["z"]
   X[0]["z"].changeit()

I think what you are talking about is more usually called "referencing."

> With a language with more ‘classical’ variable, the assignment of Y =
> X would normal make a copy of that object, so the value Y does not get
> changed by X.changeit().

I Java terms, all Python values are boxed. That's a very usual pattern
in virtually all programming languages (apart from FORTRAN).


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Chris Angelico]

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 constructed function.

... right up until the point where you realize that this is a massive
security vulnerability, so you get a segmentation fault (or
"protection fault" under Windows) for trying to execute a
non-executable segment.

> In the same vein, you could understand the "def" statement as a runtime
> compiler that takes the function body, compiles it into machine language
> and assigns the start address to the given variable. In fact, that would
> be a perfectly working way to implement "def." Whether it would be a
> smart thing to do is a different question. Key is, though, that "def"
> always creates a new *data* object that can be called as *executable
> code*.

Here's a simpler way to describe it:

The 'def' statement creates a function and assigns it to the name given.

Tada! No need to talk about compilers and addresses and stuff, which
are utterly irrelevant in Python.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Marko Rauhamaa]

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 one
> that can change between referring to fn1, fn2 or anything else.

In high-level programming languages, functions are ordinary values. You
can perform similar operations on functions as on integers or strings.
You can give me two functions, and I can use those two to create a
third function:

   def compose(f1, f2):
   def composition(x):
   return f1(f2(x))
   return composition

Here "compose", "composition", "f1" and "f2" are variables:

 * "compose" gets assigned when the first, outer "def" statement is
   executed,

 * "f1" and "f2" get assigned when the function held by "compose" is
   called,

 * "composition" gets assigned when the inner "def" statement is
   executed.


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 constructed function.

In the same vein, you could understand the "def" statement as a runtime
compiler that takes the function body, compiles it into machine language
and assigns the start address to the given variable. In fact, that would
be a perfectly working way to implement "def." Whether it would be a
smart thing to do is a different question. Key is, though, that "def"
always creates a new *data* object that can be called as *executable
code*.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[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 "bound" and "free" variables. Lambda calculus doesn't have
> assignment.
> 
> More about variable binding here:  https://en.wikipedia.org/wiki/Free_variables_and_bound_variables>
> 
> 
> Marko

Marko, I think the term binding makes sense in python due to how names work.
In python and the following code:

X = getit()
Y = X
X.changeit()

In python, presuming getit() returns some form of object (so it has a 
changeit() member) then X and Y are bound to the same object, and changeit() 
will thus also affect the object that we see at Y.
With a language with more ‘classical’ variable, the assignment of Y = X would 
normal make a copy of that object, so the value Y does not get changed by 
X.changeit().
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Marko Rauhamaa]

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 () 'ALPHA)

"Setq" is the dirty little secret of LISP.

Scheme marks its shameful primitives with an exclamation mark. Thus, its
assignment primitive is "set!".

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" variables. Lambda calculus doesn't have
assignment.

More about variable binding here: https://en.wikipedia.org/wiki/Free_variables_and_bound_variables>


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Peter J. Holzer]

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 assume that "start of
the function" was meant since "start of the compilation unit" would mean
that all variables are global (at least within the compilation unit)
which hopefully nobody considers a good practice.

> > irrespective of where it is normally used. What is the practice in
> > Python?
> > 
> > I see that, most of the code, declare variables where it is used and
> > not at the start of the program.
> 
> I would disagree that it is universally considered good practice to
> declare everything at the front. (There is much disagreement on this,
> but most consider declare at first use to be preferred, where
> possible).


> Last century, C code required this to make things easier on the
> compiler,

Nope. The language description in the German translation of K I (1984)
already shows declarations at the beginning of each block, not just each
function. The main text doesn't seem to mention this and all examples
declare variables at the start of each function, so it is possible that
this feature was added between the release of the original (1978) and
the German translation. But in any case block scope existed by 1984,
well before the turn of the century.

So the authors of C considered block scoped variables desirable
from the beginning or at least added them quite early. I would therefore
assume that they considered declaring variables in a block as good
practice.

C++ introduced the possibility to declare variables at any point in a
block, not just the beginning. C copied this in C99. Again I would argue
that Stroustrup introduced the feature because he considered declaring
variables for the smallest possible scope as good practice, and that the
C committee copied it because they agreed.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Abdur-Rahmaan Janhangeer]

except local vars

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Chris Angelico]

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, declare variables where it is used and not at 
> the start of the program.

Common practice in Python is to never declare your variables, since
Python doesn't have variable declarations.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

[Richard Damon]

> 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, declare variables where it is used and not at 
> the start of the program.

I would disagree that it is universally considered good practice to declare 
everything at the front. (There is much disagreement on this, but most consider 
declare at first use to be preferred, where possible).

Last century, C code required this to make things easier on the compiler, and 
some code bases and examples go back that far, so they use that method out of 
inertia.  
-- 
https://mail.python.org/mailman/listinfo/python-list

coding style - where to declare variables

[Sharan Basappa]

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, declare variables where it is used and not at the 
start of the program.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Coding style in CPython implementation

[Rhodri James]

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 not choosing

a) if (!variable) { ... } in place of if (variable == NULL) { ... },


"if (variable == NULL)" emphasises that "variable" is a pointer 
variable, aiding readability.



b) if (-1 == variable) { ... } in place of if (variable == -1) { ... }, and


It's just not natural English.  It's safer to write it with the constant 
first, but modern compilers will warn you about assignments in 
conditions these days, and it's not worth the reduction in readability 
in my opinion.


(Also, if you aren't using the -Werror -Wall flags to the compiler, you 
deserve everything that will be coming to you.)



c) if (variable) { ... } in place of if (variable) { ... } ?


I assume you mean "if (variable != NULL)" here.  Again, it emphasises 
the type; variable will be a pointer.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Coding style in CPython implementation

[Στέφανος Σωφρονίου]

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 comparing it to a
> Boolean.
> 
> So I would favor the "Explicit is better than Implicit" in the example cited.

Thus, my 4 Zen points are accurately interconnected:

Being simple and explicit with your code leads to elegant results that are 
indeed quite pleasant to read.


> 
> Roger Christman
> Pennsylvania State University
> 
> On Sun, Oct 29, 2017, Setfan Ram wrote: >
> =?UTF-8?B?zqPPhM6tz4bOsc69zr/PgiDOo8+Jz4bPgc6/zr3Or86/z4U=?=

> >>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 8:
> >
> >|o Don't compare boolean values to True or False using ==.
> >|
> >|Yes:   if greeting:
> >|No:if greeting == True:
> >|Worse: if greeting is True:
> >
> >

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Coding style in CPython implementation

[ROGER GRAYDON CHRISTMAN]

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 the example cited.

Roger Christman
Pennsylvania State University

On Sun, Oct 29, 2017, Setfan 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 8:
>
>|o Don't compare boolean values to True or False using ==.
>|
>|Yes:   if greeting:
>|No:if greeting == True:
>|Worse: if greeting is True:
>
>

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Coding style in CPython implementation

[Chris Angelico]

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 8:
>
> |o Don't compare boolean values to True or False using ==.
> |
> |Yes:   if greeting:
> |No:if greeting == True:
> |Worse: if greeting is True:

Or if we could agree to read PEP 7, there might be an example in
there. Granted, it might not be an explicit recommendation, merely a
tangential reference in a paragraph about braces, but it could be
indicative.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Coding style in CPython implementation

[Rick Johnson]

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 acquaint yourself with the syntactical abomination
otherwise known as Type-hints, and you will understand that
all of the aforementioned "zens" are forgotten parts of
GvR's old testament. Design guidelines born of the ideals
enshrined in a governmental contract baiting scheme slickly
marketed as "cp4e" -- which were originally encoded on punch
cards and passed to Tim Peters during secret ceremony atop
the roof of CNRI building in Reston, Virgina, on the night
of the winter solstice. Now-a-days, Python's design
philosophy is less concerned with readability and focuses
itself primarily with corporate knob-gobbling.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Coding style in CPython implementation

[Στέφανος Σωφρονίου]

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 living writing C code for a very long time, I always
> found if (!d) *harder* to read, especially if it happened to be written
> if(!d) without the space, because it was never a single character name
> the ! disappeared into the noise.

Indeed it gets harder to distinguish it after a lot of time staring at your 
source code.

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.

> OTOH, = vs. == always stuck out like
> a sore thumb.  Then again, I grew up with monochrome terminals
> vs. unusably slow syntax highlighting, and grayscale printers (and we
> had to live in a small shoebox in the middle of the road).
> 
> YMMV.  Obviously.
> 
> Dan

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Coding style in CPython implementation

[Dan Sommers]

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 read, especially if it happened to be written
if(!d) without the space, because it was never a single character name
the ! disappeared into the noise.  OTOH, = vs. == always stuck out like
a sore thumb.  Then again, I grew up with monochrome terminals
vs. unusably slow syntax highlighting, and grayscale printers (and we
had to live in a small shoebox in the middle of the road).

YMMV.  Obviously.

Dan

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Coding style in CPython implementation

[Στέφανος Σωφρονίου]

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) { ... }
> > c) if (variable != NULL) { ... }
> > 
> > What I wanted to ask is, is there a particular reason for not choosing
> > 
> > a) if (!variable) { ... } in place of if (variable == NULL) { ... },
> > b) if (-1 == variable) { ... } in place of if (variable == -1) { ... }, and
> > c) if (variable) { ... } in place of if (variable) { ... } ?
> 
> (Presumably you meant variable != NULL)

Yep, I forgot to show the != NULL part; good catch!

> 
> > Especially the (b) syntax is extremely dangerous to assign -1 to variable 
> > in case of an accidental mistyping of equals sign; it had happened 
> > countless times by now to to many of us that use various C-family languages.
> > 
> > Is there a particular reason for using this specific coding style?
> 
> Which one do you think is more readable?
> 
> Which style would you prefer to read?
> 
> Or do you prefer the more cryptic style in open source code?
> 
> 
> (The = vs. == issue is of one of numerous design flaws in C, but 
> uglifying source code to get around it isn't the answer.)

I understand what you are saying and I don't have a styling preference, at 
least in CPython's case.

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.

But indeed it's a matter of taste.

I just wanted to see whether there is a certain favor around such coding style, 
that's all.

> 
> 
> 
> -- 
> bartc

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Coding style in CPython implementation

[Ned Batchelder]

On 10/28/17 4:26 PM, Stefan Ram wrote:

Ned Batchelder <n...@nedbatchelder.com> writes:

On 10/28/17 3:00 PM, Stefan Ram wrote:

=?UTF-8?B?zqPPhM6tz4bOsc69zr/PgiDOo8+Jz4bPgc6/zr3Or86/z4U=?= 
<stefanossofroniou...@gmail.com> writes:

What I wanted to ask is, is there a particular reason for not choosing

definition of »NULL«. »NULL« is not part of the C language proper.

Especially if NULL is not part of the standard,

   »NULL« is defined in the standard, but it is an identifier
   from the library and, therefore, needs an »#include«.

   The language proper is the language core without any
   library added.

   The expression »NULL« AFAIK has only the meaning that
   usually is intended if one of the headers needed for
   it has been »#include«d.

   The operator »!« and the if-statement do not require
   any »#include«.



I certainly wouldn't adjust my coding style to avoid #include'ing the 
definition of NULL.


--Ned.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Coding style in CPython implementation

[Ned Batchelder]

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) { ... }
if (!variable) { ... }

   »!variable« is clearer, because it does not depend on the
   definition of »NULL«. »NULL« is not part of the C language proper.
Especially if NULL is not part of the standard, then you need to write 
"variable == NULL", since "!variable" may not have the same effect after 
"return NULL;" depending on how NULL is defined.


   (I sometimes like to write »if( variable ); else { ... }«.)

Ick.

--Ned.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Coding style in CPython implementation

[Chris Angelico]

On Sun, Oct 29, 2017 at 5:42 AM, Στέφανος Σωφρονίου
<stefanossofroniou...@gmail.com> 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 not choosing
>
> a) if (!variable) { ... } in place of if (variable == NULL) { ... },
> b) if (-1 == variable) { ... } in place of if (variable == -1) { ... }, and
> c) if (variable) { ... } in place of if (variable) { ... } ?
>
> Especially the (b) syntax is extremely dangerous to assign -1 to variable in 
> case of an accidental mistyping of equals sign; it had happened countless 
> times by now to to many of us that use various C-family languages.
>
> Is there a particular reason for using this specific coding style?

Have you read PEP 7?

https://www.python.org/dev/peps/pep-0007/

PEP 7 and PEP 8 are a pair of style guides that govern the CPython
source code - PEP 7 for the C code, and PEP 8 for the Python code in
the standard library. Unfortunately, many people seem to think that
PEP 8 is supposed to govern *their* code, and as such, end up not even
realizing that PEP 7 exists to answer all the same sorts of questions.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Coding style in CPython implementation

[bartc]

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 not choosing

a) if (!variable) { ... } in place of if (variable == NULL) { ... },
b) if (-1 == variable) { ... } in place of if (variable == -1) { ... }, and
c) if (variable) { ... } in place of if (variable) { ... } ?


(Presumably you meant variable != NULL)


Especially the (b) syntax is extremely dangerous to assign -1 to variable in 
case of an accidental mistyping of equals sign; it had happened countless times 
by now to to many of us that use various C-family languages.

Is there a particular reason for using this specific coding style?


Which one do you think is more readable?

Which style would you prefer to read?

Or do you prefer the more cryptic style in open source code?


(The = vs. == issue is of one of numerous design flaws in C, but 
uglifying source code to get around it isn't the answer.)




--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Coding style in CPython implementation

[Στέφανος Σωφρονίου]

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 not choosing

a) if (!variable) { ... } in place of if (variable == NULL) { ... },
b) if (-1 == variable) { ... } in place of if (variable == -1) { ... }, and
c) if (variable) { ... } in place of if (variable) { ... } ?

Especially the (b) syntax is extremely dangerous to assign -1 to variable in 
case of an accidental mistyping of equals sign; it had happened countless times 
by now to to many of us that use various C-family languages.

Is there a particular reason for using this specific coding style?

Regards,

Stefanos
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Basic question about speed/coding style/memory

[88888 Dihedral]

Jan Riechers於 2012年7月21日星期六UTC+8下午3時33分27秒寫道：
 Hello Pythonlist,
 
 I have one very basic question about speed,memory friendly coding, and 
 coding style of the following easy quot;ifquot;-statement in Python 2.7, 
 but Im 
 sure its also the same in Python 3.x
 
 Block
 #--
 if statemente_true:

if an evaluated expression result is non-zero, then 


   doSomething()

 else: 
# execute this block if  the expression evaluated as zero
 
   doSomethingElseInstead()
 
 #--
 
 versus this block:
 #--
 if statement_true:
   doSomething()
   return
 
 doSomethingElseInstead()
 
 #--
 
 
 I understand the first pattern that I tell the interpreter to do:
 Check if the conditional is true, run quot;doSomething()quot; else go 
 inside the 
 else block and quot;doSomethingElseInstead()quot;.
 
 while the 2nd does only checks:
 doSomething() if statement_true, if not, just go directly to 
 quot;doSomethingElseInstead()
 
 
 Now, very briefly, what is the better way to proceed in terms of 
 execution speed, readability, coding style?
 Letting out the fact that, in order to prevent 
 quot;doSomethingElseInsteadquot;-Block to execute, a return has to provided.
 
 Thank you for reading and hope someone brings light into that.
 
 Your fellow python programmer
 Jan

Well, the C-style branching is inherited in python.

Expressions and statements are different.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Basic question about speed/coding style/memory

[88888 Dihedral]

Chris Angelico於 2012年7月21日星期六UTC+8下午5時04分12秒寫道：
 On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers lt;janpet...@freenet.degt; 
 wrote:
 gt; Block
 gt; #--
 gt; if statemente_true:
 gt; doSomething()
 gt; else:
 gt; doSomethingElseInstead()
 gt;
 gt; #--
 
 This means, to me, that the two options are peers - you do this or you do 
 that.
 
 gt; versus this block:
 gt; #--
 gt; if statement_true:
 gt; doSomething()
 gt; return
 gt;
 gt; doSomethingElseInstead()
 gt;
 gt; #--
 
 This would be for an early abort. Don#39;t bother doing most of this
 function#39;s work, just doSomething. Might be an error condition, or
 perhaps an optimized path.
 
 Definitely for error conditions, I would use the second option. The
 quot;fail and bailquot; notation keeps the entire error handling in one 
 place:
 
 def func(x,y,z):
   if xlt;0:
 y+=5
 return
   if ylt;0:
 raise PEBKAC(quot;There#39;s an idiot here somewherequot;)
   # ... do the rest of the work
 
This is the caller responsible style when passing parameters to 
functions.


Checking types of parameters both in the caller and the callee 
does slow down a little bit.



 Note the similarity between the control structures. Raising an
 exception immediately terminates processing, without polluting the
 rest of the function with an unnecessary indentation level. Early
 aborting through normal function return can do the same thing.
 
 But this is purely a matter of style. I don#39;t think there#39;s any
 significance in terms of processing time or memory usage, and even if
 there is, it would be dwarfed by considerations of readability. Make
 your code look like what it#39;s doing, and let the execution take care
 of itself.
 
 ChrisA

-- 
http://mail.python.org/mailman/listinfo/python-list

Basic question about speed/coding style/memory

[Jan Riechers]

Hello Pythonlist,

I have one very basic question about speed,memory friendly coding, and 
coding style of the following easy if-statement in Python 2.7, but Im 
sure its also the same in Python 3.x


Block
#--
if statemente_true:
doSomething()
else:
doSomethingElseInstead()

#--

versus this block:
#--
if statement_true:
doSomething()
return

doSomethingElseInstead()

#--


I understand the first pattern that I tell the interpreter to do:
Check if the conditional is true, run doSomething() else go inside the 
else block and doSomethingElseInstead().


while the 2nd does only checks:
doSomething() if statement_true, if not, just go directly to 
doSomethingElseInstead()



Now, very briefly, what is the better way to proceed in terms of 
execution speed, readability, coding style?
Letting out the fact that, in order to prevent 
doSomethingElseInstead-Block to execute, a return has to provided.


Thank you for reading and hope someone brings light into that.

Your fellow python programmer
Jan
--
http://mail.python.org/mailman/listinfo/python-list

Re: Basic question about speed/coding style/memory

[Andrew Berg]

On 7/21/2012 2:33 AM, Jan Riechers wrote:
 Block
 ...
 versus this block:
 ...
 Now, very briefly, what is the better way to proceed in terms of 
 execution speed, readability, coding style?
Using if/else is the most readable in the general sense. Using return
(or break or continue as applicable) in this manner would indicate (at
least to me) that it's an exceptional or otherwise special case and that
the function can't do what it's supposed to. In that case, I would try
to catch an exception rather than use if/else whenever possible. I
highly doubt there is a significant performance difference between them.
-- 
CPython 3.3.0b1 | Windows NT 6.1.7601.17803
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Basic question about speed/coding style/memory

[Jan Riechers]

On 21.07.2012 11:02, Andrew Berg wrote:

On 7/21/2012 2:33 AM, Jan Riechers wrote:

Block
...
versus this block:
...
Now, very briefly, what is the better way to proceed in terms of
execution speed, readability, coding style?

Using if/else is the most readable in the general sense. Using return
(or break or continue as applicable) in this manner would indicate (at
least to me) that it's an exceptional or otherwise special case and that
the function can't do what it's supposed to. In that case, I would try
to catch an exception rather than use if/else whenever possible. I
highly doubt there is a significant performance difference between them.



Hello Andrew,

Your answer is right, in other circumstances I also would stick to 
try/except, break-statements in loops and so forth.

But the question was a bit more elementary.

Cause, as I understand the interpreter chooses either the else (1st 
block) or just proceeds with following code outside the if.


So if there is some overhead in some fashion in case we don't offer the 
else, assuming the interpreter has to exit the evaluation of the 
if-statement clause and return to a normal parsing code-state 
outside the if statement itself.


I hope this explanation makes more sense in what I want to ask ;)

Jan
--
http://mail.python.org/mailman/listinfo/python-list

Re: Basic question about speed/coding style/memory

[Chris Angelico]

On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers janpet...@freenet.de wrote:
 Block
 #--
 if statemente_true:
 doSomething()
 else:
 doSomethingElseInstead()

 #--

This means, to me, that the two options are peers - you do this or you do that.

 versus this block:
 #--
 if statement_true:
 doSomething()
 return

 doSomethingElseInstead()

 #--

This would be for an early abort. Don't bother doing most of this
function's work, just doSomething. Might be an error condition, or
perhaps an optimized path.

Definitely for error conditions, I would use the second option. The
fail and bail notation keeps the entire error handling in one place:

def func(x,y,z):
  if x0:
y+=5
return
  if y0:
raise PEBKAC(There's an idiot here somewhere)
  # ... do the rest of the work

Note the similarity between the control structures. Raising an
exception immediately terminates processing, without polluting the
rest of the function with an unnecessary indentation level. Early
aborting through normal function return can do the same thing.

But this is purely a matter of style. I don't think there's any
significance in terms of processing time or memory usage, and even if
there is, it would be dwarfed by considerations of readability. Make
your code look like what it's doing, and let the execution take care
of itself.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Basic question about speed/coding style/memory

[Andrew Berg]

On 7/21/2012 3:13 AM, Jan Riechers wrote:
 Cause, as I understand the interpreter chooses either the else (1st 
 block) or just proceeds with following code outside the if.
If none of the if/elif statements evaluate to something true, the else
block is executed.

 So if there is some overhead in some fashion in case we don't offer the 
 else, assuming the interpreter has to exit the evaluation of the 
 if-statement clause and return to a normal parsing code-state 
 outside the if statement itself.
I really don't understand. You can look into the dis module if you want
to look at how CPython bytecode is executed and the timeit module to
measure speed. In any case, I don't see how there would be any
significant difference.

http://docs.python.org/py3k/library/dis.html
http://docs.python.org/py3k/library/timeit.html
-- 
CPython 3.3.0b1 | Windows NT 6.1.7601.17803
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Basic question about speed/coding style/memory

[Steven D'Aprano]

On Sat, 21 Jul 2012 10:33:27 +0300, Jan Riechers wrote:

 Hello Pythonlist,
 
 I have one very basic question about speed,memory friendly coding, and
 coding style of the following easy if-statement in Python 2.7, but Im
 sure its also the same in Python 3.x

I assume that the following is meant to be inside a function, otherwise 
the return in the second example is illegal.

But in general, you're worrying too much about trivia. One way or the 
other, any speed difference will be trivial. Write whatever style reads 
and writes most naturally, and only worry about what's faster where it 
actually counts.

To give it an analogy that might be clear, this question is not too far 
from worrying about whether your car will be faster with the radio aerial 
up or down. Yes, technically the car will be slower with the aerial up, 
due to air resistance, but you'd have a job measuring it, and it makes no 
difference whether you are zooming down the highway at 120mph or stuck in 
traffic crawling along at 5mph.


Here's a minimal example:


def with_else(x):
if x:
a = x
else:
a = x+1
return a


def without_else(x):
if x:
a = x
return a
a = x+1
return a


Notice that I try to make each function do the same amount of work, so 
that we're seeing only the difference between else vs no else.

Now let's test the speed difference with Python 2.7. Because this is 
timing small code snippets, we should use the timeit module to time the 
code:

from timeit import Timer
setup = from __main__ import with_else, without_else
t1 = Timer(for i in (0, 1): result = with_else(i), setup)
t2 = Timer(for i in (0, 1): result = without_else(i), setup)

Each snippet calls the function twice, once to take the if branch, then 
to take the else branch.

Now we time how long it takes to run each code snippet 100 times. We 
do that six times each, and print the best (lowest) speed:

py min(t1.repeat(repeat=6))
0.9761919975280762
py min(t2.repeat(repeat=6))
0.9494419097900391

So there is approximately 0.03 second difference per TWO MILLION 
if...else blocks, or about 15 nanoseconds each. This is highly unlikely 
to be the bottleneck in your code. Assuming the difference is real, and 
not just measurement error, the difference is insignificant.

So, don't worry about which is faster. Write whichever is more natural, 
easier to read and write.


 Block
 #--
 if statemente_true:
   doSomething()
 else:
   doSomethingElseInstead()

This style is especially recommended when the two clauses are equal in 
importance.


 versus this block:
 #--
 if statement_true:
   doSomething()
   return
 doSomethingElseInstead()

This style is especially recommended when the doSomethingElseInstead() 
block is the normal procedure, and the doSomething() block is a special 
case. Not necessarily rare, but nevertheless special in some sense.

Of course, the decision as to which is the special case and which is 
the normal case is often entirely arbitrary.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Basic question about speed/coding style/memory

[Jan Riechers]

On 21.07.2012 12:06, Steven D'Aprano wrote:


But in general, you're worrying too much about trivia. One way or the
other, any speed difference will be trivial. Write whatever style reads
and writes most naturally, and only worry about what's faster where it
actually counts.





Notice that I try to make each function do the same amount of work, so
that we're seeing only the difference between else vs no else.

Now let's test the speed difference with Python 2.7. Because this is
timing small code snippets, we should use the timeit module to time the
code:

from timeit import Timer
setup = from __main__ import with_else, without_else
t1 = Timer(for i in (0, 1): result = with_else(i), setup)
t2 = Timer(for i in (0, 1): result = without_else(i), setup)

Each snippet calls the function twice, once to take the if branch, then
to take the else branch.

Now we time how long it takes to run each code snippet 100 times. We
do that six times each, and print the best (lowest) speed:

py min(t1.repeat(repeat=6))
0.9761919975280762
py min(t2.repeat(repeat=6))
0.9494419097900391

So there is approximately 0.03 second difference per TWO MILLION
if...else blocks, or about 15 nanoseconds each. This is highly unlikely
to be the bottleneck in your code. Assuming the difference is real, and
not just measurement error, the difference is insignificant.

So, don't worry about which is faster. Write whichever is more natural,
easier to read and write.




Hello Steven,

very nice example and thank you very much for also for the Timeit test!
Actually it confirms my assumption in some way:

[SNIP myself]
So if there is some overhead in some fashion in case we don't offer the
else, assuming the interpreter has to exit the evaluation of the
if-statement clause and return to a normal parsing code-state
outside the if statement itself.
[SNAP]

Without having looked at Andrew's bytecode excecution hint, using the 
dis module, to see how the interpreter handles the task on lower level.


But fare enough for me :)

But I agree, the return in my example is misleading and it would be 
illegal outside of a function call. I just added it to make clear that 
the fellow code below the return should not be executed in comparison to 
the 2nd example.


Thank you very much
Jan
--
http://mail.python.org/mailman/listinfo/python-list

Re: Basic question about speed/coding style/memory

[Thomas 'PointedEars' Lahn]

Jan Riechers wrote:

 I have one very basic question about speed,memory friendly coding, and
 coding style of the following easy if-statement in Python 2.7, but Im
 sure its also the same in Python 3.x
 
 Block
 #--
 if statemente_true:
 doSomething()
 else:
 doSomethingElseInstead()
 
 #--
 
 versus this block:
 #--
 if statement_true:
 doSomething()
 return
 
 doSomethingElseInstead()
 
 #--
 
 
 I understand the first pattern that I tell the interpreter to do:

A common misconception.  As a writer of Python source code, (usually) you 
never tell the (CPython) interpreter anything (but to start working on the 
source code).  Python source code is automatically *compiled* into bytecode 
by the (CPython) interpreter, and that bytecode is executed by a virtual 
machine.¹  So at most, you are telling that virtual machine to do something, 
through the bytecode created from your source code.

 Check if the conditional is true, run doSomething() else go inside the
 else block and doSomethingElseInstead().
 
 while the 2nd does only checks:
 doSomething() if statement_true, if not, just go directly to
 doSomethingElseInstead()
 
 
 Now, very briefly, what is the better way to proceed in terms of
 execution speed, readability, coding style?

Since this is comp.lang.python, you just need to check against the Zen of 
Python to know what you should do ;-)

http://www.python.org/dev/peps/pep-0020/

For me, this boils down in this case to the common recommendation return 
early, return often as explicit is better than implicit and readability 
counts.  If there is nothing else than the `else' block in the function, 
there is no use for you to continue in the function, so you should return 
explicitly at this point.

On the other hand, if you can *avoid repeating code* in each branch by _not_ 
returning in the first branch, you should do that instead (practicality 
beats purity).

HTH

_
¹  This is not unlike in other so-called scripting languages; although for
   reasons that escape me, the software that compiles the source code – the
   compiler – is called the (C)Python *interpreter*, even in
   http://docs.python.org/faq/general.html.
-- 
PointedEars

Please do not Cc: me. / Bitte keine Kopien per E-Mail.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Basic question about speed/coding style/memory

[Devin Jeanpierre]

On Sat, Jul 21, 2012 at 5:06 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 So there is approximately 0.03 second difference per TWO MILLION
 if...else blocks, or about 15 nanoseconds each. This is highly unlikely
 to be the bottleneck in your code. Assuming the difference is real, and
 not just measurement error, the difference is insignificant.

It's probably real. For if-else, the true case needs to make a jump
before it returns, but for if-return, there's no jump and the return
is inlined.

-- Devin

 So, don't worry about which is faster. Write whichever is more natural,
 easier to read and write.

The most important advice. Even when it's a larger difference! :)

-- Devin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Stephen Hansen]

On 9/30/11 6:54 AM, rantingrick wrote:
 a misplaced and rarely used functionality of the stdlib.

Have you tried putting \.zfill\( and selecting Python in
google.com/codesearch?

It seems to have quite a few users, among only openly available code.
Considering there is a much larger body of code that isn't openly
available, its not hard to extrapolate from the search. (Then again, the
Python Community is made up of only people on this list! Everyone knows
that.)

Sure, you can use format strings, but that is a significantly more
complicated thing to do.

It may not be /common/, but is not at all unusual for one to have in a
string a number that they want to line up numerically with zeros. You
may not have had to do it a lot. But, golly, you are not a
representative sample of the world. Your code, your projects, the things
you have done, are not a representative sample of all the Python code,
projects, and things people have done with Python out there.

The zfill may not be a super wonderful function, used by many in most
places. But its there, its simple, its clear what it does.

Removing it means that anyone who wants to do what it did, now have to
learn a fairly complex mini-language, even if perhaps that is the only
time they will /ever/ need to use said language. That's a burden which
is just, frankly, silly.

Its nice that the format mini-language is powerful. But its nice that
there are also simple, clear, direct primitives people can use to
accomplish simple, fairly common needs.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Westley Martínez]

On Thu, Sep 29, 2011 at 07:07:28PM -0400, Devin Jeanpierre wrote:
  However, as you use the new format method you will come to appreciate
  it. It's an adult beverage with an acquired taste. ;-)
 
 Yeah. It's a much more difficult to read thing, but once you learn how
 to write it it flows faster.
 
 Of course, I never managed to learn how to write it...
 
 I would suggest that rather than being complicated it is dense.
 
I'm one of the weirdos who is absolutely hostile to the format method
and continues to use % formatting.  I'm pretty sure it is because of my
C background (actually I learned Python before C, and thus learned %
formatting in Python).  However, I'm not so opposed to it that I've not
learned it.  It is quite dense, almost feels like something in a
scripting language like Perl.  Indeed, I did try it for some time, but
it was just too heavy and slow for me.  Well someday I'll probably be
forced to use it, but for anyone else who agrees with me, always know
there's at least one Python programmer out there with some (or no)
sense.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Chris Angelico]

On Fri, Sep 30, 2011 at 4:14 PM, Westley Martínez aniko...@gmail.com wrote:
 I'm one of the weirdos who is absolutely hostile to the format method
 and continues to use % formatting.  I'm pretty sure it is because of my
 C background (actually I learned Python before C, and thus learned %
 formatting in Python).

I quite like printf-style formatting. It's well known, well defined,
and compact. When I write C++ programs, I often still use
printf/sprintf extensively - it just feels nicer than iostream (and
the main downside of printf, the lack of argument checking, is largely
solved in recent gcc). So when I work with Python, it makes sense to
use the same thing there. Dense syntax results in easy-to-read format
strings, imho.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[rantingrick]

On Sep 29, 11:49 pm, Ian Kelly ian.g.ke...@gmail.com wrote:
 Nope, that doesn't work.

  {0:010}.format(-1234)

 '0-1234'

 The whole point of zfill is that it handles signs correctly.

py {0:-010d}.format(-1234)
'-01234'

My point was: Use the {char}{repeat}d format for integers and the
{char}{||=}{repeat} for strings. Problem solved. No more need for
zfill.

py {0:010}.format(-1234)
'0-1234'

What result would you expect from that string argument? I think it
behaves as anyone would expect. If you have a str and you want it
interpreted as a negative integer then cast it.

py {0:010d}.format(int(-1234))
'-01234'

If you would like for the spec to handle the case of integers and
strings transparently then you need to lobby to have the API changed.
Maybe they could add a !i like the !s and !r which would be explicit.
However, i don't think implicit coercion of strings to integers is a
good idea. Using the int function or !i removes and ambiguities.

For me, the spec works just fine as is.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[rantingrick]

Note: I am quoting Passiday to get this thread back on subject
however my reply is for alex23 the philosopher

On Sep 29, 9:50 pm, alex23 wuwe...@gmail.com wrote:
 On Sep 29, 10:23 pm, rantingrick rantingr...@gmail.com wrote:

  What is so bad about breaking code in obscure places?

 Try coding in PHP across minor release versions and see how you feel
 about deprecating core functions on a whim.

I never said we should remove it now, i said we should deprecate it
now.

  We changed print
  to a function which broke just about every piece of code every written
  in this language.

 In a well declared _break_ with backwards compatibility. Not on a whim
 between minor releases.

Please Google deprecate.

  What is so bad then about breaking some very obscure code?

 Because while you say some very obscure code, what you really mean
 is code that isn't mine.

Well alex i can't see a mob approaching with pitchforks because we
deprecate a misplaced and rarely used functionality of the stdlib.

 As you have no access
 to the inner states of _any_ of the people you regularly condemn here
 with your hypocritical attacks, I've no idea why you consider yourself
 to be an expert on their desires and opinions.

Well alex, like yourself, i hold expertise in many fields BESIDES
programming. One of which being psychology.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Chris Angelico]

On Fri, Sep 30, 2011 at 11:54 PM, rantingrick rantingr...@gmail.com wrote:
 Well alex, like yourself, i hold expertise in many fields BESIDES
 programming. One of which being psychology.


I *knew* it! We're all part of a huge experiment to see how much the
human psyche can withstand. If we succeed on the Rick test, do we
level up and get a second troll to deal with, or is this MST3K-style
eternity?

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Suggested coding style

[Prasad, Ramit]

May I suggest a[n] email client that can group mailing list threads?

Please do. Bonus points if it handles threading in a Gmail-like style.

Ramit


Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423



-Original Message-
From: python-list-bounces+ramit.prasad=jpmorgan@python.org 
[mailto:python-list-bounces+ramit.prasad=jpmorgan@python.org] On Behalf Of 
Devin Jeanpierre
Sent: Thursday, September 29, 2011 6:07 PM
To: rantingrick
Cc: python-list@python.org
Subject: Re: Suggested coding style

 However, as you use the new format method you will come to appreciate
 it. It's an adult beverage with an acquired taste. ;-)

Yeah. It's a much more difficult to read thing, but once you learn how
to write it it flows faster.

Of course, I never managed to learn how to write it...

I would suggest that rather than being complicated it is dense.

 PS: Has anyone noticed all the off topic chatter about religion and
 feelings? Since the main subject of this thread is about zfill i can't
 help but wonder if the minions where sent out to present a distraction
 with scripted pseudo arguments. Just an observation.

Devin

On Thu, Sep 29, 2011 at 6:56 PM, rantingrick rantingr...@gmail.com wrote:
 On Sep 29, 5:12 pm, Ian Kelly ian.g.ke...@gmail.com wrote:
 On Thu, Sep 29, 2011 at 6:23 AM, rantingrick rantingr...@gmail.com wrote:
  A specific method for padding a string with ONLY zeros is ludicrous
  and exposes the narrow mindedness of the creator. The only thing worse
  than zfill as a string method is making zfill into built-in
  function! The ONLY proper place for zfill is as an option in the
  str.format() method.

  py {0:zf10}.format(1234) - 001234

 Agree that zfill seems to be redundant with str.format, although your
 suggested syntax is atrocious, especially since a syntax already
 exists that fits better in the already-complicated format specifier
 syntax.

 It's interesting that you find the format specifier complicated. I
 will admit that upon first glance i lamented the new format method
 spec and attempted to cling to the old string interpolation crap.
 However, as you use the new format method you will come to appreciate
 it. It's an adult beverage with an acquired taste. ;-)

 One thing that may help format noobs is to look at the spec as two
 parts; the part before the colon and the part after the colon. If you
 break it down in this manner the meaning starts to shine through. I
 will agree, it is a lot of cryptic info squeezed into a small space
 HOWEVER you would no want a verbose format specification.

 But i wholeheartedly agree with you points and i would say the zfill
 method has no future uses in the stdlib except for historical reasons.
 We should deprecate it now.


 {0:=010d}.format(1234) - 001234

 There are a couple of warts with the existing implementation, however:

 1) str.zfill() operates on strings; the .format() syntax operates on
 numeric types.  I would suggest that the = fill alignment in format
 specifiers should be extended to do the same thing as zfill when given
 a string.

 EXACTLY!

 PS: Has anyone noticed all the off topic chatter about religion and
 feelings? Since the main subject of this thread is about zfill i can't
 help but wonder if the minions where sent out to present a distraction
 with scripted pseudo arguments. Just an observation.
 --
 http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Chris Angelico]

On Sat, Oct 1, 2011 at 2:06 AM, Prasad, Ramit ramit.pra...@jpmorgan.com wrote:
May I suggest a[n] email client that can group mailing list threads?

 Please do. Bonus points if it handles threading in a Gmail-like style.


May I suggest Gmail? It handles threading in a very Gmail-like style.

ChrisA
running and ducking
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Suggested coding style

[Prasad, Ramit]

 Please do. Bonus points if it handles threading in a Gmail-like style.


May I suggest Gmail? It handles threading in a very Gmail-like style.

Curses, foiled by my lack of specificity! I meant desktop client. Although...if 
another website does similar threading it would be good to know. Never know 
when I will want to start avoiding Gmail :)

Ramit


Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423


This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Chris Angelico]

On Sat, Oct 1, 2011 at 3:05 AM, Prasad, Ramit ramit.pra...@jpmorgan.com wrote:
 Curses, foiled by my lack of specificity! I meant desktop client. 
 Although...if another website does similar threading it would be good to 
 know. Never know when I will want to start avoiding Gmail :)


Ah, *desktop* client! Hm. I actually can't advise there; since I'm
constantly mobile, I use webmail for everything - installed Squirrel
Mail and RoundCube on my server for remote access. Neither does
threading though afaik; nor does PMMail (which is a desktop client).

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Paul Rudin]

Prasad, Ramit ramit.pra...@jpmorgan.com writes:

May I suggest a[n] email client that can group mailing list threads?

 Please do. Bonus points if it handles threading in a Gmail-like style.

The answer to any news/mail client with feature X type question is
normally gnus - although I don't know what Gmail-like style is.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Alec Taylor]

Maybe one Apache's Buzz?

On 10/1/11, Prasad, Ramit ramit.pra...@jpmorgan.com wrote:
 Please do. Bonus points if it handles threading in a Gmail-like style.


May I suggest Gmail? It handles threading in a very Gmail-like style.

 Curses, foiled by my lack of specificity! I meant desktop client.
 Although...if another website does similar threading it would be good to
 know. Never know when I will want to start avoiding Gmail :)

 Ramit


 Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
 712 Main Street | Houston, TX 77002
 work phone: 713 - 216 - 5423


 This email is confidential and subject to important disclaimers and
 conditions including on offers for the purchase or sale of
 securities, accuracy and completeness of information, viruses,
 confidentiality, legal privilege, and legal entity disclaimers,
 available at http://www.jpmorgan.com/pages/disclosures/email.
 --
 http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Neil Cerutti]

On 2011-09-30, Paul Rudin paul.nos...@rudin.co.uk wrote:
 Prasad, Ramit ramit.pra...@jpmorgan.com writes:

May I suggest a[n] email client that can group mailing list threads?

 Please do. Bonus points if it handles threading in a Gmail-like style.

 The answer to any news/mail client with feature X type question is
 normally gnus - although I don't know what Gmail-like style is.

slrn. Is good.

-- 
Neil Cerutti
A politician is an arse upon which everyone has sat except a man.
  e. e. cummings 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Alec Taylor]

http://incubator.apache.org/wave/

On 10/1/11, Neil Cerutti ne...@norwich.edu wrote:
 On 2011-09-30, Paul Rudin paul.nos...@rudin.co.uk wrote:
 Prasad, Ramit ramit.pra...@jpmorgan.com writes:

May I suggest a[n] email client that can group mailing list threads?

 Please do. Bonus points if it handles threading in a Gmail-like style.

 The answer to any news/mail client with feature X type question is
 normally gnus - although I don't know what Gmail-like style is.

 slrn. Is good.

 --
 Neil Cerutti
 A politician is an arse upon which everyone has sat except a man.
   e. e. cummings
 --
 http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Suggested coding style

[Prasad, Ramit]

May I suggest a[n] email client that can group mailing list threads?

 The answer to any news/mail client with feature X type question is
 normally gnus - although I don't know what Gmail-like style is.
Yeah

slrn. Is good.
Unless I am missing something, it does not do email.

http://incubator.apache.org/wave/
Are you suggesting I run my own webserver to aggregate emails, stick them in 
wave, and then write something that will convert my wave post to email? I 
suppose it could work, but that is *usually* not what is considered a desktop 
app.

 Maybe one Apache's Buzz?
I think you will have to Google that one for me, as the first results I found 
were Apache Wicket and Apache Beehive...both which seem not related.


Ramit


Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423



This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Suggested coding style

[Prasad, Ramit]

 The answer to any news/mail client with feature X type question is 
 normally gnus - although I don't know what Gmail-like style is.
Yeah

Gah, I got distracted mid-email and forgot to finish. What I wanted to say was, 
Yeah, not knowing what 'Gmail-like style' makes a big difference ;).

Ramit


Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423




This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Alec Taylor]

Meh, so run your own web-server.

If wave isn't right, search on sourceforge for a while.

On 10/1/11, Prasad, Ramit ramit.pra...@jpmorgan.com wrote:
 The answer to any news/mail client with feature X type question is
 normally gnus - although I don't know what Gmail-like style is.
Yeah

 Gah, I got distracted mid-email and forgot to finish. What I wanted to say
 was, Yeah, not knowing what 'Gmail-like style' makes a big difference ;).

 Ramit


 Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
 712 Main Street | Houston, TX 77002
 work phone: 713 - 216 - 5423




 This email is confidential and subject to important disclaimers and
 conditions including on offers for the purchase or sale of
 securities, accuracy and completeness of information, viruses,
 confidentiality, legal privilege, and legal entity disclaimers,
 available at http://www.jpmorgan.com/pages/disclosures/email.
 --
 http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[alex23]

  On Sep 29, 10:23 pm, rantingrick rantingr...@gmail.com wrote:
   What is so bad about breaking code in obscure places?

 On Sep 29, 9:50 pm, alex23 wuwe...@gmail.com wrote:
  Try coding in PHP across minor release versions and see how you feel
  about deprecating core functions on a whim.

On Sep 30, 11:54 pm, rantingrick rantingr...@gmail.com wrote:
 I never said we should remove it now, i said we should deprecate it
 now.

Actually, *I* said deprecate, *you* said break. I don't see the word
'remove' anywhere in my comment.

 Please Google deprecate.

Please read what I wrote rather than what you want me to have said.

 Well alex i can't see a mob approaching with pitchforks because we
 deprecate a misplaced and rarely used functionality of the stdlib.

No, but you don't see a lot of things. You're genuinely convinced that
your viewpoint is superior and singularly correct. I don't think
you're a reasonable arbiter of what functionality should be added or
removed from the stdlib.

 Well alex, like yourself, i hold expertise in many fields BESIDES
 programming. One of which being psychology.

That only makes the claims that you regularly post about others even
more offensive.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Westley Martínez]

On Wed, Sep 28, 2011 at 07:11:08PM -0700, rantingrick wrote:
 On Sep 28, 6:26 pm, Tim Johnson t...@akwebsoft.com wrote:
  * DevPlayer devpla...@gmail.com [110928 04:31]:
   On Sep 27, 10:25 pm, alex23 wuwe...@gmail.com wrote:
rantingrick rantingr...@gmail.com wrote:
 Since, like the bible
 the zen is self contradicting, any argument utilizing the zen can be
 defeated utilizing the zen.
 
And like the Bible, the Zen was created by humans as a joke. If you're
taking it too seriously, that's your problem.
 
 If however you want to learn about the accepted rules for formatting
 code then you need to read PEP-8! PEP 8 is our style guide.
 
   Contradiction is only seen by narrow perspectve.
 
   Calling the Bible a joke is used to hurt people, not enlighten them.
   Those words show bitter arrogance, not constructive critism as it
   ignores how others feel about that book. What benefit to others is
   gained by calling someones belief a joke?
 
   My wife and I are devout christians, but not fundamentalist. We
   would not take rantingrick too seriously. If _you_ take him
   seriously, you're just giving him 'street cred'.
 
 DevPlayer was not even talking about what i said, he was replying to a
 statement by Alex23 who said (and i quote) And like the Bible, the
 Zen was created by humans as a joke. Maybe you should spend the next
 fifteen or so minutes catching up to the conversation...(ಠ_ಠ)...of
 course only *after* you clean that egg from your face

Perhaps you should spend a little less time on the mailing list and a
little more time in church.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Ian Kelly]

On Thu, Sep 29, 2011 at 12:24 AM, Westley Martínez aniko...@gmail.com wrote:
 Perhaps you should spend a little less time on the mailing list and a
 little more time in church.

You must not like churchgoers very much if you want to inflict
rantingrick on them...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Ian Kelly]

On Thu, Sep 29, 2011 at 12:57 AM, Ian Kelly ian.g.ke...@gmail.com wrote:
 On Thu, Sep 29, 2011 at 12:24 AM, Westley Martínez aniko...@gmail.com wrote:
 Perhaps you should spend a little less time on the mailing list and a
 little more time in church.

 You must not like churchgoers very much if you want to inflict
 rantingrick on them...

Although come to think of it, I bet he could deliver a pretty mean sermon. ;-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Steven D'Aprano]

Westley Martínez wrote:

 Perhaps you should spend a little less time on the mailing list and a
 little more time in church.

Is that meant as punishment for Rick or for the churchgoers?


-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Passiday]

Oh, my. Who could expect this topic would iterate to some whining about 
religion (please don't respond on this remark of mine).

Here's a summary of what I take from this longwinded thread:
Read the Zen of Pthon for some fun: http://www.python.org/dev/peps/pep-0020
Read the PEP-8 for some good guidelines: http://www.python.org/dev/peps/pep-0008

My topic was Suggested coding style because I hoped there is some common 
understanding which of the ancient methods/functions are so not where they 
should be that the use of them should be depreciated. I can fully understand 
that when the language evolves, it might implement some ugly methods. Perhaps 
it was some quick itching need to format some numbers that drove some antique 
Python programmer so mad that he decided this belongs to the string class, 
instead of some number/date/string formatting class that attempts to build on 
existing well established standards. And so, the str.zfill() was born. But I'd 
expect that there exists some leadership who are brave enough to admit some bad 
decisions and lead the people by announcing that using certain methods is bad 
style. No need to take them out of the implementation, that might unnecessary 
break some code in obscure places. However, guiding programmers for better 
coding practice and avoid ugly bloating of nice scripting lang
 uage should be considered a holy (please don't rant on use of this word) 
mission.

Passiday
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[rantingrick]

On Sep 29, 5:37 am, Passiday passi...@gmail.com wrote:

 Here's a summary of what I take from this longwinded thread:
 Read the Zen of Pthon for some fun:http://www.python.org/dev/peps/pep-0020
 Read the PEP-8 for some good 
 guidelines:http://www.python.org/dev/peps/pep-0008

That's the point of all this, yes. You see, around here, once the
point is made there is an unwritten rule that the thread must then
descend into chaos. However, it seems you may have brought this
train wreck back to reality below... whether the trolls will allow
that happen remains to be seen...?

 My topic was Suggested coding style because I hoped
 there is some common understanding which of the ancient
 methods/functions are so not where they should be that the
 use of them should be depreciated.

I agree. Whilst zfill is useful, and probably should be a part of the
stlib somewhere, the string module is no place for it. The only way
zfill WOULD work as a string method is if it were changed to accept a
user defined fill char. Even then i don't like it as a string method;
too specific!

A specific method for padding a string with ONLY zeros is ludicrous
and exposes the narrow mindedness of the creator. The only thing worse
than zfill as a string method is making zfill into built-in
function! The ONLY proper place for zfill is as an option in the
str.format() method.

py {0:zf10}.format(1234) - 001234

When are they going to see that I am the best API designer this
community has ever had the privilege to work with! GvR should be
texting me every night in hopes that some of my API genius will rub
off on him.

 I can fully understand
 that when the language evolves, it might implement some
 ugly methods. Perhaps it was some quick itching need to
 format some numbers that drove some antique Python
 programmer so mad that he decided this belongs to the
 string class, instead of some number/date/string
 formatting class that attempts to build on existing well
 established standards. And so, the str.zfill() was born.

zfills foster home placement is akin to the missing Path object we
still don't have. Both are a result of poor planning. Now zfill is
like some red headed step child that nobody wants, but nobody has the
balls to return the abortion to it's rightful place.

 But I'd expect that there exists some leadership who are
 brave enough to admit some bad decisions and lead the
 people by announcing that using certain methods is bad
 style.

Ha! I would not hold my breath waiting for leadership to admit wrong
doings; these people think they are beyond reproach.

 No need to take them out of the implementation,
 that might unnecessary break some code in obscure places.

What is so bad about breaking code in obscure places? We changed print
to a function which broke just about every piece of code every written
in this language. (BTW, print should ALWAYS have been a function!)
What is so bad then about breaking some very obscure code? We could
always have a lengthy deprecation period.

 However, guiding programmers for better coding practice
 and avoid ugly bloating of nice scripting language should
 be considered a holy (please don't rant on use of this
 word) mission.

I agree. I think you'll agree also with me in the fact that Mr Van
Rossum has created the cleanest, most simplistically elegant, and no
nonsense language this world has ever seen. However. He is not immune
to the wicked influence of a few high ranking people within this
community who have hidden agendas and want to mutate Python into a
clone of some other nasty languages.

I believe GvR had a mid-dev-crisis and realized the err of his ways.
He attempted to turn back the clock with Python 3000, HOWEVER he did
not go far enough! Much more cleanup is in order to get this language
back on track to what it should be, and COULD be!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[rantingrick]

On Sep 29, 7:23 am, rantingrick rantingr...@gmail.com wrote:

 A specific method for padding a string with ONLY zeros is ludicrous
 and exposes the narrow mindedness of the creator. The only thing worse
 than zfill as a string method is making zfill into built-in
 function! The ONLY proper place for zfill is as an option in the
 str.format() method.

 py {0:zf10}.format(1234) - 001234


If something like zfill where to be included as a string method, it
should be more general like this:

class String:
def pad(self, char, count, side='left') = str

py .pad(0, 10)
'001234'

However the same can be accomplished with:

py '{0}1234'.format(0*10)
'001234'

py 0*10+'1234'
'001234'

Seems like pollution either way you go. Best to just let the
programmer handle it. Python IS NOT a 100% OOP language (and for good
reason!) so we don't need methods to scratch every little itch -- and
this itch seems to have originated in the nether regions instead of
the Netherlands.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Westley Martínez]

On Thu, Sep 29, 2011 at 08:37:53PM +1000, Steven D'Aprano wrote:
 Westley Martínez wrote:
 
  Perhaps you should spend a little less time on the mailing list and a
  little more time in church.
 
 Is that meant as punishment for Rick or for the churchgoers?
 
 

Hopefully neither, probably both.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Westley Martínez]

On Thu, Sep 29, 2011 at 05:23:30AM -0700, rantingrick wrote:
 On Sep 29, 5:37 am, Passiday passi...@gmail.com wrote:
  
 What is so bad about breaking code in obscure places? We changed print
 to a function which broke just about every piece of code every written
 in this language. (BTW, print should ALWAYS have been a function!)
 What is so bad then about breaking some very obscure code? We could
 always have a lengthy deprecation period.
 

Well, I once thought that a print function made a lot of sense.  In C,
printf is a function, however then I think why print is a function.  In
C, just about every function has side effects (the return values are
more often than not either pointers or status codes).  In Python
functions are encouraged to not have side-effects, so the implementation
of print as a statement or a method makes far more sense than as a
function.

But maybe I'm just batty as you all think I am.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Chris Angelico]

On Fri, Sep 30, 2011 at 2:42 AM, Westley Martínez aniko...@gmail.com wrote:
 But maybe I'm just batty as you all think I am.

Yes, I'm afraid so. Bonkers. Off your head. But let me tell you a
secret... All the best people are.

 Well, I once thought that a print function made a lot of sense.  In C,
 printf is a function, however then I think why print is a function.  In
 C, just about every function has side effects (the return values are
 more often than not either pointers or status codes).  In Python
 functions are encouraged to not have side-effects, so the implementation
 of print as a statement or a method makes far more sense than as a
 function.

Since functions and methods in Python are practically the same thing,
I don't know that there really need be any difference in policy. But I
do like any reduction in the number of special features of a
language. If screen output can be done as an ordinary function taking
ordinary arguments, that's better than having a special language
construct. Also, it's just plain stupid and yet just plain cool to be
able to:

print = sys.stderr.write

and smoothly redirect all your prints to stderr. (Unfortunately this
doesn't quite work, as it means you don't get your newlines put in for
you, but there's sure to be an equally stupid/cool reassignment
available.)

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Ben Finney]

Passiday passi...@gmail.com writes:

 Oh, my. Who could expect this topic would iterate to some whining
 about religion (please don't respond on this remark of mine).

That's an unreasonable request. If you make a provocative remark (I
doubt you chose to use “whining” without knowing how dismissive it is),
it's disingenuous to then ask that people please not respond.

-- 
 \ “If nothing changes, everything will remain the same.” —Barne's |
  `\   Law |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Ian Kelly]

On Thu, Sep 29, 2011 at 6:23 AM, rantingrick rantingr...@gmail.com wrote:
 A specific method for padding a string with ONLY zeros is ludicrous
 and exposes the narrow mindedness of the creator. The only thing worse
 than zfill as a string method is making zfill into built-in
 function! The ONLY proper place for zfill is as an option in the
 str.format() method.

 py {0:zf10}.format(1234) - 001234

Agree that zfill seems to be redundant with str.format, although your
suggested syntax is atrocious, especially since a syntax already
exists that fits better in the already-complicated format specifier
syntax.

{0:=010d}.format(1234) - 001234

There are a couple of warts with the existing implementation, however:

1) str.zfill() operates on strings; the .format() syntax operates on
numeric types.  I would suggest that the = fill alignment in format
specifiers should be extended to do the same thing as zfill when given
a string.

2) It seems to not behave as documented for floats.  I expect:

{0:=010f}.format(-32.7) - -032.7

I get:

{0:=010f}.format(-32.7) - -32.70

On the other hand, I can't imagine why I would ever actually want the
expected result, so maybe it's not a big deal.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[rantingrick]

On Sep 29, 5:12 pm, Ian Kelly ian.g.ke...@gmail.com wrote:
 On Thu, Sep 29, 2011 at 6:23 AM, rantingrick rantingr...@gmail.com wrote:
  A specific method for padding a string with ONLY zeros is ludicrous
  and exposes the narrow mindedness of the creator. The only thing worse
  than zfill as a string method is making zfill into built-in
  function! The ONLY proper place for zfill is as an option in the
  str.format() method.

  py {0:zf10}.format(1234) - 001234

 Agree that zfill seems to be redundant with str.format, although your
 suggested syntax is atrocious, especially since a syntax already
 exists that fits better in the already-complicated format specifier
 syntax.

It's interesting that you find the format specifier complicated. I
will admit that upon first glance i lamented the new format method
spec and attempted to cling to the old string interpolation crap.
However, as you use the new format method you will come to appreciate
it. It's an adult beverage with an acquired taste. ;-)

One thing that may help format noobs is to look at the spec as two
parts; the part before the colon and the part after the colon. If you
break it down in this manner the meaning starts to shine through. I
will agree, it is a lot of cryptic info squeezed into a small space
HOWEVER you would no want a verbose format specification.

But i wholeheartedly agree with you points and i would say the zfill
method has no future uses in the stdlib except for historical reasons.
We should deprecate it now.


 {0:=010d}.format(1234) - 001234

 There are a couple of warts with the existing implementation, however:

 1) str.zfill() operates on strings; the .format() syntax operates on
 numeric types.  I would suggest that the = fill alignment in format
 specifiers should be extended to do the same thing as zfill when given
 a string.

EXACTLY!

PS: Has anyone noticed all the off topic chatter about religion and
feelings? Since the main subject of this thread is about zfill i can't
help but wonder if the minions where sent out to present a distraction
with scripted pseudo arguments. Just an observation.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Devin Jeanpierre]

 However, as you use the new format method you will come to appreciate
 it. It's an adult beverage with an acquired taste. ;-)

Yeah. It's a much more difficult to read thing, but once you learn how
to write it it flows faster.

Of course, I never managed to learn how to write it...

I would suggest that rather than being complicated it is dense.

 PS: Has anyone noticed all the off topic chatter about religion and
 feelings? Since the main subject of this thread is about zfill i can't
 help but wonder if the minions where sent out to present a distraction
 with scripted pseudo arguments. Just an observation.

May I suggest a email client that can group mailing list threads?
Also, not accusing others of conspiracies.

Devin

On Thu, Sep 29, 2011 at 6:56 PM, rantingrick rantingr...@gmail.com wrote:
 On Sep 29, 5:12 pm, Ian Kelly ian.g.ke...@gmail.com wrote:
 On Thu, Sep 29, 2011 at 6:23 AM, rantingrick rantingr...@gmail.com wrote:
  A specific method for padding a string with ONLY zeros is ludicrous
  and exposes the narrow mindedness of the creator. The only thing worse
  than zfill as a string method is making zfill into built-in
  function! The ONLY proper place for zfill is as an option in the
  str.format() method.

  py {0:zf10}.format(1234) - 001234

 Agree that zfill seems to be redundant with str.format, although your
 suggested syntax is atrocious, especially since a syntax already
 exists that fits better in the already-complicated format specifier
 syntax.

 It's interesting that you find the format specifier complicated. I
 will admit that upon first glance i lamented the new format method
 spec and attempted to cling to the old string interpolation crap.
 However, as you use the new format method you will come to appreciate
 it. It's an adult beverage with an acquired taste. ;-)

 One thing that may help format noobs is to look at the spec as two
 parts; the part before the colon and the part after the colon. If you
 break it down in this manner the meaning starts to shine through. I
 will agree, it is a lot of cryptic info squeezed into a small space
 HOWEVER you would no want a verbose format specification.

 But i wholeheartedly agree with you points and i would say the zfill
 method has no future uses in the stdlib except for historical reasons.
 We should deprecate it now.


 {0:=010d}.format(1234) - 001234

 There are a couple of warts with the existing implementation, however:

 1) str.zfill() operates on strings; the .format() syntax operates on
 numeric types.  I would suggest that the = fill alignment in format
 specifiers should be extended to do the same thing as zfill when given
 a string.

 EXACTLY!

 PS: Has anyone noticed all the off topic chatter about religion and
 feelings? Since the main subject of this thread is about zfill i can't
 help but wonder if the minions where sent out to present a distraction
 with scripted pseudo arguments. Just an observation.
 --
 http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[rantingrick]

On Sep 29, 6:07 pm, Devin Jeanpierre jeanpierr...@gmail.com wrote:
  However, as you use the new format method you will come to appreciate
  it. It's an adult beverage with an acquired taste. ;-)

 Yeah. It's a much more difficult to read thing, but once you learn how
 to write it it flows faster.

 Of course, I never managed to learn how to write it...

A good way to start out is to just use the positional arguments.

py name = Bob

py Hello my name is {0}.format(name)
Hello my name is Bob

py Hello my name is {name}.format(name=name)
Hello my name is Bob

py Hello my name is {0}. My named spelled backwards is:
{0}.format(name)
Hello my name is Bob. My named spelled backwards is: Bob

py A small fry cost {0:0.2f}.format(1.666)
A small fry cost 1.67

py A small car cost {0:,.2f}.format(11666.)
A small car cost 11,666.67

# Python 2.7+ you can omit the index.
py {} = {}.format(value,2)
value = 2

Start with the small stuff and then diversify! You'll be glad you made
the change.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[rantingrick]

On Sep 29, 5:12 pm, Ian Kelly ian.g.ke...@gmail.com wrote:
 On Thu, Sep 29, 2011 at 6:23 AM, rantingrick rantingr...@gmail.com wrote:
  A specific method for padding a string with ONLY zeros is ludicrous
  and exposes the narrow mindedness of the creator. The only thing worse
  than zfill as a string method is making zfill into built-in
  function! The ONLY proper place for zfill is as an option in the
  str.format() method.

  py {0:zf10}.format(1234) - 001234

 Agree that zfill seems to be redundant with str.format, although your
 suggested syntax is atrocious, especially since a syntax already
 exists that fits better in the already-complicated format specifier
 syntax.

 {0:=010d}.format(1234) - 001234

 There are a couple of warts with the existing implementation, however:

 1) str.zfill() operates on strings; the .format() syntax operates on
 numeric types.  I would suggest that the = fill alignment in format
 specifiers should be extended to do the same thing as zfill when given
 a string.

Ah ha! Found the answer!

py {0:010d}.format(1234)
001234

py {0:010}.format(1234)
001234

py {0:010}.format(1234)
001234

py {0:@10}.format(1234)
@@1234

I would skip using the {int}{repeat}d syntax and just use the string
padding since you won't need to worry about the input data type. I
hate specificity types in string formats. With the old interpolation i
ALWAYS used %s for everything.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Chris Angelico]

On Fri, Sep 30, 2011 at 12:50 PM, alex23 wuwe...@gmail.com wrote:
 GvR should be texting me every night in hopes that some of my API genius 
 will rub
 off on him.

 Are you off your medication again?


He's very much like jimontrack (aka Tranzit Jim - google him if you're
curious), whose username people frequently referred to with the t
replaced with a c. Everyone thought he lived in April 1st.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Benefit and belief [was Re: Suggested coding style]

[alex23]

Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
         Well... We could try for equality in offense -- the Torah or the
 Koran? Maybe the Tripitaka or Sutras?

I always enjoyed the possibly apocryphal claim that the design of VRML
was influenced by the story of Indra's Net. Maybe some religious tomes
are just better? :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Ian Kelly]

On Thu, Sep 29, 2011 at 5:47 PM, rantingrick rantingr...@gmail.com wrote:
 Ah ha! Found the answer!

 py {0:010d}.format(1234)
 001234

 py {0:010}.format(1234)
 001234

 py {0:010}.format(1234)
 001234

 py {0:@10}.format(1234)
 @@1234

 I would skip using the {int}{repeat}d syntax and just use the string
 padding since you won't need to worry about the input data type. I
 hate specificity types in string formats. With the old interpolation i
 ALWAYS used %s for everything.

Nope, that doesn't work.

 {0:010}.format(-1234)
'0-1234'

The whole point of zfill is that it handles signs correctly.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Ian Kelly]

On Thu, Sep 29, 2011 at 4:56 PM, rantingrick rantingr...@gmail.com wrote:
 Agree that zfill seems to be redundant with str.format, although your
 suggested syntax is atrocious, especially since a syntax already
 exists that fits better in the already-complicated format specifier
 syntax.

 It's interesting that you find the format specifier complicated. I
 will admit that upon first glance i lamented the new format method
 spec and attempted to cling to the old string interpolation crap.
 However, as you use the new format method you will come to appreciate
 it. It's an adult beverage with an acquired taste. ;-)

I find it interesting that a self-proclaimed API expert like yourself
suggests that it isn't complicated.  The documentation on the format
specifiers is around 6 1/2 printed pages long, and that's not even
including the docs for the string.Formatter API.  Devin is right,
though, in that a better word for it would be dense.

Complicated is not a bad thing here, because with that complexity
comes expressiveness.  It just means that care needs to be taken when
adding new options to ensure that they integrate well with the
existing syntax.

 One thing that may help format noobs is to look at the spec as two
 parts; the part before the colon and the part after the colon. If you
 break it down in this manner the meaning starts to shine through. I
 will agree, it is a lot of cryptic info squeezed into a small space
 HOWEVER you would no want a verbose format specification.

What makes you think I'm a format noob?  The details may have
evolved over the years, but the format specifiers are fundamentally
still the same old printf syntax that we've all been using for
decades.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Ben Finney]

alex23 wuwe...@gmail.com writes:

 On Sep 29, 10:23 pm, rantingrick rantingr...@gmail.com wrote:

  GvR should be texting me every night in hopes that some of my API
  genius will rub off on him.

 Are you off your medication again?

Please don't make personal attacks. If you don't feel like addressing
the content of his message, don't switch to implying he has a mental
illness.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\   Brain, but Tuesday Weld isn't a complete sentence.” —_Pinky and |
_o__)   The Brain_ |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[alex23]

On Sep 30, 3:14 pm, Ben Finney ben+pyt...@benfinney.id.au wrote:
 alex23 wuwe...@gmail.com writes:
  On Sep 29, 10:23 pm, rantingrick rantingr...@gmail.com wrote:
   GvR should be texting me every night in hopes that some of my API
   genius will rub off on him.

  Are you off your medication again?

 Please don't make personal attacks. If you don't feel like addressing
 the content of his message, don't switch to implying he has a mental
 illness.

Fair enough. It was intended more as a ludicrous accusation to his
ridiculous claim. Lord knows there's enough in his posts to focus on
without the ad hominems :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[DevPlayer]

On Sep 27, 10:25 pm, alex23 wuwe...@gmail.com wrote:
 rantingrick rantingr...@gmail.com wrote:
  Since, like the bible
  the zen is self contradicting, any argument utilizing the zen can be
  defeated utilizing the zen.

 And like the Bible, the Zen was created by humans as a joke. If you're
 taking it too seriously, that's your problem.

  If however you want to learn about the accepted rules for formatting
  code then you need to read PEP-8! PEP 8 is our style guide.

Contradiction is only seen by narrow perspectve.

Calling the Bible a joke is used to hurt people, not enlighten them.
Those words show bitter arrogance, not constructive critism as it
ignores how others feel about that book. What benefit to others is
gained by calling someones belief a joke? To put the believers minds
straight? I think not. I think the unsensitive person who attackes
others beliefs, even if illogical or unrealistic, is after some kind
of self grandizement or to illude themself into thinking they know
the truth of the universe and should attack others to prove they do.

Although this is not the place to defend about such things it is also
not the place to attack those same things (that being someone's
faith). There is no real forum to defend a faith or religion, or words
in a book about that, other then where such faiths are in fact
attacked.

However I did laugh at the ironic use of using any-kind of zen to
seriously, even Python's, as that is very unzen-like. That is a
contradiction by it's very own definitions!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Ben Finney]

DevPlayer devpla...@gmail.com writes:

 Calling the Bible a joke is used to hurt people, not enlighten them.

How do you know that?

 Those words show bitter arrogance, not constructive critism

How do you know that?

 as it ignores how others feel about that book.

That strikes me as a good thing; how people feel about a book should not
in any way restrain our criticism of the book.

 What benefit to others is gained by calling someones belief a joke? To
 put the believers minds straight? I think not.

I can't speak for the person who wrote that. But when I call a religious
belief a joke, it is to point out the folly of the belief in the pursuit
of convincing people not to hold beliefs I consider to be foolish.

 I think the unsensitive person who attackes others beliefs, even if
 illogical or unrealistic, is after some kind of self grandizement or
 to illude themself into thinking they know the truth of the universe
 and should attack others to prove they do.

You are wrong to conflate “attack others's beliefs” with “attack
others”.

You are not your beliefs. If your beliefs are shown to be false – even
ridiculous – you can distance yourself from those beliefs. It is even
virtuous to do so.

We must always be free to attack any belief, and encourage everyone to
stop taking it as any kind of personal attack.

 Although this is not the place to defend about such things it is also
 not the place to attack those same things (that being someone's
 faith).

I will join you in deploring any attack on a person. But that's not what
you're doing, and I deny your attempt to shield any idea from ridicule,
in any forum.

Ideas don't have feelings, and you don't get to put people in front of
them as human shields against attacking those ideas.

Any idea is and must be open to attack in any forum; those that can't
survive ridicule deserve to go.

-- 
 \  “Ridicule is the only weapon which can be used against |
  `\   unintelligible propositions.” —Thomas Jefferson, 1816-07-30 |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Tim Johnson]

* DevPlayer devpla...@gmail.com [110928 04:31]:
 On Sep 27, 10:25 pm, alex23 wuwe...@gmail.com wrote:
  rantingrick rantingr...@gmail.com wrote:
   Since, like the bible
   the zen is self contradicting, any argument utilizing the zen can be
   defeated utilizing the zen.
 
  And like the Bible, the Zen was created by humans as a joke. If you're
  taking it too seriously, that's your problem.
 
   If however you want to learn about the accepted rules for formatting
   code then you need to read PEP-8! PEP 8 is our style guide.
 
 Contradiction is only seen by narrow perspectve.
 
 Calling the Bible a joke is used to hurt people, not enlighten them.
 Those words show bitter arrogance, not constructive critism as it
 ignores how others feel about that book. What benefit to others is
 gained by calling someones belief a joke? 

 My wife and I are devout christians, but not fundamentalist. We
 would not take rantingrick too seriously. If _you_ take him
 seriously, you're just giving him 'street cred'.

-- 
Tim 
tim at tee jay forty nine dot com or akwebsoft dot com
http://www.akwebsoft.com
-- 
http://mail.python.org/mailman/listinfo/python-list

[OT] Benefit and belief [was Re: Suggested coding style]

[Steven D'Aprano]

DevPlayer wrote:

 On Sep 27, 10:25 pm, alex23 wuwe...@gmail.com wrote:
 And like the Bible, the Zen was created by humans as a joke. If you're
 taking it too seriously, that's your problem.
[...]
 Calling the Bible a joke is used to hurt people, not enlighten them.
 Those words show bitter arrogance, not constructive critism as it
 ignores how others feel about that book. What benefit to others is 
 gained by calling someones belief a joke? 

It is the same benefit as the little boy who pointed out that the Emperor
was not wearing any clothes. (In real life, the story was called The
Little Boy Who Said The Emperor Wasn't Wearing Any Clothes, and Got
Arrested and Thrown in Prison Together With His Parents for Insulting The
Emperor.)


 To put the believers minds 
 straight? I think not. I think the unsensitive person who attackes
 others beliefs, even if illogical or unrealistic, is after some kind
 of self grandizement or to illude themself into thinking they know
 the truth of the universe and should attack others to prove they do.

There is a difference between attacking ideas and attacking people.

The Bible is a joke attacks the idea.

Insensitive people after self-aggrandisement deluding themselves attacks
the person.

We live in a world where religion is privileged, where governments pander to
the most sick and twisted, hateful, bigoted beliefs because of religion,
where organised conspiracies to support and protect child molesters and
sexual predators are nevertheless looked up to as sources of morality.

There are some ideas that are simply incompatible with civilization, and the
idea that religious beliefs should be beyond criticism is one of them.
Forget money, or even the love of money. The idea that one mustn't
criticise another person's beliefs is the root of all evil.



-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [OT] Benefit and belief [was Re: Suggested coding style]

[Devin Jeanpierre]

 Forget money, or even the love of money. The idea that one mustn't
 criticise another person's beliefs is the root of all evil.

This was a technical discussion, and calling the bible a joke was not
necessary at all. It creates a hostile atmosphere.

Can't you pick somewhere else to attack Christianity?

Devin

On Wed, Sep 28, 2011 at 9:14 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 DevPlayer wrote:

 On Sep 27, 10:25 pm, alex23 wuwe...@gmail.com wrote:
 And like the Bible, the Zen was created by humans as a joke. If you're
 taking it too seriously, that's your problem.
 [...]
 Calling the Bible a joke is used to hurt people, not enlighten them.
 Those words show bitter arrogance, not constructive critism as it
 ignores how others feel about that book. What benefit to others is
 gained by calling someones belief a joke?

 It is the same benefit as the little boy who pointed out that the Emperor
 was not wearing any clothes. (In real life, the story was called The
 Little Boy Who Said The Emperor Wasn't Wearing Any Clothes, and Got
 Arrested and Thrown in Prison Together With His Parents for Insulting The
 Emperor.)


 To put the believers minds
 straight? I think not. I think the unsensitive person who attackes
 others beliefs, even if illogical or unrealistic, is after some kind
 of self grandizement or to illude themself into thinking they know
 the truth of the universe and should attack others to prove they do.

 There is a difference between attacking ideas and attacking people.

 The Bible is a joke attacks the idea.

 Insensitive people after self-aggrandisement deluding themselves attacks
 the person.

 We live in a world where religion is privileged, where governments pander to
 the most sick and twisted, hateful, bigoted beliefs because of religion,
 where organised conspiracies to support and protect child molesters and
 sexual predators are nevertheless looked up to as sources of morality.

 There are some ideas that are simply incompatible with civilization, and the
 idea that religious beliefs should be beyond criticism is one of them.
 Forget money, or even the love of money. The idea that one mustn't
 criticise another person's beliefs is the root of all evil.



 --
 Steven

 --
 http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[rantingrick]

On Sep 28, 6:26 pm, Tim Johnson t...@akwebsoft.com wrote:
 * DevPlayer devpla...@gmail.com [110928 04:31]:
  On Sep 27, 10:25 pm, alex23 wuwe...@gmail.com wrote:
   rantingrick rantingr...@gmail.com wrote:
Since, like the bible
the zen is self contradicting, any argument utilizing the zen can be
defeated utilizing the zen.

   And like the Bible, the Zen was created by humans as a joke. If you're
   taking it too seriously, that's your problem.

If however you want to learn about the accepted rules for formatting
code then you need to read PEP-8! PEP 8 is our style guide.

  Contradiction is only seen by narrow perspectve.

  Calling the Bible a joke is used to hurt people, not enlighten them.
  Those words show bitter arrogance, not constructive critism as it
  ignores how others feel about that book. What benefit to others is
  gained by calling someones belief a joke?

  My wife and I are devout christians, but not fundamentalist. We
  would not take rantingrick too seriously. If _you_ take him
  seriously, you're just giving him 'street cred'.

DevPlayer was not even talking about what i said, he was replying to a
statement by Alex23 who said (and i quote) And like the Bible, the
Zen was created by humans as a joke. Maybe you should spend the next
fifteen or so minutes catching up to the conversation...(ಠ_ಠ)...of
course only *after* you clean that egg from your face.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[DevPlayer]

Oh I was just testing my intellecual-enlightenment-from-ranter-
conversation algorithm found in a previous post. I think my OOP model
failed as I'm just too tired to finished that pattern test. He had
some good points which fit the process I layed out. But the original
topic is just so much better:

Suggested coding style Options



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[alex23]

On Sep 28, 10:12 pm, DevPlayer devpla...@gmail.com wrote:
 Calling the Bible a joke is used to hurt people, not enlighten them.

Y'know, I wouldn't even bother responding to this if Xianists were as
open, forgiving and accepting as their messiah told them to be. It was
a *flippant remark*. If you want to establish intent, aggression and
religio-politico-philosophy from every throwaway remark made on the
internet, you're not really going to have much time for Python.

My belief system isn't your's. Hell, my belief system doesn't even
require that I have *any respect whatsoever* for your's. If it's okay
for Xianists to suffer not a witch to live, then I'm going to assert
my making light jokes about those whose world view is in direct
opposition to mine isn't even comparable to that mentality.

from attitude import humour

(Since we're already fully derailed here, I've always preferred
Borges' suggestion that it was actually Judas who carried the full
weight of man's sins, given that his betrayal of Christ and inevitable
condemnation to hell was a necessity. Then again, I'm able to safely
view this as *allegory* and am genuinely interested in the opinions of
modern minds over something first begun by nomads millenia ago...)


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[DevPlayer]

On Sep 25, 11:41 pm, Chris Angelico ros...@gmail.com wrote:
 On Mon, Sep 26, 2011 at 12:59 PM, Tim Johnson t...@akwebsoft.com wrote:
  BTW: If you like ranting as a spectator sport, I have found the
   Common Lisp newsgroup to be among the most spectacular. But that's
   just me.

 I do, actually, but I don't need to add another newsgroup. Rick
 provides plenty of material here, and I can easily sate myself in just
 a few other places that I frequent. It's quite amusing to watch those
 holy wars erupt...

 And every once in a while, they actually prove quite educative. I'm
 not sure how it happens, nor how to trigger it - hmm, perhaps this
 should be the subject of a scientific paper. On ranting newsgroups
 and how to make them productive.

 ChrisA

I think intellectual growth from rants works like this:

Ranter: Bla bla, bad logic, poor facts, some point.
Others: Bla bla you rant Mr Ranter, some logic, few facts, same point.
Ranter: bad mouthing
Others: bad mouthing back
Ranter: Bla Bla, I don't rant, better logic counter facts, lots of
opinion (to not get called a ranter)
Others: Bla bla, You do rant Ranter, good counter logic and facts,
same point (some reason needs to put Ranter in his place)
Ranter: Super Bla, long winded logic with some strong points, random
but accurate facts out the wazzu (tries to save face)
Others: Acknowleges Ranters point are accurate but claims they don't
apply
Ranter: makes case his points do.
Others: agrees to disagree, silently picks mute Ranter,
Ranter: picks a new topic and starts over.
-- 
http://mail.python.org/mailman/listinfo/python-list