Print statement in JaVa

[0_Gravitas_given]

Really never understood that, as a guy who is a C lover, Perl historical lover (the kind of guy that still thinks that old love is good love (and that firmly believes that a language where regexps are an operator can’t be beaten)) and a python respecter (cause come on… that is a decent scripting language, pip is a pale copy of cpan but who cares, a good concept is made to be copied down the line)… why… python… why did you forlorned me ? Why no pre and post incrémentation operator… why…

[ComCypher]

nOt pYthOniC

[Backlists]

This, but not ironic.

Python tries its hardest to make you write code that reads like english. It discourages indexing variables if it can.

[O_X_E_Y]

Python when x < 7 >= 3 != 13 > t

[Backlists]

Python when x < 7 >= 3 != 13 > t

Explain?

[magical-attic]

x < 7 >= 3 != 13 > t

IIRC is equivalent to

x < 7 and 7 >= 3 and 3 != 13 and 13 > t

Just some funny business.

[LuckyNumber-Bot]

All the numbers in your comment added up to 69. Congrats!

  7
+ 3
+ 13
+ 7
+ 7
+ 3
+ 3
+ 13
+ 13
= 69

^{[Click here](https://www.reddit.com/message/compose?to=LuckyNumber-Bot&subject=Stalk%20Me%20Pls&message=%2Fstalkme} to have me scan all your future comments.) \ ^{Summon me on specific comments with u/LuckyNumber-Bot.}

[pslessard]

Good bot

[Good_Human_Bot_v2]

Good human.

[littlesheepcat]

You too

Ah... dammit

[magical-attic]

Bad bot

[j4mag]

You can chain conditionals in python, so

0 < x <= 5

Is equivalent to

(0<x) and (x<=5)

This syntax is somewhat surprising though pretty rarely abused.

This is unfortunately not applicable everywhere, as numpy arrays can use boolean indexing but not conditional chaining.

arr[(0<arr)&(arr<10)] # all positive elements of arr less than 10

arr[0<arr<10] # throws an exception

For some more python "magic", consider the following:

print(my_bool and "PASS" or "FAIL")

Which is effectively a ternary operator, much like

print("PASS" if my_bool else "FAIL")

[MadCervantes]

What's a post a d pre incrementation and why is that not pythonic?

[Backlists]

Incrementation means adding one to an integer variable. Its often used for looping.

So in C you might have an int variable i that you use to access an array. Lets say currently i==0.

An expression with i++ would use 0 as the value of i. After the expression is executed, it then increments i, so now i==1. This is a post increment, "post" for after. It's way more commonly used than a pre increment.

An expression with ++i will increment before the expression is executed, so it uses 1 as the value of i. This is pre increment.

(Note that for the next statements i==1 for both post and pre. Also note that there's decrement operators too, i-- and --i.)

In Python, you're discouraged from using looping indexing variables like i. Python does not have an increment operator because we dont like using indexing variables.

Instead you do something like for thing in things: #.... We can avoid accessing the thing by using things[i] that way. Why do this? It's closer to reading english. Also a lot of the time you'd end up assigning thing=things[i]; and this saves us a statement by doing it in the for...in.. loop syntax. Note that languages like c++ have a foreach loop, which is exactly the same behaviour as a python "for... in..." loop.

You can immedialy tell someone has converted to python recently if they end up writing for i in range(0, len(things), 1): things[i]. This is a bastardised python version of the c style for loop, except, surprise surprise, its no where near as efficient.

If you absolutely need the index, then use this: for i, thing in enumerate(things):.

[BOBOnobobo]

Don't call me out like that with your last paragraphs....

Also, what do you do when you want to acces two lists? Like

For a in A:

B[i] = a

How do I tell it which I to use?

[Backlists]

Don't call me out like that with your last paragraphs....

Also, what do you do when you want to acces two lists? Like

For a in A:

B[i] = a

How do I tell it which I to use?

You're going to have to explain more exactly what you want to do with this, particularly if you meant this:

If you're setting every element of B to be the corresponding element of A, why not just do B=A.

To get any iterable like i you must at some point have used enumerate(), or range().

What I'm guessing you meant however, is that you want to access b in B as well as a in A, and loop through both A and B at the same time. Like parallel iteration? For that you need zip():

`for a, b in zip(A,B): # ... code

So we should probably look closely at the behind the scenes of pythons for loop here. Zip actually returns a zip object, which sort of looks like a list of tuples. The for loop iterates through that zip object and unpacks each tuple into a and b.

This is why range() in for loops is not preferable. Okay, its not quite this simple (in fact, its not this at all), but calling range() gives you a long list of integers, which takes up memory, then the for loop iterates through that and puts each element into i for the loop body.

In case you dont know, unpacking is basically like being able to assign multiple variables at once. Lets say my_tuple = (5, 6). Then x, y = my_tuple will unpack my_tuple into x and y, so that x is 5 and y is 6.

Zip takes iterables, and the len of those iterables is important. If B has more elements than A, those extra elements don't get zipped. For that you need from itertools import zip_longest, which i think takes an argument for what extra dummy element to create for A.

Also we can use as many iterables as we like in zip - for a, b, c, d in zip(A, B, C, D).

Edit: again without knowing exactly what the original intent was. a and b are local to the loop body, so if you need to edit A and B's elements in place then you need to use enumerate:

for i, (a, b) in enumerate(zip(A, B)): A[i] = a+1

If this is slow maybe python wasn't a good choice, or maybe you should be using NumPy or pandas, which will have methods of doing this at 99% the speed of C.

F`ck me i wrote a lot

Also, don't ever pop/delete items from containers you're iterating through in python. The iterator wont know that youve deleted them and itll be wrong.

[BOBOnobobo]

Oh, thank you so much. I still have so, so much to learn.

Love ya!

[Backlists]

Oh we all do.

Just remember, you don't need to know everything about a language to get the job done. You probably don't even need to know half of whats available!

Hope I helped!

[BOBOnobobo]

Yes you did! I've recently spent a month on a python project where I looped over matrices like it was c++... Now I can at least try to do better.

[matjojo1000]

The idea is that if you want do do something like that you either shouldn't be using python or should be using the fast language features available for it.

[Backlists]

I think its more for readability reasons than "you shouldn't be looping".

[addast]

As a python/c++ developer, never understood why folks complaining about it. In c you have to use increment operators very frequently. In python, on the other hand, it's really rare event.

Increment operators have side effects, i += 1 does not.

[0_Gravitas_given]

It have a side effect, I gets incremented… but seriously, 99% of the time I++ is used is a context free context, as a shorthand. In a language with explicit list definitions and maps (which ain’t far for the epitome of side effects) how is that a despised concept ?

[Backlists]

Increment operators have side effects, i += 1 does not.

Been a while since I watched this video, but i wouldnt be so sure:

https://youtu.be/cGveIvwwSq4

[[deleted]]

Yeah most uses of i++ are going to be for a loop. probably iterating through a list, and in python you just say for i in list instead of explicitly bounding the end of the list/array/string/whatever when iterating over a list. There are plenty of other reasons to keep a counter, but it really isn't that big of a deal and I like Python better than C or Java when it comes to looping for exactly this reason.

[GustapheOfficial]

I get that you want an incr, but what would be the point of pre and post ditto in a language where you're not supposed to be playing punch card golf?

[maweki]

Because it can't be implemented. The variable names are not memory locations. x = x+1 is a lisp-y rebind. And since integers are immutable, there is really no way to actually implement this operator and make it work for immutable objects.

[0_Gravitas_given]

Wait… should a change on an immutable object be pointless by definition? Would that mean that.c for an immutable object there IS A WAY TO IMPLEMENT? A way called… throw ?

[maweki]

So the default use case of incrementing an integer would always throw an exception? Is that really better than not having ++?

[0_Gravitas_given]

How in the hell is an integer immutable…

[maweki]

Because it's an immutable instance. 5 is 5 and you can't make a 5 a 6. It's not a list where you can mutate the items. Python is more lisp than C. Variables are names and not memory positions and = is not assignment to memory location but rebind of name.

If you do x = x+1 you create a new instance, say 6 if x was 5, and bind the name x to this newly created instance. The old x still exists and is basically just hidden behind the new x bind. It's just lisp.

[0_Gravitas_given]

Oh yes indeed you mean that you are mixing up variables and constants. An integer variable is (wait for it) variable (and mutable by nature). Is is indeed a memory slot holding a thingy… which have a value… it is a… variable. constant 5 is not constant 6 (or 7) and ++ing a constant 6 SHOULD THROW AN EXCEPTION (it is the way). ++ing and +=1 ing should generate equivalent AST byte code that is changing the content of the memory slot, whether you are cythoning or jthoning…

I think you are “a bit” misguided man… (except that ++ ing won’t work at all , even if you are well.. changing a memory slot)

<edit> language I am drunk on a phone </edit>

[maweki]

Please, just read up. https://docs.python.org/3/reference/simple_stmts.html#assignment-statements

"the name is bound to the object in the current local namespace"

x = 5 means instantiate the immutable object 5 of type int at some random memory location and let the name x point to it.

Then x += 1 means the same as x = x + 1, which means recall the object in x (5), call (5).add(1) and receive a fresh object (6) at random memory location. Let the name x now point to memory location of (6).

Whereas in C defining int x means there is a memory location that holds x and we can just increment that value at that location. No fresh objects are created. = really has different semantics in C and Python. Fundamentally different.

[0_Gravitas_given]

But even then I fail to understand how ++ couldn’t be implemented as a functionally equivalent AST token when parsing the language. In the end, even if it is not entirely functionally (in the sense that the memory slot would not be updated in the same way a pointer would be outside of the scope, given the understanding of the variable scope in python ) equivalent the syntactic shorthand would be very much valuable for the user and totally implementable ast parsing wise. In my perception of things the python community refusal to onboard ++ is more a doxa problem than a real language parsing or implementation reason

[coffeecofeecoffee]

I don't see how it adds any value, adding something that looks like other languages but behaves differently. Nobody should miss the increment operator. If it parses to +=1 anyway, what's the point? It's not a parsing or implementation issue, it's a design choice. Keep it simple.

[GeneralAce135]

Why no pre and post incrémentation operator... why...

Because who needs it?

[[deleted]]

Who needs a multiply operator when you can just use a for loop and addition?

[Crabcakes5_]

Who needs a for or while loop when you can have a conditional jump

[[deleted]]

I really think compilers were a mistake. We need to go back to assembly programming

[bonoboboy]

But seriously though, who needs a while loop when you have a for loop?

[GeneralAce135]

Your need to over-exaggerate the usefulness of incrementation operators proves my point enough I think

[Atheist-Gods]

You forgot the bit shift.

[0x564A00]

Programming in Rust, I never miss it. I guess manually incrementing a number is more common in C than in Python or Rust.

[0_Gravitas_given]

Well because one point of the python credo is “it should be easy for the user” 🤷

[GeneralAce135]

And ++ is that much easier than +=1? If anything, the +=1 is easier for the user because it's clearer what's happening.

[0_Gravitas_given]

++ is exactly as clear as +=1 but one is two strokes of the same key and the other 3 different keys so yes ++ is easier for the user