On Tue, Jul 05, 2016 at 08:01:43PM +0200, Petr Viktorin wrote:
> In the tkinter case, compiling for source is easy on a developer's
> computer, but doing that on a headless server brings in devel files for
> the entire graphical environment.
> Are you saying Python on servers should have a way to
On Tue, 5 Jul 2016 at 18:16 Nick Coghlan wrote:
> On 6 July 2016 at 07:04, Brett Cannon wrote:
> > Realizing that all of these are just proposals with no solid plan behind
> > them, they are all predicated on moving to GitHub, and none of these are
> > directly promoting releasing every module i
On 6 July 2016 at 11:09, Barry Warsaw wrote:
> On Jul 06, 2016, at 10:55 AM, Nick Coghlan wrote:
>
>>However, if we did decide we wanted to take minimising "time to
>>redistribution" for at least Ubuntu & Fedora into account, then the
>>two main points to consider would be:
>>
>>- starting the ups
On 6 July 2016 at 07:04, Brett Cannon wrote:
> Realizing that all of these are just proposals with no solid plan behind
> them, they are all predicated on moving to GitHub, and none of these are
> directly promoting releasing every module in the stdlib on PyPI as a
> stand-alone package with its o
On 6 July 2016 at 03:47, Barry Warsaw wrote:
> On Jul 05, 2016, at 10:38 AM, Steve Dower wrote:
>
>>My hope is that it would be essentially a "pip freeze"/"pip install -r ..."
>>(or equivalent with whatever tool is used/created for managing the
>>stdlib). Perhaps using VCS URIs rather than version
On Jul 06, 2016, at 10:55 AM, Nick Coghlan wrote:
>However, if we did decide we wanted to take minimising "time to
>redistribution" for at least Ubuntu & Fedora into account, then the
>two main points to consider would be:
>
>- starting the upstream beta phase before the first downstream alpha fre
On Jul 06, 2016, at 10:02 AM, Nick Coghlan wrote:
>On 6 July 2016 at 03:44, Barry Warsaw wrote:
>
>> Projecting ahead, it probably means 3.7 in mid-2018, which is after the
>> Ubuntu 18.04 LTS release, so we'll only do one major transition before the
>> next LTS. From my perspective, that feels
On 6 July 2016 at 05:11, Brett Cannon wrote:
> Sticking w/ 18 months is also fine, but then I would like to discuss
> choosing what months we try to release to get into a date-based release
> cadence so we know that every e.g. December and June are when releases
> typically happen thanks to our 6
On 6/07/2016 9:51 AM, Steve Dower wrote:
On 05Jul2016 1615, Peter wrote:
It's not the URL it is complaining of, rather
On Windows, Norton Internet Security virus checks all downloads. One of
the names they give to the result of their scanning is 'File Insight'.
From what I can tell, it uses a fe
On 6 July 2016 at 03:44, Barry Warsaw wrote:
> For example, 3.6 final will come out in December 2016, so it'll be past our
> current 16.10 Ubuntu release. We've pretty much decided to carry Python 3.5
> through until 17.04, and that'll give us a good year to make 18.04 LTS have a
> solid Python 3
On 05Jul2016 1615, Peter wrote:
It's not the URL it is complaining of, rather
On Windows, Norton Internet Security virus checks all downloads. One of
the names they give to the result of their scanning is 'File Insight'.
From what I can tell, it uses a few checks:
- virus scanning using known sig
On 05Jul2016 1404, Brett Cannon wrote:
Realizing that all of these are just proposals with no solid plan behind
them, they are all predicated on moving to GitHub, and none of these are
directly promoting releasing every module in the stdlib on PyPI as a
stand-alone package with its own versioning
(Response at bottom)
On 6/07/2016 2:39 AM, Steve Dower wrote:
On 04Jul2016 2241, Steve Holden wrote:
Hi Peter,
While the humble webmasters can do little about this it's possible the
developers can, so I am forwarding your email to their mailing list.
regards
Steve
Steve Holden
On Tue, Jul
On Tue, 5 Jul 2016 at 13:02 Paul Moore wrote:
> On 5 July 2016 at 19:01, Petr Viktorin wrote:
> > There are people who want to cut out what they don't need – to build
> > self-contained applications (pyinstaller, Python for Android), or to
> > eliminate unnecessary dependencies (python3-tkinter)
On 5 July 2016 at 19:01, Petr Viktorin wrote:
> There are people who want to cut out what they don't need – to build
> self-contained applications (pyinstaller, Python for Android), or to
> eliminate unnecessary dependencies (python3-tkinter). And they will do
> it with CPython's blessing or witho
On Tue, 5 Jul 2016 at 10:45 Barry Warsaw wrote:
> On Jul 04, 2016, at 10:31 AM, Nick Coghlan wrote:
>
> >While we liked the "consistent calendar cadence that is some multiple
> >of 6 months" idea, several of us thought 12 months was way too short
> >as it makes for too many entries in third party
On 07/05/2016 10:44 AM, Barry Warsaw wrote:
On Jul 04, 2016, at 10:31 AM, Nick Coghlan wrote:
While we liked the "consistent calendar cadence that is some multiple
of 6 months" idea, several of us thought 12 months was way too short
as it makes for too many entries in third party support matri
(sorry if you get this twice, I dropped python-dev by mistake)
On 07/05/2016 07:02 PM, Steven D'Aprano wrote:
> On Tue, Jul 05, 2016 at 09:53:24AM +0200, Petr Viktorin wrote:
>
>> While we're on the subject, I'd like to offer another point for
>> consideration: not all implementations of Python c
On Jul 05, 2016, at 10:38 AM, Steve Dower wrote:
>My hope is that it would be essentially a "pip freeze"/"pip install -r ..."
>(or equivalent with whatever tool is used/created for managing the
>stdlib). Perhaps using VCS URIs rather than version numbers?
>
>That is, the test run would dump a list
On Jul 04, 2016, at 10:31 AM, Nick Coghlan wrote:
>While we liked the "consistent calendar cadence that is some multiple
>of 6 months" idea, several of us thought 12 months was way too short
>as it makes for too many entries in third party support matrices.
18 months for a major release cadence s
On 05Jul2016 1028, Barry Warsaw wrote:
On Jul 03, 2016, at 04:21 PM, Steve Dower wrote:
A rough count of how I'd break up the current 3.5 Lib folder (which I
happened to have handy) suggests no more than 50 repos.
A concern with a highly split stdlib is local testing. I'm not worried about
p
On Jul 03, 2016, at 04:21 PM, Steve Dower wrote:
>A rough count of how I'd break up the current 3.5 Lib folder (which I
>happened to have handy) suggests no more than 50 repos.
A concern with a highly split stdlib is local testing. I'm not worried about
pull request testing, or after-the-fact bu
On Jul 05, 2016, at 11:19 AM, Victor Stinner wrote:
>pip supports a requirements.txt file which is a nice may to declare
>dependency. You can:
>
>* specify the minimum library version
>* make some library specific to some operation systems
>* skip dependencies on some Python versions -- very helpf
On 05Jul2016 1021, Paul Moore wrote:
On 5 July 2016 at 18:02, Steven D'Aprano wrote:
Yes, we're all probably sick and tired of hearing all the Chicken Little
scare stories about how the GIL is killing Python, how everyone is
abandoning Python for Ruby/Javascript/Go/Swift, how Python 3 is killin
On 5 July 2016 at 18:02, Steven D'Aprano wrote:
> Yes, we're all probably sick and tired of hearing all the Chicken Little
> scare stories about how the GIL is killing Python, how everyone is
> abandoning Python for Ruby/Javascript/Go/Swift, how Python 3 is killing
> Python, etc. But sometimes the
On Tue, Jul 05, 2016 at 09:53:24AM +0200, Petr Viktorin wrote:
> While we're on the subject, I'd like to offer another point for
> consideration: not all implementations of Python can provide the full
> stdlib, and not everyone wants the full stdlib.
>
> For MicroPython, most of Python's batterie
On 04Jul2016 2241, Steve Holden wrote:
Hi Peter,
While the humble webmasters can do little about this it's possible the
developers can, so I am forwarding your email to their mailing list.
regards
Steve
Steve Holden
On Tue, Jul 5, 2016 at 3:30 AM, Peter via Webmaster
mailto:webmas...@python.
> This is an area of exceeding subtlety (and also not very well
> documented/specified, probably). I'd worry that changing anything here
> might break some code. When a metaclass overrides neither __init__ nor
> __new__, keyword args will not work because type.__init__ forbids
> them. However when
On Jul 03, 2016, at 01:17 AM, Ludovic Gasc wrote:
>If 3.5.2.1 or 3.5.3 are impossible to release before december, what are the
>alternative solutions for AsyncIO users ?
>1. Use 3.5.1 and hope that Linux distributions won't use 3.5.2 ?
Matthias just uploaded a 3.5.2-2 to Debian unstable, which wi
Hi,
asyncio is a good example because it wants to evolve faster than the
whole "CPython package". Each minor version of CPython adds news
features in asyncio. It is not always easy to document these changes.
Moreover, the behaviour of some functions also changed in minor
versions.
asyncio doesn't
On 07/05/2016 10:05 AM, Chris Angelico wrote:
> On Tue, Jul 5, 2016 at 5:53 PM, Petr Viktorin wrote:
>> If packages had a way to opt-out of needing the whole standard library,
>> and instead specify the stdlib subset they need, answering questions
>> like "will this run on my phone?" and "what pie
On Tue, Jul 5, 2016 at 5:53 PM, Petr Viktorin wrote:
> If packages had a way to opt-out of needing the whole standard library,
> and instead specify the stdlib subset they need, answering questions
> like "will this run on my phone?" and "what piece of the stdlib do we
> want to port next?" would
On 07/04/2016 12:19 AM, Steve Dower wrote:
> My thinking on this issue was that some/most packages from the stdlib
> would move into site-packages. Certainly I'd expect asyncio to be in
> this category, and probably typing. Even going as far as email and
> urllib would potentially be beneficial (to
33 matches
Mail list logo
