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 d
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
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__
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 en
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
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 c
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
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.pyt
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__
> >
> > > >
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:
_
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
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.
___
Py
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
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
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 __a
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)
.
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,
whil
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.
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]
-- 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 b
> 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 c
21 matches
Mail list logo
