Python becomes the most popular language

[Siwastaja]

This demonstrates the usual issue in almost all high-level languages: they do have constructs which seem like lower level, but these mechanisms are not reliable or predictable.

In this case, one expects that creating objects a and b results in two different objects. Now it's fully understandable if the programming language does not expose the concept of "object identity" to the programmer, at all, but Python chooses to expose it, and offer a keyword to check if the objects are the same. Yet, it's illogical and unexpected that two objects may be combined to become one, with another's name being just an alias to the same object. The fact that this sometimes happens and sometimes not, based on such hilarious decision making process like the magnitude of the stored value, is just a one more funny detail but not that important in itself. The takeaway is to understand that objects may be combined, and the code should not rely on objects not being combined.

Probably if you have problems with this, it's an indicator you should be working in C, instead. I like low-level control, which is why I also like C. It has a few massive footguns, but after you learn those, you get no ugly surprises, while higher level languages always tend to give ugly low-level surprises if you just assume they are easy and not learn them properly.

[Cerebus]

This demonstrates the usual issue in almost all high-level languages: they do have constructs which seem like lower level, but these mechanisms are not reliable or predictable.

No I think you've got that the wrong way around. The idea here is that it is exposing an interface that ought to be high level, but is actually low level and you have to understand the low level [implementation specific] behaviour to use it.

The high level idea is that an immutable entity, let's say the number 1, is always the same entity. So if you have two variables that refer to the entity that is what they do (in an abstract sense), they don't store values, they currently refer to the entity [and you're supposed to know nothing of the concrete implementation, of the idea of values being represented by bit patterns stored in words or bytes, or pointers to words or bytes storing bit patterns]. That's the high level abstraction that is being presented, an attempt to present things in their set-theoretic representation. If that's what one wants to do, fine do it. But don't have window dressing that says you're doing that and then in fact present a god awful mish-mash of an abstract model and physical implementation that can't be treated as the abstract model that you pretend you're presenting.

[Siwastaja]

Yes, the low level "leaks" into high level.

Here, you really should do without thinking about the identity of the objects, at all. If you have to do it, you have already lost due to optimizations like this happening.

[jfiresto]

I tend to the notion that Python is for pragmatists.

[RoGeorge]

What's even stranger is the range of integers for which a is b:  [-5 to +256] inclusive.   

[Cerebus]

What's even stranger is the range of integers for which a is b:  [-5 to +256] inclusive.   

I'm not going to scribble bit patterns and work out what is going on, but I will note that in Smalltalk implementations small integers are represented in a fashion that allows one to have a word hold a pointer to an Integer (which is a fully fledged object) or contain a restricted range of integers that don't occupy a full word. The bits 'stolen' to mark the type vary depending on platform and on some platforms (SPARC, SOAR) allow one to let the hardware sort out whether to call an object method or just do the arithmetic in the ALU (which understands tagged arithmetic). I'd guess it's some similar scheme that 'steals' a (few) bit(s) from a pointer as a type marker.

[tszaboo]

This demonstrates the usual issue in almost all high-level languages: they do have constructs which seem like lower level, but these mechanisms are not reliable or predictable.

No I think you've got that the wrong way around. The idea here is that it is exposing an interface that ought to be high level, but is actually low level and you have to understand the low level [implementation specific] behaviour to use it.

The high level idea is that an immutable entity, let's say the number 1, is always the same entity. So if you have two variables that refer to the entity that is what they do (in an abstract sense), they don't store values, they currently refer to the entity [and you're supposed to know nothing of the concrete implementation, of the idea of values being represented by bit patterns stored in words or bytes, or pointers to words or bytes storing bit patterns]. That's the high level abstraction that is being presented, an attempt to present things in their set-theoretic representation. If that's what one wants to do, fine do it. But don't have window dressing that says you're doing that and then in fact present a god awful mish-mash of an abstract model and physical implementation that can't be treated as the abstract model that you pretend you're presenting.

It would probably be slower, and then you would bitch about that instead of this.

[Cerebus]

This demonstrates the usual issue in almost all high-level languages: they do have constructs which seem like lower level, but these mechanisms are not reliable or predictable.

No I think you've got that the wrong way around. The idea here is that it is exposing an interface that ought to be high level, but is actually low level and you have to understand the low level [implementation specific] behaviour to use it.

The high level idea is that an immutable entity, let's say the number 1, is always the same entity. So if you have two variables that refer to the entity that is what they do (in an abstract sense), they don't store values, they currently refer to the entity [and you're supposed to know nothing of the concrete implementation, of the idea of values being represented by bit patterns stored in words or bytes, or pointers to words or bytes storing bit patterns]. That's the high level abstraction that is being presented, an attempt to present things in their set-theoretic representation. If that's what one wants to do, fine do it. But don't have window dressing that says you're doing that and then in fact present a god awful mish-mash of an abstract model and physical implementation that can't be treated as the abstract model that you pretend you're presenting.

It would probably be slower, and then you would bitch about that instead of this.

Eh? What I, and RoGeorge, are bitching about is the lack of consistency and coherence. Those are rather important to being able to write a correct program that functions correctly.  Why implement a feature if you can't reliably use it?  What's difficult to grasp about that?

[Nominal Animal]

The high level idea is that an immutable entity, let's say the number 1, is always the same entity. So if you have two variables that refer to the entity that is what they do (in an abstract sense), they don't store values, they currently refer to the entity [and you're supposed to know nothing of the concrete implementation, of the idea of values being represented by bit patterns stored in words or bytes, or pointers to words or bytes storing bit patterns]. That's the high level abstraction that is being presented, an attempt to present things in their set-theoretic representation. If that's what one wants to do, fine do it. But don't have window dressing that says you're doing that and then in fact present a god awful mish-mash of an abstract model and physical implementation that can't be treated as the abstract model that you pretend you're presenting.

The reality, of course, is that the is test is only practically useful for mutable objects (for example, in a singleton unit test), and because there is no real world practical use case for the test with immutable objects, Python devs do not care.  (Or, in other words, they implemented the test for all objects, since it is useful for mutable ones; and simply avoided making any exceptions for immutable objects.)

In other words, I think you are lambasting a detail that is not useful in practice, and only has meaning to theorists.  If you don't mind, could you show me wrong, and describe a pattern where this test is actually useful when applied to immutable objects?  One where the objects need to be immutable, and it is not just an arbitrary choice?

I do hope we're not kicking Python just because some of its implementation offends impractical theorists?  If we start down that road, we need to kick the Linux kernel, too; after all, it is monolithic.

[RoGeorge]

...
It would probably be slower, and then you would bitch about that instead of this.

Eh? What I, and RoGeorge, are bitching about ...

Please don't drag me into this, not bitching, in fact I'm having a lot of fun, me just trying to become a Python comedian. 

Found out about immutable integers only this morning.  I would have never thought.  And it was from a topic where somebody was asking about the strip() function.  Yeah, so about the stripping function:

\[\star \ \star \ \star \]
Music:  Tito & Tarantula - After Dark
The clip is from the movie "From Dusk Till Dawn (1996)"



- Never trust a Python stripper!
- Why?

Code: [Select]

$ python3
Python 3.8.12 (default, Jan  2 2022, 01:12:07)
[Clang 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c on freebsd13
Type "help", "copyright", "credits" or "license" for more information.

>>> girl = "Dana"
>>> girl.strip("all clothes")
'Dan'
 



P.S.  In the movie she's not trustable for a different reason.

[PlainName]

lambasting a detail that is not useful in practice

I thought about this and figured it might be a problem if you were collecting objects and wanted to remove duplicates. It's conceivable that two different objects could contain the same data, but they are not duplicates of an object.

But then I figured if you doing this you would embed an ID in each object so you wouldn't be using the objects (arbitrary) address as an ID. But... maybe you're not a programming guru (just got here via Arduino hacking or something) - wouldn't that then mean the language is too sharp for mere mortals to use? That's the kind of argument against using C or other low-level languages: they are too easy to cut yourself badly enough to require stitches.

[Edit: surely not needed but just in case - it's the 'royal' you, nothing personal ]

[Nominal Animal]

I thought about this and figured it might be a problem if you were collecting objects and wanted to remove duplicates.

That's exactly how one would make sure in an unit test that a singleton object really is a singleton.  I just don't see any use case wrt. immutable objects; for those, all uses I can think of, equivalence check (logical equality) works; remembering that Python is a language with automatic garbage collection.

I want this discussion to be clear about which complaints are personal, theoretical, or practical, because the distinction is useful to those who are deciding whether Python is a good fit for their particular use case.

[Also, please note that I am asking Cerebus, because I could be wrong here.  It is always a possibility.  And although I stated it as if a fact, it is only my understanding of the reason why it is so in Python right now, since it is how many if not most Python details get agreed upon; see PEPs.)

[brucehoult]

What's even stranger is the range of integers for which a is b:  [-5 to +256] inclusive.   

I'm not going to scribble bit patterns and work out what is going on, but I will note that in Smalltalk implementations small integers are represented in a fashion that allows one to have a word hold a pointer to an Integer (which is a fully fledged object) or contain a restricted range of integers that don't occupy a full word. The bits 'stolen' to mark the type vary depending on platform and on some platforms (SPARC, SOAR) allow one to let the hardware sort out whether to call an object method or just do the arithmetic in the ALU (which understands tagged arithmetic). I'd guess it's some similar scheme that 'steals' a (few) bit(s) from a pointer as a type marker.

I expect RoGeorge is aware of such schemes, and that (on a 32 bit machine) they normally give you fast "machine" integers in the range -1073741824..1073741823 or possibly -536870912..536870911.

It's really really hard to imagine an implementation of tagged objects in which a range of -5..256 makes sense. That needs 9 bits to represent, with 250 unused values. What would you do with those?

It doesn't make any sense for traditional tagged objects. It doesn't even make any sense for NAN-boxing where the fundamental type is IEEE floating point (usually double precision), and "small" integers, characters, booleans, and pointers are hidden inside the mantissa bits of NaN values.

[Cerebus]

I thought about this and figured it might be a problem if you were collecting objects and wanted to remove duplicates.

That's exactly how one would make sure in an unit test that a singleton object really is a singleton.  I just don't see any use case wrt. immutable objects; for those, all uses I can think of, equivalence check (logical equality) works; remembering that Python is a language with automatic garbage collection.

I want this discussion to be clear about which complaints are personal, theoretical, or practical, because the distinction is useful to those who are deciding whether Python is a good fit for their particular use case.

[Also, please note that I am asking Cerebus, because I could be wrong here.  It is always a possibility.  And although I stated it as if a fact, it is only my understanding of the reason why it is so in Python right now, since it is how many if not most Python details get agreed upon; see PEPs.)

Wrong person to ask as I'm not a Python language lawyer. My take on it is simply one of disliking the inconsistent behaviour. Philosophically, when you assign an integer to a variable in Python you bind the variable to the immutable integer object that has that particular value (obviously in implementation terms you just store an integer value somewhere) so two identical integers (identical values as we'd normally say if we were discussing, say, C) should return True for an is. In CPython* they don't, which is inconsistent. Thusly:

Python 2.7.17 (default, Dec 23 2019, 21:25:34)
[GCC 4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.33.16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 is 1
True
>>> 1024 is 1024
True
>>> 1000000 is 1000000
True
>>> a = 1
>>> b = 1
>>> a is b
True
>>> a = 1000000
>>> b = 1000000
>>> a is b
False
>>> quit()

(I used Python 2 rather than 3 because 3 gives a warning message if you put 'is' between literals which clouds the issue. You still get the same results.)

In practical terms the whole thing probably isn't a problem, I can't think of a single place where I've used 'is' in a generic function in real Python code. But there's a bit of me that says that if there's an inconsistency lurking, then somewhere there's a programmer who is going to get bitten by it. In fact it's more likely to nobble a 'pure' Python programmer who actually writes their Python in Python (that is follows the philosophical precepts of Python when writing their Python), whereas I like most people with prior programming experience tend to bring my baggage with me, so I'm not really writing Python, I'm writing C, or Smalltalk, or FORTRAN, in Python.

*I haven't tried it in other than CPython, there's every possibility that it's different in one of the other implementations.

[Cerebus]

It's really really hard to imagine an implementation of tagged objects in which a range of -5..256 makes sense.

Prexactly, that's why I didn't feel like fiddling with bits - I could sense a headache in the making if I tried. 

[Nominal Animal]

Philosophically, when you assign an integer to a variable in Python you bind the variable to the immutable integer object that has that particular value (obviously in implementation terms you just store an integer value somewhere) so two identical integers (identical values as we'd normally say if we were discussing, say, C) should return True for an is. In CPython* they don't, which is inconsistent.

Where this philosophy stems from, I do not understand.  It sounds nothing like what I've read at python.org.  It sounds more like information theoretical model someone thought up.

For example, the is operator is described in terms of object identity, which in turn is defined in terms of id() built-in function, which is described thus:

Return the “identity” of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. Two objects with non-overlapping lifetimes may have the same id() value.

When describing Python's data model,

Objects are Python’s abstraction for data. All data in a Python program is represented by objects or by relations between objects. (In a sense, and in conformance to Von Neumann’s model of a “stored program computer”, code is also represented by objects.)

Every object has an identity, a type and a value. An object’s identity never changes once it has been created; you may think of it as the object’s address in memory. The ‘is’ operator compares the identity of two objects; the id() function returns an integer representing its identity.

My problem is twofold, and is about this philosophy (or programming paradigm) you described.  One, I cannot see any practical use for it, compared to say how Python documents its objects and their identity.  Two, I do not see how you have determined that the philosophy applies to Python, because nothing in the official documentation I've seen event hints that way.

Like I wrote above, I use Python because it is practical for certain cases, not because of any intrinsic excellence.  I fear that you are applying a philosophy described by theorists, that does not lead to any practical use patterns.  As such, such philophies are useless in my opinion.  Because it does matter to you, I am interested in knowing why.  Unless it's just me failing English again, and you're actually agreeing with Siwastaja.

My take on it is simply one of disliking the inconsistent behaviour.

This I can fully appreciate; and I agree.  It is annoying –– I would say even suspicious! –– that the documentation lies: that in fact, some immutable objects (integers between -5 and 256, inclusive, for Python 3.6.9 on x86-64 in Linux at least) do not actually have an unique identity when using CPython Python interpreter.

As a pure difference observed between official documentation and observable behaviour, like Siwastaja wrote in reply #400, this is illogical and unexpected.  Like I said earlier, it seems obvious to me that this is only allowed (for those integer objects) because the developers believe nobody will notice it in practice.  That kind of purely practical examination is how Python has evolved thus far.

[Cerebus]

Every object has an identity, a type and a value. An object’s identity never changes once it has been created; you may think of it as the object’s address in memory. The ‘is’ operator compares the identity of two objects; the id() function returns an integer representing its identity.

My problem is twofold, and is about this philosophy (or programming paradigm) you described.  One, I cannot see any practical use for it, compared to say how Python documents its objects and their identity.  Two, I do not see how you have determined that the philosophy applies to Python, because nothing in the official documentation I've seen event hints that way.

The description is mine alone, not drawn from anything more than my gleanings of various things I've learned or read about the language over the years. You've just reiterated it there: "Every object  has ..." - that is a philosophical statement. This is philosophy as in the "this is how we want to look at things" sense of philosophy, not the "how many angels can dance on the head of a pin" variety. I'm not suggesting that there's a manifesto anywhere, just that from observation Python has a certain philosophy, as does C, COBOL, Pascal etc.

As to what practical use that philosophy has? Well, it is what moulds the language. You must have encountered discussions that include a phrase like "What would be the most pythonic way to do it?". The very existence of the word is indicative that there is a philosophy of Python (that encompasses everything from the design of the language to coding styles), and if anything that the existence of a philosophy of Python is more important to some people than it is to aficionados of [most*] other programming languages because someone coined the word and it gained currency.

Or you can flip that on its head and say that if a new programming language doesn't have a philosophy then what is the point of having the new language? If it does all the same things, in the same ways, as existing programming languages, just with different syntax then it brings nothing new to the table.

Finally examining the philosophy (in the general sense) of the type systems of programming languages is in itself important in the same way that Russell examining the philosophy of mathematics was important. As you know, Russell discovered problems with, and solutions to the problems of, the very foundations of mathematics. Instinctively I feel we are in Russell territory here asking the question "In the light of these inconsistencies, is the Python type system well formed?" with, at least on my behalf, a sneaking suspicion that the answer might be "no" . Now, as I know I'm not in the least qualified to discuss Russell's logic that's where I'm going to leave it.

This I can fully appreciate; and I agree.  It is annoying –– I would say even suspicious! –– that the documentation lies: that in fact, some immutable objects (integers between -5 and 256, inclusive, for Python 3.6.9 on x86-64 in Linux at least) do not actually have an unique identity when using CPython Python interpreter.

As a pure difference observed between official documentation and observable behaviour, like Siwastaja wrote in reply #400, this is illogical and unexpected.  Like I said earlier, it seems obvious to me that this is only allowed (for those integer objects) because the developers believe nobody will notice it in practice.  That kind of purely practical examination is how Python has evolved thus far.

You're more than entitled to take that position. It's just for me that "purely practical" stepping around the issue feels rather like cleaning the floor by sweeping the dust up, and then putting it underneath the carpet. It will niggle and moreover it make me wonder "What other things might we have missed? Will they be gotchas with practical importance?". It's a bit like Gödel, Russell and the underpinnings of mathematics  (perhaps with a little sprinkle of Turing), for all practical purposes it all worked before they got their hands on it, but now we how to make some bits work better, and perhaps most importantly, we now know where it can't work.

*I've noticed that several of the more recent programming languages tend to attract these neologisms. e.g. Rustaceans for "rust programmers".

[jfiresto]

... What other things might we have missed? Will they be gotchas with practical importance?...

Every language seems to have its gotcha's. If you know one that does not, I am all ears. The question I ask is: how often will I be bitten? With Python it has been about once every thousands of hours of exploratory, original programming. That is easily the best record of the languages I have used – and one reason I use Python.

The last two gotchas were with exec. Both were respectively and sympathetically heard and then understandably reclassified as documentation bugs. Fixing them would have been hard and there is only so much the developers can do. Perhaps that should read fixing one of them was hard, as I can not replicate a gotcha using more recent versions of Python. (Both issues remain open.)

For comparison, I seem to get bitten about once an hour when I do Windows programming. That might explain why I do little of it. Perhaps the issue is I am a poor cut and paste programmer.

[nigelwright7557]

I prefer the strongly typed languages.
At least then the compiler throws it out if I made a mistake.
Add 1 to 1 and getting 11 because the compiler thought the the types were a string and not numbers isnt good.

I got on with Python OK but took a while to get used to the code indentation after 20 years of curly brackets.

[brucehoult]

I prefer the strongly typed languages.
At least then the compiler throws it out if I made a mistake.

*Some* limited kinds of mistakes.

Add 1 to 1 and getting 11 because the compiler thought the the types were a string and not numbers isnt good.

Type - instead of + by accident, or > instead of >= and no compiler will help you.

[nfmax]

Oh how I hate this damn machine,
I wish that they would sell it!
It never does quite what I want,
but only what I tell it

(anon)

[Siwastaja]

Strong (manual) typing is one way of communicating explicit intent to the compiler. The problem with assumptions is, they are prone to go wrong, and then you need to understand how the assumptions are made, actually increasing the mental load when the whole purpose of automation was to decrease it. Unless you somehow manage such "small details" out of your mind and just happen to get it right.

Therefore, I agree with explicit typing, and I find "easy" languages with automatic typing more difficult to use. I did struggle with PHP typing after having some years of limited experience in C++ and C, even though the automatic type system was supposedly "easier".

I would like to see even more explicit control and writing down assumptions in formal ways; for example, add ranges to variables in C (pretty much like Ada/VHDL does).

[Nominal Animal]

As to what practical use that philosophy has? Well, it is what moulds the language. You must have encountered discussions that include a phrase like "What would be the most pythonic way to do it?". The very existence of the word is indicative that there is a philosophy of Python (that encompasses everything from the design of the language to coding styles), and if anything that the existence of a philosophy of Python is more important to some people than it is to aficionados of [most*] other programming languages because someone coined the word and it gained currency.

Or you can flip that on its head and say that if a new programming language doesn't have a philosophy then what is the point of having the new language? If it does all the same things, in the same ways, as existing programming languages, just with different syntax then it brings nothing new to the table.

Ah, now I understand.  As I've said before, I don't like Python because it has nice features, I like it because it has fewer/milder practical downsides than the alternatives.

Similarly, instead of an underlying philosophy as you described, I consider programming languages' based on their practical approach to problem solving and their patterns (which I call their 'programming paradigm').  In my opinion, the difference between philosophy and paradigm is analogous to the difference between models and patterns, or the difference between asking why and how.  (Or, how there is Unix philosophy, and then there is POSIX – not just the extensions to the C standard library, but things like sockets, signals, timers, et cetera.)

In a perfect programming language, both would be well formed and described... but what we have at hand, especially Python, is more like a set of compromises.

Finally examining the philosophy (in the general sense) of the type systems of programming languages is in itself important in the same way that Russell examining the philosophy of mathematics was important. As you know, Russell discovered problems with, and solutions to the problems of, the very foundations of mathematics. Instinctively I feel we are in Russell territory here asking the question "In the light of these inconsistencies, is the Python type system well formed?" with, at least on my behalf, a sneaking suspicion that the answer might be "no" . Now, as I know I'm not in the least qualified to discuss Russell's logic that's where I'm going to leave it.

I understand, and definitely do not disagree.  Perhaps my stance here could be summarised as "True; but the programming languages we currently have are just practical tools full of compromises and less than optimal design choices, their philosophies full of elephant-sized holes, so I do not think analysis at that level is appropriate yet."

You're more than entitled to take that position. It's just for me that "purely practical" stepping around the issue feels rather like cleaning the floor by sweeping the dust up, and then putting it underneath the carpet. It will niggle and moreover it make me wonder "What other things might we have missed? Will they be gotchas with practical importance?". It's a bit like Gödel, Russell and the underpinnings of mathematics  (perhaps with a little sprinkle of Turing), for all practical purposes it all worked before they got their hands on it, but now we how to make some bits work better, and perhaps most importantly, we now know where it can't work.

I can definitely appreciate that.  To me, the situation is more like an earthen floor, sweeping of which for dust is impractical, and see concentrating on the larger debris and unwanted dirt more appropriate for now.  I would love to have a proper floor (programming language with solid underpinnings), but I do not have the, uh, engineering experience in floors?, to construct one myself; so, I have resigned to work with what I have, and help develop better stuff in other, more limited scopes first.  (Like embedded C patterns or a replacement for the C standard library.  Or how to make web based services more secure by leveraging the Unix/POSIX kernel-provided privilege separation mechanisms (process user and groups) and so on, using Python (or any other scripting language) on the backend.)

(Apologies for stretching the analogy so far .)

In systems programming, my attitude shows clearest in that I insist that whenever a program detects an error when dealing with my data, I want it to tell it to me, the user whose data that is.  I care much less whether the program can deal with the error or can work around it –– that would be nice, but much less important to me.  I never trust tools like computers or computer programs the way I trust mathematics, so I am always 'suspicious'.  With Python, I use it for user interface stuff and server-side backend (HTML) processing, which both are at best a "best effort" scheme, without any true guarantees of successful functionality; with much, much heavier emphasis on things like data security, privilege separation/escalation models, and so on.

[Cerebus]

I can definitely appreciate that.  To me, the situation is more like an earthen floor, sweeping of which for dust is impractical, and see concentrating on the larger debris and unwanted dirt more appropriate for now.  I would love to have a proper floor (programming language with solid underpinnings), but I do not have the, uh, engineering experience in floors?, to construct one myself; so, I have resigned to work with what I have, and help develop better stuff in other, more limited scopes first.  (Like embedded C patterns or a replacement for the C standard library.  Or how to make web based services more secure by leveraging the Unix/POSIX kernel-provided privilege separation mechanisms (process user and groups) and so on, using Python (or any other scripting language) on the backend.)

(Apologies for stretching the analogy so far .)

So, to completely round off the analogy - "Python programmer, him live in mud hut!". 

One final thought on this, and then I think we have all had enough of it. This particular oddity, where something has apparent behaviour that can be silently altered by the specific values being dealt with could be called hidden or covert behaviour. It's pretty obvious that covert behaviour is exactly the kind of thing that can be used to create and exploit security holes.

You could have a chunk of software that would pass peer review based on its overt behaviour, but conceals a deliberate vulnerability based on its covert behaviour. Not straightforward or simple, but doable. It's that kind of possibility that has been subconsciously niggling at me and saying "This is bad, worse than the trivial quirk it appears to be.". It gives you something that looks right, but is in fact wrong, and that's all you need to sneak something through a code review.

Just to demonstrate that Python gets used in places where it could have serious consequences we only have to look at the last Python gig I had. We were writing what was planned to go on and become the core network orchestration tool for a very large telco in Python. We configured routing/switching fabrics, we configured load balancers, we configured firewalls. If you could plant an exploit in this it could give you access to reconfigure core networking equipment in any way it liked, certainly in a way that could bypass protections between the core network and the Internet, or just bring the core network to a dead halt that would take weeks to recover from. Precisely because of this we were very security oriented, parameter validation left, right and centre, peer review twice (code review and security review) for every bit of code. Nevertheless I could have smuggled a vulnerability based on this quirk through all that, had I (a) wished to, (b) known of this quirk at the time.

[Bassman59]

Type - instead of + by accident, or > instead of >= and no compiler will help you.

If you do VHDL most of the time, and occasionally drop down into C, you might have done something like this and wondered why it didn't work:

Code: [Select]

    if( foo /= bar) {
       doSomething();
    }

and of course this one is very exciting:

Code: [Select]

    if( foo /= 0) {
        doWeEvenGetHere();
    }