[Python-Dev] Re: Python for Windows (python-3.7.4.exe) location confusing

[Steve Dower]

On 09Sep2019 1950, Glenn Linderman wrote:

On 9/9/2019 2:48 AM, Steve Dower wrote:
User with administrative privileges are by implication better able to 
handle decisions such as this. If they are not, they should not be 
administrating a machine. 
Most home machines are administered by people that should not be 
"administrating" a machine.


Correct, and by defaulting to per-user installs we help them avoid 
having to do it.


I've trained the home "administrators" in my family to be skeptical of 
every UAC prompt they deal with, because they _shouldn't_ be 
administrators, as they're not prepared to make machine-wide decisions. 
It's worked out fine. (Unfortunately, Windows S and other ideas for 
further reducing their need to act as administrators have not taken off, 
probably because of the smugness of those who think that because *they* 
can handle full control of their machine, everyone else ought to be able 
to as well.)


Perhaps one day when the Store install overtakes the traditional 
installer in popularity, we can consider adapting the traditional 
installer to assume that the person using it is actually prepared to be 
an administrator. Until then, I'm going to assume the person installing 
Python is representative of our user base, which (on Windows) is *not* 
pre-existing experts.


If that means that pre-existing experts need to make an extra click or 
two, in my mind that's worth it to simplify the experience for those who 
are less experienced, and to avoid further ingraining poor decision 
making into our wide range of users.


Cheers,
Steve
___
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/ACJYH7AGQEV5VZPG644VWMNP53UI4ENZ/

[Python-Dev] Python library maintainers: PEP 602 needs your feedback

[Łukasz Langa]

Hey there, Python library maintainers!
Python is looking into increasing its release cadence. You can read the current 
proposal here: https://python.org/dev/peps/pep-0602/ 


More importantly, we need your input. Read the PEP and please let us know what 
you think via this form:
https://forms.gle/fA1FDhtna9sFnckk9 

Free-form discussion is happening here:
https://discuss.python.org/t/pep-602-annual-release-cycle-for-python/2296/ 


Thanks in advance,
Ł

Python 3.8 and 3.9 Release Manager


signature.asc
Description: Message signed with OpenPGP
___
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/WQ64ZGBECFDIRO6DS7JN3NALYDJGPAAE/

[Python-Dev] Re: python3 -bb and hash collisions

[Daniel Holth]

On Sat, Jun 22, 2019 at 2:48 AM Serhiy Storchaka 
wrote:

> 22.06.19 01:08, Daniel Holth пише:
> > Thanks. I think I might like an option to disable str(bytes) without
> > disabling str != bytes. Unless the second operation would also corrupt
> > output.
> >
> > Came across this kind of set in the hyper http library which uses a set
> > to accept certain headers with either str or bytes keys.
>
> Does that library support Python 2?  If it is true than you have a
> problem, because u'abc' == b'abc' in Python 2 and u'abc' != b'abc' in
> Python 3.
>
> If it is Python 3 only, you can just ignore BytesWarning. It was added
> purely to help to catch subtle bugs in transition to Python 3. In
> future, after Python 2 be out of use, BytesWarning will become deprecated.
>

I stopped using Python 3 after learning about str(bytes) by finding it in
my corrupted database. Ever since then I've been anxious about changing to
the new language, since it makes it so easy to convert from bytes to
unicode by accident without specifying a valid encoding. So I would like to
see a future where str(bytes) is effectively removed. I started working on
a pull request that adds an API to toggle str(bytes) at runtime with a
thread local (instead of requiring a command line argument), so you could
do with no_str_bytes(): if you were worried about the feature, but got a
bit stuck in the internals.
___
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/5HIHFIJODYSLFCEASM37K3V7XPAF56PK/

[Python-Dev] Re: The Python 2 death march

[Ned Batchelder]

Maybe I'm not involved enough in the release process, but this seems 
confusing to me.  On the same day that the PSF put up a page about the 
1/1/2020 date, we choose April 2020 as the last release?  Why?  I 
thought the point was to save core devs efforts.  Is this an unofficial 
grace period?  Will there be a public document that announces the April 
date?


What does the "official EOL date" mean if there's a release in April?

--Ned.

On 9/9/19 9:29 AM, Benjamin Peterson wrote:

Hi all,
It's finally time to schedule the last releases in Python 2's life. There will 
be two more releases of Python 2.7: Python 2.7.17 and Python 2.7.18.

Python 2.7.17 release candidate 1 will happen on October 5th followed by the 
final release on October 19th.

I'm going to time Python 2.7.18 to coincide with PyCon 2020 in April, so 
attendees can enjoy some collective catharsis. We'll still say January 1st is 
the official EOL date.

Thanks to Sumana Harihareswara, there's now a FAQ about the Python 2 sunset on 
the website: https://www.python.org/doc/sunset-python-2/

Regards,
Benjamin
___
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/APWHFYQDKNVYQAK3HZMBGQIZHAVRHCV2/

___
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/TVIMZGRZQXDAXKARJBUEZJJ7YSTNWMKA/

[Python-Dev] Re: The Python 2 death march

[Benjamin Peterson]

On Tue, Sep 10, 2019, at 15:54, Ned Batchelder wrote:
> Maybe I'm not involved enough in the release process, but this seems 
> confusing to me.  On the same day that the PSF put up a page about the 
> 1/1/2020 date, we choose April 2020 as the last release?  Why?  I 
> thought the point was to save core devs efforts.  Is this an unofficial 
> grace period?  Will there be a public document that announces the April 
> date?

This mail is a public document.

The thinking is that ±2 months is rounding error in Python 2's lifetime, so why 
not move it to a significant community time? (There was never going to be a 
release exactly on January 1 simply because it's an inconvenient time of the 
year for "work".) I suppose practically it amounts to a small grace period if 
core devs willing to merge 2.7 changes post 2020-01-01 can be found.
___
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/N6JIGTTJCJHS47AYSI76SJPCQS25EBWR/

[Python-Dev] Re: The Python 2 death march

[Guido van Rossum]

It probably means that from January to April Benjamin will be too busy
porting Dropbox to Python 3 to have time for Python 2 support.

Or possibly it means that until PyCon 2020, there will be only one core
developer supporting Python 2, and it will be Benjamin.

You choose. :-)


On Tue, Sep 10, 2019 at 4:00 PM Ned Batchelder 
wrote:

> Maybe I'm not involved enough in the release process, but this seems
> confusing to me.  On the same day that the PSF put up a page about the
> 1/1/2020 date, we choose April 2020 as the last release?  Why?  I
> thought the point was to save core devs efforts.  Is this an unofficial
> grace period?  Will there be a public document that announces the April
> date?
>
> What does the "official EOL date" mean if there's a release in April?
>
> --Ned.
>
> On 9/9/19 9:29 AM, Benjamin Peterson wrote:
> > Hi all,
> > It's finally time to schedule the last releases in Python 2's life.
> There will be two more releases of Python 2.7: Python 2.7.17 and Python
> 2.7.18.
> >
> > Python 2.7.17 release candidate 1 will happen on October 5th followed by
> the final release on October 19th.
> >
> > I'm going to time Python 2.7.18 to coincide with PyCon 2020 in April, so
> attendees can enjoy some collective catharsis. We'll still say January 1st
> is the official EOL date.
> >
> > Thanks to Sumana Harihareswara, there's now a FAQ about the Python 2
> sunset on the website: https://www.python.org/doc/sunset-python-2/
> >
> > Regards,
> > Benjamin
> > ___
> > 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/APWHFYQDKNVYQAK3HZMBGQIZHAVRHCV2/
> ___
> 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/TVIMZGRZQXDAXKARJBUEZJJ7YSTNWMKA/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*

___
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/7FVTDKLUXTDYOZDDE47V7ABSNXA5QKZ5/

[Python-Dev] Re: The Python 2 death march

[Terry Reedy]

On 9/10/2019 10:54 AM, Ned Batchelder wrote:


What does the "official EOL date" mean if there's a release in April?


To me, it means that coredevs freely patching 2.7 ends 1/1/2020 and that 
the final release will occur by PyCon and that everything between the 
two is at the discretion of Benjamin, the release manager.


I think that the first release candidate should be well before PyCon, 
maybe even in January, to make 2.7 EOL real and to allow time for a 
second or even a third, due to last minute pleas.  But that is up to 
Benjamin.


--
Terry Jan Reedy
___
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/EEQWV67ERFG6CYOBMM43JDT6ZZYJ43TK/

[Python-Dev] Re: The Python 2 death march

[Stefan Behnel]

Ned Batchelder schrieb am 10.09.19 um 16:54:
> this seems confusing to me
> What does the "official EOL date" mean if there's a release in April?

Also, what day in April? For example, planning the release for the 1st
could possibly add further to the confusion.

Stefan
___
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/ETQO7XXHRSAB43SXKO6FAMHI45OKV6HB/

[Python-Dev] Re: python3 -bb and hash collisions

[Chris Angelico]

On Wed, Sep 11, 2019 at 12:47 AM Daniel Holth  wrote:
>
> On Sat, Jun 22, 2019 at 2:48 AM Serhiy Storchaka  wrote:
>>
>> 22.06.19 01:08, Daniel Holth пише:
>> > Thanks. I think I might like an option to disable str(bytes) without
>> > disabling str != bytes. Unless the second operation would also corrupt
>> > output.
>> >
>> > Came across this kind of set in the hyper http library which uses a set
>> > to accept certain headers with either str or bytes keys.
>>
>> Does that library support Python 2?  If it is true than you have a
>> problem, because u'abc' == b'abc' in Python 2 and u'abc' != b'abc' in
>> Python 3.
>>
>> If it is Python 3 only, you can just ignore BytesWarning. It was added
>> purely to help to catch subtle bugs in transition to Python 3. In
>> future, after Python 2 be out of use, BytesWarning will become deprecated.
>
>
> I stopped using Python 3 after learning about str(bytes) by finding it in my 
> corrupted database. Ever since then I've been anxious about changing to the 
> new language, since it makes it so easy to convert from bytes to unicode by 
> accident without specifying a valid encoding. So I would like to see a future 
> where str(bytes) is effectively removed. I started working on a pull request 
> that adds an API to toggle str(bytes) at runtime with a thread local (instead 
> of requiring a command line argument), so you could do with no_str_bytes(): 
> if you were worried about the feature, but got a bit stuck in the internals.
>

Python has, for as long as I've known it, permitted you to call str()
on literally any object - if there's no other string form, you get its
repr. Breaking this would break all manner of debugging techniques.

ChrisA
___
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/74W36BRRQZ7JDAPP5X37NZVXENLORZPF/

[Python-Dev] Re: The Python 2 death march

[Ned Batchelder]

On 9/10/19 11:06 AM, Benjamin Peterson wrote:

On Tue, Sep 10, 2019, at 15:54, Ned Batchelder wrote:

Maybe I'm not involved enough in the release process, but this seems
confusing to me.  On the same day that the PSF put up a page about the
1/1/2020 date, we choose April 2020 as the last release?  Why?  I
thought the point was to save core devs efforts.  Is this an unofficial
grace period?  Will there be a public document that announces the April
date?

This mail is a public document.

The thinking is that ±2 months is rounding error in Python 2's lifetime, so why not move 
it to a significant community time? (There was never going to be a release exactly on 
January 1 simply because it's an inconvenient time of the year for "work".) I 
suppose practically it amounts to a small grace period if core devs willing to merge 2.7 
changes post 2020-01-01 can be found.



I'm not looking forward to answering questions from the public about why 
the PSF is writing dire and specific warnings like "We have decided that 
January 1, 2020, will be the day that we sunset Python 2," while the 
core devs are planning a release four months after that.  It won't help 
Python's credibility, and may convince some people that they don't have 
to take the date seriously..


--Ned.
___
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/ZTXTUW2WGSZSXP2LCQFUVHSBJYBZUHJQ/

[Python-Dev] Re: The Python 2 death march

[Chris Angelico]

On Wed, Sep 11, 2019 at 5:05 AM Ned Batchelder  wrote:
>
> On 9/10/19 11:06 AM, Benjamin Peterson wrote:
> > On Tue, Sep 10, 2019, at 15:54, Ned Batchelder wrote:
> >> Maybe I'm not involved enough in the release process, but this seems
> >> confusing to me.  On the same day that the PSF put up a page about the
> >> 1/1/2020 date, we choose April 2020 as the last release?  Why?  I
> >> thought the point was to save core devs efforts.  Is this an unofficial
> >> grace period?  Will there be a public document that announces the April
> >> date?
> > This mail is a public document.
> >
> > The thinking is that ±2 months is rounding error in Python 2's lifetime, so 
> > why not move it to a significant community time? (There was never going to 
> > be a release exactly on January 1 simply because it's an inconvenient time 
> > of the year for "work".) I suppose practically it amounts to a small grace 
> > period if core devs willing to merge 2.7 changes post 2020-01-01 can be 
> > found.
>
>
> I'm not looking forward to answering questions from the public about why
> the PSF is writing dire and specific warnings like "We have decided that
> January 1, 2020, will be the day that we sunset Python 2," while the
> core devs are planning a release four months after that.  It won't help
> Python's credibility, and may convince some people that they don't have
> to take the date seriously..
>

It always takes some time to go through the phases of a release. If
the final release happened on Jan 1st, there wouldn't be time to get
patches in during the tail of 2019. Python 2's sunset does indeed
happen as 2020 starts, but before night completely falls, there are
some final actions to be taken in order to produce one good, clean,
final release.

Plus the whole "let's align it with something else that's happening"
thing, but that doesn't sound half as grand :)

ChrisA
___
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/ISSSHTDBTCGBXY7YSMS3EZCT42CXL7A5/

[Python-Dev] Re: python3 -bb and hash collisions

[Ivan Pozdeev via Python-Dev]

On 10.09.2019 21:12, Chris Angelico wrote:

On Wed, Sep 11, 2019 at 12:47 AM Daniel Holth  wrote:

On Sat, Jun 22, 2019 at 2:48 AM Serhiy Storchaka  wrote:

22.06.19 01:08, Daniel Holth пише:

Thanks. I think I might like an option to disable str(bytes) without
disabling str != bytes. Unless the second operation would also corrupt
output.

Came across this kind of set in the hyper http library which uses a set
to accept certain headers with either str or bytes keys.

Does that library support Python 2?  If it is true than you have a
problem, because u'abc' == b'abc' in Python 2 and u'abc' != b'abc' in
Python 3.

If it is Python 3 only, you can just ignore BytesWarning. It was added
purely to help to catch subtle bugs in transition to Python 3. In
future, after Python 2 be out of use, BytesWarning will become deprecated.


I stopped using Python 3 after learning about str(bytes) by finding it in my 
corrupted database. Ever since then I've been anxious about changing to the new 
language, since it makes it so easy to convert from bytes to unicode by 
accident without specifying a valid encoding. So I would like to see a future 
where str(bytes) is effectively removed. I started working on a pull request 
that adds an API to toggle str(bytes) at runtime with a thread local (instead 
of requiring a command line argument), so you could do with no_str_bytes(): if 
you were worried about the feature, but got a bit stuck in the internals.


Python has, for as long as I've known it, permitted you to call str()
on literally any object - if there's no other string form, you get its
repr. Breaking this would break all manner of debugging techniques.

Isn't repr() the API intended for "all manner of debugging techniques"?

ChrisA
___
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/74W36BRRQZ7JDAPP5X37NZVXENLORZPF/


--
Regards,
Ivan
___
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/3W72OXGDFILI7OKAFE2L6O4LQALIJAEO/

[Python-Dev] Re: python3 -bb and hash collisions

[Chris Angelico]

On Wed, Sep 11, 2019 at 5:49 AM Ivan Pozdeev via Python-Dev
 wrote:
>
> On 10.09.2019 21:12, Chris Angelico wrote:
> > On Wed, Sep 11, 2019 at 12:47 AM Daniel Holth  wrote:
> >> On Sat, Jun 22, 2019 at 2:48 AM Serhiy Storchaka  
> >> wrote:
> >>> 22.06.19 01:08, Daniel Holth пише:
>  Thanks. I think I might like an option to disable str(bytes) without
>  disabling str != bytes. Unless the second operation would also corrupt
>  output.
> 
>  Came across this kind of set in the hyper http library which uses a set
>  to accept certain headers with either str or bytes keys.
> >>> Does that library support Python 2?  If it is true than you have a
> >>> problem, because u'abc' == b'abc' in Python 2 and u'abc' != b'abc' in
> >>> Python 3.
> >>>
> >>> If it is Python 3 only, you can just ignore BytesWarning. It was added
> >>> purely to help to catch subtle bugs in transition to Python 3. In
> >>> future, after Python 2 be out of use, BytesWarning will become deprecated.
> >>
> >> I stopped using Python 3 after learning about str(bytes) by finding it in 
> >> my corrupted database. Ever since then I've been anxious about changing to 
> >> the new language, since it makes it so easy to convert from bytes to 
> >> unicode by accident without specifying a valid encoding. So I would like 
> >> to see a future where str(bytes) is effectively removed. I started working 
> >> on a pull request that adds an API to toggle str(bytes) at runtime with a 
> >> thread local (instead of requiring a command line argument), so you could 
> >> do with no_str_bytes(): if you were worried about the feature, but got a 
> >> bit stuck in the internals.
> >>
> > Python has, for as long as I've known it, permitted you to call str()
> > on literally any object - if there's no other string form, you get its
> > repr. Breaking this would break all manner of debugging techniques.
> Isn't repr() the API intended for "all manner of debugging techniques"?

If you simply print(some_obj) it will use str by default, so you don't
want to break that.

ChrisA
___
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/EMDXVPYCYASCA66AKUB5ENEM453STIDE/

[Python-Dev] Re: python3 -bb and hash collisions

[Eric V. Smith]

On 9/10/2019 2:12 PM, Chris Angelico wrote:

On Wed, Sep 11, 2019 at 12:47 AM Daniel Holth  wrote:


On Sat, Jun 22, 2019 at 2:48 AM Serhiy Storchaka  wrote:


22.06.19 01:08, Daniel Holth пише:

Thanks. I think I might like an option to disable str(bytes) without
disabling str != bytes. Unless the second operation would also corrupt
output.

Came across this kind of set in the hyper http library which uses a set
to accept certain headers with either str or bytes keys.


Does that library support Python 2?  If it is true than you have a
problem, because u'abc' == b'abc' in Python 2 and u'abc' != b'abc' in
Python 3.

If it is Python 3 only, you can just ignore BytesWarning. It was added
purely to help to catch subtle bugs in transition to Python 3. In
future, after Python 2 be out of use, BytesWarning will become deprecated.



I stopped using Python 3 after learning about str(bytes) by finding it in my 
corrupted database. Ever since then I've been anxious about changing to the new 
language, since it makes it so easy to convert from bytes to unicode by 
accident without specifying a valid encoding. So I would like to see a future 
where str(bytes) is effectively removed. I started working on a pull request 
that adds an API to toggle str(bytes) at runtime with a thread local (instead 
of requiring a command line argument), so you could do with no_str_bytes(): if 
you were worried about the feature, but got a bit stuck in the internals.



Python has, for as long as I've known it, permitted you to call str()
on literally any object - if there's no other string form, you get its
repr. Breaking this would break all manner of debugging techniques.


Right. Think of print(bytes).

Eric
___
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/GZ47OO2TNB3MOJ72W2F2R3A7JNFGHL6N/

[Python-Dev] Re: The Python 2 death march

[Tal Einat]

On Tue, Sep 10, 2019 at 10:03 PM Ned Batchelder  wrote:
>
> I'm not looking forward to answering questions from the public about why
> the PSF is writing dire and specific warnings like "We have decided that
> January 1, 2020, will be the day that we sunset Python 2," while the
> core devs are planning a release four months after that.  It won't help
> Python's credibility, and may convince some people that they don't have
> to take the date seriously..

To me it seems pretty clear: On Jan 1st 2020, the 2.7.x branch will no
longer receive fixes for any *new* bugs or security issues, nor other
improvements. I would expect that be the time of the code freeze for
the first release candidate, not the time of the final release. While
we will still fix issues *introduced in 2.7.18 since 2.7.17* before
the final 2.7.18 release, we won't address any other bugs or security
issues and won't backport anything *new* from 3.x. (I may have some
details not exactly correct here, but I hope the gist is correct.)

I'm sure the wording could be improved, but generally this seems
entirely reasonable to me.

- Tal Einat
___
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/KSU2A5SDGDHCLPKA7BSW2PH5OIZVUOCB/

[Python-Dev] Python for Windows (python-3.7.4.exe) location confusing

[Jim J. Jewett]

Is it possible for the installer to check whether or not there is a
pre-existing system-wide launcher, and only do the complicated stuff
if it is actually there?

-jJ
___
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/2HWPDLQRWJGTOE6TNNEB4VCWO5SPB65X/

[Python-Dev] Re: The Python 2 death march

[Jacqueline Kazil]

*RE: Ned's comments -- *That is the same reaction I had when I read through
this thread.

*RE: Tal's comment - *I could see this making sense as an explanation.

*RE: Guido's comment*
This makes me think that April 2020 is not a thing. And if Ben is
supporting solo, then can people email him directly with issues? 😂😂😂

*On a serious note...*
I would like clarification, so we (dev community and PSF) have a shared
understanding of the direction and are sending the same messaging.

-Jackie
PSF Board of Directors

On Tue, Sep 10, 2019 at 4:20 PM Tal Einat  wrote:

> On Tue, Sep 10, 2019 at 10:03 PM Ned Batchelder 
> wrote:
> >
> > I'm not looking forward to answering questions from the public about why
> > the PSF is writing dire and specific warnings like "We have decided that
> > January 1, 2020, will be the day that we sunset Python 2," while the
> > core devs are planning a release four months after that.  It won't help
> > Python's credibility, and may convince some people that they don't have
> > to take the date seriously..
>
> To me it seems pretty clear: On Jan 1st 2020, the 2.7.x branch will no
> longer receive fixes for any *new* bugs or security issues, nor other
> improvements. I would expect that be the time of the code freeze for
> the first release candidate, not the time of the final release. While
> we will still fix issues *introduced in 2.7.18 since 2.7.17* before
> the final 2.7.18 release, we won't address any other bugs or security
> issues and won't backport anything *new* from 3.x. (I may have some
> details not exactly correct here, but I hope the gist is correct.)
>
> I'm sure the wording could be improved, but generally this seems
> entirely reasonable to me.
>
> - Tal Einat
> ___
> 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/KSU2A5SDGDHCLPKA7BSW2PH5OIZVUOCB/
>


-- 
Jacqueline Kazil | @jackiekazil
___
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/WOAYYHGIQG7W4DUXBJHBOXEE44C2THDV/

[Python-Dev] Re: The Python 2 death march

[Barry Warsaw]

I think it’s fine to say that Python 2 EOL is on January 1, 2020.  That doesn’t 
preclude a Contractual Obligation release in April.  There’s precedence in the 
last Python 1 (1.6.1) release!

https://en.wikipedia.org/wiki/Monty_Python%27s_Contractual_Obligation_Album

-Barry

> On Sep 10, 2019, at 14:09, Jacqueline Kazil  wrote:
> 
> RE: Ned's comments -- That is the same reaction I had when I read through 
> this thread.
> 
> RE: Tal's comment - I could see this making sense as an explanation.
> 
> RE: Guido's comment
> This makes me think that April 2020 is not a thing. And if Ben is supporting 
> solo, then can people email him directly with issues? 😂😂😂
> 
> On a serious note...
> I would like clarification, so we (dev community and PSF) have a shared 
> understanding of the direction and are sending the same messaging.
> 
> -Jackie
> PSF Board of Directors
> 
> On Tue, Sep 10, 2019 at 4:20 PM Tal Einat  wrote:
> On Tue, Sep 10, 2019 at 10:03 PM Ned Batchelder  
> wrote:
> >
> > I'm not looking forward to answering questions from the public about why
> > the PSF is writing dire and specific warnings like "We have decided that
> > January 1, 2020, will be the day that we sunset Python 2," while the
> > core devs are planning a release four months after that.  It won't help
> > Python's credibility, and may convince some people that they don't have
> > to take the date seriously..
> 
> To me it seems pretty clear: On Jan 1st 2020, the 2.7.x branch will no
> longer receive fixes for any *new* bugs or security issues, nor other
> improvements. I would expect that be the time of the code freeze for
> the first release candidate, not the time of the final release. While
> we will still fix issues *introduced in 2.7.18 since 2.7.17* before
> the final 2.7.18 release, we won't address any other bugs or security
> issues and won't backport anything *new* from 3.x. (I may have some
> details not exactly correct here, but I hope the gist is correct.)
> 
> I'm sure the wording could be improved, but generally this seems
> entirely reasonable to me.
> 
> - Tal Einat
> ___
> 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/KSU2A5SDGDHCLPKA7BSW2PH5OIZVUOCB/
> 
> 
> --
> Jacqueline Kazil | @jackiekazil
> 
> ___
> 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/WOAYYHGIQG7W4DUXBJHBOXEE44C2THDV/



signature.asc
Description: Message signed with OpenPGP
___
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/52YWO5YR47AAPGJM6WJ7MQMVHHQRQE7X/

[Python-Dev] Re: Python library maintainers: PEP 602 needs your feedback

[Miro Hrončok]

On 10. 09. 19 16:23, Łukasz Langa wrote:

Free-form discussion is happening here:
https://discuss.python.org/t/pep-602-annual-release-cycle-for-python/2296/


Does free-form mean it is meant for everybody? I'm not very familiar with 
Discourse, but ti seems only committer are allowed to discuss this topic. Was it 
intentional?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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/VYXE7IW7N2UZ4R5TOFLNDMF5MMCHHXM5/

[Python-Dev] Re: The Python 2 death march

[Eric V. Smith]

I think Ned's concerns are real, and the sunset-python-2 page could use 
some wordsmithing to explain that even though support ends on Jan 1, 
there will be a wrap-up release some time after that, but it won't 
incorporate any changes made or proposed after Jan 1.


Another place where that document could be improved is in clarifying the 
different uses of the word "volunteers". For me, that's the most 
confusing part as I was reading it. As near as I can tell, these are 
different groups, or at least largely disjoint:


 * "We are volunteers who make and take care of the Python programming
   language"
 * "most volunteers will not help fix them"
 * "If you need free help from volunteers"

Unfortunately I'm heading out of town and don't have time to help clean 
this up.


Eric

On 9/10/2019 5:09 PM, Jacqueline Kazil wrote:
*RE: Ned's comments -- *That is the same reaction I had when I read 
through this thread.


*RE: Tal's comment - *I could see this making sense as an explanation.

*RE: Guido's comment*
This makes me think that April 2020 is not a thing. And if Ben is 
supporting solo, then can people email him directly with issues? 😂😂😂


*On a serious note...*
I would like clarification, so we (dev community and PSF) have a 
shared understanding of the direction and are sending the same messaging.


-Jackie
PSF Board of Directors

On Tue, Sep 10, 2019 at 4:20 PM Tal Einat > wrote:


On Tue, Sep 10, 2019 at 10:03 PM Ned Batchelder
mailto:n...@nedbatchelder.com>> wrote:
>
> I'm not looking forward to answering questions from the public
about why
> the PSF is writing dire and specific warnings like "We have
decided that
> January 1, 2020, will be the day that we sunset Python 2," while the
> core devs are planning a release four months after that. It
won't help
> Python's credibility, and may convince some people that they
don't have
> to take the date seriously..

To me it seems pretty clear: On Jan 1st 2020, the 2.7.x branch will no
longer receive fixes for any *new* bugs or security issues, nor other
improvements. I would expect that be the time of the code freeze for
the first release candidate, not the time of the final release. While
we will still fix issues *introduced in 2.7.18 since 2.7.17* before
the final 2.7.18 release, we won't address any other bugs or security
issues and won't backport anything *new* from 3.x. (I may have some
details not exactly correct here, but I hope the gist is correct.)

I'm sure the wording could be improved, but generally this seems
entirely reasonable to me.

- Tal Einat
___
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/KSU2A5SDGDHCLPKA7BSW2PH5OIZVUOCB/



--
Jacqueline Kazil | @jackiekazil

___
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/WOAYYHGIQG7W4DUXBJHBOXEE44C2THDV/
___
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/JJWQYZZTTOWELRGSHYLG5FKKCIMRSI2K/

[Python-Dev] Re: python3 -bb and hash collisions

[Matt Billenstein]

On Tue, Sep 10, 2019 at 10:42:52AM -0400, Daniel Holth wrote:
> I stopped using Python 3 after learning about str(bytes) by finding it in my
> corrupted database. Ever since then I've been anxious about changing to the 
> new
> language, since it makes it so easy to convert from bytes to unicode by
> accident without specifying a valid encoding. So I would like to see a future
> where str(bytes) is effectively removed. I started working on a pull request
> that adds an API to toggle str(bytes) at runtime with a thread local (instead
> of requiring a command line argument), so you could do with no_str_bytes(): if
> you were worried about the feature, but got a bit stuck in the internals.

How is this different than all the str -> unicode bugs we had in python2?  If
you have special needs, you can always monkey-patch it in plain python code by
overriding __builtins__.str with something that asserts the given arg is not
bytes.

m

-- 
Matt Billenstein
m...@vazor.com
http://www.vazor.com/
___
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/J3MLBIRRUSHO7TSTZ54FFYQZBJBVJCMY/