Re: [Python-Dev] provisional status for asyncio
On 28 August 2015 at 00:25, Nick Coghlan wrote: > I'd suggest including a clearer motivation there: > > Note: The asyncio package has been included in the standard > library on a provisional basis, and thus may gain new APIs and > capabilities in maintenance releases as it matures. Backwards > incompatible changes may occur if deemed absolutely necessary by the > core developers. I'm happy with a statement like this offering additional guidance, but I think that formally we should stick with the current provisional-or-not situation (with asyncio remaining provisional for another release, if the asyncio devs feel that's needed). Ultimately, end users only really have two choices - use a library or not - so adding extra levels of "provisionalness" actually complicates their choice rather than simplifying it. 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] provisional status for asyncio
Hi,
2015-08-27 23:15 GMT+02:00 Yury Selivanov :
> Recently, in an asyncio related issue [1], Guido said that new features
> for asyncio have to wait till 3.6, since asyncio is no longer a provisional
> package. (...)
> For example, there is an issue [2] to add starttls support to asyncio.
> (...)
> Aside from adding new APIs, we also have to improve debugging
> capabilities.
> (...)
I would propose something more radical: remove asyncio from the stdlib.
PEP 411: "While it is considered an unlikely outcome, such packages
*may even be removed* from the standard library without a deprecation
period if the concerns regarding their API or maintenance prove
well-founded."
As an asyncio developer, I'm not sure that asyncio fits well into the
Python stdlib. The release cycle of feature release is long (18
months? or more?), the release cycle for bugfix release is sometimes
also too long (1 month at least). It's also frustrating to have subtle
API differences between Python 3.3, 3.4 and 3.5. For example,
asyncio.JoinableQueue was removed in Python 3.5, asyncio.Queue can
*now* be used instead, but asyncio.JoinableQueue should be used on
older Python version... It means that you have to write different code
depending on your Python version to support all Python versions.
I can give much more examples of missing asyncio features. Example:
Windows proactor event loop doesn't support signals (CTRL+C) nor UDP.
asyncio is moving so fast, that changes are not documented at all in
Misc/NEWS or Doc/whatsnews/x.y.rst. I tried to document changes in my
fork Trollius. See its changelog to have an idea how fast asyncio is
still changing:
http://trollius.readthedocs.org/changelog.html
I don't know how users will react to the removal of asyncio from the
stdlib ("asyncio is not trusted/supported by Python?").
The idea is to install it using pip: "pip install asyncio". The major
difference is that "pip install -U asyncio" allows to retrieve the
latest asyncio version, independently of your Python version. Hum, I
don't know if it works with Python 3.4 (which "asyncio" module is used
in this case?).
Developing asyncio only on Github would avoid the risk of having
patches temporary only in Github or only in CPython. It avoids the
need to synchronize the Git (Github) and Mercurial (CPython)
repositories.
Compare Python release dates with Twisted, Tornado and eventlet release dates.
Twisted releases:
* 2015-01-30: 15.0.0
* 2015-04-13: 15.1.0
* 2015-05-19: 15.2.0
* 2015-08-04: 15.3.0
Tornado releases:
* 2014-07-15: 4.0
* 2015-02-07: 4.1
* 2015-05-27: 4.2
* 2015-07-17: 4.2.1
eventlet releases:
* 2015-02-25: 0.17.1
* 2015-04-03: 0.17.2
* 2015-04-09: 0.17.3
* 2015-05-08: 0.17.4
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/archive%40mail-archive.com
Re: [Python-Dev] provisional status for asyncio
I think this is a packaging problem.
In an ideal world, Python would ship some version of asyncio, but you would
also be able to pip install a newer version into your virtual environment,
and it would override the version in stdlib.
As it stands now, however, if you pip install another version of asyncio,
the version in stdlib still takes precedence. What I end up doing in my
(non open source) projects is to include a copy of asyncio and manually
modify sys.path to point to it.
Can we fix pip/virtualenv instead?
On 28 Aug 2015 10:02 am, "Victor Stinner" wrote:
> Hi,
>
> 2015-08-27 23:15 GMT+02:00 Yury Selivanov :
> > Recently, in an asyncio related issue [1], Guido said that new features
> > for asyncio have to wait till 3.6, since asyncio is no longer a
> provisional
> > package. (...)
> > For example, there is an issue [2] to add starttls support to asyncio.
> > (...)
> > Aside from adding new APIs, we also have to improve debugging
> > capabilities.
> > (...)
>
> I would propose something more radical: remove asyncio from the stdlib.
>
> PEP 411: "While it is considered an unlikely outcome, such packages
> *may even be removed* from the standard library without a deprecation
> period if the concerns regarding their API or maintenance prove
> well-founded."
>
> As an asyncio developer, I'm not sure that asyncio fits well into the
> Python stdlib. The release cycle of feature release is long (18
> months? or more?), the release cycle for bugfix release is sometimes
> also too long (1 month at least). It's also frustrating to have subtle
> API differences between Python 3.3, 3.4 and 3.5. For example,
> asyncio.JoinableQueue was removed in Python 3.5, asyncio.Queue can
> *now* be used instead, but asyncio.JoinableQueue should be used on
> older Python version... It means that you have to write different code
> depending on your Python version to support all Python versions.
>
> I can give much more examples of missing asyncio features. Example:
> Windows proactor event loop doesn't support signals (CTRL+C) nor UDP.
>
> asyncio is moving so fast, that changes are not documented at all in
> Misc/NEWS or Doc/whatsnews/x.y.rst. I tried to document changes in my
> fork Trollius. See its changelog to have an idea how fast asyncio is
> still changing:
> http://trollius.readthedocs.org/changelog.html
>
> I don't know how users will react to the removal of asyncio from the
> stdlib ("asyncio is not trusted/supported by Python?").
>
> The idea is to install it using pip: "pip install asyncio". The major
> difference is that "pip install -U asyncio" allows to retrieve the
> latest asyncio version, independently of your Python version. Hum, I
> don't know if it works with Python 3.4 (which "asyncio" module is used
> in this case?).
>
> Developing asyncio only on Github would avoid the risk of having
> patches temporary only in Github or only in CPython. It avoids the
> need to synchronize the Git (Github) and Mercurial (CPython)
> repositories.
>
>
> Compare Python release dates with Twisted, Tornado and eventlet release
> dates.
>
> Twisted releases:
>
> * 2015-01-30: 15.0.0
> * 2015-04-13: 15.1.0
> * 2015-05-19: 15.2.0
> * 2015-08-04: 15.3.0
>
> Tornado releases:
>
> * 2014-07-15: 4.0
> * 2015-02-07: 4.1
> * 2015-05-27: 4.2
> * 2015-07-17: 4.2.1
>
> eventlet releases:
>
> * 2015-02-25: 0.17.1
> * 2015-04-03: 0.17.2
> * 2015-04-09: 0.17.3
> * 2015-05-08: 0.17.4
>
> 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/gjcarneiro%40gmail.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] provisional status for asyncio
On 28 August 2015 at 10:46, Gustavo Carneiro wrote: > I think this is a packaging problem. > > In an ideal world, Python would ship some version of asyncio, but you would > also be able to pip install a newer version into your virtual environment, > and it would override the version in stdlib. > > As it stands now, however, if you pip install another version of asyncio, > the version in stdlib still takes precedence. What I end up doing in my > (non open source) projects is to include a copy of asyncio and manually > modify sys.path to point to it. > > Can we fix pip/virtualenv instead? It's not a pip/virtualenv issue - it's a result of the way sys.path is set (in site.py IIRC). And it was a deliberate decision to put the stdlib before user installed packages, precisely so that random PyPI packages can't override the standard behaviour. (Setuptools included some hacks to circumvent this, but they are pretty nasty, and TBH not widely liked...) 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] provisional status for asyncio
On August 28, 2015 at 6:36:21 AM, Paul Moore (p.f.mo...@gmail.com) wrote: > On 28 August 2015 at 10:46, Gustavo Carneiro wrote: > > I think this is a packaging problem. > > > > In an ideal world, Python would ship some version of asyncio, but you would > > also be able to pip install a newer version into your virtual environment, > > and it would override the version in stdlib. > > > > As it stands now, however, if you pip install another version of asyncio, > > the version in stdlib still takes precedence. What I end up doing in my > > (non open source) projects is to include a copy of asyncio and manually > > modify sys.path to point to it. > > > > Can we fix pip/virtualenv instead? > > It's not a pip/virtualenv issue - it's a result of the way sys.path is > set (in site.py IIRC). And it was a deliberate decision to put the > stdlib before user installed packages, precisely so that random PyPI > packages can't override the standard behaviour. (Setuptools included > some hacks to circumvent this, but they are pretty nasty, and TBH not > widely liked...) > Right, the default sys.path is stdlib > user-packages > site-packages. I would personally prefer it if looked more like user-packages > site-packages > stdlib but I’m not sure how popular that opinion is :) - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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] provisional status for asyncio
Victor,
On 2015-08-28 5:01 AM, Victor Stinner wrote:
Hi,
2015-08-27 23:15 GMT+02:00 Yury Selivanov :
Recently, in an asyncio related issue [1], Guido said that new features
for asyncio have to wait till 3.6, since asyncio is no longer a provisional
package. (...)
For example, there is an issue [2] to add starttls support to asyncio.
(...)
Aside from adding new APIs, we also have to improve debugging
capabilities.
(...)
I would propose something more radical: remove asyncio from the stdlib.
I too would enjoy more frequent release schedule of asyncio.
Unfortunately, separating it from the standard library is something
that I don't think we can do so late in the 3.5 release candidates
process.
PEP 411: "While it is considered an unlikely outcome, such packages
*may even be removed* from the standard library without a deprecation
period if the concerns regarding their API or maintenance prove
well-founded."
As an asyncio developer, I'm not sure that asyncio fits well into the
Python stdlib. The release cycle of feature release is long (18
months? or more?), the release cycle for bugfix release is sometimes
also too long (1 month at least). It's also frustrating to have subtle
API differences between Python 3.3, 3.4 and 3.5. For example,
asyncio.JoinableQueue was removed in Python 3.5, asyncio.Queue can
*now* be used instead, but asyncio.JoinableQueue should be used on
older Python version... It means that you have to write different code
depending on your Python version to support all Python versions.
I can give much more examples of missing asyncio features. Example:
Windows proactor event loop doesn't support signals (CTRL+C) nor UDP.
asyncio is moving so fast, that changes are not documented at all in
Misc/NEWS or Doc/whatsnews/x.y.rst. I tried to document changes in my
fork Trollius. See its changelog to have an idea how fast asyncio is
still changing:
http://trollius.readthedocs.org/changelog.html
I don't know how users will react to the removal of asyncio from the
stdlib ("asyncio is not trusted/supported by Python?").
That's another concern.
The idea is to install it using pip: "pip install asyncio". The major
difference is that "pip install -U asyncio" allows to retrieve the
latest asyncio version, independently of your Python version. Hum, I
don't know if it works with Python 3.4 (which "asyncio" module is used
in this case?).
The one from the stdlib.
Developing asyncio only on Github would avoid the risk of having
patches temporary only in Github or only in CPython. It avoids the
need to synchronize the Git (Github) and Mercurial (CPython)
repositories.
Compare Python release dates with Twisted, Tornado and eventlet release dates.
Twisted releases:
* 2015-01-30: 15.0.0
* 2015-04-13: 15.1.0
* 2015-05-19: 15.2.0
* 2015-08-04: 15.3.0
Tornado releases:
* 2014-07-15: 4.0
* 2015-02-07: 4.1
* 2015-05-27: 4.2
* 2015-07-17: 4.2.1
eventlet releases:
* 2015-02-25: 0.17.1
* 2015-04-03: 0.17.2
* 2015-04-09: 0.17.3
* 2015-05-08: 0.17.4
These are very good stats. It shows that even mature async libraries
require frequent release cycles.
Anyways, I vote for at least keeping asyncio provisional in 3.5.x.
I'd be glad if we can consider to have more bugfix releases of 3.5
(and 3.6), say every 3 months.
Yury
___
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] provisional status for asyncio
On Fri, 28 Aug 2015 at 08:35 Yury Selivanov wrote:
> Victor,
>
> On 2015-08-28 5:01 AM, Victor Stinner wrote:
> > Hi,
> >
> > 2015-08-27 23:15 GMT+02:00 Yury Selivanov :
> >> Recently, in an asyncio related issue [1], Guido said that new features
> >> for asyncio have to wait till 3.6, since asyncio is no longer a
> provisional
> >> package. (...)
> >> For example, there is an issue [2] to add starttls support to asyncio.
> >> (...)
> >> Aside from adding new APIs, we also have to improve debugging
> >> capabilities.
> >> (...)
> > I would propose something more radical: remove asyncio from the stdlib.
>
> I too would enjoy more frequent release schedule of asyncio.
>
> Unfortunately, separating it from the standard library is something
> that I don't think we can do so late in the 3.5 release candidates
> process.
>
Ultimately it's Larry's call, but I don't see why we couldn't. If we were
talking about something as low-level as the urllib package then I would
agree, but beyond its own tests is there anything in the stdlib that
depends on asyncio?
-Brett
>
>
> >
> > PEP 411: "While it is considered an unlikely outcome, such packages
> > *may even be removed* from the standard library without a deprecation
> > period if the concerns regarding their API or maintenance prove
> > well-founded."
> >
> > As an asyncio developer, I'm not sure that asyncio fits well into the
> > Python stdlib. The release cycle of feature release is long (18
> > months? or more?), the release cycle for bugfix release is sometimes
> > also too long (1 month at least). It's also frustrating to have subtle
> > API differences between Python 3.3, 3.4 and 3.5. For example,
> > asyncio.JoinableQueue was removed in Python 3.5, asyncio.Queue can
> > *now* be used instead, but asyncio.JoinableQueue should be used on
> > older Python version... It means that you have to write different code
> > depending on your Python version to support all Python versions.
> >
> > I can give much more examples of missing asyncio features. Example:
> > Windows proactor event loop doesn't support signals (CTRL+C) nor UDP.
> >
> > asyncio is moving so fast, that changes are not documented at all in
> > Misc/NEWS or Doc/whatsnews/x.y.rst. I tried to document changes in my
> > fork Trollius. See its changelog to have an idea how fast asyncio is
> > still changing:
> > http://trollius.readthedocs.org/changelog.html
> >
> > I don't know how users will react to the removal of asyncio from the
> > stdlib ("asyncio is not trusted/supported by Python?").
>
> That's another concern.
>
> >
> > The idea is to install it using pip: "pip install asyncio". The major
> > difference is that "pip install -U asyncio" allows to retrieve the
> > latest asyncio version, independently of your Python version. Hum, I
> > don't know if it works with Python 3.4 (which "asyncio" module is used
> > in this case?).
>
> The one from the stdlib.
>
> >
> > Developing asyncio only on Github would avoid the risk of having
> > patches temporary only in Github or only in CPython. It avoids the
> > need to synchronize the Git (Github) and Mercurial (CPython)
> > repositories.
> >
> >
> > Compare Python release dates with Twisted, Tornado and eventlet release
> dates.
> >
> > Twisted releases:
> >
> > * 2015-01-30: 15.0.0
> > * 2015-04-13: 15.1.0
> > * 2015-05-19: 15.2.0
> > * 2015-08-04: 15.3.0
> >
> > Tornado releases:
> >
> > * 2014-07-15: 4.0
> > * 2015-02-07: 4.1
> > * 2015-05-27: 4.2
> > * 2015-07-17: 4.2.1
> >
> > eventlet releases:
> >
> > * 2015-02-25: 0.17.1
> > * 2015-04-03: 0.17.2
> > * 2015-04-09: 0.17.3
> > * 2015-05-08: 0.17.4
> >
>
>
> These are very good stats. It shows that even mature async libraries
> require frequent release cycles.
>
> Anyways, I vote for at least keeping asyncio provisional in 3.5.x.
>
> I'd be glad if we can consider to have more bugfix releases of 3.5
> (and 3.6), say every 3 months.
>
>
> Yury
> ___
> 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/brett%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] provisional status for asyncio
2015-08-28 17:44 GMT+02:00 Brett Cannon : > Ultimately it's Larry's call, but I don't see why we couldn't. If we were > talking about something as low-level as the urllib package then I would > agree, but beyond its own tests is there anything in the stdlib that depends > on asyncio? At the beginning, asyncio was more fat: it contained a HTTP client and server. The HTTP code was moved out of asyncio (into the aiohttp project, which is great and popular by the way) to keep asyncio small and simple. There is no plan to put libraries based on asyncio into the stdlib. And I don't think that existing modules should start to support asyncio, it's more the opposite :-) For example, urllib.request, http.client and http.server are replaced by aiohttp. I don't think that it would make sense to add new asynchronous methods to these modules. 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/archive%40mail-archive.com
Re: [Python-Dev] provisional status for asyncio
2015-08-28 17:34 GMT+02:00 Yury Selivanov : > I too would enjoy more frequent release schedule of asyncio. The problem is also to allow users to upgrade easily asyncio to retrieve new features, or simply latest bug fixes. As explained in other emails, if asyncio is part of the stlidb, it's *not* possible to upgrade it using "pip install -U asyncio", except if you "hack" sys.path. Usually, Python 3 comes with the system, for an user, it's hard to upgrade it. For example, Ubuntu Trusty still provides Python 3.4.0. asyncio doesn't have the loop.create_task() method for example in this release. asyncio got many bugfixes and some new features between 3.4.0 and 3.4.3. It's much easier to upgrade a third-party library than upgrading the system python. 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/archive%40mail-archive.com
Re: [Python-Dev] provisional status for asyncio
On August 28, 2015 at 12:01:25 PM, Victor Stinner (victor.stin...@gmail.com) wrote: > 2015-08-28 17:34 GMT+02:00 Yury Selivanov : > > I too would enjoy more frequent release schedule of asyncio. > > The problem is also to allow users to upgrade easily asyncio to > retrieve new features, or simply latest bug fixes. As explained in > other emails, if asyncio is part of the stlidb, it's *not* possible to > upgrade it using "pip install -U asyncio", except if you "hack" > sys.path. > > Usually, Python 3 comes with the system, for an user, it's hard to > upgrade it. For example, Ubuntu Trusty still provides Python 3.4.0. > asyncio doesn't have the loop.create_task() method for example in this > release. asyncio got many bugfixes and some new features between 3.4.0 > and 3.4.3. It's much easier to upgrade a third-party library than > upgrading the system python. > Unless we fix the sys.path ordering to make it possible. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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] provisional status for asyncio
2015-08-28 18:02 GMT+02:00 Donald Stufft : > Unless we fix the sys.path ordering to make it possible. The problem is the deadline: Python 3.5 final is scheduled for the September, 13. We have 2 weeks to decide what to do with asyncio. I don't think that it's a good idea to modify how sys.path is built between an RC version (ex: 3.5rc2) and 3.5.0 final... 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/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2015-08-21 - 2015-08-28) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open5042 (+29) closed 31671 (+15) total 36713 (+44) Open issues with patches: 2251 Issues opened (39) == #24909: Windows: subprocess.Popen: race condition for leaking inherita http://bugs.python.org/issue24909 opened by Adam Meily #24910: Windows MSIs don't have unique display names http://bugs.python.org/issue24910 opened by steve.dower #24911: Context manager of socket.socket is not documented http://bugs.python.org/issue24911 opened by zodalahtathi #24912: The type of cached objects is mutable http://bugs.python.org/issue24912 opened by serhiy.storchaka #24913: deque.index() overruns deque boundary http://bugs.python.org/issue24913 opened by JohnLeitch #24914: Python: Not just OO style but this is not mentioned on python. http://bugs.python.org/issue24914 opened by Paddy McCarthy #24915: Profile Guided Optimization improvements (better training, llv http://bugs.python.org/issue24915 opened by alecsandru.patrascu #24916: In sysconfig, don't rely on sys.version format http://bugs.python.org/issue24916 opened by takluyver #24917: time_strftime() Buffer Over-read http://bugs.python.org/issue24917 opened by JohnLeitch #24918: Docs layout bug http://bugs.python.org/issue24918 opened by reag #24920: shutil.get_terminal_size throws AttributeError http://bugs.python.org/issue24920 opened by Isaac Levy #24921: Operator precedence table in 5.15 should be highest to lowest http://bugs.python.org/issue24921 opened by Joseph Schachner #24922: assertWarnsRegex doesn't allow multiple warning messages http://bugs.python.org/issue24922 opened by sleepycal #24923: Append system paths in setup.py instead of prepending http://bugs.python.org/issue24923 opened by christopher.hogan #24924: _posixsubprocess.c: sysconf() might not be async-signal-safe http://bugs.python.org/issue24924 opened by jwilk #24925: Allow doctest to find line number of __test__ strings if forma http://bugs.python.org/issue24925 opened by r.david.murray #24927: multiprocessing.Pool hangs forever on segfault http://bugs.python.org/issue24927 opened by Jonas Obrist #24928: mock.patch.dict spoils order of items in collections.OrderedDi http://bugs.python.org/issue24928 opened by Alexander Oblovatniy #24929: _strptime.TimeRE should not enforce range in regex http://bugs.python.org/issue24929 opened by Steve Yeung #24930: test_ssl broker was fixed http://bugs.python.org/issue24930 opened by marcosptf #24931: _asdict breaks when inheriting from a namedtuple http://bugs.python.org/issue24931 opened by Samuel Isaacson #24932: Migrate _testembed to a C unit testing library http://bugs.python.org/issue24932 opened by ncoghlan #24933: socket.recv(size, MSG_TRUNC) returns more than size bytes http://bugs.python.org/issue24933 opened by Andrey Wagin #24934: django_v2 benchmark not working in Python 3.6 http://bugs.python.org/issue24934 opened by florin.papa #24935: LDSHARED is not set according when CC is set. http://bugs.python.org/issue24935 opened by yunlian #24936: Idle: handle 'raise' properly when running with subprocess (2. http://bugs.python.org/issue24936 opened by terry.reedy #24937: Multiple problems in getters & setters in capsulethunk.h http://bugs.python.org/issue24937 opened by encukou #24938: Measure if _warnings.c is still worth having http://bugs.python.org/issue24938 opened by brett.cannon #24939: Remove unicode_format.h from stringlib http://bugs.python.org/issue24939 opened by eric.smith #24940: RotatingFileHandler uses tell in non-binary mode to determine http://bugs.python.org/issue24940 opened by Ilya.Kulakov #24941: Add classproperty as builtin class http://bugs.python.org/issue24941 opened by guettli #24942: Remove domain from ipaddress.reverse_pointer property and add http://bugs.python.org/issue24942 opened by leeclemens #24945: Expose Py_TPFLAGS_ values from Python http://bugs.python.org/issue24945 opened by erik.bray #24946: Tkinter tests that fail on linux in tiling window manager http://bugs.python.org/issue24946 opened by terry.reedy #24948: Multiprocessing not timely flushing stack trace to stderr http://bugs.python.org/issue24948 opened by memeplex #24949: Identifier lookup in a multi-level package is flakey http://bugs.python.org/issue24949 opened by SegundoBob #24950: FAIL: test_expanduser when $HOME=/ http://bugs.python.org/issue24950 opened by felixonmars #24951: Idle test_configdialog fails on Fedora 23, 3.6 http://bugs.python.org/issue24951 opened by terry.reedy #24952: stack_size([size]) is actually stack_size(size=0) http://bugs.python.org/issue24952 opened by mattip Most recent 15 issues with no replies (15) == #24946: Tkinter tests that fail on linux in
Re: [Python-Dev] provisional status for asyncio
On August 28, 2015 at 12:07:48 PM, Victor Stinner (victor.stin...@gmail.com) wrote: > 2015-08-28 18:02 GMT+02:00 Donald Stufft : > > Unless we fix the sys.path ordering to make it possible. > > The problem is the deadline: Python 3.5 final is scheduled for the > September, 13. We have 2 weeks to decide what to do with asyncio. > > I don't think that it's a good idea to modify how sys.path is built > between an RC version (ex: 3.5rc2) and 3.5.0 final... > Yea, there’s always 3.6 though! - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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] provisional status for asyncio
On 2015-08-28 11:44 AM, Brett Cannon wrote: Unfortunately, separating it from the standard library is something that I don't think we can do so late in the 3.5 release candidates process. Ultimately it's Larry's call, but I don't see why we couldn't. If we were talking about something as low-level as the urllib package then I would agree, but beyond its own tests is there anything in the stdlib that depends on asyncio? As Victor already replied, asyncio is pretty self contained, and nothing in the stdlib depends on it. If we really can remove it, let's consider it. Yury ___ 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] provisional status for asyncio
On 28 August 2015 at 17:11, Yury Selivanov wrote: > On 2015-08-28 11:44 AM, Brett Cannon wrote: > >> >> Unfortunately, separating it from the standard library is something >> that I don't think we can do so late in the 3.5 release candidates >> process. >> >> >> Ultimately it's Larry's call, but I don't see why we couldn't. If we were >> talking about something as low-level as the urllib package then I would >> agree, but beyond its own tests is there anything in the stdlib that >> depends on asyncio? >> > > As Victor already replied, asyncio is pretty self contained, and > nothing in the stdlib depends on it. > > If we really can remove it, let's consider it. -1 for removing it. It is way too late for 3.5 IMHO. You should have proposed it at least 6 months ago. This feels too rushed. +1 for changing sys.path to allow pip-installed asyncio to override the stdlib version (for 3.6). Some developers complain that NodeJS's packaging system is better that Python, maybe this lack of flexibility is one of the reasons... -- Gustavo J. A. M. Carneiro Gambit Research "The universe is always one step beyond logic." -- Frank Herbert ___ 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] provisional status for asyncio
On 29 August 2015 at 04:44, Gustavo Carneiro wrote: > On 28 August 2015 at 17:11, Yury Selivanov wrote: >> >> On 2015-08-28 11:44 AM, Brett Cannon wrote: >>> >>> >>> Unfortunately, separating it from the standard library is something >>> that I don't think we can do so late in the 3.5 release candidates >>> process. >>> >>> >>> Ultimately it's Larry's call, but I don't see why we couldn't. If we were >>> talking about something as low-level as the urllib package then I would >>> agree, but beyond its own tests is there anything in the stdlib that depends >>> on asyncio? >> >> >> As Victor already replied, asyncio is pretty self contained, and >> nothing in the stdlib depends on it. >> >> If we really can remove it, let's consider it. > > -1 for removing it. It is way too late for 3.5 IMHO. You should have > proposed it at least 6 months ago. This feels too rushed. > > +1 for changing sys.path to allow pip-installed asyncio to override the > stdlib version (for 3.6). Some developers complain that NodeJS's packaging > system is better that Python, maybe this lack of flexibility is one of the > reasons... I think ensurepip now offers us a better option for dealing with this kind of situation: create a new category of "recommended" 3rd party modules, which have their own upgrade cycle and maintenance model, independent of the standard library, but use pip and bundled wheel files to install them by default in the CPython installers. This allows them to be made available by default to new Python users, but also still easily kept in sync across all supported Python versions. We've started inching our way towards this already, with provisional modules, the IDLE enhancement exception for all releases, the network security backports to Python 2.7, and ensurepip itself. This means it isn't just asyncio that could benefit from such an enhancement to our modularisation capabilities - we could also apply it to tkinter, idle and distutils (all of which are often unbundled by downstream redistributors anyway), and potentially even to particularly security sensitive components like the ssl module. >From a Linux downstream perspective, APT has long supported a distinction between hard requirements, recommended additions, and suggested ones in the Debian world, and RPM recently gained that capability as well, so such a change would actually make our lives easier, since "bundled as a wheel file" in the CPython Windows and Mac OS X installers would map to a Recommends or Suggests downstream, rather than a hard requirement. However, we don't need to rush into this. As long as we keep asyncio provisional for 3.5.0, then we can take our time in considering what we want to do in terms of its ongoing maintenance and release management model, and then apply that new approach to at least asyncio for 3.5.x, and consider modularising the development and release cycles for other components of interest in 3.6+ (and potentially 2.7.x in some cases). Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
