That is true, but of course in Django the field is an object, and it is
the object that knows it's name.
There is nothing to stop you declaring a field in a model called
'person_name' but also doing this in the code :
user_name = instance.person_name
In Django the user_name variabl
The challenge with anything like
result = default if bar is None else bar
or
result = bar if bar else default
or even
result = bar is None ? default : bar
is that sure default is only evaluated once - but in all cases 'bar' is
evaluated twice, and if bar is a function call then no parser
Personally,
I am -1 on the name - I think '-X importtrace' or similar would be
better I think.
I am +100 on the functionality - Unless you put in log messages,
tracking imports is complex - so something like this I can see being
very useful.
I know I don't make the decisions, but it seems
A proposal for a new tool to be implemented -
It is often the case that developer write Code in Python and then
convert to a C extension module for performance regions.
A C extension module has a lot of boiler plate code - for instance the
Structures required for each class, the functions fo
All,
I know that /os.path/ includes a function /expandvars(..)/ which expands
any environment variables in a given path, but from looking at the
/pathlib/ documentation It seems there is
no equivalent to /os.path.expandvars(..) on any class/ in /pathlib/, and
the recommendation seems to be to
On 09/04/2021 19:02, Guido van Rossum wrote:
But if there are two proposals with conflicting semantics for the same
syntax that kills both ideas, doesn’t it? Because apparently it’s not
clear what the syntax should mean.
Surely it depends (if we adopt a proposal) how we document it. You could
We are all familiar with the `with` statement for context managers, so
that the resources are correctly finalized/closed in case of an
exception either in terms
of the resources being allocated of the processing.
It is very common though to wrap the `with block` in an outer `try`
block, since
Dear Anthony,
Greetings from another Anthony (although my friends call me Tony).
Thank you for your suggestion about changes to the Python Syntax.
The Idea of having curly braces with blocks of code has been considered
many times, and every time it has not been accepted.
When you do enough p
On 12/02/2021 07:32, Paul Sokolovsky wrote:
Hello,
On Fri, 12 Feb 2021 18:26:53 +1100
Chris Angelico wrote:
On Fri, Feb 12, 2021 at 6:24 PM Paul Sokolovsky
wrote:
... And on the 2nd thought, that won't work. The reason it works in
JS is that it doesn't have tuples. In Python, "(a, b) => (
