Most of us pay for a lot of services like netflix, spotify, etc.
We are ok with paying, but not:
- giving money to a user hostile company with a terrible moral track record
- giving money to keep being tracked anyway
- having to log in with a google account that can be locked down any time with no given reason, and will take over your entire android phone even from a single app
- being served ads from other unrelated services using data collected from google service we paid for
Numpy and pandas are their own little island. It's not just dates and time, it's everything.
If you use numpy and pandas, you should also not use Python datetime, generators, most stdlib mathematical functions, the itertools module, random, etc.
It's the first thing you learn if you read any good pandas book, and the first thing I teach in my numpy/pandas trainings.
It has pretty much nothing to do with pendulum.
Basically, half the Python ecosystem is "well, except with numpy/pandas of course".
BS, you can still make a deal with microsoft as a non profit, where the deal gives them an exclusive licence to use the result in exchange for financing.
MS doesn't care about how money it cost, they care about the fact it's their ticket back into the fight with google and apple.
Honestly, I'm pretty picky about the food at buy at the store, and even I can't tell anymore if something is safe appart from raw fruits and vegetables I buy from a local old man I've known for years. And I live in France, with very protective laws, and parents that educated me to choose wisely.
How the average American, with the worst consumer protection laws and a terrible food culture, is supposed to find a way?
It’s not intended to be an exception disproving the rules. It’s a trigger to induce the rational reader to recognize the obviously fallacious hyperbole of accusing the US of having the worst consumer protection law.
> Honestly, I'm pretty picky about the food at buy at the store
Forever chemicals, like PFAs can end up in food, but it is not made to be in food. The nature of this pollution means that trying to prevent environmental pollution to end up in your food is a fool's errand. The solution is to avoid releasing more of the substance in the environment.
For instance, PFAs see a lot of use in water-repellent clothing and material. As these products take rain, some of the repellent is shed in the environment, and contaminate stuff we consume. Awareness about it in the population and people looking to buy something else can lead manufacturers to look for alternatives and develop new lines of clothing.
hardly call it stealing. they decided to no longer work for the previously agreed upon compensation package. the employer found new employees that would do the work they need done.
no one stole anything. I agree and encourage unions and collective bargaining, but a strike breaker is hardly a thief, they are just a worker who needs money like the guy striking
> They steal their livelyhood, it's not a misunderstanding. Should not be legal anywhere.
If you're no longer working your job, it's no longer your livelihood. That's your right of course, but you don't own a job anymore than the company owns you.
The GIL is not a required language feature. Neither Jython nor IronPython have a GIL.
What would it mean to have a language standard? A publication from ISO or ECMA?
I ask because the Python Language Reference at https://docs.python.org/3/reference/index.html seems to be a (terse) language standard. Among other things, it highlights some of the things which are implementation defined, rather than language defined.
It's not a required language feature, but it's most certainly a feature of CPython, and CPython is still effectively synonymous with Python, even if other implementations deviate in various ways from its behavior.
It's been a while since I've followed Python closely but last I heard Python-the-language is de facto defined as "whatever CPython does". Has Python since grown a proper language specification?
Python doesn't have a full specification, but it does have first party documentation that distinguishes between CPython implementation details and language guarantees, in part to support alternative implementations.
The introduction section states that it's not a complete/exact specification. If you're using a Python implementation and have a question, this should answer it. If you're writing a Python implementation and have a question, this may not answer it.
> Consequently, if you were coming from Mars and tried to re-implement Python from this document alone, you might have to guess things and in fact you would probably end up implementing quite a different language. On the other hand, if you are using Python and wonder what the precise rules about a particular area of the language are, you should definitely be able to find them here. If you would like to see a more formal definition of the language, maybe you could volunteer your time — or invent a cloning machine :-).
> If you're writing a Python implementation and have a question, this may not answer it.
Depends on the question. If your question is, say, "how should I implement the built-in types", yes, the language reference won't answer that question. But if your question is "what does my implementation have to do to count as an implementation of the Python language", then yes, the language reference does answer that question--since the language reference is what defines the Python language.
To me that is a "specification" of the Python language. It's not a specification of the implementation of the language, but why should that be required for something to be considered a language specification? The whole point is to specify what is required to define the language without specifying every detail of the implementation.
> if you were coming from Mars and tried to re-implement Python from this document alone, you might have to guess things and in fact you would probably end up implementing quite a different language
Yes, I know that statement is in the Introduction, but I think it's rather ill-considered. If my implementation is consistent with the language reference, on what grounds would someone claim it was not an implementation of Python but a "different language"?
On the grounds that we live in the real world, not a world where anything written down is a true and complete description of reality. "Technically correct" is sometimes a synonym of "incorrect".
By your criterion, no programming language has a language specification at all. I don't think that's a useful way to look at things.
I would like to see some indication from the people who say that the Python Language Reference I gave a link to does not qualify as "language specification", of what would qualify. Specific examples would be nice.
I would say that that is intended as documentation for users (includong implementors of tools targeting the language), not a specification for implementors of Python, but I would agree that it is largely usable in either role; my point in the GP was that something distinct called “the Python Language Specification” doesn't exist, but that a (not necessarily complete, from a language implementors perspective) specification distinct from the implementation behavior of CPython does effectively exist in the documentation.
I don't see why not. The "Introduction" section specifically mentions different implementations and distinguishes implementation details, which can vary by implementation, from the language reference itself, which defines what every implementation has to meet to be considered an implementation of the Python language.
> my point in the GP was that something distinct called “the Python Language Specification” doesn't exist
And that's the point I'm disputing; AFAIK the language reference I linked to is that something distinct, even if it isn't called a "Language Specification" but instead a "Language Reference". Either way it defines what the Python language is.
So, we rather explicitly agree that Python has nothing called a “language specification”, but that its published first party documentation includes what is, functionally, a specification of the language distinct from CPython implementation details?
> we rather explicitly agree that Python has nothing called a “language specification”
No, we don't. I have already said explicitly that I think the Python Language Reference is such a thing. (I am ignoring quibbles about it being called a "reference" instead of a "specification".) If you think it isn't, why? What does count as a "language specification" in your view? Do you have any specific examples that you can contrast with Python?
This implies that, if CPython differs from that specification in any way, it is not, in fact, Python. What have I been using all these years, I wonder?
This specification does not mention the GIL anywhere, which means it is, as the GP said, an implementation detail. Other implementations of Python that do not have the GIL are still "Python" implementations because they meet this language specification.
That is not a specification. A specification is a prescriptive document of how a system is required to work whereas a reference is a descriptive document of how a system happens to currently work. Python has a reference, in fact it has many references that even contradict one another in subtle ways, but it does not have a specification.
I mean, I can see the point if there are multiple commercial competitors in the market, as there is with C/C++, or if the implementation is proprietary and the users want to avoid vendor lock-in.
But the Minimal BASIC of ANSI X3.60-1978 never did catch on for any of the BASICs I used in the 1990s, and the Full BASIC of ANSI X3.113-1987 was a flop, so clearly it's possible to put a lot of time into a standard only to have it be irrelevant.
I never mentioned any advantage or disadvantage. I am only stating a fact about the current state of Python.
Python does not have a specification or a standards document, it has a reference that describes how Python happens to work and the reference is a great resource for people to familiarize themselves with the language but it should simply be clear that its purpose is to reflect the existing state of the language rather than to specify how Python works.
Because the original comment was about the appropriateness of writing Python code according to the reference implementation as opposed to writing Python code strictly according to the reference document. Some people are arguing that the reference documentation is in some sense authoritative and the only resource that should be used to define Python's semantics. In particular the issue at hand is whether the GIL is a part of the semantics of a Python program.
As my position is that the CPython implementation is the reference implementation for Python and as the GIL is an integral part of that implementation, then the GIL does form a part of Python's semantics regardless of whether the reference documentation mentions it or not.
The Python reference documentation is not a specification and it's not intended to be one.
Then why are different implementations of Python all implementations of Python? What makes them implementations of Python rather than different languages?
I've already given my answer: they all meet the language reference I linked to (yes, the word "reference" appears in its title, not "specification"; that's just another quibble).
Haha, no they don't all meet the language reference you linked to and if you used them you'd know that!
Python is a lot more like LISP than it is C++. There are many flavors of Python, from MicroPython to GraalPython to Cyston and literally dozens of them. They most certainly do not all meet the language reference you linked to and they all have quirks here and there.
A language does not need a specification in order to exist or to have a name. What matters is that people use it and get work done with it, and ultimately if looks like a Python and quacks like a Python, then it's fine to call it a Python.
Whether it is a specification or a reference doesn't really matter for this discussion. What matters is that it is the closest thing to a specification that exists for Python. Assuming anything beyond it ties the program to internals of a specific implementation. Internals for which the vendor might have different intentions about keeping stable or change than users expect.
It's absolutely pertinent to this discussion, this whole discussion is about whether the GIL is part of the semantics of a Python program or not. My position is that it is because the GIL is a part of the CPython reference implementation.
Others object saying that the Python reference document is what specifies its semantics, not the reference implementation.
My position is that both the CPython reference implementation and the reference documentation are valid sources that document Python's semantics and that they both can and should be used.
Both of the former provide stronger promises about how likely changes in the future are. For the former, user input and coordination is absolutely required.
Implementation details are documented to allow performance optimizations and to give insight into why certain things are how they are. Therefore, users can reasonably expect that the vendor won't cause performance regressions for existing code. However, it is unwise to derive semantics from them, even if they are technically documented in that way.
One of the biggest disadvantages of relying on implementation details is that it makes it way more troublesome for the vendor to maintain and improve the product.
Anyways, the GIL and the presence of possible concurrency bugs are completely orthogonal things as the GIL has always only served to prevent corruption of runtime data structures, not of user code.
> this whole discussion is about whether the GIL is part of the semantics of a Python program or not. My position is that it is because the GIL is a part of the CPython reference implementation.
And my position is that it is not because there are other implementations of Python that do not have it, and which everybody agrees are implementations of Python.
Not only that, but the very language reference that I linked to explicitly distinguishes CPython implementation details from the language itself. So the Python dev team does not appear to agree with your position.
You're quibbling. By your definition, no programming language has a "specification". Every language has implementations that do things that aren't explicitly described in any document.
Plenty of languages have a specification. C++, Java, C# all do.
Some languages do not, such as Python and Rust.
The ISO C++ committee even uses quite strong language about the C++ standard and makes it a point to differentiate between the C++ specification and C++ references:
>The standard is not intended to teach how to use C++. Rather, it is an international treaty – a formal, legal, and sometimes mind-numbingly detailed technical document intended primarily for people writing C++ compilers and standard library implementations.
Does every C++ implementation do exactly what is in the C++ language specification, no more, no less?
Same question for Java and C#.
If the answer to all of these questions is "no", as I believe it is, on what grounds do you claim that these languages have a specification, while Python and Rust do not?
Yes the C++ and Java implementations do exactly what is in the language specification. The C++ specification explicitly allows languages to do more, but it can not do less. I believe Java has a similar clause but I'm not sure.
The grounds that I claim is that you can read them, here they are:
Note what the actual C++ standard states, and I quote:
>This document specifies requirements for implementations of the C++ programming language. The first such
requirement is that they implement the language, so this document also defines C++. Other requirements
and relaxations of the first requirement appear at various places within this document
> the C++ and Java implementations do exactly what is in the language specification
The number of Google hits I get when I search on "C++ implementations that do not meet the language specification" does not seem to support this claim.
> Note what the actual C++ standard states
But your position with respect to Python is that it doesn't matter what the "standard" states because the actual definition of the language is in its reference implementation. Why are you now shifting your ground?
> That is an incredibly weak and ill-informed method for vetting technical matters.
So is your claim that, because a "standard" says something and claims it's a "specification", that is sufficient to guarantee that every implementation does exactly what the "standard" or "specification" says.
> Python doesn't have a standard
Again, you're quibbling. It has a language reference, which I linked to, and which is what is used to determine what implementations count as Python implementations.
At this point I don't think we have enough common ground for a useful discussion.
>So is your claim that, because a "standard" says something and claims it's a "specification", that is sufficient to guarantee that every implementation does exactly what the "standard" or "specification" says.
It's the other way around, a standard specifies the requirements of a conforming implementation, and then an implementation can claim conformance with respect to that standard. With C++, many well-known implementations do claim conformance to the standard such as MSVC, GCC and Clang. With Python no one makes such a claim, not even the CPython reference implementation, because there is no standard to conform to. On the contrary what you do find are implementations that try to be compatible with CPython reference implementation specifically, such as PyPy and Pyston but no one claims to conform to the Python reference manual. The reference document simply describes how some Python implementations happen to work, but it does not prescribe how a Python implementation is required to work in order to be in compliance.
If tomorrow CPython decides to add a new feature to the language, then the reference will be updated to include this change because the reference is a reflection of the implementation.
If tomorrow the C++ specification changes, then it's GCC or any compiler that claims conformance that will update to include that change because with C++ it's the implementation that is a reflection of the specification.
That's the key difference between a descriptive document and a prescriptive document. This may seem like a quibble as you put it, but quibbles can lead to multimillion dollar lawsuits as Microsoft learned in the 90s when they claimed to have an implementation of the Java specification and then were sued by Sun Microsystems because Microsoft's implementation did not in fact conform to the Java standard.
Microsoft ended up paying 20 million dollars over this so called "quibble":
The C and C++ specifications are rather infamous about being incomplete, i.e., containing features that might lead to undefined behavior. On the other hand, Java is quite comprehensive. It is one of the earliest instances of languages specifying a memory model.
