Re: [Python-ideas] Possible enhancement to typing

[Steven D'Aprano]

On Sun, Nov 05, 2017 at 07:18:30PM +, Steve Barnes wrote:

> If a group of iterators were to be added to the typing module it would 
> be reasonably simple to automatically add and assert to any decorated 
> modules to ensure that such modules were always called with the 
> documented types.

"Iterators"?


> I am thinking of decorators such as:
> 
>   - @typing.assert_params_mismatch - this would provide a wrapper that 
> had auto-generated asserts that all the parameters were of designated types.
>   - @typing.debug_assert_params_mismatch - this would provide a wrapper 
> that had auto-generated asserts that all the parameters were of 
> designated types only if a DEBUG environmental variable was set or similar.

That's what assert does: assert only runs when __DEBUG__ is true. That's 
not controlled by an environment variable, but by the -O flag to the 
interpreter.

So your assert_params_mismatch and debug_assert_params_mismatch are 
effectively the same thing.

But using assert to check to perform argument checks is often an abuse 
of assert. To be more specific, using assert to check the value of 
public arguments in library code (where the arguments come from outside the 
library) is wrong, since you (the library author) cannot guarantee 
that your type tests will even run.

Using asserts for argument checking inside application code is more of a 
grey area, with arguments for and against using assert.

But in my opinion, the deciding factor is nearly always that an 
AssertionError is the wrong sort of exception. Outside of some fairly 
limited circumstances, most of which don't involve type-checking 
function arguments, using assert robs the caller of some useful 
information: the *kind* of error. (TypeError, ValueError, etc.)

See here for further discussion: 

https://import-that.dreamwidth.org/676.html

In general, I don't think we want to encourage such runtime type 
testing. Obviously there are exceptions -- library code should 
probably type check arguments, applications perhaps not -- and 
we're not exactly discouraging it either. There are already a number of 
third-party libraries that provide argument type tests at runtime, and 
I think that's probably the right place for them.


[...]
> I also think that this might increase the uptake of typing by giving 
> some clear benefits outside of documentation and static type checking.

Problem is, the benefits of runtime type checking aren't clear. But the 
costs certainly are: if you want slow code, do lots and lots of runtime 
type checks.


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Looking for input to help with the pip situation

[Michel Desmoulin]

Hello,

Today I'm going to give a training in Python again.

And again it will go the same way.

On Mac I will have to make people install python, then tell them to use
pip3.

On Windows, I will have to warn them about checking the "add python
executable to system path" (that one of them will ALWAYS miss anyway).
Then tell them to use py -3.x -m pip because some of them will have
several versions of Python installed.

Then on linux, I will tell them to install python-pip and python-venv
and use python3 -m pip.

I'll talk about --user, but commands won't be usable on some machine
where the Scripts or bin dir is not in the system path.

Then I will make them create a virtualenv so that they can avoid messing
with their system python and finally can just use "pip install" like in
most tutorials on the Web.

And eventually I'll talk about pipenv and conda. The first one so they
don't have to think about activating the virtualenv everytime, or pip
freeze, or create the venv, or add it to gitignore, etc. The second
because anaconda is very popular on windows.

There is no way a beginner is going to get any that by themselves
without a lot of time and pain. They will read some tutorial on the web
and struggle to make sens of what pip is and why "pip install" doesn't
work and why "python sucks".

I think Python is offering an incredible experience for first timer.
However, the whole "where is walpip" shenanigans is not one of them.

I really want some people from this list to discuss here so we can find
a way to either unify a bit the way we install and use pip, or find a
way to express a tutorial that always works for people on the most
popular platforms and spread the word so that any doc uses it.

Michel

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

[Lukasz Langa]

> On 5 Nov, 2017, at 10:30 PM, Michel Desmoulin  
> wrote:
> 
> Le 06/11/2017 à 07:07, Nick Coghlan a écrit :
> 
>> It's the default on Unix as well - you have to do "make install
>> ENSUREPIP=no" to avoid getting it. (And some distros also modify their
>> Python installations so that pip is missing by default)
> 
> On debian and derivatives (so Ubuntu) you need to install python-pip to
> be able to use pip.
> 
> Now it's annoying already. Because you have to write every tutorial to
> include a special case for them. But at least it's not a required step
> to run your program.
> 
> However, if you do code using type hints and typing is not installed,
> you can't even run the program without installing something. So we
> finally have Python 3 by default on most Linux system, but still would
> not be able to assume we can run a modern script on it.

This is a valid concern. Although this particular problem is self-inflicted by 
Debian, I can understand their rationale behind explicit packaging. They need 
to have control over the entire package graph. I wonder if there's a way in 
.deb to specify a required installed package. I'm not calling it a "dependency" 
since obviously it would rather be "python3-typing" that depends on "python3". 
Barry, do you know?

But even if Debian installs python3-typing by default, will "pip install -U 
typing" be possible in this scenario? I guess it wouldn't be terrible if that 
only worked in virtualenvs, although ideally it would work also for the raw 
host installation.

- Ł


signature.asc
Description: Message signed with OpenPGP
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

[Michel Desmoulin]

Le 06/11/2017 à 07:07, Nick Coghlan a écrit :

> It's the default on Unix as well - you have to do "make install
> ENSUREPIP=no" to avoid getting it. (And some distros also modify their
> Python installations so that pip is missing by default)

On debian and derivatives (so Ubuntu) you need to install python-pip to
be able to use pip.

Now it's annoying already. Because you have to write every tutorial to
include a special case for them. But at least it's not a required step
to run your program.

However, if you do code using type hints and typing is not installed,
you can't even run the program without installing something. So we
finally have Python 3 by default on most Linux system, but still would
not be able to assume we can run a modern script on it.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

[Chris Angelico]

On Mon, Nov 6, 2017 at 5:06 PM, Nick Coghlan  wrote:
> On 6 November 2017 at 09:08, Chris Angelico  wrote:
>> On Mon, Nov 6, 2017 at 9:29 AM, Barry Scott  wrote:
>>> If this is a mechanism that python kitting has then you would be able to
>>> bundle other packages like requests or six as well as typing, but because
>>> you can use pip to override the one shipped a user can optionally keep
>>> up with the latest versions.
>>
>> If this were to happen, I would be inclined to put these "bootstrap"
>> modules into their own directory in sys.path, after the rest of the
>> stdlib. Then someone who's paranoid about stdlib shadowing could put
>> pip-installed modules after the bulk of the stdlib (thus preventing
>> any third-party package from overriding "import random", for instance)
>> but still update modules that are specifically intended for updating;
>> plus it'd mean you can get a directory listing of that, and go grab
>> all the "blessed by python.org as an extension of the stdlib"
>> packages.
>
> When we say bundled, we mean bundled: the exact same bits you would
> get from PyPI, installed the same way, and if you upgrade it system
> wide, there's no trace of the one we bundled.

Oh, that's even better! :+1:

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

[Nick Coghlan]

On 6 November 2017 at 05:00, Paul Moore  wrote:
> On 5 November 2017 at 18:40, Antoine Pitrou  wrote:
>> I think typing shouldn't require any extra typing (ha) on Unix either.
>> I don't remember what the rationale was for having to type
>> "python -m ensurepip" to get pip installed, but typing is just a
>> library, not an executable tool that may be able to mess with the
>> system state, so I don't think it's worthwhile introducing an extra
>> step for it.
>
> Yes, I agree. I didn't realise that "give me pip" was an extra step on
> Unix. I don't know what the arguments for doing it like that on Unix
> were, but they certainly don't seem to apply to typing.

It's the default on Unix as well - you have to do "make install
ENSUREPIP=no" to avoid getting it. (And some distros also modify their
Python installations so that pip is missing by default)

We provide "python -m ensurepip" because we offer ways to skip doing
it at install time (and venv creation time), so the explicit command
gives folks a straightforward way to change their minds later.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

[Nick Coghlan]

On 6 November 2017 at 09:08, Chris Angelico  wrote:
> On Mon, Nov 6, 2017 at 9:29 AM, Barry Scott  wrote:
>> If this is a mechanism that python kitting has then you would be able to
>> bundle other packages like requests or six as well as typing, but because
>> you can use pip to override the one shipped a user can optionally keep
>> up with the latest versions.
>
> If this were to happen, I would be inclined to put these "bootstrap"
> modules into their own directory in sys.path, after the rest of the
> stdlib. Then someone who's paranoid about stdlib shadowing could put
> pip-installed modules after the bulk of the stdlib (thus preventing
> any third-party package from overriding "import random", for instance)
> but still update modules that are specifically intended for updating;
> plus it'd mean you can get a directory listing of that, and go grab
> all the "blessed by python.org as an extension of the stdlib"
> packages.

When we say bundled, we mean bundled: the exact same bits you would
get from PyPI, installed the same way, and if you upgrade it system
wide, there's no trace of the one we bundled.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Possible enhancement to typing

[Steve Barnes]

The discussions on moving typing to a standalone library prompted me to 
take a look at the documentation for typing which in turn lead to an 
idea that should be reasonably simple to implement but greatly add value 
to typing for some applications.

If a group of iterators were to be added to the typing module it would 
be reasonably simple to automatically add and assert to any decorated 
modules to ensure that such modules were always called with the 
documented types.

I am thinking of decorators such as:

  - @typing.assert_params_mismatch - this would provide a wrapper that 
had auto-generated asserts that all the parameters were of designated types.
  - @typing.debug_assert_params_mismatch - this would provide a wrapper 
that had auto-generated asserts that all the parameters were of 
designated types only if a DEBUG environmental variable was set or similar.
  - @typing.warn_params_mismatch - this would provide a wrapper that had 
auto-generated warnings issued to stderr if any of the parameters were 
of not of the designated types.
  - @typing.coerce_params - this would add a wrapper to attempt to 
convert any mismatched parameters to the specified type(s).

I also think that this might increase the uptake of typing by giving 
some clear benefits outside of documentation and static type checking.

Pushing this out for comment before considering a more formal, (PEP), 
proposal.
-- 
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect 
those of my employer.

---
This email has been checked for viruses by AVG.
http://www.avg.com

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Proposal to change Python version release cycle

[Random832]

On Sat, Nov 4, 2017, at 10:29, Wolfgang wrote:
> For example the user specified python3 but I know it will be compatible 
> with python4 so the launcher can do something like
> python3 is not found then I use python4 if available.
> 
> ex.:
> 
> #!/usr/bin/env py -3

If you actually try that, you'll find out the dirty little secret of the
#! functionality - on many systems, it only supports one argument.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

[Chris Angelico]

On Mon, Nov 6, 2017 at 9:29 AM, Barry Scott  wrote:
> On Saturday, 4 November 2017 20:22:25 GMT Guido van Rossum wrote:
>> On Sat, Nov 4, 2017 at 7:05 AM, Nick Coghlan  wrote:
>> > Perhaps typing could switch to being a bundled module, such that it
>> > had its own version, independent of the Python standard library
>> > version, but was still present by default in new installations?
>>
>> This is beginning to sound like the most attractive solution. We could
>> possibly do away with typing_extensions. Are there precedents of how to
>> bundle a module in this way? Or is it going to be another special case like
>> pip?
>
> Is the outcome you want that you ship a version of typing with the python kit,
> but if you install from pip it overrides the one shipped in the python kit?
>
> That would be a matter of being having a suitable sys.path/site config I
> guess. pip folder before the bundled packages folder.
>
> If this is a mechanism that python kitting has then you would be able to
> bundle other packages like requests or six as well as typing, but because
> you can use pip to override the one shipped a user can optionally keep
> up with the latest versions.

If this were to happen, I would be inclined to put these "bootstrap"
modules into their own directory in sys.path, after the rest of the
stdlib. Then someone who's paranoid about stdlib shadowing could put
pip-installed modules after the bulk of the stdlib (thus preventing
any third-party package from overriding "import random", for instance)
but still update modules that are specifically intended for updating;
plus it'd mean you can get a directory listing of that, and go grab
all the "blessed by python.org as an extension of the stdlib"
packages.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

[Barry Scott]

On Saturday, 4 November 2017 20:22:25 GMT Guido van Rossum wrote:
> On Sat, Nov 4, 2017 at 7:05 AM, Nick Coghlan  wrote:
> > Perhaps typing could switch to being a bundled module, such that it
> > had its own version, independent of the Python standard library
> > version, but was still present by default in new installations?
> 
> This is beginning to sound like the most attractive solution. We could
> possibly do away with typing_extensions. Are there precedents of how to
> bundle a module in this way? Or is it going to be another special case like
> pip?

Is the outcome you want that you ship a version of typing with the python kit,
but if you install from pip it overrides the one shipped in the python kit?

That would be a matter of being having a suitable sys.path/site config I 
guess. pip folder before the bundled packages folder.

If this is a mechanism that python kitting has then you would be able to
bundle other packages like requests or six as well as typing, but because
you can use pip to override the one shipped a user can optionally keep
up with the latest versions.

Barry

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] About the efficiency of range()

[Terry Reedy]

On 11/5/2017 1:49 PM, Juancarlo Añez wrote:

I found this interesting:
https://stackoverflow.com/a/46996392 


python-list is the place to post 'interesting' python-related items.

If you are proposing a repeat(n) builtin, that was discussed on this 
list and rejected a year or two ago.  It would be be a bit faster than 
even itertools.repeat(None, n) in a for loop.  The speed argument for 
the proposal was countered then with the point made on the 3rd comment 
in the link: "But in practical code the body of the loop will be more 
complex, and dominate the over all timing. "  An overhead of .23 
microseconds per loop is small enough for real use cases.


The better argument for repeat(n) was simplicity, not speed.  The 
counter for that was and is that never needing the index for the 
lifetime of a particular loop, including learning, testing, debugging, 
and maintenance, is rare and not predictable.


--
Terry Jan Reedy


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Proposal to change Python version release cycle

[Stephan Houben]

2017-11-05 21:02 GMT+01:00 Serhiy Storchaka :

> But len(os.fsencode("python3⑽.dll")) != len(os.fsencode("python39.dll")).
>
>
I think it is on Windows. os.fsencode should use UTF-16 there.
⑽ is in the BMP

Presumably, non-Windows platforms wouldn't be interested in .dll
files anyway...

Stephan


>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Proposal to change Python version release cycle

[Serhiy Storchaka]

05.11.17 21:53, Stephan Houben пише:

After python39.dll I'd expect python3A.dll .


The problem will return in 3.36.


Or possibly python3⑽.dll

 >>> len("python3⑽.dll") == len("python39.dll")
True

No worries, then.


But len(os.fsencode("python3⑽.dll")) != len(os.fsencode("python39.dll")).

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Proposal to change Python version release cycle

[Stephan Houben]

After python39.dll I'd expect python3A.dll .

Or possibly python3⑽.dll

>>> len("python3⑽.dll") == len("python39.dll")
True

No worries, then.

Stephan

2017-11-05 20:28 GMT+01:00 Serhiy Storchaka :

> 04.11.17 17:29, Wolfgang пише:
>
>> A good point but two digits minor version numbers have the possibility
>> to break a lot code. There is a lot of stuff out where a single digit
>> major version is assumed. Even the official Python build for windows
>> with python27.dll, python36.dll can be problematic because the dot
>> is omitted between numbers.
>> Other do the same for compilation they concatenate only majorminor for a
>> name.
>> Then version 3.10 is the same as 31.0.
>>
>
> Actually this is yet one argument against your idea. With your proposal 27
> will be the same as 2.7.
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Proposal to change Python version release cycle

[Serhiy Storchaka]

04.11.17 17:29, Wolfgang пише:

A good point but two digits minor version numbers have the possibility
to break a lot code. There is a lot of stuff out where a single digit
major version is assumed. Even the official Python build for windows
with python27.dll, python36.dll can be problematic because the dot
is omitted between numbers.
Other do the same for compilation they concatenate only majorminor for a
name.
Then version 3.10 is the same as 31.0.


Actually this is yet one argument against your idea. With your proposal 
27 will be the same as 2.7.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] About the efficiency of range()

[Serhiy Storchaka]

05.11.17 20:49, Juancarlo Añez пише:

I found this interesting:

https://stackoverflow.com/a/46996392 


Please explain your suggestion.

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

[Paul Moore]

On 5 November 2017 at 18:40, Antoine Pitrou  wrote:
> I think typing shouldn't require any extra typing (ha) on Unix either.
> I don't remember what the rationale was for having to type
> "python -m ensurepip" to get pip installed, but typing is just a
> library, not an executable tool that may be able to mess with the
> system state, so I don't think it's worthwhile introducing an extra
> step for it.

Yes, I agree. I didn't realise that "give me pip" was an extra step on
Unix. I don't know what the arguments for doing it like that on Unix
were, but they certainly don't seem to apply to typing.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] About the efficiency of range()

[Juancarlo Añez]

I found this interesting:

https://stackoverflow.com/a/46996392


-- 
Juancarlo *Añez*
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

[Antoine Pitrou]

On Sun, 5 Nov 2017 18:22:11 +
Paul Moore  wrote:

> On 5 November 2017 at 14:47, Antoine Pitrou  wrote:
> >
> > Le 05/11/2017 à 14:30, Paul Moore a écrit :  
> >> On 5 November 2017 at 10:48, Antoine Pitrou  wrote:  
> >>> On Sun, 5 Nov 2017 13:46:59 +1000
> >>> Nick Coghlan  wrote:  
>  * ensurepip gains the ability to also install bundled wheel files  
> >>>
> >>> Why? Why wouldn't you put the wheel directly in site-packages on
> >>> install?  
> >>
> >> I'm not quite sure what you mean? It needs to be "installed", in the
> >> sense of being unpacked into site-packages, and the ensurepip
> >> mechanism is already able to do that for pip and setuptools, so adding
> >> an extra wheel to install wouldn't be too hard.  
> >
> > Ok, perhaps my question wasn't quite clear.  Are you suggesting that
> > people have to run "python -m ensurepip typing" after they installed
> > Python?  Or would the typing module be importable as soon as you have an
> > installed Python, like stdlib modules are?  
> 
> Ah, I get you now. I'd expect typing to be available exactly the same
> way as pip is. For me (on Windows) that means that it's available in a
> standard install. On Unix, I don't know (I think there's certain
> situations where you need to take extra steps in a custom build to
> ensure pip is available? I'd expect those steps to also install
> typing.

I think typing shouldn't require any extra typing (ha) on Unix either.
I don't remember what the rationale was for having to type
"python -m ensurepip" to get pip installed, but typing is just a
library, not an executable tool that may be able to mess with the
system state, so I don't think it's worthwhile introducing an extra
step for it.

Regards

Antoine.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

[Paul Moore]

On 5 November 2017 at 14:47, Antoine Pitrou  wrote:
>
> Le 05/11/2017 à 14:30, Paul Moore a écrit :
>> On 5 November 2017 at 10:48, Antoine Pitrou  wrote:
>>> On Sun, 5 Nov 2017 13:46:59 +1000
>>> Nick Coghlan  wrote:
 * ensurepip gains the ability to also install bundled wheel files
>>>
>>> Why? Why wouldn't you put the wheel directly in site-packages on
>>> install?
>>
>> I'm not quite sure what you mean? It needs to be "installed", in the
>> sense of being unpacked into site-packages, and the ensurepip
>> mechanism is already able to do that for pip and setuptools, so adding
>> an extra wheel to install wouldn't be too hard.
>
> Ok, perhaps my question wasn't quite clear.  Are you suggesting that
> people have to run "python -m ensurepip typing" after they installed
> Python?  Or would the typing module be importable as soon as you have an
> installed Python, like stdlib modules are?

Ah, I get you now. I'd expect typing to be available exactly the same
way as pip is. For me (on Windows) that means that it's available in a
standard install. On Unix, I don't know (I think there's certain
situations where you need to take extra steps in a custom build to
ensure pip is available? I'd expect those steps to also install
typing.

So basically, yes, typing can be expected to be available in all
installations, exactly the same as pip is.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Proposal to change Python version release cycle

[MRAB]

On 2017-11-05 03:07, Nick Coghlan wrote:

On 5 November 2017 at 01:29, Wolfgang  wrote:

On 04.11.2017 16:01, Nick Coghlan wrote:

We're currently more likely to go the other direction, and stick with
the 3.x numbering for an extended period (potentially reaching 3.10,
3.11, 3.12, etc), so that the ongoing disruption caused by the 2.x ->
3.x transition has had a chance to settle down before we ask anyone to
start calling anything "Python 4".


A good point but two digits minor version numbers have the possibility
to break a lot code. There is a lot of stuff out where a single digit
major version is assumed. Even the official Python build for windows
with python27.dll, python36.dll can be problematic because the dot
is omitted between numbers.
Other do the same for compilation they concatenate only majorminor for a
name.
Then version 3.10 is the same as 31.0.
Ok I know this will take a while.
But for the first 2.7.10 version even there some other library code
was broken because of such assumptions.


Aye, we're aware :)

We're not in a situation where we'll have any *good* options
available, so the question we're considering is "What do we think will
be the least bad approach?".

At our current release cadence, 3.7 will be in mid 2018, 3.8 in late
2019 or early 2020, and then 3.9 in mid 2021.

The open question will be what we call the release after that (in late
2022), with the main leading contenders being "4.0" (on the grounds
that so many changes will have accumulated since 2008's 3.0 release by
then that it makes sense to call them different major versions,
similar to the rationale the Linux kernel now uses for major version
updates), and "3.10" (on the grounds that the release won't be any
more different from 3.9 than 3.9 will be from 3.8). Other variants
(like making the major release number "40" or "2022", and using the
minor version field for some new purpose other than indicating
compatibility breaks in the compiler AST, interpreter opcode format,
code caching tags, and C ABI), tend to introduce the same pragmatic
questions that will already need to be considered in choosing between
the 3.10 and 4.0 alternatives.

It's not just the version numbering aesthetics that need to be
considered either - in addition to the point you raise around how the
Python version gets embedded in file path names (such that the 3-digit
form is technically ambiguous without a separator, and may break
parsers that are expecting exactly two digits), there are other
backwards compatibility concerns around how folks do version
compatibility checks based on sys.version and sys.version_info. Python
and CPython will be more than 3 decades old by 2022, and an ecosystem
can build up a *lot* of implicit assumptions regarding how a
platform's versioning scheme works in that kind of time frame :)

Personally, I doubt we'll make a firm decision on how we're going to
handle this until some time after 2.7 goes EOL in 2020, as by then
we'll necessarily have a better idea of how the various Linux distros
(including the LTS commercial ones) ended up handling the Python 2 ->
Python 3 switch, and the fact that the next release at that point will
be 3.9 making it eminently clear that we've run out of time to
continue postponing the question. We'll hopefully also have more
experience with folks relying on the stable runtime ABI, and hence
whether or not it might be beneficial to define new "py4" and "abi4"
compatibility tags for the binary wheel distribution format.


If there are 2 digits, it's major + minor.
We could decide that if there are 3 digits, it's major + double-digit 
minor (e.g. "310" is "3.10"), and we could switch to major.minor when we 
get to Python 4.0 (or Python 10?).

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

[Antoine Pitrou]

Le 05/11/2017 à 14:30, Paul Moore a écrit :
> On 5 November 2017 at 10:48, Antoine Pitrou  wrote:
>> On Sun, 5 Nov 2017 13:46:59 +1000
>> Nick Coghlan  wrote:
>>> * ensurepip gains the ability to also install bundled wheel files
>>
>> Why? Why wouldn't you put the wheel directly in site-packages on
>> install?
> 
> I'm not quite sure what you mean? It needs to be "installed", in the
> sense of being unpacked into site-packages, and the ensurepip
> mechanism is already able to do that for pip and setuptools, so adding
> an extra wheel to install wouldn't be too hard.

Ok, perhaps my question wasn't quite clear.  Are you suggesting that
people have to run "python -m ensurepip typing" after they installed
Python?  Or would the typing module be importable as soon as you have an
installed Python, like stdlib modules are?

Regards

Antoine.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Proposal to change Python version release cycle

[M.-A. Lemburg]

On 04.11.2017 20:33, Nick Timkovich wrote:
> On Sat, Nov 4, 2017 at 10:44 AM, M.-A. Lemburg  wrote:
> 
>> Just to clarify: Python 2.0 was called 2.0 because the BeOpen marketing
>> department thought it was good idea, not because there were major
>> incompatible changes going into that release.
>>
> 
> Alternative history question: if it was just 1.6, then would Python 3000,
> probably called "Python 2000/2.x" in that world, with all the fixes have
> happened sooner because you would have "ran out" (yes, v1.10 > v1.9) of
> numbers leading up to 2?

There was a Python 1.6, but this was cut during the Python 2.0
release cycle to make CNRI happy. It included everything
the CNRI team had developed after Python 1.5.2 before
moving on to BeOpen to form the "PythonLabs":

https://www.python.org/download/releases/1.6/

See "Overview of Changes Since 1.6" in
https://www.python.org/download/releases/2.0/
for a list of changes between 1.6 and 2.0.

The Python 1.6 never went into wide distribution, so for all
practical purposes the move was from Python 1.5.2 to
Python 2.0.

More on all this is available in the "What's New in Python 2.0"
document:

https://docs.python.org/3/whatsnew/2.0.html

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Nov 05 2017)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

[Nick Coghlan]

On 5 November 2017 at 23:30, Paul Moore  wrote:
> On 5 November 2017 at 10:48, Antoine Pitrou  wrote:
>> On Sun, 5 Nov 2017 13:46:59 +1000
>> Nick Coghlan  wrote:
>>> * ensurepip gains the ability to also install bundled wheel files
>>
>> Why? Why wouldn't you put the wheel directly in site-packages on
>> install?
>
> I'm not quite sure what you mean? It needs to be "installed", in the
> sense of being unpacked into site-packages, and the ensurepip
> mechanism is already able to do that for pip and setuptools, so adding
> an extra wheel to install wouldn't be too hard. If we don't install
> like that, people won't be able to easily upgrade typing by just using
> "pip install --upgrade typing".
>
> Wheels don't support simply being added to sys.path the way that eggs
> did, if that's what you mean.

What Paul said here. While wheels *can* be designed to support
use-without-extraction (and pip's own wheel file is constructed that
way so you can use a pip wheel to install itself), the general design
principle is that we expect them to be installed prior to use, such
that they get proper PEP 376 metadata entries, and so that their
subcomponents end up in the right sysconfig directories for the
deployment environment.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

[Paul Moore]

On 5 November 2017 at 10:48, Antoine Pitrou  wrote:
> On Sun, 5 Nov 2017 13:46:59 +1000
> Nick Coghlan  wrote:
>> * ensurepip gains the ability to also install bundled wheel files
>
> Why? Why wouldn't you put the wheel directly in site-packages on
> install?

I'm not quite sure what you mean? It needs to be "installed", in the
sense of being unpacked into site-packages, and the ensurepip
mechanism is already able to do that for pip and setuptools, so adding
an extra wheel to install wouldn't be too hard. If we don't install
like that, people won't be able to easily upgrade typing by just using
"pip install --upgrade typing".

Wheels don't support simply being added to sys.path the way that eggs
did, if that's what you mean.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

[Antoine Pitrou]

On Sun, 5 Nov 2017 13:46:59 +1000
Nick Coghlan  wrote:
> * ensurepip gains the ability to also install bundled wheel files

Why? Why wouldn't you put the wheel directly in site-packages on
install?

Regards

Antoine.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/