[Python-ideas] Re: Integer concatenation to byte string

[Barry Scott]

> On 2 Mar 2021, at 23:49, Steven D'Aprano  wrote:
> 
> 
> [Barry]
>> All python byte code is interpreted by calling functions. They take 
>> time and resources.
> 
> That's not entirely correct. Literals such as text strings, ints and 
> floats get compiled directly into the byte-code. Now of course there is 
> some overhead while executing the byte-code, but that doesn't include 
> the heavy cost of a Python function call.

I was thinking of the C functions that are executed in ceval.c to run the 
interpreter
for any byte code.

Barry


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

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

[George Harding]

-- Forwarded message -
From: Anthony Farino 
Date: Wed, Mar 3, 2021 at 5:52 PM
Subject: [Python-Dev] Suggestion About Python Syntax
To: 


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.


-- 
   mmm#
   ##   m mm   mm#mm  # mmmmm   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 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/OEIEGBD5CNZSHY3D4EIIM35WELCKHPRJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Integer concatenation to byte string

[Random832]

On Wed, Mar 3, 2021, at 04:09, Barry Scott wrote:
> I was thinking of the C functions that are executed in ceval.c to run 
> the interpreter for any byte code.

In that case, it's not clear how your proposed syntax would not have the same 
overhead [especially your suggestion of a += 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/4ZIVPMD4JY73NDAQU46TU2OWB7NV7UTM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] list.extend() should return self

[Hans Ginzel]

Please, is there a reason why extend() method does not return self?


a = [1,2].extend((3,4))
a
type(a)



b = [1,2]
b.extend((3,4))
b

[1, 2, 3, 4]
___
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/5BAHV7VURBOSFUCTPFPQ646CGMHB7RTP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: list.extend() should return self

[Richard Damon]

On 3/3/21 3:23 PM, Hans Ginzel wrote:
> Please, is there a reason why extend() method does not return self?
>
 a = [1,2].extend((3,4))
 a
 type(a)
> 
 b = [1,2]
 b.extend((3,4))
 b
> [1, 2, 3, 4] 

I think it just the general principle that mutating methods return None,
while methods that create a new object return that object.

Thus you use the return type if you expect a new object, and getting
None alerts you to the fact that it mutated the original instead of just
makeing a new object for the answer.

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

[Python-ideas] Re: list.extend() should return self

[Matthias Bussonnier]

Methods that mutate their argument typically return None, to avoid
confusing them with methods that return copies;

If you both mutate and return a copy it is easy to end up with shared
objects in place you actually don't want them

>>> even = [2,4,6]
>>> odd = [1,3,5]
>>> all = odd.extend(even)

... oops.
-- 
M

On Wed, 3 Mar 2021 at 12:43, Hans Ginzel  wrote:
>
> Please, is there a reason why extend() method does not return self?
>
> >>> a = [1,2].extend((3,4))
> >>> a
> >>> type(a)
> 
> >>> b = [1,2]
> >>> b.extend((3,4))
> >>> b
> [1, 2, 3, 4]
> ___
> 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/5BAHV7VURBOSFUCTPFPQ646CGMHB7RTP/
> 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/KGMZ6IUWTNN4SX27U2UHZAZSULAKNTBX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Add an __exclude_all__ complement to __all__

[George Harding]

Hi,

Python has an __all__ variable that can be defined in a module to restrict
which members of the module should be included in a call `from foo import
*`. However specifying which members of the module should be excluded is
more difficult. There are three workarounds that I see:

1) Defining __all__ to specify most of the members of the module, except
the few that should be excluded.

2) Naming members to be excluded with a leading underscore. e.g. as done
here in ctypes:
https://github.com/python/cpython/blob/master/Lib/ctypes/__init__.py#L3

3) Manually deleting members from the module. e.g. as done here in numpy:
https://github.com/numpy/numpy/blob/master/numpy/core/__init__.py#L52

I think it might be cleaner to also allow an __exclude_all__ variable which
will exclude some members from being imported.

If both were defined I would imagine __exclude_all__ being applied second.

Best,

George Harding
___
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/YMP7WQ3RI4BW3HUID6JFIOBVAARFA3WL/
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: Add an __exclude_all__ complement to __all__

[Ethan Furman]

On 3/3/21 12:55 PM, George Harding wrote:


Python has an __all__ variable that can be defined in a module to restrict
which members of the module should be included in a call `from foo import *`.


The primary purpose these days for `__all__` is to codify a module's API.  The 
*-import is just a happy accident.


However specifying which members of the module should be excluded is more
difficult.


And unnecessary -- specify `__all__` so your users know which classes, 
functions, variables, etc., can be safely used.  If it should be excluded, 
don't put it in `__all__`.

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

[Python-ideas] class(obj) could return obj.__class__

[Hans Ginzel]

Please, consider class(obj) to return obj.__class__
consistenly with dir(), vars(), repr(), str(),…


class c: pass
o = c()
o.__class__



class(o)

   File "", line 1
 class(o)
  ^
SyntaxError: invalid syntax

Thank you in advance,
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/HYHCN5RUW76BXSAW22UFLFBK6DVOGFJV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: class(obj) could return obj.__class__

[Paul Bryan]

Since class is a keyword, this is unlikely. Why is type(o) not
insufficient?

On Wed, 2021-03-03 at 22:59 +0100, Hans Ginzel wrote:
> > > > class c: pass
> > > > o = c()
> > > > o.__class__
> 
> > > > class(o)
>     File "", line 1
>   class(o)
>    ^
> SyntaxError: invalid syntax

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

[Python-ideas] Re: Add an __exclude_all__ complement to __all__

[Chris Angelico]

On Thu, Mar 4, 2021 at 7:57 AM George Harding
 wrote:
> I think it might be cleaner to also allow an __exclude_all__ variable which 
> will exclude some members from being imported.
>
> If both were defined I would imagine __exclude_all__ being applied second.

You could implement that yourself:

__all__ = {n for n in globals() if not n.startswith("_")} - __exclude_all__

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

[Python-ideas] Re: class(obj) could return obj.__class__

[Paul Bryan]

Err, why is it insufficient?

On Wed, 2021-03-03 at 14:03 -0800, Paul Bryan wrote:
> Since class is a keyword, this is unlikely. Why is type(o) not
> insufficient?
> 
> On Wed, 2021-03-03 at 22:59 +0100, Hans Ginzel wrote:
> > > > > class c: pass
> > > > > o = c()
> > > > > o.__class__
> > 
> > > > > class(o)
> >     File "", line 1
> >   class(o)
> >    ^
> > SyntaxError: invalid syntax
> 

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

[Python-ideas] Re: Add an __exclude_all__ complement to __all__

[George Harding]

Hi Ethan,

I'm not convinced that __all__ is responsible for codifying the api. The
contents of __all__, does not stop anyone from importing anything in the
module using `from foo import bar`. __all__ is specified in the tutorial as
being included for the `from foo import *` case:

https://docs.python.org/3/tutorial/modules.html

And similar the first result for __all__ on google, is a stack overflow
post stating that it is for from foo import *:

https://stackoverflow.com/questions/44834/can-someone-explain-all-in-python

Best,

George

On Wed, Mar 3, 2021 at 9:47 PM Ethan Furman  wrote:

> On 3/3/21 12:55 PM, George Harding wrote:
>
> > Python has an __all__ variable that can be defined in a module to
> restrict
> > which members of the module should be included in a call `from foo
> import *`.
>
> The primary purpose these days for `__all__` is to codify a module's API.
> The *-import is just a happy accident.
>
> > However specifying which members of the module should be excluded is more
> > difficult.
>
> And unnecessary -- specify `__all__` so your users know which classes,
> functions, variables, etc., can be safely used.  If it should be excluded,
> don't put it in `__all__`.
>
> --
> ~Ethan~
> ___
> 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/EPNXFKCBYTCQVEWLZZGLR2XUKXXVJEQC/
> 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/SZZ6DTPBLZWS56PRCTK7R6EGFOKVINH4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: class(obj) could return obj.__class__

[Hans Ginzel]

Thank you, type(o) is sufficient.
It is possible to use class properties:


type(o).__name__

'c'

On Wed, Mar 03, 2021 at 10:03:03PM +, Paul Bryan wrote:

Since class is a keyword, this is unlikely. Why is type(o)
insufficient?

On Wed, 2021-03-03 at 22:59 +0100, Hans Ginzel wrote:

>>> class c: pass
>>> o = c()
>>> o.__class__

>>> class(o)
    File "", line 1
  class(o)
   ^
SyntaxError: invalid syntax



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

[Python-ideas] Re: Add an __exclude_all__ complement to __all__

[George Harding]

Hi Ethan,

I'm sorry, I take that back, that convention was codified in PEP8.

https://www.python.org/dev/peps/pep-0008/#id50

Best,

George

On Wed, Mar 3, 2021 at 10:18 PM George Harding <
george.winton.hard...@gmail.com> wrote:

> Hi Ethan,
>
> I'm not convinced that __all__ is responsible for codifying the api. The
> contents of __all__, does not stop anyone from importing anything in the
> module using `from foo import bar`. __all__ is specified in the tutorial as
> being included for the `from foo import *` case:
>
> https://docs.python.org/3/tutorial/modules.html
>
> And similar the first result for __all__ on google, is a stack overflow
> post stating that it is for from foo import *:
>
> https://stackoverflow.com/questions/44834/can-someone-explain-all-in-python
>
> Best,
>
> George
>
> On Wed, Mar 3, 2021 at 9:47 PM Ethan Furman  wrote:
>
>> On 3/3/21 12:55 PM, George Harding wrote:
>>
>> > Python has an __all__ variable that can be defined in a module to
>> restrict
>> > which members of the module should be included in a call `from foo
>> import *`.
>>
>> The primary purpose these days for `__all__` is to codify a module's
>> API.  The *-import is just a happy accident.
>>
>> > However specifying which members of the module should be excluded is
>> more
>> > difficult.
>>
>> And unnecessary -- specify `__all__` so your users know which classes,
>> functions, variables, etc., can be safely used.  If it should be excluded,
>> don't put it in `__all__`.
>>
>> --
>> ~Ethan~
>> ___
>> 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/EPNXFKCBYTCQVEWLZZGLR2XUKXXVJEQC/
>> 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/TBSDL7OA2LMV7VTMRUVD2DTXIFDKN2NV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add an __exclude_all__ complement to __all__

[Brendan Barnwell]

On 2021-03-03 14:06, Chris Angelico wrote:

You could implement that yourself:

__all__ = {n for n in globals() if not n.startswith("_")} - __exclude_all__


	Sort of.  That will only work if you define __all__ at the end of the 
file.  But usually you want to define it at the beginning as a sort of 
documentation aid ("this is the public API").


	I do think something like __exclude_all__ would be handy.  It can be 
annoying to have to define __all__ just to exclude a few things.  But 
it's not a huge issue.


--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

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

[Python-ideas] Re: Add an __exclude_all__ complement to __all__

[Chris Angelico]

On Thu, Mar 4, 2021 at 9:57 AM Brendan Barnwell  wrote:
>
> On 2021-03-03 14:06, Chris Angelico wrote:
> > You could implement that yourself:
> >
> > __all__ = {n for n in globals() if not n.startswith("_")} - __exclude_all__
>
> Sort of.  That will only work if you define __all__ at the end of the
> file.  But usually you want to define it at the beginning as a sort of
> documentation aid ("this is the public API").

Given that it's meant to be program-readable, that shouldn't be too
big a deal. You can always put your human-readable public API
description in the docstring (where there's room for actual
descriptions, not just a list of names).

> I do think something like __exclude_all__ would be handy.  It can be
> annoying to have to define __all__ just to exclude a few things.  But
> it's not a huge issue.

We are programmers. When there is a problem, we (should!) seek a
solution that involves getting the computer to do the work for us.

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

[Python-ideas] Re: Add an __exclude_all__ complement to __all__

[Ethan Furman]

On 3/3/21 2:17 PM, Brendan Barnwell wrote:


[...] usually you want to define [__all__] at the beginning as a sort of 
documentation
aid ("this is the public API").


That is its purpose. :-)


I do think something like __exclude_all__ would be handy.  It can be annoying 
to have
to define __all__ just to exclude a few things.


Exclude a few things from what?  *-imports?  If you're using *-imports that 
often you are already courting confusion (where did that name come from?  why 
is this name not that function?).

I maintain a handful of libraries, all with `__all__`, and only one them is 
designed to be used with `from ... import *`.

The presence or absence of `__all__` has no bearing on named imports.  `from 
blahblah import _xyz` will work in either case.

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

[Python-ideas] Re: Add an __exclude_all__ complement to __all__

[George Harding]

If you are using __all__ to define your API, then you'll end up needing
`from foo import *` if you want to combine modules, e.g.:

https://github.com/python/cpython/blob/master/Lib/asyncio/__init__.py

So the two need to coexist. *-import does have valid uses. The majority of
these cases are within a library, rather than between libraries.

Best,

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

[Python-ideas] Re: Add an __exclude_all__ complement to __all__

[Ethan Furman]

On 3/3/21 3:38 PM, George Harding wrote:


If you are using __all__ to define your API, then you'll end up needing `from 
foo import *` if you want to combine modules, e.g.:

https://github.com/python/cpython/blob/master/Lib/asyncio/__init__.py


Absolutely!

So the two need to coexist. *-import does have valid uses. 


Agreed.

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