PythonLearn | primary school students are learning Python | Compiler library

Try python 2.7

With *(23,), you are unpacking the values in the tuple (23,) as positional arguments, following the positional arguments that are already defined, namely 3 for a and 7 for b, so 23 would be assigned to parameter c, which is why fun(3, 7, d=10, *(23,)) works, but in fun(3, 7, c=10, *(23,)) you are also assigning to value 10 to c as a keyword argument, so it is considered a conflict as c cannot be assigned with both 23 and 10.

Note that while legal, it is discouraged by some to unpack iterable arguments after keyword arguments, as discussed here, although the syntax is ultimately ruled to stay.

Inside NonMeta.__new__, x is an instance of NonMeta, so the assignment to x.attr is creating an instance attribute for the instance x.

Inside Meta.__new__, x is an instance of Meta, namely a new class. In this case, x is the class WithMeta, so the assignment to x.attr creates a class attribute.

The class statement is, in some sense, syntactic sugar for a call to the metatype. That is,

Your point of view seems to be based on the assumption that what is private or public ( or the equivalent suggestions in python ) is based on the developer who read and write code. That is wrong.

Even if you write all alone a single application that you only will use, if it is correctly designed it will be divided into modules, and those modules will expose an interface and have a private implementation.

The fact that you write both the module and the code that uses it doesn't mean that there are not parts which should be private to keep encapsulation. So yes, having the leading underscore to mark parts of a module as private make sense regardless of the number of developer working on the project or depending by it.

EDIT:

What we are really discussing about is encapsulation, which is the concept, general to software engineering for python and any other language.

The idea is that you divide your whole application into pieces (the modules I was talking about, which might be python packages but might also be something else in your design) and decide which of the several functionality needed to perform your goal is implemented there (this is called the Single Responsibility Principle).

It is a good approach to design by contract, which means to decide the abstraction your module is going to expose to other parts of the software and to hide everything which is not part of it as an implementation detail. Other modules should not rely on your implementation by only on your exposed functionalities so that you are free to change whenever you want to increase performance, favor new functionalities, improve maintainability or any other reason.

Now, all this theoretical rant is language agnostic and application agnostic, which means that every time you design a piece of software you have to rely on the facilities offered by the language to design your modules and to build encapsulation.

Python, one of the few if not the only one, as far as I know, has made the deliberate choice (bad, in my opinion), to not enforce encapsulation but to allow developers to have access to everything, as you have already discovered.

This, however, does not mean that the aforementioned concepts do not apply, but just that they cannot be enforced at the language level and must be implemented in a more loose way, as a simple suggestion.

Does it mean it is a bad idea to encapsulate implementation and freely use each bit of information available? Obviously not, it is still a good SOLID principle upon which build an architecture.

Nothing of all this is really necessary, they are just good principles that with time and experience have been proven to create good quality software.

Should you use in your small application that nobody else uses it? If you want things done as they should be, yes, you should.

Are they necessary? Well, you can make it work without, but you might discover that it will cost you more effort later down the way.

What if I'm not writing a library but a finished application? Well, does that mean that you shouldn't write it in a good, clean, tidy way?

Perhaps try:

just change the for line in rd loop into this:

There are several problems with your code:

• you're using string methods like find() and strip() on the list rd instead of parsing the individual line.
• find() returns the lowest index of the substring if there's a match (since "X-DSPAM-Confidence: " seems to occur at the beginning of the line in the text file, it will return index 0), otherwise it returns -1. However, you're not checking the return value (so you're always assuming there's a match), and rd[srchD + 1:fmLen] should be line[srchD + len("X-DSPAM-Confidence: "):fmLen-1] since you want to extract everything after the substring till the end of the line.
• count and total are not defined, although they might be somewhere else in your code
• with total = fltNum + count, you're replacing the total at each iteration with fltNum + count... you should be adding fltNum to the total every time a match is found

Working implementation:

List-comprehensions can often replace for-loops that add to a list:

You don't need the dot in the format