[Python-Dev] Re: PEP 638: Syntactic macros

[Stéfane Fermigier]

"


On Fri, Feb 3, 2023 at 12:28 PM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:

> Stéfane Fermigier writes:
>
>  > NB: on a very basic level, I remember trying, a few years ago, to use
> the
>  > Unicode "empty set" symbol as a synonym for set(), and it didn't end
> well,
>  > for several reasons, including the fact that Python didn't like it as a
>  > variable name.
>
> I know about the issue that '∅' is not valid in identifiers, but I'm
> curious about these other "several reasons".
>

IIRC (this was a few years back):  '∅' (aka EMPTY SET) was not accepted by
Python, so I used instead ''Ø" (aka "LATIN CAPITAL LETTER O WITH STROKE").

Python was OK with it, but some of the tools I use (one of flake8, isort,
black... or maybe one of my IDE) barfed on it.

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Co-Founder & Co-Chairman, National Council for Free & Open Source Software
(CNLL) - http://cnll.fr/
Co-Founder & Chairman, Association Professionnelle Européenne du Logiciel
Libre (APELL) - https://www.apell.info/
Co-Founder & Spokesperson, European Cloud Industrial Alliance (EUCLIDIA) -
https://www.euclidia.eu/

"I wish you were as accurate, & as much to be relied on, as I am myself" -
Lady Ada Lovelace
___
Python-Dev mailing list -- python-dev@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-dev@python.org/message/H2UALG4YAA6IBMZQMWEL2QIOPDPK4RTG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[Stéfane Fermigier]

On Thu, Feb 2, 2023 at 8:34 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:

> cd...@cam.ac.uk writes:
>
>  > I don't want to be forced to learn lots of weird little functions
>  > like `np.matmul(x1, x2)` when there's already one obvious syntax
>  > I'm very familiar with: `x1 * x2`.
>
> I don't recall ever writing matrix multiplication that way in
> mathematics though.  That's universally written as juxtaposition in my
> experience.  And the obvious way to write it in Python (and np) has
> been "x1 @ x2" for some years now.  In np, "*" means element-wise
> multiplication, I believe.
>

My 2 cents as a former mathematician:

Mathematicians have come up with hundreds of symbols to express the variety
of structures they are dealing with.

Just to list a few:

https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode
https://oeis.org/wiki/List_of_LaTeX_mathematical_symbols

So +, *, -, /, @ and ** are a good start to express the most common
mathematical structures (groups, rings, vector spaces), and <, >, <=, >=,
==, != for ordered sets, but that's it.

It's great that Python supports overloading these operations. That's
something that drew me to Python when I was still working in computational
number theory, 25 years ago.

But that's probably not enough for some people. A way to add new symbols
(including non-ascii Unicode characters) and operations could have some
value, but also the drawback of tremendous additional complexity, specially
if done in the most generic way.

NB: on a very basic level, I remember trying, a few years ago, to use the
Unicode "empty set" symbol as a synonym for set(), and it didn't end well,
for several reasons, including the fact that Python didn't like it as a
variable name.

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Co-Founder & Co-Chairman, National Council for Free & Open Source Software
(CNLL) - http://cnll.fr/
Co-Founder & Chairman, Association Professionnelle Européenne du Logiciel
Libre (APELL) - https://www.apell.info/
Co-Founder & Spokesperson, European Cloud Industrial Alliance (EUCLIDIA) -
https://www.euclidia.eu/

"I wish you were as accurate, & as much to be relied on, as I am myself" -
Lady Ada Lovelace
___
Python-Dev mailing list -- python-dev@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-dev@python.org/message/G2XSNXZSTPCDUDIUFHURGIBQ4HO7SG5B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

[Stéfane Fermigier]

My two cents:

1. I’ve grepped ("ag-ed" acually) through all my code bases, and as noted
by others, urllib.parse is used in many places. urllib.request never is, as
we've been using requests or httpx instead.

IMHO and for the context I'm using it (YMMV), urllib.parse is useful and
should be kept (could be replaced by third-party libs like furl or yarl,
but probably not a great idea).

2. Obviously bootstrapping pip or similar package management tools should
be a concern.

3. Overall, I think the days were "battery included" was a positive
argument are over. I'd rather make the standard library leaner, and
focussed on core language constructs. The only advantage that I can see is
that having stuff in the standard lib can reduce fragmentation, at least
initially, and ensure a very high level of quality and support, but at some
point in the future history has shown us that usually a better alternative
ends up emerging.

4. When deprecating and removing stuff from the stdlib and if there are no
dependency issues, it should be possible to more the components to their
own dedicated packages, maybe under an "extra" or "legacy" organisation.
The question of support stays open, though.

Regards,

  S.

On 6 Feb 2022 at 23:39:55, Gregory P. Smith  wrote:

>
>
> On Sun, Feb 6, 2022 at 9:13 AM Paul Moore  wrote:
>
>> On Sun, 6 Feb 2022 at 16:51, Christian Heimes 
>> wrote:
>>
>> > The urllib package -- and to some degree also the http package -- are
>> > constant source of security bugs. The code is old and the parsers for
>> > HTTP and URLs don't handle edge cases well. Python core lacks a true
>> > maintainer of the code. To be honest, we have to admit defeat and be up
>> > front that urllib is not up to the task for this decade. It was designed
>> > written during a more friendly, less scary time on the internet.
>> >
>> > If I had the power and time, then I would replace urllib with a simpler,
>> > reduced HTTP client that uses platform's HTTP library under the hood
>> > (WinHTTP on Windows, NSURLSession (?) on macOS, Web API for Emscripten,
>> > maybe curl on Linux/BSD). For non-trivial HTTP requests, httpx or
>> > aiohttp are much better suited than urllib.
>> >
>> > The second best option is to reduce the feature set of urllib to core
>> > HTTP (no ftp, proxy, HTTP auth) and a partial rewrite with stricter,
>> > more standard conform parsers for urls, query strings, and RFC 2822
>> > instead of RFC 822 for headers.
>>
>> I'd likely be fine with either of these two options. I'm not worried
>> about supporting "advanced" uses. But having no way of getting a file
>> from the internet without relying on 3rd party packages seems like a
>> huge gap in functionality for a modern language. And having to use a
>> 3rd party library to parse URLs will simply push more people to use
>> home-grown regexes rather than something safe and correct. Remember
>> that a lot of Python users are not professional software developers,
>> but scientists, data analysts, and occasional users, for whom the
>> existence of something in the stdlib is the *only* reason they have
>> any idea that URLs need specialised parsing in the first place.
>>
>> And while we all like to say 3rd party modules are great, the reality
>> is that they provide a genuine problem for many of these
>> non-specialist users - and I say that as a packaging specialist and
>> pip maintainer. The packaging ecosystem is *not* newcomer-friendly in
>> the way that core Python is, much as we're trying to improve that
>> situation.
>>
>> I've said it previously, but I'll reiterate - IMO this *must* have a
>> PEP, and that PEP must be clear that the intention is to *remove*
>> urllib, not simply to "deprecate and then think about it". That could
>> be making it part of PEP 594, or a separate PEP, but one way or
>> another it needs a PEP.
>>
>
> This would need to be it's own PEP.  urllib et. al. are used by virtually
> everybody.  They're highly used batteries.
>
> I'm -1 on deprecating it for that reason alone.
>
> Christian proposes that having a simpler scope rewrite of it might be
> nice, but I think disruption to the world and loss of trust in Python would
> be similar either way.
>
> -gps
>
>
>>
>> Paul
>> ___
>> Python-Dev mailing list -- python-dev@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-dev@python.org/message/KT6TGUBTLLETHES2OVVGZWSGYC5JCEKC/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@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-dev@python.org/message/QMSFZBQJFWKFFE3LFQLQE2AT6WKMLPGL/
> 

[Python-Dev] Re: Suggestion: a little language for type definitions

[Stéfane Fermigier]

On 9 Jan 2022 at 02:22:31, Steven D'Aprano  wrote:

> On Sat, Jan 08, 2022 at 12:59:38AM +0100, jack.jan...@cwi.nl wrote:
>
> I posted this suggestion earlier in the callable type syntax discussion,
> at which point it was completely ignored. Possibly because it’s a really
> stupid idea, but let me post it again on the off chance that it isn’t a
> stupid idea but was overlooked.
>
>
> > If I can make a wild suggestion: why not create a little language
>
> > for type specifications?
>
>
> Any time we are tempted to prefix a question with "Why not ...", the
> question is backwards. The right question is, "why should we ...".
>
> Python is 30 years old and mature, with a HUGE ecosystem of users,
> libraries, tooling, etc. It is far, far easier to get changes wrong than
> to get them right, which is why we should be conservative when it comes
> to language changes (including syntax). Changes to the language are
> "default deny", not "default accept", and it is up to the proponents of
> the change to prove their case, not for opponents to disprove it.
>

I agree 100% on these principles.

As a counter-argument, in this specific case, I’d say that the Python
typing ecosystem is only ~5 years old and still evolving rapidly, so these
principles apply with less force.

I personally believe that the syntax for type annotation doesn’t have, from
the point of view of users, to be strictly Python, as long as it’s
pythonic.

I can sympathise with the idea of repurposing the regular Python syntax to
describe types, and agree that it makes easier to bootstrap tools
(typecheckers, IDEs…) but I think it has its limits in terms of
expressivity, first.

Second, I think willing to keep the same syntax constructs for the sake of
lowering the cognitive burden of new developers is a red herring. These are
two different languages, with entirely different semantics, and the links
between them is not complement intuitive.

As an example (just for the sake of argument, I’m not proposing this kind
of change) one could argue that 'list[int]’ doesn’t really relate to how
lists are constructed or how the bracket operator is used in regular
Python. A more intuitive construct (from this point of view) could have
been ‘[int…]’. Same for dictionaries: ‘dict[int, str]’ vs. ‘{int: str}’
which looks closer that how dictionaries are constructed in Python.

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Co-Founder & Co-Chairman, National Council for Free & Open Source Software
(CNLL) - http://cnll.fr/
Co-Founder & Chairman, Association Professionnelle Européenne du Logiciel
Libre (APELL) - https://www.apell.info/
Co-Founder & Spokesperson, European Cloud Industrial Alliance (EUCLIDIA) -
https://www.euclidia.eu/
Founder, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/
___
Python-Dev mailing list -- python-dev@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-dev@python.org/message/V3T7JISJOSXUDBB3XZJLPG4FBZQTBSUY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Suggestion: a little language for type definitions

[Stéfane Fermigier]

On 8 Jan 2022 at 00:59:38, jack.jan...@cwi.nl wrote:

> I posted this suggestion earlier in the callable type syntax discussion,
> at which point it was completely ignored. Possibly because it’s a really
> stupid idea, but let me post it again on the off chance that it isn’t a
> stupid idea but was overlooked.
>
> If I can make a wild suggestion: why not create a little language for type
> specifications?
>
>
Indeed.

Using the same syntax may have some benefits for language implementors
(e.g. less complex grammar to implement), but I don’t really see these
benefits for language users.

As an example, and I don’t know if this has been discussed before, I think
a pretty neat syntax construct for optional argument would be (like, for
instance, in Kotlin):

def f(x: int? = None): ...

Instead of:

def f(x: Optional[int] = None): …

or

def f(x: int | None = None): …

One could even argue that the “= None” part would be redundant (def f(x:
int?): ...)  and could be made optional. But that would open another can of
worms.

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Co-Founder & Co-Chairman, National Council for Free & Open Source Software
(CNLL) - http://cnll.fr/
Co-Founder & Chairman, Association Professionnelle Européenne du Logiciel
Libre (APELL) - https://www.apell.info/
Co-Founder & Spokesperson, European Cloud Industrial Alliance (EUCLIDIA) -
https://www.euclidia.eu/
Founder, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/
___
Python-Dev mailing list -- python-dev@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-dev@python.org/message/PDRKIUCGM257VRZCPGBVB2LN34XAIZZR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

[Stéfane Fermigier]

On Thu, May 13, 2021 at 8:42 AM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

> Actual quote by "a Python Software Foundation fellow and contrib-
> utor to Python infrastructure projects"
>

Ah, this is what you were referring to. The document was published 5 years
ago, so this may or may not reflect the current situation.


> What frustrates me most is that we have an all-time high of
> Python developers and an all-time low on high quality contri-
> butions.[...] As soon as pivotal developers like Armin Ronacher
> slow down their churn, the whole community feels it immedi-
> ately.
>

That's true, but, AFAIK, Armin was never a direct contributor to CPython
(confirmed by looking at
https://github.com/python/cpython/graphs/contributors ) so I guess that's
another issue.


But to add a specific comment on this topic: Armin was indeed a very
creative and prolific developer of Python libraries and frameworks, and
since he's mostly left the Python world this has been an issue indeed. Some
of his projects, like Lektor (which I'm using for my blog) have lost their
traction and some of their users are moving to other tools.

But the good news is that some of his projects have been picked up by other
contributors, as the "Pallets" project, and, as a coincidence, they have
made major new releases of most of Armin's old projects just a couple of
days ago: https://www.palletsprojects.com/blog/flask-2-0-released/

   S.

>

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ &
http://pydata.fr/
___
Python-Dev mailing list -- python-dev@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-dev@python.org/message/NQGHCOCXSKY75GXH6DN2KGCMFRMQA6DA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

[Stéfane Fermigier]

On Wed, May 12, 2021 at 8:51 PM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

> Great news, just a tiny bit from me.
> I read the other day in the OpenSource report
> sponsored by the Ford Foundation a CPython
> contributor stating that we have an all time high
> count of Python users but an all time low number of
> contributors to CPython.
>

There's also (probably, I didn't count myself) a record number of Python
implementations that are not CPython (including Cython, Pythran and similar
projects) as well as CPython forks (Pyjion, Pyston, the project announced
by Guido, etc.)

Also: judging from https://github.com/python/cpython/graphs/contributors,
the "all time low number of contributors to CPython" assertion doesn't seem
to hold. In terms of committers, and according to this page, I count a
similar number or slightly higher of committers (50+) over the last year,
similar to over previous years (including those that seem more active in
terms of commit counts on the graph, like around 2010).

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ &
http://pydata.fr/
___
Python-Dev mailing list -- python-dev@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-dev@python.org/message/IVNEVZE6Z25EHXWNE5RKJPZDIU3LVKWC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[Stéfane Fermigier]

I agree that showing support for type hints is important, as long as this
doesn't convey the counterproductive message that type hints have become
almost mandatory. They are useful in some circumstances, and less so
(specially when dealing with beginners or non-professional programmers) in
others.

I don't agree that mypy should become part of the standard lib.

1) It's already obvious that it's the prefered implementation (in Python -
there are at least 3 other implementations that are not written in Python
and/or not open source that have an impact on the market).

2) Mypy is already part of the Python organisation on GitHub, it's even one
of the 6 featured repositories (which means it probably has a top-level
status with the PSF).

3) But it has a release cycle that is shorter than Python. It hasn't even
reached 1.0 !

4) If we are to "commit all the way to supporting type hints", a first step
IMHO would be to type hint all the standard library. AFAICT, type hints for
the stdlib are currently supported in the typeshed project, which is also a
top-level project. But I have not checked if it covers 100% of the stdlib.

Also, one could argue that the stdlib type hints should live closer to the
stdlib itself, and have a release cycle aligned with that of the stdlib,
and that typeshed should be reserved for type hinting popular third-party
libraries.

Indeed, if there was a proposal to make, mine would be to do exactly this :)

  S.


On Tue, Apr 13, 2021 at 11:58 PM Luciano Ramalho 
wrote:

> Hugh was unfortunate in presenting the problem, but I agree that we
> should commit all the way to supporting type hints, and that means
> bundling a type checker as part of the standard library and
> distribution.
>
> There is always a delay after a Python release before Mypy catches up
> to—and that's the type checker hosted in the python organization on
> github.
>
> I believe this is an unfortunate state of affairs for many users. I am
> not aware of any other optionally typed language that underwent core
> changes to support type annotations and yet does not bundle a type
> checker.
>
> Cheers,
>
> Luciano
>
>
>
> On Mon, Apr 12, 2021 at 7:01 AM Hugh Fisher  wrote:
> >
> > > Message: 1
> > > Date: Sun, 11 Apr 2021 13:31:12 -0700
> > > From: Barry Warsaw 
> > > Subject: [Python-Dev] Re: PEP 647 Accepted
> >
> > >
> > > This is something the SC has been musing about, but as it’s not a
> fully formed idea, I’m a little hesitant to bring it up.  That said, it’s
> somewhat relevant: We wonder if it may be time to in a sense separate the
> typing syntax from Python’s regular syntax.  TypeGuards are a case where if
> typing had more flexibility to adopt syntax that wasn’t strictly legal
> “normal” Python, maybe something more intuitive could have been proposed.
> I wonder if the typing-sig has discussed this possibility (in the future,
> of course)?
> >
> > [ munch ]
> >
> > >
> > > Agreed.  It’s interesting that PEP 593 proposes a different approach
> to enriching the typing system.  Typing itself is becoming a little
> ecosystem of its own, and given that many Python users are still not fully
> embracing typing, maybe continuing to tie the typing syntax to Python
> syntax is starting to strain.
> >
> > I would really like to see either "Typed Python" become a different
> programming
> > language, or progress to building type checking into the CPython
> implementation
> > itself. (Python 4 seems to me the obvious release.) The current halfway
> approach
> > is confusing and slightly ridiculous.
> >
> > The first, a separate programming language, would be like RATFOR and
> CFront
> > in the past and TypeScript today. Typed Python can have whatever syntax
> the
> > designers want because it doesn't have to be compatible with Python,
> just as
> > TypeScript is not constrained by JavaScript. A type checker translates
> > the original
> > Typed Python source into "dynamic" or "classic" Python for execution.
> (Maybe
> > into .pyc instead of .py?)
> >
> > This would mean no overhead for type checking in CPython itself. No need
> to
> > contort the parser into ignoring bits of code that are, in effect,
> > syntax checked
> > comments. And for the typing in Python enthusiasts, you won't have to
> listen
> > to people like me complaining.
> >
> > The second approach is to assume that type checking in Python is useful
> and
> > popular. Not with me, but I'm willing to accept that I'm in the minority
> and can
> > be ignored - after all, I can still write my Python code without type
> > annotations.
> > If so running a type checker as a separate step, as we do at the moment,
> is
> > like asking C programmers to run the preprocessor by hand.
> >
> > In today's world of continuous build and integration, it seems silly
> > to me to have
> > a type checker read the source, scan into lexical tokens, build an
> > abstract syntax
> > tree, perform semantic analysis with type checking, and then throw it
> away
> > before running an 

[Python-Dev] Re: Typing syntax and ecosystem, take 2

[Stéfane Fermigier]

On Tue, Apr 13, 2021 at 1:46 AM Hugh Fisher  wrote:

> In any Python 3.6 or later, type
>
> >>> x : float = 1
> >>> isinstance(x, float)
>
> or replace the second line with
>
> >>> type(x)
>
> As someone who has programmed in FORTRAN, Pascal, C/C++,
> Java, and Go this is not at all what I consider reasonable. I do not
> believe other programmers with experience in typed languages
> would expect this behaviour either.
>

I have 30 years experience in other programming languages (C, C++, Pascal,
Java...) and I'm OK with this behaviour :)

Python is, historically, a dynamically typed language, and gradual typing
(see https://en.wikipedia.org/wiki/Gradual_typing) has been progressively
added to it in the last decade or so. This is a legitimate approach, both
from an academic and industrial point of view, and similar (with some
variants) to what has been done also for JavaScript, Ruby, PHP, Lua, Perl,
Scheme, etc. over the same period.

See for instance
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.683.8854=rep1=pdf
for more references.


> If typing is the future of Python, and the number of PEPs being
> worked on suggests that it is, then type checking should be
> integrated into CPython itself.
>

No need to integrate in CPython, one can already provide runtime type
checking using the current language, see e.g.
https://pypi.org/project/typeguard/


> An alternative is the TypeScript/JavaScript model, where typed
> Python becomes a distinct programming language that cannot
> be executed directly by the Python interpreter.
>

There are a few compile-to-Python languages out there (See a list here:
https://github.com/sfermigier/awesome-functional-python#languages ), some
with desirable (for some people at least) characteristics (homoiconic
syntax, language-level support for actors and functional programming,
pattern matching, etc.). They have very limited success in terms of
adoption which is probably a lesson to keep in mind.

  S.


-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ &
http://pydata.fr/
___
Python-Dev mailing list -- python-dev@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-dev@python.org/message/7TZPJ6F7W6LLWKRQIFP3EWFW4SYBY2XT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Python-ideas] Re: Re: Have virtual environments led to neglect of the actual environment?

[Stéfane Fermigier]

On Wed, Feb 24, 2021 at 12:42 PM Paul Moore  wrote:

> On Wed, 24 Feb 2021 at 10:55, Stéfane Fermigier  wrote:
> > There is probably a clever way to reuse common packages (probably via
> clever symlinking) and reduce the footprint of these installations.
>
> Ultimately the problem is that a general tool can't deal with
> conflicts (except by raising an error). If application A depends on
> lib==1.0 and application B depends on lib==2.0, you simply can't have
> a (consistent) environment that supports both A and B. But that's the
> rare case - 99% of the time, there are no conflicts. One env per app
> is a safe, but heavy handed, approach. Managing environments manually
> isn't exactly *hard*, but it's annoying manual work that pipx does an
> excellent job of automating, so it's a disk space vs admin time
> trade-off.
>

There are three ways to approach the question:

1) Fully isolated envs. The safest option but uses the most space.

2) Try to minimise the number of dependencies installed by interpreting the
requirements specification in the looser way possible. This is both
algorithmically hard (see
https://hal.archives-ouvertes.fr/hal-00149566/document for instance, or the
more recent https://hal.archives-ouvertes.fr/hal-03005932/document ) and
risky, as you've noted.

3) But the best way IMHO is to compute dependencies for each virtualenv
independently from the others, but still share the packages, using some
indirection mechanisms (hard links, symlinks or some Python-specific
constructs) when the versions match exactly.

The 3rd solution is probably the best of the 3, but the sharing mechanism
still needs to be specified (and, if needed, implemented) properly.

I've tried Christian's suggestions of using rdfind on my pipx installation,
and it claims to reduce the footprint by 30% (nice, but less than I
expected. This would however scale better with the number of installed
packages).

I'm not sure this would be practical in reality, OTOH, because I think
there is a serious risk of breakage each time I would upgrade one of the
packages (via 'pipx upgrade-all' for instance).

So IMHO the best way to implement solution 3 would be by using some variant
of the approach popularized by Nix (repository of immutable packages +
links to each virtualenv).

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ &
http://pydata.fr/
___
Python-Dev mailing list -- python-dev@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-dev@python.org/message/6GV3EPYU2SW2QKAKLXZCG3JLNCVSQZWG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

[Stéfane Fermigier]

On Wed, Feb 24, 2021 at 11:43 AM Henk-Jaap Wagenaar <
wagenaarhenkj...@gmail.com> wrote:

>
>>
> I've been using pyenv (on MacBooks to be fair, not Linux/Debian) and been
> quite happy with that, and it basically does what Jonathan does manually:
> clone the github repo and build python from scratch.
>

Also using pyenv myself, on platforms where either, or both, new and old
version of Python are not available (so on Ubuntu I'm sticking with Anthony
Sottile's deadsnakes.)

But I'm not using it to manage virtual envs. For my own development
projects, I'm using VirtualFish since I've switched to Fish as my main
shell, but I was happy with VirtualenvWrapper when I was still using bash
or zsh. I can't live without VirtualFish's autoactivation plugin (which
activate a given virtualenv each time you enter your project). There was
something similar for Zsh though I don't remember which. Sometimes I forget
that I'm not in the right folder, or that I didn't create the virtualenv,
or that I removed it in the case of an old project, and I end up polluting
my default Python install after a 'pip install ...'. No big deal but always
a bit unpleasant.

And as I wrote before, I'm now using pipx to install the apps that I use.

This works not so bad (except for some quirks now and then) but it took
quite some time to select the right (for me) tools, to set up the proper
config files on my computer, and it can be annoying when working on a
server which has not been set up the same way. It also takes some time to
explain to collaborators, especially interns or juniors.

So obviously there is room for improvement, especially in terms of
simplicity for beginners.

  S.

___
> Python-Dev mailing list -- python-dev@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-dev@python.org/message/OZRHP3Q6EZNCPCTEEXLZGOCTGY6B7YFW/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ &
http://pydata.fr/
___
Python-Dev mailing list -- python-dev@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-dev@python.org/message/X7GSLJIICBL5TJVUG32XGBGVLPLIHKIW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Python-ideas] Have virtual environments led to neglect of the actual environment?

[Stéfane Fermigier]

I love pipx and I'm glad it exists at this point because it make

The main issue is that each virtualenv takes space, lots of space.

I have currently 57 apps installed via pipx on my laptop, and the 57
environments take almost 1 GB already.

 ~  cd .local/pipx/venvs/
 ~/.l/p/venvs  ls
abilian-tools/  concentration/  gitlabber/  pygount/sphinx/
ansible/cookiecutter/   httpie/ pyinfra/tentakel/
assertize/  cruft/  isort/  pylint/ tlv/
autoflake/  cython/ jupyterlab/ pyre-check/ towncrier/
black/  dephell/lektor/ pytype/ tox/
borgbackup/ docformatter/   md2pdf/ pyupgrade/  twine/
borgmatic/  flake8/ medikit/radon/  virtualenv/
bpytop/ flit/   mypy/   re-ver/ virtualfish/
check-manifest/ flynt/  nox/sailboat/   vulture/
clone-github/   gh-clone/   pdoc3/  salvo/
cloneall/   ghtop/  pdocs/  shed/
com2ann/gitchangelog/   pybetter/   sixer/
 ~/.l/p/venvs  du -sh .
990M .
 ~/.l/p/venvs  ls | wc
  57  57 475

There is probably a clever way to reuse common packages (probably via
clever symlinking) and reduce the footprint of these installations.

Still, I'm glad that pipx exists as it is now, and that it has been
packaged on Ubuntu 20.04 and later (and probably other distros as well).

Having pipx (or something similar) installed by the distro, and the distro
focussed on packaging only the packages that are needed for its own sake,
means that we could go past the controversies between the Python community
and the Debian (or other distros) packagers community, which are based on
different goals and assumption, such as this one:
https://gist.github.com/tiran/2dec9e03c6f901814f6d1e8dad09528e

  S.

On Wed, Feb 24, 2021 at 2:28 AM Paul Bryan  wrote:

> I think it's a classic case of dependency hell.
>
> OS packagers are rebundling Python packages as OS packages and expressing
> their own OS-package dependency graphs. Then, you sudo pip install
> something that has a conflicting dependency, it bypasses OS packaging, and
> *boom*.
>
> I find tools like pipx  go a long
> way to solve this, as they install a Python package and all of its
> dependencies in its own venv. This is great for Python apps, and (kinda)
> treats them like apps on platforms like Android, where all app dependencies
> are bundled and isolated from others.
>
> I think it would great if OS vendors did something similar to pipx for
> Python-based apps: bundle the app and all of its dependencies into its own
> venv.
>
>
> On Tue, 2021-02-23 at 19:45 -0500, Random832 wrote:
>
> I was reading a discussion thread <
> https://gist.github.com/tiran/2dec9e03c6f901814f6d1e8dad09528e> about
> various issues with the Debian packaged version of Python, and the
> following statement stood out for me as shocking:
>
> Christian Heimes wrote:
>
> Core dev and PyPA has spent a lot of effort in promoting venv because we
> don't want users to break their operating system with sudo pip install.
>
>
> I don't think sudo pip install should break the operating system. And I
> think if it does, that problem should be solved rather than merely advising
> users against using it. And why is it, anyway, that distributions whose
> package managers can't coexist with pip-installed packages don't ever seem
> to get the same amount of flak for "damaging python's brand" as Debian is
> getting from some of the people in the discussion thread? Why is it that
> this community is resigned to recommending a workaround when distributions
> decide the site-packages directory belongs to their package manager rather
> than pip, instead of bringing the same amount of fiery condemnation of that
> practice as we apparently have for *checks notes* splitting parts of the
> stdlib into optional packages? Why demand that pip be present if we're not
> going to demand that it works properly?
>
> I think that installing packages into the actual python installation, both
> via distribution packaging tools and pip [and using both simultaneously -
> the Debian model of separated dist-packages and site-packages folders seems
> like a reasonable solution to this problem] can and should be a supported
> paradigm, and that virtual environments [or more extreme measures such as
> shipping an entire python installation as part of an application's
> deployment] should ideally be reserved for the rare corner cases where that
> doesn't work for some reason.
>
> How is it that virtual environments have become so indispensable, that
> no-one considers installing libraries centrally to be a viable model
> anymore? Are library maintainers making breaking changes too frequently,
> reasoning that if someone needs the old version they can just venv it? Is
> there some other cause?
> 

[Python-Dev] Re: [Python-ideas] Re: Re: Have virtual environments led to neglect of the actual environment?

[Stéfane Fermigier]

On Wed, Feb 24, 2021 at 1:47 PM Stéfane Fermigier  wrote:

>
> So IMHO the best way to implement solution 3 would be by using some
> variant of the approach popularized by Nix (repository of immutable
> packages + links to each virtualenv).
>

Another benefit of this kind of approach, besides sparing disk space, could
be similar improvements in terms of installation time (and even bigger
improvements when reinstalling a package, which happens all the time when
developing).

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ &
http://pydata.fr/
___
Python-Dev mailing list -- python-dev@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-dev@python.org/message/UO2AZHKZUNEQ34SGNKCR5RTD4GYI2SHF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Remove formatter module

[Stéfane Fermigier]

On Tue, Nov 24, 2020 at 12:51 PM Victor Stinner  wrote:

>
> I never used this module, I don't know what it is.
>

I've run a quick search on GitHub and the only meaningful reference I could
find is the Grail browser (which had its last release, AFAICT, in 1999).

http://grail.sourceforge.net/

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ &
http://pydata.fr/
___
Python-Dev mailing list -- python-dev@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-dev@python.org/message/FNMTOX37DMZLCJEHQ55VZO7K4PQHPL7B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Stéfane Fermigier]

I didn't want to participate in this discussion, but I will, probably for
the following reasons:

- I'm French
- I bought a copy of Strunk & White during my first trip to the US, in
1990, in a desperate attempt to improve my english writing style.
- I can't say it changed my life, but I found the advice it contains useful
- and, as noted by others, not just for english speakers.
- For this reason, I have some fondness for this book (I know it has its
limitations too...).
- I'm puzzled by how some people might equate S with white supremacy.

I was still puzzled, as many others in this thread, until I googled for it,
and found some reference to this story:

*His former executive assistant, Cassie Jones, who is black, quit shortly
after he gave her a gift she considered insulting, three people with
knowledge of the matter said.*

> *In November, after she had spent four months working for him, Mr. Lynch
called Ms. Jones into his office and handed her “The Elements of Style,” a
guide to standard English usage by William Strunk Jr. and E.B. White. Mr.
Lynch said he thought she could benefit from it.*

> *With its suggestion that her own language skills were lacking, the gift
struck Ms. Jones as a microaggression, the people said. A few days later,
she quit. Before leaving the headquarters at 1 World Trade in Lower
Manhattan, she placed the book on his desk.*

*Mr. Lynch said he hadn’t meant to insult Ms. Jones, who declined to
comment for this article. “I really only had the intention — like every
time I’ve given it before — for it to be a helpful resource, as it has been
for me,” he said. “I still use it today. I’m really sorry if she
interpreted it that way.”*

https://www.nytimes.com/2020/06/13/business/media/conde-nast-racial.html

So I guess this gives some context to this discussion.

Additional personal remark: I have many times in my professional life given
or been given a book about specific work-related topics when I or the other
party thought that one could benefit from it in terms of useful
work-related skill acquisition. I find it quite hard to understand how
someone would reject such a gift and take it as a reason to resign (unless
of course there were other things going on in this company, in which case,
why bring the focus on S ?).

  S.


On Tue, Jun 30, 2020 at 3:29 PM Kyle Stanley  wrote:

> > Basically, it feels like we were lied to.  And if that wasn't bad
> enough, to see that Guido accepted that vitriolic commit message and merged
> it in ... it makes me embarrassed to be a Python supporter.
>
> Only Guido could attest to this, but as someone who spoke in support of
> the change, I personally missed the commit message until attention was
> drawn to it in the python-ideas thread. When reviewing PRs, I'll admit that
> I don't pay a whole lot of attention to the individual commit messages
> (particularly extended descriptions); most of my attention is on the actual
> changes made. So, perhaps he did the same?
>
> Either way, I don't think I would go as far as to say that it embarrasses
> me as a Python contributor. That being said, it did very much feel like it
> went in a completely different direction than the PR description, and I'm
> uncomfortable with it as well for that reason. So, my vote would be to
> amend the commit message based on the description of the PR and proposal
> made in python-ideas.
>
> On Tue, Jun 30, 2020 at 8:53 AM Ethan Furman  wrote:
>
>> On 06/30/2020 05:03 AM, Łukasz Langa wrote:
>> >
>> >> On 30 Jun 2020, at 12:44, Ethan Furman > et...@stoneleaf.us>> wrote:
>> >>
>> >> Of course I don't know if Keara or Guido knew any of this, but it
>> certainly feels to me that the commit message is ostracizing an entire
>> family line because they had the misfortune to have the wrong last name.
>> In fact, it seems like Strunk & White is making changes to be inclusive in
>> its advice -- exactly what I would have thought we wanted on our side ("our
>> side" being the diverse and welcoming side).
>> >
>> > In any case, saying that Keara and Guido mistook the family name of one
>> of the authors for skin color feels derogatory.
>>
>> My apologies, that was not my intent.  As I said, I never knew what it
>> was until today (er, yesterday now).
>>
>> > The commit message clearly is controversial but when you say the change
>> itself was unnecessary, consider that English is now a language
>> predominantly used outside of USA and Great Britain. Relaxing the
>> recommendation to use S & L Standard English in the CPython codebase isn't
>> problematic in this sense. That recommendation was largely ignored anyway,
>> as core developer voices in the other threads already admitted. So, chaos
>> won't ensue. We still want to maintain consistency, as PEP 8 recommends. I
>> don't think you have to worry now about seeing organization and
>> organisation in the same docstring.
>>
>> Well, that wouldn't bother me -- as often as not I use non-US-English
>> spellings; I just appreciate if it's 

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Stéfane Fermigier]

On Fri, Jun 26, 2020 at 3:38 PM Mark Shannon  wrote:

>
> What does "static and dynamic specifications" mean? Surely, there are
> just specifications.
>

There are specifications for both the runtime and the static aspects of the
Python programming language.


> Python does not have a static checking phase,


The (C)Python *interpreter* doesn't. Other Python implementations (existing
or hypothetical) may or may not have a static checking phase.

But static tools need specifications beyond (ie. additionally to) runtime
specifications, which are defined in PEP 483, 484, 585 and others.

> Let us start from some anecdotal evidence: isinstance() is one of the
> most called functions in large scale Python code-bases (by static call
> count). In particular, when analyzing some multi-million line production
> code base, it was discovered that isinstance() is the second most called
> builtin function (after len()). Even taking into account builtin classes,
> it is still in the top ten. Most of such calls are followed by specific
> attribute access.
>
> Why use anecdotal evidence? I don't doubt the numbers, but it would be
> better to use the standard library, or the top N most popular packages
> from GitHub.
>

Maybe a scientific paper could be written on this subject. I'm guessing
the "multi-million line production code base" in question is the Dropbox
code base, and maybe Dropbox has an idiomatic way of writing Python with
lots of "isinstance()"s.

> In general, we believe that pattern matching has been proved to be a
> useful and expressive tool in various modern languages. In particular, many
> aspects of this PEP were inspired by how pattern matching works in Rust [3]
> and Scala [4].
>
> Both those languages are statically typed, which allows the compiler to
> perform the much of the pattern matching at compile time.
>
> You should give examples from dynamic typed languages instead, e.g.
> clojure.
>

Here's one example:

https://github.com/clojure/core.match (in particular:
https://github.com/clojure/core.match/wiki/Understanding-the-algorithm ).

Alson some insights from
https://softwareengineering.stackexchange.com/questions/237023/pattern-matching-in-clojure-vs-scala


In this video  I watched
recently, Rich Hickey comments that he likes the destructuring part of
languages like Scala, but not so much the pattern matching part, and he
designed Clojure accordingly. That probably explains why the pattern
matching is in a library and not as robust, although the kind of problems
seen in the post you mentioned are clearly bugs.

What Rich Hickey mentions as an alternative to pattern matching is
multimethods . Most languages let you do
polymorphic dispatch based on type. Some languages let you also do it based
on a value. Using multimethods, Clojure lets you do it based on any
arbitrary function. That's a pretty powerful concept.

It comes down to the principle that programmers using a language should use
the language's own best idioms. Trying to write Scala-like code in Clojure
is going to have its difficulties, and vice versa.


  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ &
http://pydata.fr/
___
Python-Dev mailing list -- python-dev@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-dev@python.org/message/JWBAB4EC57NCTYREKPF63K6J347TCQXJ/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] Python Language Governance Proposals

[Stéfane Fermigier]

+1 (for what it's worth) to any proposal which includes one (or more)
GUIDOs :)

  S.

On Tue, Oct 23, 2018 at 11:57 AM Victor Stinner  wrote:

> Hi,
>
> Last July, Guido van Rossum decided to resign from his role of BDFL.
> Python core developers decided to design a new governance/organization
> for Python. 6 governance PEPs have been proposed. It has been decided
> that discussions are reserved to core developers (everyone can read,
> but only core devs can write), since the governance will mostly impact
> the life of core developers. I'm writing this email to python-dev to
> keep you aware that something is happening :-)
>
> Core developers (of the GitHub team) will vote to decide the new
> Python governance in 3 weeks:
> "The vote will happen in a 2-week-long window from November 16 2018 to
> November 30 (Anywhere-on-Earth)."
>
> See PEP 8001: Python Governance Voting Process
> https://www.python.org/dev/peps/pep-8001/
>
>
> Below are links to the governance PEPs, their abstract, and link to
> the Discourse discussions.
>
> Note: a Discourse instance is experimented at discuss.python.org to
> maybe replace python-{ideas,dev,committers} mailing lists. See the
> "Discourse Feedback" category at https://discuss.python.org/  :-)
>
>
> (1) PEP 8010: The BDFL Governance Model
> https://www.python.org/dev/peps/pep-8010
>
> Abstract:
> """
> This PEP proposes a continuation of the singular project leader model,
> euphemistically called the Benevolent Dictator For Life (BDFL) model
> of Python governance, to be henceforth called in this PEP the Gracious
> Umpire Influencing Decisions Officer (GUIDO). This change in name
> reflects both the expanded view of the GUIDO as final arbiter for the
> Python language decision making process in consultation with the wider
> development community, and the recognition that "for life" while
> perhaps aspirational, is not necessarily in the best interest of the
> well-being of either the language or the GUIDO themselves.
>
> This PEP describes:
>
> * The rationale for maintaining the singular leader model
> * The process for how the GUIDO will be selected, elected, retained,
> recalled, and succeeded;
> * The roles of the GUIDO in the Python language evolution process;
> * The term length of service;
> * The relationship of the GUIDO with a Council of Pythonistas (CoP)
> that advise the GUIDO on technical matters;
> * The size, election, and roles of the CoP;
> * The decision delegation process;
> * Any changes to the PEP process to fit the new governance model;
>
> This PEP does not name a new BDFL. Should this model be adopted, it
> will be codified in PEP 13 along with the names of all officeholders
> described in this PEP, as voted on per the guidelines in PEP 8001.
> """
>
> Discussion:
> https://discuss.python.org/t/pep-8010-the-singular-leader/188
>
>
> (2) PEP 8011: Python Governance Model Lead by Trio of Pythonistas
> https://www.python.org/dev/peps/pep-8011
>
> Abstract:
> """
> This PEP proposes a governance model for the Core Python development
> community, led by a trio of equally authoritative leaders. The Trio of
> Pythonistas (ToP, or simply Trio) is tasked with making final
> decisions for the language. It differs from PEP 8010 by specifically
> not proposing a central singular leader, but instead a group of three
> people as the leaders.
>
> This PEP also proposes a formation of specialized workgroups to assist
> the leadership trio in making decisions.
>
> This PEP does not name the members of the Trio. Should this model be
> adopted, it will be codified in PEP 13 along with the names of all
> officeholders described in this PEP.
>
> This PEP describes:
>
> * The role and responsibilities of the Trio
> * Guidelines of how trio members should be formed
> * Reasoning of the group of three, instead of a singular leader
> * Role and responsibilities of Python core developers to the trio
> * Sustainability considerations
> * Diversity and inclusivity considerations
> """
>
> Discussion:
>
> https://discuss.python.org/t/pep-8011-leadership-by-trio-of-pythonistas-top-or-simply-trio/199
>
>
> (3) PEP 8012: The Community Governance Model
> https://www.python.org/dev/peps/pep-8012/
>
> Abstract:
> """
> This PEP proposes a new model of Python governance based on consensus
> and voting by the Python community. This model relies on workgroups to
> carry out the governance of the Python language. This governance model
> works without the role of a centralized singular leader or a governing
> council.
>
> It describes how, when, and why votes are conducted for decisions
> affecting the Python language. It also describes the criteria for
> voting eligibility.
>
> Should this model be adopted, it will be codified in PEP 13.
>
> This model can be affectionately called "The Least Worst Governance
> Model" by its property that while far from ideal, it's still the most
> robust one compared to the others. Since avoiding issues inherent to
> the other models is a paramount 

[Python-Dev] Fwd: Examples for PEP 572

[Stéfane Fermigier]

On Wed, Jul 4, 2018 at 12:09 PM Chris Angelico  wrote:

>
> Even assuming your figures to be 100% accurate, I don't think you can
> accept that scaling. Are you claiming that every high school student
> (a) continues to use Python forever, and (b) continues to use it at a
> non-professional level? I find that highly unlikely.
>

What I'm claiming is that ~300 000 pupils in "seconde" (~ 10th grade in the
US, cf.
https://jeretiens.net/conversion-des-niveaux-scolaires-france-grande-bretagne-etats-unis/amp/
) are supposed to start learning (some basics of) Python this year during
their math classes, next year theses 300k pupils will be in 11th grade and
still be doing some Python, and next year they will be in 12th and pass
their baccalauréat (~ "high school diploma").

That's 1 millions pupils actively learning some Python in 2020, not
counting other categories of students ("classes prépa", engineering school,
etc.).

A majority of them will probably stop being involved with Python later, and
a small percentage will become "professional Python programmers".

I'm pretty dubious that these figures will correspond to the rest of
> the world,


It's probably similar to every country where Python is the recommended or
mandated language for teaching algorithmics or the basics of CS in school.
I have unfortunately no idea if there are any other countries in a similar
situation.

And dissimilar to countries where CS is not taught in schools, or another
language is used (Scratch or other block-languages are usually popular).

(Fun fact: before Python, the language that used to be taught in high
school in France, though only to a minority of students, used to be OCaml,
a language that was created by french academics in the 80s and 90s. Python
won because it's simpler and more mainstream.)

  S.


> where you can't expect that every single high school
> student is using Python.
>
> ChrisA
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/sfermigier%2Blists%40gmail.com
>


-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free Group @ Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ &
http://pydata.fr/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Examples for PEP 572

[Stéfane Fermigier]

On Tue, Jul 3, 2018 at 11:52 PM Chris Angelico  wrote:

> On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka 
> wrote:
> > I believe most Python users are not
> > professional programmers -- they are sysadmins, scientists, hobbyists and
> > kids --
>
> [citation needed]
>

Let's focus on France:

1) there are ~800 000 person aged 15. (Source:
https://www.insee.fr/fr/statistiques/1892088?sommaire=1912926 )

2) 40% of these are pupils in the "filière générale" (Source:
https://fr.wikipedia.org/wiki/Baccalaur%C3%A9at_en_France#Statistiques ).

3) Since 2017, Python is the language used to teach algorithmics to these
pupils.

=> We can conclude that there are at least 320 000 pupils learning Python
this year, and safely assume that most of them are not "professional
programmers".

Note also that this number is accretive (i.e.: 320 000 this year, 640 000
next year, etc.).

4) The annual turnover for the IT sector in France (including: software
vendor, service and consulting) was 54 billions euros in 2017. This
probably translates to around or less than 600 000 IT professionals. How
many of them are developers ? I have no idea, but I'm sure it's less that
50%. How many of them are developing professionally in Python ? I have no
idea, I'd guess less than 10%, but let's assume 20%.

=> This gives less than 60 000 professional Python programmers in France.
Probably much less.

Conclusion: there are probably more than 5 times more non professional
Python programmers in France (counting only the high-school pupils, not
other categories such as their teachers, but also scientist, sysadmins or
hobbyist) than professional programmers.

Next year it will be (more than) 1 to 10. The year after that, 1 to 15, etc.

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free Group @ Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ &
http://pydata.fr/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Examples for PEP 572

[Stéfane Fermigier]

On Wed, Jul 4, 2018 at 12:36 PM Stéfane Fermigier  wrote:

>
> And dissimilar to countries where CS is not taught in schools, or another
> language is used (Scratch or other block-languages are usually popular).
>

Just found:
https://www.ibtimes.co.uk/coding-uk-classroom-python-overtakes-french-most-popular-language-primary-schools-1517491

:) as a pythonista.

:( as a frenchman

Also, not sure how that translates into raw numbers.

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free Group @ Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ &
http://pydata.fr/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Meta-question about this mailing list

[Stéfane Fermigier]

Hi,

the description on https://mail.python.org/mailman/listinfo/python-dev
 reads:

"On this list the key Python developers discuss the future of the language
and its implementation."

I interpret this sentence as "only key (core?) developers are supposed to
participate in the discussion (ie. post messages), the rest is welcome to
lurk."

Is this the intended meaning ?

There is an additional description in the devguide:

"python-dev is the primary mailing list for discussions about Python’s
development. The list is open to the public and is subscribed to by all
core developers plus many people simply interested in following Python’s
development. Discussion is focused on issues related to Python’s
development, such as how to handle a specific issue, a PEP, etc."

I would interpret it as "it's OK for non core developers to post", except
for the "many people simply interested in following Python’s development"
part which hints that we are welcome to "follow" but not actively
participate.

So in either case (and both descriptions) it would IMHO be useful to use
clearer language.


Another point: later in the Mailman description, one reads: "Consider using
Gmane." (with a link to http://dir.gmane.org/gmane.comp.python.devel ).

I went to Gmane and found all the links broken. I remember there was some
turmoil at Gmane a couple of years back:

https://en.wikipedia.org/wiki/Gmane#References

=> It seems the migration didn't work that well and the service shouldn't
been relied upon.

Regards,

  S.








-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free Group @ Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ &
http://pydata.fr/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slipping Python 3.5.5rc1 and 3.4.8rc1 because of a Travis CI issue--can someone make Travis CI happy?

[Stéfane Fermigier]

On Mon, Jan 22, 2018 at 11:33 AM, Larry Hastings  wrote:

>
>
> I have three PRs for Python 3.5.5rc1:
>
> https://github.com/python/cpython/pull/4656
> https://github.com/python/cpython/pull/5197
> https://github.com/python/cpython/pull/5201
>
> I can't merge them because Travis CI is unhappy.  All three CI tests fail
> in the same way, reporting this error:
>
> The command "pyenv global system 3.5" failed and exited with 1 during .
>
>
This seems to be related to
https://github.com/travis-ci/travis-ci/issues/8363

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free Group / Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyData Paris - http://pydata.fr/
---
“You never change things by fighting the existing reality. To change
something, build a new model that makes the existing model obsolete.” — R.
Buckminster Fuller
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib

[Stéfane Fermigier]

On Fri, Nov 3, 2017 at 6:47 PM, Antoine Pitrou  wrote:

> On Fri, 3 Nov 2017 12:46:33 -0400
> "Eric V. Smith"  wrote:
> > On 11/3/2017 12:15 PM, Victor Stinner wrote:
> > > Hi,
> > >
> > > 2017-11-03 15:36 GMT+01:00 Guido van Rossum :
> > >> Maybe we should remove typing from the stdlib?
> > >> https://github.com/python/typing/issues/495
> >
> > > The typing module is not used yet in the stdlib, so there is no
> > > technically reason to keep typing part of the stdlib. IMHO it's
> > > perfectly fine to keep typing and annotations out of the stdlib, since
> > > the venv & pip tooling is now rock solid ;-)
> >
> > I'm planning on using it for PEP 557:
> > https://www.python.org/dev/peps/pep-0557/#class-variables
> >
> > The way the code currently checks for this should still work if typing
> > is not in the stdlib, although of course it's assuming that the name
> > "typing" really is the "official" typing library.
>
> I don't think other modules should start relying on the typing module at
> runtime.
>

They already do, as I've noted in my message about dependency injection,
and I find this quite elegant.

Previously, similar projects used decorators, or less elegant constructs.

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free Group / Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyData Paris - http://pydata.fr/
---
“You never change things by fighting the existing reality. To change
something, build a new model that makes the existing model obsolete.” — R.
Buckminster Fuller
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

[Stéfane Fermigier]

On Thu, Nov 2, 2017 at 7:39 PM, Jukka Lehtosalo 
wrote:

>
> As type checking has become the main use case for annotations, using
> annotations without a type checker is fast becoming a marginal use case.
> Type checkers can easily and reliably validate that names in annotations 
> aren't
> misspelled.
>

Another common use case is dependency injection / IoC:

Examples include:

- Injector (https://github.com/alecthomas/injector):

>>> class Outer:
... @inject
... def __init__(self, inner: Inner):
... self.inner = inner


- Flsk-Injector (ok it's the same underlying injector):

# Route with injection
@app.route("/foo")
def foo(db: sqlite3.Connection):
users = db.execute('SELECT * FROM users').all()
return render("foo.html")

- Apistar components (https://github.com/encode/apistar#components ):

def say_hello(user: User):
return {'hello': user.username}

=> In each of the examples, the type annotation are used at runtime by the
IoC container to inject an object of the appropriate type, based on some
specifications.

They may or may not be used by a typechecker too, but that's secondary.

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free Group / Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyData Paris - http://pydata.fr/
---
“You never change things by fighting the existing reality. To change
something, build a new model that makes the existing model obsolete.” — R.
Buckminster Fuller
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 557: Data Classes

[Stéfane Fermigier]

On Thu, Oct 12, 2017 at 10:20 AM, Mike Miller <python-...@mgmiller.net>
wrote:

>
> On 2017-10-12 00:36, Stéfane Fermigier wrote:
>
>> "An object that is not defined by its attributes, but rather by a thread
>> of continuity and its identity." (from https://en.wikipedia.org/wiki/
>> Domain-driven_design#Building_blocks)
>>
>
> Not sure I follow all this, but Python objects do have identities once
> instantiated.  e.g. >>> id('')


Yes, for the lifetime of the object in the Python VM.

But if you are dealing with objects that are persisted using some kind of
ORM, ODM, OODB, then it wont work.

It's quite common (but not always the best solution) to use some kind of
UUID to represent the identity of each entity.

Also, there can be circumstances where two objects can exist at the same
time in the VM which represent the same object, in which case one should
ensure that a == b iff a.uid == a.uid (in the case 'uid' is the attribute
used to carry the unique identifier).


> I don't believe either module particularly supports or restricts
> immutability?


http://www.attrs.org/en/stable/examples.html#immutability
https://www.python.org/dev/peps/pep-0557/#frozen-instances

  S.


>
>
> -Mike
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/sfermigie
> r%2Blists%40gmail.com
>
>

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free Group / Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyData Paris - http://pydata.fr/
---
“You never change things by fighting the existing reality. To change
something, build a new model that makes the existing model obsolete.” — R.
Buckminster Fuller
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 557: Data Classes

[Stéfane Fermigier]

On Wed, Oct 11, 2017 at 10:33 PM, Mike Miller 
wrote:

> (Apologies for reviving a dead horse, but may not be around at the blessed
> time.)
>
> As potential names of this concept, I liked record and row, but agreed
> they were a bit too specific and not quite exact.  In my recent (unrelated)
> reading however, I came across another term and think it might fit better,
> called an "entity."
>

I'm not familiar with ER modelling but I would advise against using the
term "entity", as it has, in domain-driven design (DDD) a very specific
meaning:

"An object that is not defined by its attributes, but rather by a thread of
continuity and its identity." (from
https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks)

See also the more general Wikipedia definition "An entity is something that
exists as itself, as a subject or as an object, actually or potentially,
concretely or abstractly, physically or not." (
https://en.wikipedia.org/wiki/Entity).

In the context of DDD, entities are usually opposed to value objects: "An
object that contains attributes but has no conceptual identity. They should
be treated as immutable.". (
https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks)

Attrs, and by extension the dataclass proposal (I guess), provide some
support for both:

- Providing support for quickly constructing immutable objects from a bag
of attributes, and providing equality based on those attributes, it helps
implement Value Objects (not sure much more is needed actually)

- By supporting equality based on some "primary key", it will also help
with maintaining the concept of "equality" in entities.

It would be great if the dataclass proposal could help implement DDD
technical concepts in Python, but its terminology should not conflict the
DDD terminology, if we want to avoid confusion.

Cheers,

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free Group / Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyData Paris - http://pydata.fr/
---
“You never change things by fighting the existing reality. To change
something, build a new model that makes the existing model obsolete.” — R.
Buckminster Fuller
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Investigating time for `import requests`

[Stéfane Fermigier]

Hi,

On Mon, Oct 2, 2017 at 11:42 AM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
>
> I don't expect to find anything that would help users of Django, Flask,
> and Bottle since those are typically long-running apps where we value
> response time more than startup time.
>

Actually, as web developers, we also value startup time when in development
mode, specially when we are in "hot reload" mode (when the app restarts
automatically each time we save a development file).

In my mid-sized projects (~10 kE LOC, ~150 pip dependencies) it takes
between 5 and 10s. This is probably the upper limit to "stay in flow".

Same for unit tests.

There is this famous Gary Bernhardt talk [https://youtu.be/RAxiiRPHS9k?t=12m
] he argues that a whole unit test suite should be able to run in < 1s and
actually show examples where the developer is able to run hundreds of tests
in less that 1s.

Note: In my projects, it take 3-4 seconds just to collect them (using
pytest --collect-only), but I suspect Python's startup time is only
responsible for a small part of this delay. Still, this is an important
point to keep in mind.

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free Group / Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyData Paris - http://pydata.fr/
---
“You never change things by fighting the existing reality. To change
something, build a new model that makes the existing model obsolete.” — R.
Buckminster Fuller
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 557: Data Classes

[Stéfane Fermigier]

Hi, first post here.

My two cents:

Here's a list of "prior arts" that I have collected over the years, besides
attrs, that address similar needs (and often, much more):

- https://github.com/bluedynamics/plumber
- https://github.com/ionelmc/python-fields
- https://github.com/frasertweedale/elk
- https://github.com/kuujo/yuppy

Regarding the name, 'dataclass', I agree that it can be a bit misleading
(my first idea of a "dataclass" would be a class with only data and no
behaviour, e.g. a 'struct', a 'record', a DTO, 'anemic' class, etc.).

Scala has 'case classes' with some similarities (
https://docs.scala-lang.org/tour/case-classes.html).

Regards,

  S.


On Fri, Sep 8, 2017 at 4:57 PM, Eric V. Smith  wrote:

> I've written a PEP for what might be thought of as "mutable namedtuples
> with defaults, but not inheriting tuple's behavior" (a mouthful, but it
> sounded simpler when I first thought of it). It's heavily influenced by the
> attrs project. It uses PEP 526 type annotations to define fields. From the
> overview section:
>
> @dataclass
> class InventoryItem:
> name: str
> unit_price: float
> quantity_on_hand: int = 0
>
> def total_cost(self) -> float:
> return self.unit_price * self.quantity_on_hand
>
> Will automatically add these methods:
>
>   def __init__(self, name: str, unit_price: float, quantity_on_hand: int =
> 0) -> None:
>   self.name = name
>   self.unit_price = unit_price
>   self.quantity_on_hand = quantity_on_hand
>   def __repr__(self):
>   return f'InventoryItem(name={self.name!r},unit_price={self.unit_pri
> ce!r},quantity_on_hand={self.quantity_on_hand!r})'
>   def __eq__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) == (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>   def __ne__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) != (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>   def __lt__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) < (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>   def __le__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) <= (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>   def __gt__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) > (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>   def __ge__(self, other):
>   if other.__class__ is self.__class__:
>   return (self.name, self.unit_price, self.quantity_on_hand) >= (
> other.name, other.unit_price, other.quantity_on_hand)
>   return NotImplemented
>
> Data Classes saves you from writing and maintaining these functions.
>
> The PEP is largely complete, but could use some filling out in places.
> Comments welcome!
>
> Eric.
>
> P.S. I wrote this PEP when I was in my happy place.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/sfermigie
> r%2Blists%40gmail.com
>



-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free Group / Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyData Paris - http://pydata.fr/
---
“You never change things by fighting the existing reality. To change
something, build a new model that makes the existing model obsolete.” — R.
Buckminster Fuller
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 544: Protocols - second round

[Stéfane Fermigier]

On Thu, Jun 22, 2017 at 10:44 AM, Markus Wissinger <
markus.wissin...@gmail.com> wrote:

> Hi,
>
> I have to admit I am not happy with separating the concepts of 'runtime'
> and 'static' types as implied by pep544.
>
> I am currently exploring a type hint generator that produces hints out of
> types used in unit tests. It debugs the tests and collects the parameter
> types of call and return events. It ignores a type when a supertype is
> present. Failing isinstance/issubclass calls for protocols would hurt
> there. I understand that any type checker code that could provide
> isinstance functionality for pep544 protocols would rely on method
> signatures that my hint generator is just producing.
>
> proof of concept implementation (writes method docstrings, no pep484 type
> hints yet):
> https://github.com/markuswissinger/ducktestpy
>
> This is currently just some personal project that some of you will
> consider a strange idea.
>

Not a strange idea, I've had a similar idea and played a bit with it ~10
years ago (inspired by a Java project whose name eludes me now).

Also, I think PyCharm is able to do similar things (see
https://blog.jetbrains.com/pycharm/2013/02/dynamic-runtime-type-inference-in-pycharm-2-7/
).

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free Group / Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyData Paris - http://pydata.fr/
---
“You never change things by fighting the existing reality. To change
something, build a new model that makes the existing model obsolete.” — R.
Buckminster Fuller
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com