Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

[Alex Walters]

I've watched the entire thread and its taken me a few days to put a finger
on what bothers me about it.

In my opinion, this shouldn't be a pep describing the list of modules that
need to go as "dead batteries", but should be a process pep describing how
dead batteries should be removed, and the individual modules should be given
their own pep.  I think reactions to individual module peps will give a
better indication of if it's a used module or not.

> -Original Message-
> From: Python-Dev  list=sdamon@python.org> On Behalf Of Christian Heimes
> Sent: Monday, May 20, 2019 4:15 PM
> To: Python Dev 
> Subject: [Python-Dev] PEP 594: Removing dead batteries from the standard
> library
> 
> Hi,
> 
> here is the first version of my PEP 594 to deprecate and eventually remove
> modules from the standard library. The PEP started last year with talk
during
> the Python Language Summit 2018, https://lwn.net/Articles/755229/.
> 
> The PEP can be confirmed in two stages. I'm not planning any code changes
> for 3.8. Instead I only like to document a bunch of modules as deprecated.
> Active deprecation is planned for 3.9 and removal for 3.10. The long
> deprecation phase gives us 3 years to change our minds or handle edge
> cases, too.
> 
> Regards,
> Christian
> 
> 
>

> PEP: 594
> Title: Removing dead batteries from the standard library
> Author: Christian Heimes 
> Status: Active
> Type: Process
> Content-Type: text/x-rst
> Created: 20-May-2019
> Post-History:
> 
> 
> Abstract
> 
> 
> This PEP proposed a list of standard library modules to be removed from
the
> standard library. The modules are mostly historic data formats and APIs
that
> have been superseded a long time ago, e.g. Mac OS 9 and Commodore.
> 
> 
> Rationale
> =
> 
> Back in the early days of Python, the interpreter came with a large set of
> useful modules. This was often refrained to as "batteries included"
> philosophy and was one of the corner stones to Python's success story.
> Users didn't have to figure out how to download and install separate
> packages in order to write a simple web server or parse email.
> 
> Times have changed. The introduction of the cheese shop (PyPI),
setuptools,
> and later pip, it became simple and straight forward to download and
install
> packages. Nowadays Python has a rich and vibrant ecosystem of third party
> packages. It's pretty much standard to either install packages from PyPI
or
> use one of the many Python or Linux distributions.
> 
> On the other hand, Python's standard library is piling up cruft,
unnecessary
> duplication of functionality, and dispensable features. This is
undesirable
> for several reasons.
> 
> * Any additional module increases the maintenance cost for the Python core
>   development team. The team has limited resources, reduced maintenance
> cost
>   frees development time for other improvements.
> * Modules in the standard library are generally favored and seen as the
>   de-facto solution for a problem. A majority of users only pick 3rd party
>   modules to replace a stdlib module, when they have a compelling reason,
> e.g.
>   lxml instead of `xml`. The removal of an unmaintained stdlib module
>   increases the chances of a community contributed module to become
> widely
>   used.
> * A lean and mean standard library benefits platforms with limited
resources
>   like devices with just a few hundred kilobyte of storage (e.g. BBC
>   Micro:bit). Python on mobile platforms like BeeWare or WebAssembly
>   (e.g. pyodide) also benefit from reduced download size.
> 
> The modules in the PEP have been selected for deprecation because their
> removal is either least controversial or most beneficial. For example
> least controversial are 30 years old multimedia formats like ``sunau``
> audio format, which was used on SPARC and NeXT workstations in the late
> 1980ties. The ``crypt`` module has fundamental flaws that are better
solved
> outside the standard library.
> 
> This PEP also designates some modules as not scheduled for removal. Some
> modules have been deprecated for several releases or seem unnecessary at
> first glance. However it is beneficial to keep the modules in the standard
> library, mostly for environments where installing a package from PyPI is
not
> an option. This can be cooperate environments or class rooms where
> external
> code is not permitted without legal approval.
> 
> * The usage of FTP is declining, but some files are still provided over
>   the FTP protocol or hosters offer FTP to upload content. Therefore
>   ``ftplib`` is going to stay.
> * The ``optparse`` and ``getopt`` module are widely used. They are mature
>   modules with very low maintenance overhead.
> * According to David Beazley [5]_ the ``wave`` module is easy to teach to
>   kids and can make crazy sounds. Making a computer generate crazy sounds
> is
>   powerful and highly motivating exercise for 

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

[Alex Walters]

I'm confused about this.  Didn't you need someone with merge permissions 
already to merge a pep into the pep repo?  Isn't this just adding a layer of 
paperwork to something that was already the case for all practical purposes?

> -Original Message-
> From: Python-Dev  list=sdamon@python.org> On Behalf Of Brett Cannon
> Sent: Monday, March 4, 2019 8:44 PM
> To: python-dev 
> Subject: [Python-Dev] PEPs from non-core devs now need a sponsor
> 
> The steering council has implemented a new idea called sponsors to the PEP
> process (added in
> https://github.com/python/peps/commit/c58d32c33bd06eb386d3f33963a14
> 34510528f68). The thinking is that to help make sure PEPs from non-core
> developers receive appropriate guidance through the PEP process, a core
> developer needs to sign on to be a sponsor of the PEP. Being a sponsor does
> not preclude the core dev from eventually becoming a co-author or BDFL-
> delegate later on (but obviously not both), but the expectation is the
> sponsor is supportive of the idea (because if a single core dev won't sign on
> to help then what chance does the PEP have of being accepted?).
> 
> 
> If this doesn't turn out well we can obviously revert this, but hopefully this
> will make things smoother for those who are new to the PEP process.


___
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] Get a running instance of the doc for a PR.

[Alex Walters]

Doesn't read the docs already do this for pull requests?  Even if it doesn't, 
don't the core maintainers of read the docs go to pycon?  I wouldn't suggest 
read the docs for primary docs hosting for python, but they are perfectly fine 
for live testing pull request documentation without having to roll our own.

> -Original Message-
> From: Python-Dev  list=sdamon@python.org> On Behalf Of Stephane Wirtel
> Sent: Sunday, November 4, 2018 8:38 AM
> To: python-dev@python.org
> Subject: [Python-Dev] Get a running instance of the doc for a PR.
> 
> Hi all,
> 
> When we receive a PR about the documentation, I think that could be
> interesting if we could have a running instance of the doc on a sub
> domain of python.org.
> 
> For example, pr-1-doc.python.org or whatever, but by this way the
> reviewers could see the result online.
> 
> The workflow would be like that:
> 
> New PR -> build the doc (done by Travis) -> publish it to a server ->
> once published, the PR is notified by "doc is available at URL".
> 
> Once merged -> we remove the doc and the link (hello bedevere).
> 
> I am interested by this feature and if you also interested, tell me.
> I would like discuss with Julien Palard and Ernest W.  Durbin III for a
> solution as soon as possible.
> 
> Have a nice day,
> 
> Stéphane
> 
> --
> Stéphane Wirtel - https://wirtel.be - @matrixise
> ___
> 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/tritium-
> list%40sdamon.com

___
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] Change in Python 3's "round" behavior

[Alex Walters]

> -Original Message-
> From: Python-Dev  list=sdamon@python.org> On Behalf Of Greg Ewing
> Sent: Saturday, September 29, 2018 9:50 PM
> To: python-dev@python.org
> Subject: Re: [Python-Dev] Change in Python 3's "round" behavior
> 
> I don't really get the statistical argument. If you're doing something
> like calculating an average and care about accuracy, why are you rounding
> the values before averaging? Why not average first and then round the
> result if you need to?
> 

Other use case is finance, where you can end up with interest calculations
that are fractional of the base unit of currency.  US$2.345 is impossible to
represent in real currency, so it has to be rounded.  With
half-towards-even, that rounds to $2.34, and $2.355 rounds to $2.36.  It
evens out in the long run.  While that is very helpful for finance
calculations, if you are doing finance with that level of precision, you
should be using decimal instead of float anyways and decimal's round has
configurable round method.

> --
> Greg
> 
> ___
> 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/tritium-
> list%40sdamon.com

___
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] Change in Python 3's "round" behavior

[Alex Walters]

> -Original Message-
> From: Python-Dev  list=sdamon@python.org> On Behalf Of Steven D'Aprano
> Sent: Thursday, September 27, 2018 9:54 AM
> To: python-dev@python.org
> Subject: Re: [Python-Dev] Change in Python 3's "round" behavior
> 
> On Thu, Sep 27, 2018 at 05:55:07PM +1200, Greg Ewing wrote:
> > j...@math.brown.edu wrote:
> > >I understand from
> > >https://github.com/cosmologicon/pywat/pull/40#discussion_r219962259
> > >that "to always round up... can theoretically skew the data"
> >
> > *Very* theoretically. If the number is even a whisker bigger than
> > 2.5 it's going to get rounded up regardless:
> >
> > >>> round(2.501)
> > 3
> >
> > That difference is on the order of the error you expect from
> > representing decimal fractions in binary, so I would be surprised
> > if anyone can actually measure this bias in a real application.
> 
> I think you may have misunderstood the nature of the bias. It's not
> about individual roundings and it definitely has nothing to do with
> binary representation.
> 
> Any one round operation will introduce a bias. You had a number, say
> 2.3, and it gets rounded down to 2.0, introducing an error of -0.3. But
> if you have lots of rounds, some will round up, and some will round
> down, and we want the rounding errors to cancel.
> 
> The errors *almost* cancel using the naive rounding algorithm as most of
> the digits pair up:
> 
> .1 rounds down, error = -0.1
> .9 rounds up, error = +0.1
> 
> .2 rounds down, error = -0.2
> .8 rounds up, error = +0.2
> 
> etc. If each digit is equally likely, then on average they'll cancel and
> we're left with *almost* no overall error.
> 
> The problem is that while there are four digits rounding down (.1
> through .4) there are FIVE which round up (.5 through .9). Two digits
> don't pair up:
> 
> .0 stays unchanged, error = 0
> .5 always rounds up, error = +0.5
> 
> Given that for many purposes, our data is recorded only to a fixed
> number of decimal places, we're dealing with numbers like 0.5 rather
> than 0.51, so this can become a real issue. Every ten rounding
> operations will introduce an average error of +0.05 instead of
> cancelling out. Rounding introduces a small but real bias.
> 
> The most common (and, in many experts' opinion, the best default
> behaviour) is Banker's Rounding, or round-to-even. All the other digits
> round as per the usual rule, but .5 rounds UP half the time and DOWN the
> rest of the time:
> 
> 0.5, 2.5, 3.5 etc round down, error = -0.5
> 1.5, 3.5, 5.5 etc round up, error = +0.5
> 
> thus on average the .5 digit introduces no error and the bias goes away.
> 
> 

...and we have a stats module that would be a great place for a round
function that needs to cancel rounding errors.  The simple case should be
the intuitive case for most users.  My experience and that of many users of
the python irc channel on freenode is that round-half-to-even is not the
intuitive, or even desired, behavior - round-half-up is.  This wouldn't be
frustrating to the human user if the round built-in let you pick the method,
instead you have to use the very complicated decimal module with a modified
context to get intuitive behavior.

I could live with `round(2.5) -> 2.0` if `round(2.5, method='up') -> 3.0`
(or some similar spelling) was an option.  As it stands, this is a wart on
the language.  "Statistically balanced rounding" is a special case, not the
default case.

> 
> --
> Steve
> ___
> 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/tritium-
> list%40sdamon.com

___
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] Can I make marshal.dumps() slower but stabler?

[Alex Walters]

> -Original Message-
> From: Python-Dev  list=sdamon@python.org> On Behalf Of Victor Stinner
> Sent: Thursday, July 12, 2018 4:01 AM
> To: Serhiy Storchaka 
> Cc: python-dev 
> Subject: Re: [Python-Dev] Can I make marshal.dumps() slower but stabler?
> 
> 2018-07-12 8:21 GMT+02:00 Serhiy Storchaka :
> >> Is there any real application which marshal.dumps() performance is
> >> critical?
> >
> > EVE Online is a well known example.
> 
> EVE Online has been created in 2003. I guess that it still uses Python
2.7.
> 
> I'm not sure that a video game would pick marshal in 2018.
> 

EVE doesn't use stock CPython, IIRC.  They use a version of stackless 2,
with their own patches.  If a company is willing to patch python itself, I
don't think their practices should be cited without more context about what
they actually modified.

> Victor
> ___
> 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/tritium-
> list%40sdamon.com

___
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] why is not 64-bit installer the default download link for Windows?

[Alex Walters]

> -Original Message-
> From: Python-Dev  list=sdamon@python.org> On Behalf Of Paul Moore
 
> Why not just have a second button, "Download Python 3.7.0 (64-bit)"
> alongside or below the "Download Python 3.7.0" button? People who
> don't know the difference will just ignore it, people who do will be
> able to choose straight from the main download page.
> 

I think this is the solution.

* If you don't know your architecture, 32-bit will mostly work so should
remain the default (I say most, not all, since there are windows versions
that run on ARM, but I think you can only install software through the store
on those anyways.)

* It's not exposed in the download drop down at all that x64 editions exist
for those who know they want it.  The drop down is wide enough to support a
second download button.

> Paul
> ___
> 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/tritium-
> list%40sdamon.com

___
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] Microsoft to acquire GitHub for $7.5 b

[Alex Walters]

> -Original Message-
> From: Python-Dev  list=sdamon@python.org> On Behalf Of Ivan Pozdeev via Python-Dev
> Sent: Tuesday, June 5, 2018 10:01 PM
> To: python-dev@python.org
> Subject: Re: [Python-Dev] Microsoft to acquire GitHub for $7.5 b
> 
> On 05.06.2018 17:28, Martin Gainty wrote:
> who owns the Data hosted on Github?
> 
> Github Author?
> Microsoft?
> 
> Martin
> https://help.github.com/articles/github-terms-of-service/#d-user-
> generated-content :
> 
> "You own content you create, but you allow us certain rights to it, so
that we
> can display and share the content you post. You still have control over
your
> content, and responsibility for it, and the rights you grant us are
limited to
> those we need to provide the service. We have the right to remove content
> or close Accounts if we need to."
> 
> 
And this is not likely to change under Microsoft.  CodePlex had similar
language, as does BitBucket, GitLab, and pretty much any service that hosts
creative content that isn’t a social network (and even then, some of them do
too.)

> 
> 
> From: Python-Dev  bounces+mgainty=hotmail@python.org> on behalf of
> M.-A. Lemburg 
> Sent: Tuesday, June 5, 2018 7:54 AM
> To: Antoine Pitrou; python-dev@python.org
> Subject: Re: [Python-Dev] Microsoft to acquire GitHub for
> $7.5 billion
> 
> Something that may change is the way they treat Github
> accounts, after all, MS is very much a sales driven company.
> 
> But then there's always the possibility to move to Gitlab
> as alternative (hosted or run on PSF VMs), so I would
> worry too much.
> 
> Do note, however, that the value in Github is not so much
> with
> the products they have, but with the data. Their databases
> know more about IT developer than anyone else and given
> that Github is put under the AI umbrella in MS should tell
> us something :-)
> 
> 
> On 04.06.2018 19:02, Antoine Pitrou wrote:
> >
> > That's true, but Microsoft has a lot of stakes in the
> ecosystem.
> > For example, since it has its own CI service that it tries to
> promote
> > (VSTS), is it in Microsoft's best interest to polish and
> improve
> > integrations with other CI services?
> >
> > Regards
> >
> > Antoine.
> >
> >
> > On Mon, 4 Jun 2018 09:06:28 -0700
> > Guido van Rossum  wrote:
> >> On Mon, Jun 4, 2018 at 8:40 AM, Antoine Pitrou
>  wrote:
> >>
> >>>
> >>> On Mon, 4 Jun 2018 17:03:27 +0200
> >>> Victor Stinner  wrote:
> 
>  At this point, I have no opinion about the event :-) I just
> guess that
>  it should make GitHub more sustainable since Microsoft
> is a big
>  company with money and interest in GitHub. I'm also
> confident that
>  nothing will change soon. IMHO there is no need to
> worry about
>  anything.
> >>>
> >>> It does spell uncertainty on the long term.  While there is
> no need to
> >>> worry for now, I think it gives a different colour to the
> debate about
> >>> moving issues to Github.
> >>>
> >>
> >> I don't see how this *increases* the uncertainty. Surely if
> GitHub had
> >> remained independent there would have been be similar
> concerns about how it
> >> would make enough money to stay in business.
> >>
> >
> >
> __
> _
> > Python-Dev mailing list
> > Python-Dev@python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> Python-
> Dev Info
> Page
> mail.pyth
> on.org
> Do not
> post
> general
> Python
> questions
> to this list.
> For help
> with
> Python
> please
> see the
> Python
> help
> page.. On
> this list
> the key
> Python
> developer
> s discuss
> the future
> of the
> language
> and its
> implemen
> tation.
> 
> 
> 
> > Unsubscribe:
> https://mail.python.org/mailman/options/python-
> dev/mal%40egenix.com
> >
> 
> --
> Marc-Andre Lemburg
> eGenix.com
> 
> Professional Python Services directly from the Experts (#1,
> Jun 05 2018)
> >>> 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-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-
> dev/mgainty%40hotmail.com
> 
> 
> 
> __
> _
> Python-Dev mailing list
> Python-Dev@python.org
> 

Re: [Python-Dev] What is the rationale behind source only releases?

[Alex Walters]

> -Original Message-
> From: Paul Moore <p.f.mo...@gmail.com>
> Sent: Wednesday, May 16, 2018 4:07 AM
> To: Alex Walters <tritium-l...@sdamon.com>
> Cc: Python Dev <python-dev@python.org>
> Subject: Re: [Python-Dev] What is the rationale behind source only releases?
> 
> On 16 May 2018 at 05:35, Alex Walters <tritium-l...@sdamon.com> wrote:
> > In the spirit of learning why there is a fence across the road before I tear
> > it down out of ignorance [1], I'd like to know the rationale behind source
> > only releases of cpython.  I have an opinion on their utility and perhaps an
> > idea about changing them, but I'd like to know why they are done (as
> opposed
> > to source+binary releases or no release at all) before I head over to
> > python-ideas.  Is this documented somewhere where my google-fu can't
> find
> > it?
> >
> >
> > [1]: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
> 
> Assuming you're referring to the practice of no longer distributing
> binaries for patch releases of older versions of Python, the reason is
> basically as follows:
> 
> 1. Producing binaries (to the quality we normally deliver - I'm not
> talking about auto-built binaries produced from a CI system) is a
> chunk of extra work for the release managers.

This is actually the heart of the reason I asked the question.  CI tools are 
fairly good now.  If the CI tools could be used in such a way to make the 
building of binary artifacts less of a burden on the release managers, would 
there be interest in doing that, and in the process, releasing binary artifact 
installers for all security update releases.

My rationale for asking if its possible is... well.. security releases are 
important, and it's hard to ask Windows users to install Visual Studio and 
build python to use the most secure version of python that will run your python 
program.  Yes there are better ideal solutions (porting your code to the latest 
and greatest feature release version), but that’s not a zero burden option 
either.

If CI tools just aren't up to the task, then so be it, and this isn't something 
I would darken -ideas' door with.

> 2. The releases in question are essentially end of life, and we're
> only accepting security fixes.
> 3. Not even releasing sources means that people still using those
> releases will no longer have access to security fixes, so we'd be
> reducing the length of time we offer that level of support.
> 
> So extra binaries = more work for the release managers, no source
> release = less support for our users.
> 
> There's no reason we couldn't have a discussion on changing the
> policy, but any such discussion would probably need active support
> from the release managers if it were to stand any chance of going
> anywhere (as they are the people directly impacted by any such
> change).
> 
> Paul

___
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] What is the rationale behind source only releases?

[Alex Walters]

This is precisely what I meant.  Before asking this question, I didn’t fully 
understand why, for example, 3.5.4 got a binary installer for windows and mac, 
but 3.5.5 did not.  This thread has cleared that up for me.

 

From: Python-Dev  On 
Behalf Of Donald Stufft
Sent: Wednesday, May 16, 2018 1:23 AM
To: Ben Finney 
Cc: python-dev@python.org
Subject: Re: [Python-Dev] What is the rationale behind source only releases?

 

 

On May 16, 2018, at 1:06 AM, Ben Finney  > wrote:

 


I'd like to know the rationale behind source only releases of cpython.


Software freedom entails the freedom to modify and build the software.
For that, one needs the source form of the software.

Portable software should be feasible to build from source, on a platform
where no builds (of that particular release) were done before. For that,
one needs the source form of the software.

 

I’m guessing the question isn’t why is it useful to have a source release of 
CPython, but why does CPython transition from having both source releases and 
binary releases to only source releases. My assumption is the rationale is to 
reduce the maintenance burden as time goes on for older release channels.

___
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] What is the rationale behind source only releases?

[Alex Walters]

Thank you, that's exactly what I needed to read.

> -Original Message-
> From: Ned Deily <n...@python.org>
> Sent: Wednesday, May 16, 2018 7:07 AM
> To: Alex Walters <tritium-l...@sdamon.com>
> Cc: Python-Dev <python-dev@python.org>
> Subject: Re: [Python-Dev] What is the rationale behind source only
releases?
> 
> On May 16, 2018, at 00:35, Alex Walters <tritium-l...@sdamon.com> wrote:
> > In the spirit of learning why there is a fence across the road before I
tear
> > it down out of ignorance [1], I'd like to know the rationale behind
source
> > only releases of cpython.  I have an opinion on their utility and
perhaps an
> > idea about changing them, but I'd like to know why they are done (as
> opposed
> > to source+binary releases or no release at all) before I head over to
> > python-ideas.  Is this documented somewhere where my google-fu can't
> find
> > it?
> 
> The Python Developer's Guide has a discussion of the lifecycle of cPython
> releases here:
> 
> https://devguide.python.org/#status-of-python-branches
> 
> The ~short answer is that we produce source+binary (Windows and macOS
> binary installers) artifacts for release branches in "bugfix" (AKA
> "maintenance") mode (currently 3.6 and 2.7) as well as during the later
> stages of the in-development phase for future feature releases
> ("prerelease" mode) (currently 3.7); we produce only source releases for
> release branches in "security" mode.
> 
> After the initial release of a new feature branch (for example, the
upcoming
> 3.7.0 release), we will continue to support the previous release branch in
> bugfix mode for some overlapping period of time.  So, for example, the
> current plan is to support both 3.7.x and 3.6.x (along with 2.7.x) in
bugfix
> mode, releasing both source and binary artifacts for about six months
after
> the 3.7.0 release.  At that point, 3.6.x will transition to
security-fix-only mode,
> where we will only produce releases on an as-needed basis and only in
> source form.  Currently, 3.5 and 3.4 are also in security-fix-only mode.
> Eventually, usually five years after its initial release, a release branch
will
> reach end-of-life: the branch will be frozen and no further issues for
that
> release branch will be accepted nor will fixes be produced by Python Dev.
> 2.7 is a special case, with a greatly extended bugfix phase; it will
proceed
> directly to end-of-life status as of 2020-01-01.
> 
> There is more information later elsewhere in the devguide:
> 
> https://devguide.python.org/devcycle/
> 
> and in the release PEPs linked in the Status of Python Branches section.
> 
> Hope that helps!
> 
> --
>   Ned Deily
>   n...@python.org -- []


___
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] What is the rationale behind source only releases?

[Alex Walters]

In the spirit of learning why there is a fence across the road before I tear
it down out of ignorance [1], I'd like to know the rationale behind source
only releases of cpython.  I have an opinion on their utility and perhaps an
idea about changing them, but I'd like to know why they are done (as opposed
to source+binary releases or no release at all) before I head over to
python-ideas.  Is this documented somewhere where my google-fu can't find
it?


[1]: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

___
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] [RELEASE] Python 2.7.15

[Alex Walters]

I've gotten some mixed signals on the status of this release, notably from
the BDFL:

https://twitter.com/gvanrossum/status/991170064417153025
"Python 2.7.15 released -- the last 2.7 release!" (and a link to this
thread)

I was under the impression that 2.7 was being supported until 2020.  If this
is the final release of 2.7, what would "support" constitute?  My assumption
was that the final release of 2.7 would be sometime in 2020 (or much closer
to 2020 than 19 months).

> -Original Message-
> From: Python-Dev  list=sdamon@python.org> On Behalf Of Benjamin Peterson
> Sent: Tuesday, May 1, 2018 12:10 AM
> To: python-l...@python.org; python-annou...@python.org; python-
> d...@python.org
> Subject: [Python-Dev] [RELEASE] Python 2.7.15
> 
> Greetings,
> I'm pleased to announce the immediate availability of Python 2.7.15, the
> latest bug fix release in the senescent Python 2.7 series.
> 
> Source and binary downloads may be found on python.org:
> 
>  https://www.python.org/downloads/release/python-2715/
> 
> Bugs should be reported to https://bugs.python.org/
> 
> The source tarball contains a complete changelog in the Misc/NEWS file.
The
> only change since the release candidate is a fix for undefined C behavior
that
> newer compilers (including GCC 8) have started to exploit.
> 
> Users of the macOS binaries should note that all python.org macOS
installers
> now ship with a builtin copy of OpenSSL. Additionally, there is a new
> additional installer variant for macOS 10.9+ that includes a built-in
version of
> Tcl/Tk 8.6. See the installer README for more information.
> 
> Happy May,
> Benjamin
> 2.7 release manager
> ___
> 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/tritium-
> list%40sdamon.com

___
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 572 contradicts PEP 3099

[Alex Walters]

> -Original Message-
> From: Python-Dev <python-dev-bounces+tritium-
> list=sdamon@python.org> On Behalf Of Greg Ewing
> Sent: Saturday, April 28, 2018 10:53 PM
> To: 'Python-Dev' <python-dev@python.org>
> Subject: Re: [Python-Dev] PEP 572 contradicts PEP 3099
> 
> Alex Walters wrote:
> > PEP 3099 is the big list of things that will not happen in Python 3.
> >
> > "There will be no alternative binding operators such as :=."
> 
> The thread referenced by that is taling about a different issue,
> i.e. using a different symbol to rebind names in an outer scope.
> 

Yeah, that's not really the issue, if there is an issue - just the wording
of direct assertion.  I'm just adding to the list of things that need to be
touched if 572 is accepted, and that includes clarifying what was meant by
that.

> --
> Greg
> ___
> 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/tritium-
> list%40sdamon.com

___
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] PEP 572 contradicts PEP 3099

[Alex Walters]

PEP 3099 is the big list of things that will not happen in Python 3.
Everything on that list is still true, 12 years after it was posted.
However...

"There will be no alternative binding operators such as :=."

While earlier versions of PEP 572 avoided breaking this declaration, the
current version does not.  Now, this isn't a major issue or anything - if
572 is accepted, that section of 3099 would just need a note added (or just
be removed).  I don't want this message to impact the fate of 572.

___
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] (Looking for) A Retrospective on the Move to Python 3

[Alex Walters]

http://pyvideo.org/pycascades-2018/bdfl-python-3-retrospective.html link to 
Guido’s talk, for your convenience

 

From: Python-Dev  On 
Behalf Of Guido van Rossum
Sent: Thursday, April 26, 2018 6:12 PM
To: Brett Cannon 
Cc: Barry Warsaw ; Python-Dev 
Subject: Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

 

Also see my talk at PyCascades and Victor's upcoming talk at PyCon.

 

On Thu, Apr 26, 2018, 12:02 Brett Cannon  > wrote:

 

On Thu, 26 Apr 2018 at 10:19 Barry Warsaw  > wrote:

On Apr 26, 2018, at 09:28, Eric Snow  > wrote:
> 
> On Thu, Apr 26, 2018 at 10:25 AM, Eric Snow   > wrote:
>> In pondering our approach to future Python major releases, I found
>> myself considering the experience we've had with Python 3.  The whole
>> Py3k effort predates my involvement in the community so I missed a
>> bunch of context about the motivations, decisions, and challenges.
>> While I've pieced some of that together over the years now since I've
>> been around, I've certainly seen much of the aftermath.  For me, at
>> least, it would be helpful to have a bit more insight into the
>> history. :)

It would certainly be an interesting document, but I suspect you’ll get a bit 
of the old “ask 3 lawyers and get 5 opinions” kind of response. ;)

As I remember it, there was definitely a feeling like, this would be our only 
chance to clean up some annoying cruft, and rectify some (in hindsight) 
incorrect design decisions made over the years, couple with a healthy dose of 
“we have no idea how to do the bytes/str split in a backward compatible way".  
There was probably a sense that the Python community was just small enough to 
be able to handle such a disruptive change, but wouldn’t ever be so again.  The 
latter is definitely true today, even if the former was overly optimistic.

 

I agree with everything Barry said. There are some lessons in hindsight of how 
we could have handled bytes/str, but it was more of a decision of "really long 
transition versus a short one" -- jokes on us for what "short" became ;) -- 
which we simply won't make ever again.

___
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/guido%40python.org

___
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] Is it useful to update cgitb module?

[Alex Walters]

Extremely useful … for CGI scripts.  Now, my sample size is quite small – 
mainly the #python irc channel on freenode, but I have been informally asking 
for a few years, and you are the first person I have encountered who admitted 
to writing and maintaining new CGI based sites.  I still say the value of 
supporting such an obsolete model is… questionable.

 

That said, I have no power to block commits.

 

From: Python-Dev <python-dev-bounces+tritium-list=sdamon@python.org> On 
Behalf Of Glenn Linderman
Sent: Sunday, April 8, 2018 2:28 AM
To: python-dev@python.org
Subject: Re: [Python-Dev] Is it useful to update cgitb module?

 

On 4/7/2018 9:45 PM, Alex Walters wrote:

Are there people still actively developing new cgi scripts in python?  I know 
some modern HTTPDs don’t even support classic cgi without some kind of fastcgi 
daemon in between.  I am aware that some parts of various wsgi tools use the 
cgi module, but is the cgitb module useful for them?


Yes. I have several web sites and applications built as Python CGI scripts.  
cgitb is extremely useful.

___
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] Is it useful to update cgitb module?

[Alex Walters]

Are there people still actively developing new cgi scripts in python?  I know 
some modern HTTPDs don’t even support classic cgi without some kind of fastcgi 
daemon in between.  I am aware that some parts of various wsgi tools use the 
cgi module, but is the cgitb module useful for them?

Your suggestions might be good ideas, but I don’t know if they would be used.  
I feel like its kind of like updating the macpath module - sure you can make 
code improvements to it if you want, but its for a workflow that is very rarely 
used.

> -Original Message-
> From: Python-Dev  list=sdamon@python.org> On Behalf Of Stéphane Blondon
> Sent: Saturday, April 7, 2018 4:21 PM
> To: python-dev@python.org
> Subject: [Python-Dev] Is it useful to update cgitb module?
> 
> Hello,
> 
> I wonder if it's useful to update the cgitb module, in particular the
> html output.
> I see some possible improvements:
> 
> 1. In both text and html versions:
> 
> When a module is called, there are no parameters (displayed as '()'). I
> think they are unnecessary. Perhaps the parentheses should be removed?
> Perhaps it's better to keep them for backward compatibility?
> 
> ### example for the text version ###
> $ python3 demo.py
> [...]
>  /home/stephane/src/cgitest/demo.py in ()
> 7 def func1(a, b):
> [...]
> ### end of example ###
> 
> 2. In html version only:
>  a. If the executed code is in : in this case, it is not shown
> in the html version because the square brackets are interpreted as a
> html tag (see the picture in attachement).
>  b. Update the style of the html or/and using html5. It would be
> prettier but it will be a big change for probably too few benefits.
> 
> What do you think about them? I can report bugs and send pull-requests
> for them but I would prefer to get feedbacks before.
> 
> Regards,
> Stéphane

___
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] Is 4.0 a major breaking changes release?

[Alex Walters]

I am still working on porting code from 2.x to 3.x.  As of late on the lists
I've seen comments about making somewhat major changes in 4.0 - now I'm
concerned that I should pause my porting effort until that is released.  Is
python 4 going to be another python 3?

___
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] A minimal Python interpreter written in Python for experimenting with language changes

[Alex Walters]

Are you aware of pypy?

> -Original Message-
> From: Python-Dev [mailto:python-dev-bounces+tritium-
> list=sdamon@python.org] On Behalf Of asrp asrp
> Sent: Friday, February 2, 2018 7:02 PM
> To: python-dev@python.org
> Subject: [Python-Dev] A minimal Python interpreter written in Python for
> experimenting with language changes
> 
> Hello,
> 
> I don't know if this is the right place to post this. Please redirect as
needed.
> 
> I've made a small Python interpreter in Python with runtime AST node
> semantics and edit-and-continue. I thought it could make prototyping
> language changes more easily and visualize usage before writing them in C.
> 
> Its here: https://github.com/asrp/python_terp
> 
> So, for example, redefining the for_stmt function in the right scope
changes
> the behaviour of future for loops at runtime.
> 
> Although from discussion I've read in PEPs, actual implementation always
> look like a non-issue (which seems like magic to me) so maybe no-one here
> actually needs this.
> 
> (I really needed edit-and-continue for one of my projects but of course,
> running it in this extra interpreter is much too slow.)
> 
> asrp
> ___
> 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/tritium-
> list%40sdamon.com

___
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] Deprecate PEP 370 Per user site-packages directory?

[Alex Walters]

I would suggest throwing this to -ideas, rather than just keeping it in -dev
as there is a much wider community of users and usecases in -ideas.

... and -ideas will shoot it down because user installs are too useful.  It
is also my understanding that it is the desire of PyPA to eventually have
pip default to --user when run outside of a virtualenv (to mitigate people
running sudo pip).  Eliminating user installs would change the situation
from one where, with pip install --user, one can recoverably break their
system to one, with sudo pip install, one can un-recoverably break their
system.

> -Original Message-
> From: Python-Dev [mailto:python-dev-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Christian Heimes
> Sent: Saturday, January 13, 2018 12:06 PM
> To: python-dev@python.org
> Subject: [Python-Dev] Deprecate PEP 370 Per user site-packages directory?
> 
> Hi,
> 
> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
> virtual environment support in Python. Ian Bicking had just started to
> create the virtualenv project a couple of months earlier.
> 
> Fast forward 10 years...
> 
> Nowadays Python has venv in the standard library. The user-specific
> site-packages directory is no longer that useful. I would even say it's
> causing more trouble than it's worth. For example it's common for system
> script to use "#!/usr/bin/python3" shebang without -s or -I option.
> 
> I propose to deprecate the feature and remove it in Python 4.0.
> 
> Regards,
> Christian
> 
> [1] https://www.python.org/dev/peps/pep-0370/
> 
> ___
> 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/tritium-
> list%40sdamon.com

___
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] iso8601 parsing

[Alex Walters]

 

 

From: Python-Dev [mailto:python-dev-bounces+tritium-list=sdamon@python.org] 
On Behalf Of Chris Barker
Sent: Thursday, October 26, 2017 12:46 PM
To: Wes Turner 
Cc: Python-Dev 
Subject: Re: [Python-Dev] iso8601 parsing

 

> No, it doesn't -- it may call them "timezones", but it only supports offsets 
> -- that is, and offset of -6 could be US Eastern Standard Time or US Central 
> Daylight TIme (or I got that backwards :-)  )

 

US Central Standard, Mountain Daylight.  (Eastern is -5/-4DST)

___
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] iso8601 parsing

[Alex Walters]

> -Original Message-
> From: Alexander Belopolsky [mailto:alexander.belopol...@gmail.com]
> Sent: Wednesday, October 25, 2017 4:33 PM
> To: Alex Walters <tritium-l...@sdamon.com>
> Cc: Elvis Pranskevichus <elpr...@gmail.com>; Python-Dev  d...@python.org>; Chris Barker <chris.bar...@noaa.gov>
> Subject: Re: [Python-Dev] iso8601 parsing
> 
> On Wed, Oct 25, 2017 at 3:48 PM, Alex Walters <tritium-l...@sdamon.com>
> wrote:
> >  Why make parsing ISO time special?
> 
> It's not the ISO format per se that is special, but parsing of str(x).
> For all numeric types, int, float, complex and even
> fractions.Fraction, we have a roundtrip invariant T(str(x)) == x.
> Datetime types are a special kind of numbers, but they don't follow
> this established pattern.  This is annoying when you deal with time
> series where it is common to have text files with a mix of dates,
> timestamps and numbers.  You can write generic code to deal with ints
> and floats, but have to special-case anything time related.

>>> repr(datetime.datetime.now())
'datetime.datetime(2017, 10, 25, 17, 16, 20, 973107)'

You can already roundtrip the repr of datetime objects with eval (if you care 
to do so).  You get iso formatting from a method on dt objects, I don’t see why 
it should be parsed by anything but a classmethod.

___
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] iso8601 parsing

[Alex Walters]

> -Original Message-
> From: Python-Dev [mailto:python-dev-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Elvis Pranskevichus
> Sent: Tuesday, October 24, 2017 8:12 PM
> To: python-dev@python.org
> Cc: Chris Barker 
> Subject: Re: [Python-Dev] iso8601 parsing
> 
> On Tuesday, October 24, 2017 5:53:58 PM EDT Alexander Belopolsky wrote:
> > No, but the last time I suggested that that datetime types should
> > satisfy the same invariants as numbers, namely
> > T(repr(x)) == x, the idea was met will silence.  I, on the other hand,
> > am not very enthusiastic about named constructors such as
> > date.isoparse().  Compared with date(s:str), this is one more method
> > name to remember, plus the potential for abuse as an instance method.
> > What is d.isoparse('2017-11-24')?
> 
> Agreed.  datetime(s:str) seems like a far more natural and consistent
> choice.

It's inconsistent with the rest of the module.  All other constructions of
datetime objects are on classmethods.  Why make parsing ISO time special?

> 
>  Elvis
> ___
> 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/tritium-
> list%40sdamon.com

___
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] iso8601 parsing

[Alex Walters]

> -Original Message-
> From: Alexander Belopolsky [mailto:alexander.belopol...@gmail.com]
> Sent: Wednesday, October 25, 2017 12:07 PM
> To: Alex Walters <tritium-l...@sdamon.com>
> Cc: Chris Barker <chris.bar...@noaa.gov>; Python-Dev  d...@python.org>
> Subject: Re: [Python-Dev] iso8601 parsing
> 
> 
> 
> > On Oct 25, 2017, at 11:45 AM, Alex Walters <tritium-l...@sdamon.com>
> wrote:
> >
> > it means
> > the type of the first argument changes the semantic meaning of
> subsequent
> > arguments, and that just adds a level of confusion to any api.
> 
> No, it does not. Passing a string a the first of three arguments will
still be a
> type error.

And that is a confusing api.  The problem has already been solved by
classmethod alternate constructors - they are already used widely in the
datetime api.  NOT using classmethod constructors is new and confusing for
the SINGLE use case of parsing iso formatted dates and times.  Why is that
special?  Why isn't ordinal time special to get into __init__?

___
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] iso8601 parsing

[Alex Walters]

> -Original Message-
> From: Python-Dev [mailto:python-dev-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Alexander Belopolsky
> Sent: Tuesday, October 24, 2017 5:54 PM
> To: Chris Barker 
> Cc: Python-Dev 
> Subject: Re: [Python-Dev] iso8601 parsing
> 
> On Tue, Oct 24, 2017 at 5:26 PM, Chris Barker 
> wrote:
> > On Mon, Oct 23, 2017 at 5:33 PM, Hasan Diwan 
> wrote:
> >>
> > can anyone argue that it's not a good idea for datetime ot
> > be able to read the iso format it puts out?
> 
> No, but the last time I suggested that that datetime types should
> satisfy the same invariants as numbers, namely
> T(repr(x)) == x, the idea was met will silence.  I, on the other hand,
> am not very enthusiastic about named constructors such as
> date.isoparse().  Compared with date(s:str), this is one more method
> name to remember, plus the potential for abuse as an instance method.
> What is d.isoparse('2017-11-24')?

Datetime.datetime.fromiso() (classmethod) is much more in keeping with the
rest of the datetime api - in fact, I have tried calling that method more
than once, before remembering datetime *doesn't* have that classmethod.
Making it a classmethod solves any concerns about calling it as an instance
method (the same way d.now() and d.strptime() just create and return a new
datetime objects, not mutates the current).  In fact, looking at the docs,
most of the methods are classmethods, so an additional classmethod is
fitting.

I really do not like the idea of making the first positional argument of the
datetime constructor int or str.  What happens when you pass a string for
the first argument and ints for subsequent arguments?  You would have to
raise a typeerror or valueerror.  I don't like that API design - it means
the type of the first argument changes the semantic meaning of subsequent
arguments, and that just adds a level of confusion to any api.  You might be
able to get away with that in third party code, but this is the standard
library, and this is the time manipulation module in the standard library -
you have to assume that this is one of the first modules a new user uses, we
have to keep the api sane.

The only way I can think of keeping the api sane and still pass an iso
string to the constructor is to pass It as a keyword argument - and at that
point you have to remember the argument name anyways, so you might as well
make it a classmethod to match everything else in the library.

$0.02

> ___
> 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/tritium-
> list%40sdamon.com

___
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] Is Windows XP still supported on Python 2.7?

[Alex Walters]

The promise that PEP-11 is making is that as long as a python was released
while Microsoft still supported that OS, and that python is still supported,
there will still be a python that works for you.  So, yes, Windows XP is
long since unsupported by Microsoft, but a disturbing number of people still
run it.  (I think the NHS in the UK still runs embedded windows XP, just to
name a big one).  Yes, it's a support burden, but it's on the support burden
version of python anyways.  2.7 is a very slow moving branch so it shouldn't
be THAT big of a pain for the last 2 years of python 2 support.

> -Original Message-
> From: Python-Dev [mailto:python-dev-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Victor Stinner
> Sent: Monday, July 24, 2017 5:05 AM
> To: Python Dev ; David Bolen
> 
> Subject: [Python-Dev] Is Windows XP still supported on Python 2.7?
> 
> Hi,
> 
> We have a Windows XP buildbot for Python 2.7, run by David Bolen:
> http://buildbot.python.org/all/builders/x86%20Windows%20XP%202.7/
> 
> test_bsddb3 fails randomly on this buildbot:
> http://bugs.python.org/issue30778
> 
> But Windows XP clearly reached its end-of-life, Microsoft doesn't
> support it anymore. So my question is if it makes sense to spend time
> on it?
> 
> We have a rule for new x.y.0 released, but not if a Microsoft Windows
> support expires during the lifetime of a Python release (2.7 here):
> https://www.python.org/dev/peps/pep-0011/#microsoft-windows
> 
> Firefox made great efforts to support Windows XP last years, but they
> decided to drop support last March with Firefox 52, last release
> supporting XP and Visa:
> https://support.mozilla.org/en-US/kb/end-support-windows-xp-and-vista
> 
> Victor
> ___
> 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/tritium-
> list%40sdamon.com

___
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] Python startup time

[Alex Walters]

> -Original Message-
> From: Python-Dev [mailto:python-dev-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Paul Moore
> Sent: Saturday, July 22, 2017 4:14 AM
> To: David Mertz 
> Cc: Barry Warsaw ; Python-Dev  d...@python.org>
> Subject: Re: [Python-Dev] Python startup time


> It's a bit of a chicken and egg problem - Windows users avoid
> excessive command line program invocation because startup time is
> high, so no-one optimises startup time because Windows users don't use
> short-lived command line programs. But I'm seeing a trend away from
> that - more and more Windows tools these days seem to be comfortable
> spawning subprocesses. I don't know what prompted that trend.

The programs I see that are comfortable spawning processes willy-nilly on
windows are mostly .net, which has a lot of the runtime assemblies cached by
the OS in the GAC - if you are spawning a second processes of yourself, or
something that uses the same libraries as you, the compile step on those can
be skipped.  Unless you are talking about python/non-.NET programs, in which
case, I have no answer.
 
> Paul
> ___
> 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/tritium-
> list%40sdamon.com

___
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] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Alex Walters]

> -Original Message-
> From: Python-Dev [mailto:python-dev-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Sebastian Krause
> Sent: Friday, June 10, 2016 1:01 PM
> To: python-dev@python.org
> Subject: Re: [Python-Dev] BDFL ruling request: should we block forever
> waiting for high-quality random bits?
> 
> Guido van Rossum  wrote:
> > I just don't like the potentially blocking behavior, and experts'
opinions
> > seem to widely vary on how insecure the fallback bits really are, how
> > likely you are to find yourself in that situation, and how probable an
> > exploit would be.
> 
> This is not just a theoretical problem being discussed by security
> experts that *could* be exploited, there have already been multiple
> real-life cases of devices (mostly embedded Linux machines)
> generating predicatable SSH keys because they read from an
> uninitialized /dev/urandom at first boot. Most recently in the
> Raspbian distribution for the Raspberry Pi:
> https://www.raspberrypi.org/forums/viewtopic.php?f=66=126892
> 
> At least in 3.6 there should be obvious way to get random data that
> *always* guarantees to be secure and either fails or blocks if it
> can't guarantee that.
> 
> Sebastian

And that should live in the secrets module.

___
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