[Python-ideas] Re: Please update shutil.py copyfileobj to include code mentioned in below issues

[Jim Schwartz]

Ok, Thanks.  I didn't know this wasn't the place to go for help.  I'll post 
there.  I don't care if this is not done.  I just thought it might help others 
down the road like it helped me.  

Also, the reason I posted this to this email list was as follows.  This is the 
text that shows up when I click in GitHub under new issue, then feature.  Maybe 
the mailing list should be removed from that template.

-

# Feature or enhancement

(A clear and concise description of your proposal.)

# Pitch

(Explain why this feature or enhancement should be implemented and how it would 
be used.
 Add examples, if applicable.)

# Previous discussion






-Original Message-
From: Eryk Sun  
Sent: Thursday, June 8, 2023 12:02 PM
To: jsch...@sbcglobal.net
Cc: python-ideas@python.org
Subject: Re: [Python-ideas] Please update shutil.py copyfileobj to include code 
mentioned in below issues

On 6/8/23, jsch...@sbcglobal.net  wrote:
> I opened two issues regarding copyfileobj that were not bugs, but a 
> fix that was involved helped me figure out I needed a new external 
> drive, since it displayed the error number from the copyfileobj 
> function.  I'd like a modified version of this code implemented 
> permanently in shutil.py so others could see if they have the same issue as 
> me.

I don't know how many people still subscribe to and read this mailing list. 
More people would see this suggestion if you posted this on 
discuss.python.org/c/ideas.

> This is the original issue that has the code I was using that Eryksun 
> posted.
>
> https://github.com/python/cpython/issues/96721
>
> Here's the second issue where it happened again.  I put the error 
> message in this post, so you can see how it helped me.  Also, the code 
> might need to be modified slightly, since it generated an error.
>
> https://github.com/python/cpython/issues/102357

The ctypes code that I provided was only for debugging purposes.
Python needs to support the C runtime's _doserrno value (actually it's a 
Windows error code) internally for I/O calls such as _wopen(), close(), read(), 
and write().

Also, the error that you encountered, ERROR_NO_SUCH_DEVICE (433), should be 
mapped to the C errno value ENOENT (i.e. FileNotFoundError) in PC/errmap.h.

___
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/LV2NN2W2ZV37KICFR6IHLGBCAD7KYTXT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Fwd: Explicit encapsulation is better than implicit hardcoding?

[Dom Grigonis]

I stand corrected.!

I have very little experience with asyncio. I ended up postponing it’s learning 
one of the reasons being this query. (Another - extra keywords).

Still, the query is more concerned with module level interfaces. That includes 
module level initialisations as well as interface functions acting on variables 
defined at module’s level while partly (if not completely) abstracting 
architecture from the user.

What I am aiming at is providing easier explicit instantiation of root objects, 
rather than abstracting their creation and usage. There would be much smoother 
library learning path if the first line the user wrote was:

```
loop = asyncio.Loop()
```
or
```
log_manager = logging.Manager(logging.BaseLogger())
logger = log_manager.getLogger(’name')
```

Whether to provide default arguments or force user to set them explicitly is 
another question. (Maybe can provide class methods for construction with some 
default presets)

The key is that if user started with explicitly defined objects, the transition 
to understanding/modifying/extending source would be smoother than playing with 
an interface, which abstracts the architecture.

For asyncio, learning curve is already steep. And this approach, in my opinion, 
is an extra obstacle, which prevents a significant portion of basic users 
crossing to the next level.

In my experience, this would save few lines of code and also only 1 interface 
is easier to maintain.
Also, I think this suggestion to some extent intersects with:

"There should be one-- and preferably only one --obvious way to do it.”

Now, with these libraries it feels like: “There is one obvious way to do it, 
but it changes to another obvious way for advanced usage”

Having said that, just want to emphasise that I am trying to argue general 
point, rather than complain about specific libraries. I think the same holds 
for many 3rd party libraries too.

Also, personally I lean strongly towards modularity so just trying to find out 
if anyone else agrees or I am simply over-extending here, in python case.

> Begin forwarded message:
> 
> From: "Joao S. O. Bueno" 
> Subject: Re: [Python-ideas] Explicit encapsulation is better than implicit 
> hardcoding?
> Date: 8 June 2023 at 20:36:11 EEST
> To: Dom Grigonis 
> Cc: python-ideas@python.org
> 
> "it's a bit more challenging to obtain a separate asyncio loop."
> 
> Just call `asyncio.new_event_loop`  and you can have as many event loops in 
> the same thread as you want. 
> 
> On Thu, Jun 8, 2023 at 10:58 AM Dom Grigonis  > wrote:
> Hey there! I'm curious to know what this group thinks about the implicit 
> design of many Python libraries, both core and open source. What I mean by 
> "implicit design" is when an interface of library is established and 
> initialised at module’s level rather than explicitly encapsulated in classes.
> 
> Couple of the examples:
> 1. logging
> 2. asyncio
> 
> Both of the libraries (by design) allow only 1 framework per process, which 
> can be limiting. Although it's easier to hack the logging library to obtain 
> an independent hierarchy with separate root node, it's a bit more challenging 
> to obtain a separate asyncio loop.
> 
> Allowing users to instantiate a fresh instance of framework would be 
> advantageous in various ways:
> 
> 1. "Explicit is better than implicit" - easier to understand, inherit, and 
> edit.
> 2. The ability to instantiate multiple framework nodes leads in a modifiable, 
> therefore easier to comprehend workflow. For example, having separate logging 
> and asyncio on a thread would provide for greater design freedom.
> 3. Code reusability. When I am looking for code (to avoid reinventing the 
> wheel), whenever I find initialisations at the module level it is a signal 
> that the code is not easily reusable, and I continue my search. I'll return 
> to such code as a last option.
> 
> I think such design is reasonable for “end result” products, that are not at 
> the risk of becoming standard dependencies, but is it a good idea to continue 
> this standard practice for "building block" libraries?
> 
> It is not a complaint in and of itself (maybe a bit), but rather an attempt 
> to spark a discussion about whether more modular and explicitly contained 
> architecture would help the Python community the most in the long run.
> 
> 
> 
> 
> 
> 
> ___
> 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/M7D7G6R6RYKPX4AM2SDERYOKT4ISXODN/
>  
> 

[Python-ideas] Re: Explicit encapsulation is better than implicit hardcoding?

[Joao S. O. Bueno]

"it's a bit more challenging to obtain a separate asyncio loop."

Just call `asyncio.new_event_loop`  and you can have as many event loops in
the same thread as you want.

On Thu, Jun 8, 2023 at 10:58 AM Dom Grigonis  wrote:

> Hey there! I'm curious to know what this group thinks about the implicit
> design of many Python libraries, both core and open source. What I mean by
> "implicit design" is when an interface of library is established and
> initialised at module’s level rather than explicitly encapsulated in
> classes.
>
> Couple of the examples:
> 1. logging
> 2. asyncio
>
> Both of the libraries (by design) allow only 1 framework per process,
> which can be limiting. Although it's easier to hack the logging library
> to obtain an independent hierarchy with separate root node, it's a bit more
> challenging to obtain a separate asyncio loop.
>
> Allowing users to instantiate a fresh instance of framework would be
> advantageous in various ways:
>
> 1. "Explicit is better than implicit" - easier to understand, inherit, and
> edit.
> 2. The ability to instantiate multiple framework nodes leads in a
> modifiable, therefore easier to comprehend workflow. For example, having
> separate logging and asyncio on a thread would provide for greater design
> freedom.
> 3. Code reusability. When I am looking for code (to avoid reinventing the
> wheel), whenever I find initialisations at the module level it is a signal
> that the code is not easily reusable, and I continue my search. I'll return
> to such code as a last option.
>
> I think such design is reasonable for “end result” products, that are not
> at the risk of becoming standard dependencies, but is it a good idea to
> continue this standard practice for "building block" libraries?
>
> It is not a complaint in and of itself (maybe a bit), but rather an
> attempt to spark a discussion about whether more modular and explicitly
> contained architecture would help the Python community the most in the long
> run.
>
>
>
>
>
>
> ___
> 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/M7D7G6R6RYKPX4AM2SDERYOKT4ISXODN/
> 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/MHYVBO7ALVNYXG6JGH7XPNPITJ6YGUDB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Please update shutil.py copyfileobj to include code mentioned in below issues

[Eryk Sun]

On 6/8/23, jsch...@sbcglobal.net  wrote:
> I opened two issues regarding copyfileobj that were not bugs, but a fix that
> was involved helped me figure out I needed a new external drive, since it
> displayed the error number from the copyfileobj function.  I'd like a
> modified version of this code implemented permanently in shutil.py so others
> could see if they have the same issue as me.

I don't know how many people still subscribe to and read this mailing
list. More people would see this suggestion if you posted this on
discuss.python.org/c/ideas.

> This is the original issue that has the code I was using that Eryksun
> posted.
>
> https://github.com/python/cpython/issues/96721
>
> Here's the second issue where it happened again.  I put the error message in
> this post, so you can see how it helped me.  Also, the code might need to be
> modified slightly, since it generated an error.
>
> https://github.com/python/cpython/issues/102357

The ctypes code that I provided was only for debugging purposes.
Python needs to support the C runtime's _doserrno value (actually it's
a Windows error code) internally for I/O calls such as _wopen(),
close(), read(), and write().

Also, the error that you encountered, ERROR_NO_SUCH_DEVICE (433),
should be mapped to the C errno value ENOENT (i.e. FileNotFoundError)
in PC/errmap.h.
___
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/KVIYVVZCHCOYLOFQNJDNILCF7KQVBR6A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Fwd: Undefined type

[Dom Grigonis]

Thank you all for links. Much appreciated.

> Begin forwarded message:
> 
> From: Michael Foord 
> Subject: Re: [Python-ideas] Re: Undefined type
> Date: 8 June 2023 at 17:41:46 EEST
> To: david.me...@gmail.com
> Cc: Dom Grigonis , python-ideas@python.org
> 
> There's an implementation of a sentinel object in unittest.mock :
> 
> >>> from unittest.mock import sentinel
> >>> sentinel.THING
> sentinel.THING
> 
> On Thu, 8 Jun 2023 at 15:20, David Mertz, Ph.D.  > wrote:
> https://peps.python.org/pep-0661/ 
> 
> On Thu, Jun 8, 2023 at 9:58 AM Dom Grigonis  > wrote:
> This has been bugging me for a long time. It seems that python doesn’t have a 
> convention for “Undefined” type.
> 
> When I started using python I naturally used None for it (as advised).
> 
> However, the more I work with python, the more I find that None is a 
> meaningful type. And it is a type that is convenient to use in a lot of 
> cases, where it is not actually “None”.
> 
> One big example is:
> numpy: array[None, :]
> 
> Another is simple cascading of defaults.
> E.g.
> 
> ```python
> class A:
> def __init__(self, default=’string'):
> self.default = default
> 
> def method(self, default=None):
> default = default if default is not None else self.default
>   dct[‘key’] = other_dict.get(‘key’, default)
> return to_json(dct)
> ```
> 
> None has a logic in `some_func`, which is important.
> Now if I want to enforce None passed to to_json I have no way to do it.
> 
> I know there are many workarounds for this, but there is no `consistent` way 
> of doing this.
> 
> I have been using Ellipsis in the past, but it doesn’t feel right, because it 
> also has a meaning and I might need to use those functions with e.g. numpy in 
> he future and will have to change it.
> 
> Now, I came back to this issue again and my latest solution is to just define:
> UNDEFINED = object()
> in library constants.py
> 
> Then code above is very clear and I think this is a good and sustainable 
> solution.
> 
> I know, that in a way ’None’ is already this, but it is generally used in 2 
> ways:
> 1. A variable/argument is undefined in python space
> 2. Global indication, that a value is undefined (e.g. equivalence of null in 
> json)
> 
> What I am proposing is to have 1 more constant in python ‘Undefined’, which 
> will indicate ‘Undefined’ in python space and leave None to be used in more 
> general sense.
> 
> I also found this article while looking for solution just now:
> https://levelup.gitconnected.com/python-why-none-is-not-nothing-bb3de55dd471 
> 
> It seems that people who use typing are also running into ambiguities and 
> trying to hack something together.
> I avoid typing until its 99% mature so can't comment more on this.
> 
> What are your thoughts? Am I onto something or am I missing something? Anyone 
> else had similar encounters?
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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/RGUNJYXWHE7UM2W6FCAMGLJVLXEYHA2Q/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
> 
> 
> 
> -- 
> The dead increasingly dominate and strangle both the living and the 
> not-yet born.  Vampiric capital and undead corporate persons abuse 
> the lives and control the thoughts of homo faber. Ideas, once born, 
> become abortifacients against new conceptions.
> ___
> 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/YTCPDFDUZTMTXS5LYHKCYJ23WVMPE6CL/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
> 
> 
> 
> -- 
> Michael Foord
> Python Consultant, Contractor and Trainer
> https://agileabstractions.com/ 
___
Python-ideas mailing 

[Python-ideas] Re: Undefined type

[Michael Foord]

There's an implementation of a sentinel object in unittest.mock :

>>> from unittest.mock import sentinel
>>> sentinel.THING
sentinel.THING

On Thu, 8 Jun 2023 at 15:20, David Mertz, Ph.D. 
wrote:

> https://peps.python.org/pep-0661/
>
> On Thu, Jun 8, 2023 at 9:58 AM Dom Grigonis 
> wrote:
>
>> This has been bugging me for a long time. It seems that python doesn’t
>> have a convention for “Undefined” type.
>>
>> When I started using python I naturally used None for it (as advised).
>>
>> However, the more I work with python, the more I find that None is a
>> meaningful type. And it is a type that is convenient to use in a lot of
>> cases, where it is not actually “None”.
>>
>> One big example is:
>> numpy: array[None, :]
>>
>> Another is simple cascading of defaults.
>> E.g.
>>
>> ```python
>> class A:
>> def __init__(self, default=’string'):
>> self.default = default
>>
>> def method(self, default=None):
>> default = default if default is not None else self.default
>> dct[‘key’] = other_dict.get(‘key’, default)
>> return to_json(dct)
>> ```
>>
>> None has a logic in `some_func`, which is important.
>> Now if I want to enforce None passed to to_json I have no way to do it.
>>
>> I know there are many workarounds for this, but there is no `consistent`
>> way of doing this.
>>
>> I have been using Ellipsis in the past, but it doesn’t feel right,
>> because it also has a meaning and I might need to use those functions with
>> e.g. numpy in he future and will have to change it.
>>
>> Now, I came back to this issue again and my latest solution is to just
>> define:
>> UNDEFINED = object()
>> in library constants.py
>>
>> Then code above is very clear and I think this is a good and sustainable
>> solution.
>>
>> I know, that in a way ’None’ is already this, but it is generally used in
>> 2 ways:
>> 1. A variable/argument is undefined in python space
>> 2. Global indication, that a value is undefined (e.g. equivalence of null
>> in json)
>>
>> What I am proposing is to have 1 more constant in python ‘Undefined’,
>> which will indicate ‘Undefined’ in python space and leave None to be used
>> in more general sense.
>>
>> I also found this article while looking for solution just now:
>>
>> https://levelup.gitconnected.com/python-why-none-is-not-nothing-bb3de55dd471
>> It seems that people who use typing are also running into ambiguities and
>> trying to hack something together.
>> I avoid typing until its 99% mature so can't comment more on this.
>>
>> What are your thoughts? Am I onto something or am I missing something?
>> Anyone else had similar encounters?
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 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/RGUNJYXWHE7UM2W6FCAMGLJVLXEYHA2Q/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> The dead increasingly dominate and strangle both the living and the
> not-yet born.  Vampiric capital and undead corporate persons abuse
> the lives and control the thoughts of homo faber. Ideas, once born,
> become abortifacients against new conceptions.
> ___
> 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/YTCPDFDUZTMTXS5LYHKCYJ23WVMPE6CL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 

Michael Foord

Python Consultant, Contractor and Trainer

https://agileabstractions.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/YNKTVZM6GMQAGR5XAJ3SH6HTAWGYG5VT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Undefined type

[David Mertz, Ph.D.]

https://peps.python.org/pep-0661/

On Thu, Jun 8, 2023 at 9:58 AM Dom Grigonis  wrote:

> This has been bugging me for a long time. It seems that python doesn’t
> have a convention for “Undefined” type.
>
> When I started using python I naturally used None for it (as advised).
>
> However, the more I work with python, the more I find that None is a
> meaningful type. And it is a type that is convenient to use in a lot of
> cases, where it is not actually “None”.
>
> One big example is:
> numpy: array[None, :]
>
> Another is simple cascading of defaults.
> E.g.
>
> ```python
> class A:
> def __init__(self, default=’string'):
> self.default = default
>
> def method(self, default=None):
> default = default if default is not None else self.default
> dct[‘key’] = other_dict.get(‘key’, default)
> return to_json(dct)
> ```
>
> None has a logic in `some_func`, which is important.
> Now if I want to enforce None passed to to_json I have no way to do it.
>
> I know there are many workarounds for this, but there is no `consistent`
> way of doing this.
>
> I have been using Ellipsis in the past, but it doesn’t feel right, because
> it also has a meaning and I might need to use those functions with e.g.
> numpy in he future and will have to change it.
>
> Now, I came back to this issue again and my latest solution is to just
> define:
> UNDEFINED = object()
> in library constants.py
>
> Then code above is very clear and I think this is a good and sustainable
> solution.
>
> I know, that in a way ’None’ is already this, but it is generally used in
> 2 ways:
> 1. A variable/argument is undefined in python space
> 2. Global indication, that a value is undefined (e.g. equivalence of null
> in json)
>
> What I am proposing is to have 1 more constant in python ‘Undefined’,
> which will indicate ‘Undefined’ in python space and leave None to be used
> in more general sense.
>
> I also found this article while looking for solution just now:
>
> https://levelup.gitconnected.com/python-why-none-is-not-nothing-bb3de55dd471
> It seems that people who use typing are also running into ambiguities and
> trying to hack something together.
> I avoid typing until its 99% mature so can't comment more on this.
>
> What are your thoughts? Am I onto something or am I missing something?
> Anyone else had similar encounters?
>
>
>
>
>
>
>
>
> ___
> 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/RGUNJYXWHE7UM2W6FCAMGLJVLXEYHA2Q/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/YTCPDFDUZTMTXS5LYHKCYJ23WVMPE6CL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Please update shutil.py copyfileobj to include code mentioned in below issues

[jschwar]

I opened two issues regarding copyfileobj that were not bugs, but a fix that 
was involved helped me figure out I needed a new external drive, since it 
displayed the error number from the copyfileobj function.  I'd like a modified 
version of this code implemented permanently in shutil.py so others could see 
if they have the same issue as me.  Here are the two issues I opened:

This is the original issue that has the code I was using that Eryksun posted.

https://github.com/python/cpython/issues/96721

Here's the second issue where it happened again.  I put the error message in 
this post, so you can see how it helped me.  Also, the code might need to be 
modified slightly, since it generated an error.

https://github.com/python/cpython/issues/102357
___
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/L7SL6PN6SDLLOHRMQTK2PZGD2ZDTW5P2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Undefined type

[Dom Grigonis]

This has been bugging me for a long time. It seems that python doesn’t have a 
convention for “Undefined” type.

When I started using python I naturally used None for it (as advised).

However, the more I work with python, the more I find that None is a meaningful 
type. And it is a type that is convenient to use in a lot of cases, where it is 
not actually “None”.

One big example is:
numpy: array[None, :]

Another is simple cascading of defaults.
E.g.

```python
class A:
def __init__(self, default=’string'):
self.default = default

def method(self, default=None):
default = default if default is not None else self.default
dct[‘key’] = other_dict.get(‘key’, default)
return to_json(dct)
```

None has a logic in `some_func`, which is important.
Now if I want to enforce None passed to to_json I have no way to do it.

I know there are many workarounds for this, but there is no `consistent` way of 
doing this.

I have been using Ellipsis in the past, but it doesn’t feel right, because it 
also has a meaning and I might need to use those functions with e.g. numpy in 
he future and will have to change it.

Now, I came back to this issue again and my latest solution is to just define:
UNDEFINED = object()
in library constants.py

Then code above is very clear and I think this is a good and sustainable 
solution.

I know, that in a way ’None’ is already this, but it is generally used in 2 
ways:
1. A variable/argument is undefined in python space
2. Global indication, that a value is undefined (e.g. equivalence of null in 
json)

What I am proposing is to have 1 more constant in python ‘Undefined’, which 
will indicate ‘Undefined’ in python space and leave None to be used in more 
general sense.

I also found this article while looking for solution just now:
https://levelup.gitconnected.com/python-why-none-is-not-nothing-bb3de55dd471
It seems that people who use typing are also running into ambiguities and 
trying to hack something together.
I avoid typing until its 99% mature so can't comment more on this.

What are your thoughts? Am I onto something or am I missing something? Anyone 
else had similar encounters?







___
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/RGUNJYXWHE7UM2W6FCAMGLJVLXEYHA2Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Explicit encapsulation is better than implicit hardcoding?

[Dom Grigonis]

Hey there! I'm curious to know what this group thinks about the implicit design 
of many Python libraries, both core and open source. What I mean by "implicit 
design" is when an interface of library is established and initialised at 
module’s level rather than explicitly encapsulated in classes.

Couple of the examples:
1. logging
2. asyncio

Both of the libraries (by design) allow only 1 framework per process, which can 
be limiting. Although it's easier to hack the logging library to obtain an 
independent hierarchy with separate root node, it's a bit more challenging to 
obtain a separate asyncio loop.

Allowing users to instantiate a fresh instance of framework would be 
advantageous in various ways:

1. "Explicit is better than implicit" - easier to understand, inherit, and edit.
2. The ability to instantiate multiple framework nodes leads in a modifiable, 
therefore easier to comprehend workflow. For example, having separate logging 
and asyncio on a thread would provide for greater design freedom.
3. Code reusability. When I am looking for code (to avoid reinventing the 
wheel), whenever I find initialisations at the module level it is a signal that 
the code is not easily reusable, and I continue my search. I'll return to such 
code as a last option.

I think such design is reasonable for “end result” products, that are not at 
the risk of becoming standard dependencies, but is it a good idea to continue 
this standard practice for "building block" libraries?

It is not a complaint in and of itself (maybe a bit), but rather an attempt to 
spark a discussion about whether more modular and explicitly contained 
architecture would help the Python community the most in the long run.






___
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/M7D7G6R6RYKPX4AM2SDERYOKT4ISXODN/
Code of Conduct: http://python.org/psf/codeofconduct/