[Python-ideas] Re: Extract variable name from itself

[anthony.flury via Python-ideas]

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 variable will only have the name 'person_name', 
but not user_name, as the field objects need to know their names on the 
model (and their names on the views/forms).




-- Original Message --
From: "Rene Nejsum" 
To: python-ideas@python.org
Sent: Saturday, 4 Nov, 23 At 08:13
Subject: [Python-ideas] Re: Extract variable name from itself

A little late, but the requirement to "Extract variable name from 
itself" is widely used in Django. Each field in a Django model, knows 
it's own variable name




user_name = models.CharField(...)



The instance of CharField knows that it's variable name is "user_name", 
so that it can name the row in the database the same.




On startup Django runs through the Model class searching for instances 
of Field and gets the name that way


___

Python-ideas mailing list -- python-ideas@python.org

To unsubscribe send an email to python-ideas-le...@python.org

https://mail.python.org/mailman3/lists/python-ideas.python.org/

Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SJUKWXOJY6CLPAVTH4NZHDNFXND6USDM/


Code of Conduct: http://python.org/psf/codeofconduct/



-- Anthony Fluryanthony.fl...@btinternet.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QN7Y4JQIE2MLPS3THW5GBXDAB673FUV5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[anthony.flury via Python-ideas]

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 is clever 
enough to diagnose all possible side effects of calling bar() twice, or 
even detect that bar can be cached, so it will always be called twice.


In Python then a better way might be

result = temp := bar() if temp else default

This way only bar() and default are evaluated and invoked once.


-- Original Message --
From: "Rob Cliffe via Python-ideas" 
To: "Dom Grigonis" ; "Jothir Adithyan" 


Cc: python-ideas@python.org
Sent: Monday, 17 Jul, 23 At 16:09
Subject: [Python-ideas] Re: Proposal for get_or function in Python 
dictionaries




On 15/07/2023 21:08, Dom Grigonis   wrote:

   Just to add. I haven’t thought about evaluation. 
Thus, to prevent   evaluation of unnecessary code, introduction of 
C-style expression   is needed anyways:




1. result = bar   is None ? default : bar





The below would have to evaluate all arguments,   thus not 
achieving benefits of PEP505.




2. result = ifelse(bar is None, default, bar)







So I would vote for something similar to:




result = bar is None ? default : bar






Where default and bar is only evaluated if needed. Although 
not to the extent as initially intended, it would offer 
satisfiable solutions to several proposals.



  Well, default is only evaluated if needed; bar is always 
evaluated.

 What is wrong with the Python equivalent

 result = default if bar is None else bar
 or if you prefer
 result = bar if bar is not None else default

 Perhaps you didn't know about this construction?
 It does exactly the same as the C version and is more readable. 
Or am I missing something?

 Best wishes
 Rob Cliffe
 ___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/ 

Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4QBAYBAT6EZFILNS2MCK3D6XW4LNRDZ5/ 

Code of Conduct: http://python.org/psf/codeofconduct/ 



-- Anthony Fluryanthony.fl...@btinternet.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/552SFNHUTBOON7FHZQLSKKIQNO6ELEGS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal: -X importcache to supplement -X importtime for loaded modules

[anthony.flury via Python-ideas]

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 if this really is only a 
couple of lines, and all the test cases pass this (or something very 
similar) should be a considered for 3.12.


Thank you Noah,


-- Original Message --
From: "Noah Kim" 
To: python-ideas@python.org
Sent: Saturday, 11 Feb, 23 At 00:07
Subject: [Python-ideas] Proposal: -X importcache to supplement -X 
importtime for loaded modules


All,

I'm writing to propose an adjacent interpreter flag to `-X importtime`: 
`-X importcache` (open to alternative naming).



While `-X importtime` is incredibly useful for analyzing module import 
times, by design, it doesn't log anything if an imported module has 
already been loaded. `-X importcache` would provide additional output 
for every module that's already been loaded:



```

import uuid

import time: cached| cached |   _io
import time: cached| cached |   _io
import time: cached| cached |   os
import time: cached| cached |   sys
import time: cached| cached |   enum
import time: cached| cached | _io
import time: cached| cached | _io
import time: cached| cached | collections
import time: cached| cached | os
import time: cached| cached | re
import time: cached| cached | sys
import time: cached| cached | functools
import time: cached| cached | itertools
import time:   151 |151 | _wmi
import time: 18290 |  18440 |   platform
import time:   372 |372 |   _uuid
import time: 10955 |  29766 | uuid
```


In codebases with convoluted/poorly managed import graphs (and 
consequently, workloads that suffer from long import times), the ability 
to record all paths to an expensive dependency--not just the 
first-imported--can help expedite refactoring (and help scale 
identification of this type of issue). More generally, this flag would 
provide a more efficient path to tracking runtime dependencies.



As a proof of concept, I was able to hack this functionality into `-X 
importtime` by adding a couple lines to `import_ensure_initialized` in 
`Python/import.c` (hence the output above). A separate flag is probably 
desirable to preserve backwards compatibility.



Looking forward to your feedback,
Noah










 ___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/ 

Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GEISYQ5BXWGKT33RWF77EOSOMMMFUBUS/ 

Code of Conduct: http://python.org/psf/codeofconduct/ 

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ENFJY2RP73IYPUSRVGHBPNELS5JVQLAA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] New Tool Proposal

[anthony.flury via Python-ideas]

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 for Module 
initialization etc.


My Idea is a simple tool that uses introspection tools to take a Python 
module and to generate the relevant boiler plate for the module - 
including blank functions for the module classes and for methods. This 
tool would use type annotations (if given) to make sensible choices for 
parameter and attribute types, including using int and float directly 
rather than Internal objects (depending on tool options).


The idea is that the C extension module would present the same 'API' as 
the original Python module.


The tool would not attempt to write the C code within the functions/methods.

I am aware of the challenges writing this tool, but I think a tool could 
make a good fist of the conversion.


-

What do you think ? Would you use the tool if provided ?

If there is interested I probably could develop a version 0.1, but it 
would be useful to know if there is interest and if there is anyone else 
interested in joining me in this journey.


--
Anthony Flury
*Moble*: +44 07743 282707
*Home*: +44 (0)1206 391294
*email*: anthony.fl...@btinternet.comBEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:anthony.fl...@btinternet.com
FN:Anthony Flury
NICKNAME:Tony
N:Flury;Anthony;;;
TEL;TYPE=home;VALUE=TEXT:01206 391294
TEL;TYPE=cell;VALUE=TEXT:07743282707
UID:c00fc9c3-a56a-4584-8886-6466cf32b9c8
END:VCARD
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TEGZUBYCSB4IFP6EWMPCPHDILVBNCFML/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Missing expandvars equivalent in pathlib

[anthony.flury via Python-ideas]

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 use /pathlib/ to do any and all path 
manipulations, with the exception of expanding environment variables.


It appears that the recommended /pathlib/ compatible code to fully 
convert any file path (which may have environment variables and or ~ or 
~user constructs) to a fully resolved absolute path is :


   import os.path

   import pathlib

   given_path = input('Provide the full path')

   abs_path =
   
pathlib.Path(os.path.expandvars(pathlib.Path(givenpath).expanduser())).resolve()

It seems to me that /pathlib.Path/ would benefit massively from an 
/os.path.expandvars(..)/ equivalent - so that the equivalent code could be :


   import os.path

   import pathlib

   given_path = input('Provide the full path')

   abs_path = pathlib.Path(givenpath).expandvars().expanduser().resolve()

I know the need to do this is likely to be a corner case, but even still 
it continues dependency on /os.path/ for those programs that need to 
resolve environment variables in paths, and increases the cognitive load 
for this operation, , and it seems like a missed feature in /pathlib/


A change such as this shouldn't affect backwards compatibility.

What do people think - have I missed something or is pathlib missing 
something ?



/Pathlib documentation
/

   /https://docs.python.org/3/library/pathlib.html#module-pathlib/


--
Anthony Flury
*Moble*: +44 07743 282707
*Home*: +44 (0)1206 391294
*email*: anthony.fl...@btinternet.comBEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:anthony.fl...@btinternet.com
FN:Anthony Flury
NICKNAME:Tony
N:Flury;Anthony;;;
TEL;TYPE=home;VALUE=TEXT:01206 391294
TEL;TYPE=cell;VALUE=TEXT:07743282707
UID:c00fc9c3-a56a-4584-8886-6466cf32b9c8
END:VCARD
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IJSOTVIDYLWRYEXFZCOFWSCIYHORQS6Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python Idea - extension of 'with'

[anthony.flury via Python-ideas]

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 
argue that very few syntax elements are entirely clear unless we explain 
it - which is what the point of the documentation.


For example for someone who doesn't know what 'with' does, it isn't 
necessarily clear (just from the syntax) that 'with' ensures finalizing 
of resources when an exception occurs - the documentation has to explain 
that.


IF we reject a syntax because it isn't self-explanatory that sounds like 
a bad precedence.


--
Anthony Flury
*Moble*: +44 07743 282707
*Home*: +44 (0)1206 391294
*email*: anthony.fl...@btinternet.com 
<>___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6Q6BEU6URZUSWJPZWJ4EKTICY2Q7ZQBZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Python Idea - extension of 'with'

[anthony.flury via Python-ideas]

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 although we know that the resource has been closed, at an 
'application' level it is still neccessary

to deal with the exception - an example might be :


   try:
    with open('config.cfg', 'r') as cfg:
   # Process the open  file
    config = load_config(cfg)
   except FileNotFound:
    logging.info('Config file not found - using default configuration')
   except PermissionError:
   logging.warning('Cannot open config .cfg - using default configuration')
    config = default_config()
   else:
    logging.info('Using config from config.cfg')

It struck me that this is probably quite a common idiom, and we have the 
main processing (of the opened resources) indented twice just to accommodate

the outer try block.

I was wondering whether a worthwhile extension might be to allow the 
`with` statement to have an `except` and `else` clauses which would have 
the same
semantics as wrapping the `with` block with a try - for example the 
above would now look like:



   with open('config.cfg', 'r') as cfg:
    # Process the open  file
    config = load_config(cfg)
   except FileNotFound:
    logging.info('Config file not found - using default configuration')
   except PermissionError:
    logging.warning('Cannot open config .cfg - using default
   configuration')
    config = default_config()
   else:
    logging.info('Using config from config.cfg')

Treating the 'with' as an implied `try` would reduce the march to the 
right - now the key processing of the resource is now indented only one 
level - and the association of the exception

from the `with` block is syntactically clear.

I am not good enough with core development to put together a working 
prototype, but I can imagine that this simple extension would be worth 
while, but I would be more than happy to author a PEP for this if it 
gets some initial positive feedback.


Open questions - that I have - should we allow `except`, `else` and 
`finally` clauses (or just `except` and `else` - do we need `finally` here).


--

Anthony Flury
*Moble*: +44 07743 282707
*Home*: +44 (0)1206 391294
*email*: anthony.fl...@btinternet.com 
<>___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ITNCZD2GOQS7TQF7XYFWFYABDP5ZNS5G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Fwd: [Python-Dev] Suggestion About Python Syntax

[anthony.flury via Python-ideas]

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 programming even in languages such as C, C++ and Java 
which do use Curly braces (or languages such as Pascal which use 
Begin/End and other such keywords),  you will find that you do indent 
your code consistently as a matter of habit. Most serious developers in 
those languages will use auto-formatters to ensure that their code is 
nicely indented. Even though they use languages which have syntax 
elements to denote the start and end of a block, they recognize that 
indentation is a very natural way to layout code to make it readable, 
and they avoid 'indentation where ever they want'.


Python - by adopting indentation as it does - has simply adopted a very 
natural form for writing code, and made it mandatory.


You might be surprised to know that Python does allow semicolons at the 
end of statements, but they are optional, and really only used to run 
mutiple statements together on a single line; which is not considered to 
be a good style of writing.


Don't be put off by this message - keep enjoying Python and learning 
about the world of programming. You have taken your first steps in the 
Python community, and we all look forward to hearing what ever ideas you 
might have in future.


Good luck in your future journey in the computing universe.

Tony Flury.



On 03/03/2021 18:24, George Harding wrote:



-- Forwarded message -
From: *Anthony Farino* >

Date: Wed, Mar 3, 2021 at 5:52 PM
Subject: [Python-Dev] Suggestion About Python Syntax
To: mailto:python-...@python.org>>


I love the Python scripting language, but there’s something that 
would make it much better. Almost every other programming language 
uses curly braces to enclose blocks of code and semicolons after the 
lines of code. That means that:


1.

You can have as much white space as you want.

2.

You don’t need to worry about indentation, and you can indent
whenever you want.

I hope that you consider these issues and fix them in Python 4 (if 
you ever make it).


Sincerely, Anthony, age 10.



--
   mm            m    #
   ##   m mm   mm#mm  # mm    mmm   m mm   m   m
  #  #  #"  #    #    #" #  #" "#  #"  #  "m m"
  #mm#  #   #    #    #  #  #   #  #   #   #m#
 #    # #   #    "mm  #  #  "#m#"  #   #   "#
                  m"
                 ""
___
Python-Dev mailing list -- python-...@python.org 

To unsubscribe send an email to python-dev-le...@python.org 

https://mail.python.org/mailman3/lists/python-dev.python.org/ 

Message archived at 
https://mail.python.org/archives/list/python-...@python.org/message/RZR2O3Y6Z6RCAXW72Y4WPWZ6HN3MYVFJ/ 

Code of Conduct: http://python.org/psf/codeofconduct/ 



___
Python-ideas mailing list --python-ideas@python.org
To unsubscribe send an email topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-ideas@python.org/message/OEIEGBD5CNZSHY3D4EIIM35WELCKHPRJ/
Code of Conduct:http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WK3WSL4IDSMQ53F3E6LANPKLDYNLPST3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[anthony.flury via Python-ideas]

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) => (1, 2)"
means "compare a tuple for greater-or-equal".

Should be safe actually - "=>" is not a valid comparison operator.
It may not be a valid operator - but it reads as if it could be. using 
'=>' for this will decrease the readability as far as I can see.


It takes a bit of mental processing to realise this isn't a valid 
comparison, and then more processing to understand what it does mean; it 
will definitely be a source of confusion for beginners. The fact that a 
very respected member of the community got it wrong at first sight 
suggests that many will do so.


If we were going to do this - and I am still on the fence - I think we 
should avoid anything that reads like it could be confused as an operator.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3SAONT64IU4LP4ML3XARVPESJKG25CY2/
Code of Conduct: http://python.org/psf/codeofconduct/