Re: [Python-Dev] PEP 492 documentation
Nikolaus, Strange. PEP 492 changes are fully documented since b3. Here are just few examples: https://docs.python.org/3.5/whatsnew/3.5.html#pep-492-coroutines-with-async-and-await-syntax https://docs.python.org/3.5/reference/datamodel.html#coroutines https://docs.python.org/3.5/reference/compound_stmts.html#coroutines Perhaps, it's a browser cache issue? Yury On 2015-08-02 12:38 AM, Nikolaus Rath wrote: Hello, Looking at the language reference for 3.5.0b4, I noticed that it mentions neither async nor await. Is this still going to get updated, or will the only documentation consist of the PEP itself? I think having a Python release recognize keywords that are not mentioned in the language reference would be quite unfortunate (even if they're treated specially to preserve backwards compatibility). Best, -Nikolaus ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Issues not responded to.
On Fri, Jul 31, 2015 at 9:37 AM, Carl Meyer wrote:
>
> I'm a Django core developer. For the last half-year or so, the Django
> Software Foundation has (for the first time) paid a "Django Fellow" or
> two (currently Tim Graham) to work on core Django. For me the experience
> has been excellent.
>
> So based on my experience with the transition to having a DSF-paid
> Fellow on the Django core team, and having watched important python-dev
> work (e.g. the core workflow stuff) linger due to lack of available
> volunteer time, I'd recommend that python-dev run, not walk, to ask the
> PSF board to fund a similar position for Python core.
>
> Of course there may be differences between the culture of python-dev and
> Django core
>
>
A view from the other side.
Yeah I guess its a good idea for PSF to spend some money to clear 'ugly'
bugs.
Dunno about the proc-n-cons of this so wont get into it.
Instead I'd like to draw attention to the free side of the equation --
What would it take to have more hands with sleeves rolled up and doing
the housecleaning?
Context:
We had a bunch of college students (2nd year Engineering) doing some
projects
with us.
One was inside the CPython sources:
https://github.com/rusimody/l10Python
Their final presentation was last Thursday.
Q: Is there anything in there that can reasonably be a patch for python?
A: Please dont be embarrassing!
However as a student project it was enough for us to say: "Good work!"
Here's an REPL-session to demo:
[Note १२३४५६७८९० is devanagari equivalent of 1234567890]
--
Python 3.5.0b2 (default, Jul 30 2015, 19:32:42)
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> १२
12
>>> 23 == २३
True
>>> १२ + ३४
46
>>> १२ + 34
46
>>> "12" == "१२"
False
>>> 2 ≤ 3
True
>>> 2 ≠ 3
True
>>> (λ x: x+3)(4)
7
>>> # as a result of which this doesn't work... I did say they are kids!
...
>>> δ = 3
File "", line 1
δ = 3
^
SyntaxError: invalid syntax
>>> {1,2,3} ∩ {2,3,4}
{2, 3}
>>> {1,2,3} ∪ {2,3,4}
{1, 2, 3, 4}
>>> ¬ True
False
>>> Σ([1,2,3,4])
10
>>>
--
The last is actually more an embarrassment than the δ breaking since
they’ve *changed the lexer* to read the Σ when all that was required was
Σ = sum !!
In short... Kids!
However as kids we could say they are farther to being programmers than
they were before
this -- opening something of the scale of CPython, finding one's way around
and adding/modifying
even the tiniest bit of functionality is a big growing-up step.
Brings me to the point of this mail:
Surely me+my students is not unique configuration -- there must be zillions
of such across the world.
And if inexperienced/kids like us had more help from people like the
members of
this list we would get farther and at least some subset of these may go
on to become actual devs/contributors.
So the request is that some of you give a tiny fraction of your time to
teams just mucking
around in the CPython codebase as a long term investment to producing more
devs even when it is
not directly connected to a possible contribution/patch.
[Yeah I am a lurker on the mentors list but I dont see much *technical*
discussion happening there]
We could actually submit patches.
Just that the priorities of the 3 parties -- teachers, students, devs --
is clearly different:
- Teachers need to give/create a good learning experience
- Students need to shine, do well, excel...("show off" is not an
inaccurate description)
- Devs need the language to progress and bugs to be fixed
Though these priorities are different I believe a symbiosis is possible.
In particular, at least some of the -- for a dev -- 'ugly-bugs' could be a
challenge in an academic context.
I will be teaching again to more advanced students this time
If I could find a path through bugs of different challenge-levels we may
get some bugs fixed...
Thanks
Rusi
--
http://blog.languager.org
___
Python-Dev mailing list
[email protected]
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 492 documentation
Shouldn't at least ayncio doc https://docs.python.org/3.5/library/asyncio.html be updated accordingly ? for example https://docs.python.org/3.5/search.html?q=await&check_keywords=yes&area=default doesn't mention https://docs.python.org/3.5/library/asyncio.html 2015-08-02 16:21 GMT+02:00 Yury Selivanov : > Nikolaus, > > Strange. PEP 492 changes are fully documented since b3. > > Here are just few examples: > > > https://docs.python.org/3.5/whatsnew/3.5.html#pep-492-coroutines-with-async-and-await-syntax > https://docs.python.org/3.5/reference/datamodel.html#coroutines > https://docs.python.org/3.5/reference/compound_stmts.html#coroutines > > Perhaps, it's a browser cache issue? > > Yury > > On 2015-08-02 12:38 AM, Nikolaus Rath wrote: > >> Hello, >> >> Looking at the language reference for 3.5.0b4, I noticed that it >> mentions neither async nor await. >> >> Is this still going to get updated, or will the only documentation >> consist of the PEP itself? I think having a Python release recognize >> keywords that are not mentioned in the language reference would be quite >> unfortunate (even if they're treated specially to preserve backwards >> compatibility). >> >> Best, >> -Nikolaus >> >> > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/xavier.combelle%40gmail.com > ___ Python-Dev mailing list [email protected] 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 492 documentation
On 2015-08-02 4:04 PM, Xavier Combelle wrote: Shouldn't at least ayncio doc https://docs.python.org/3.5/library/asyncio.html be updated accordingly ? for example https://docs.python.org/3.5/search.html?q=await&check_keywords=yes&area=default doesn't mention https://docs.python.org/3.5/library/asyncio.html Yes, it was updated:https://docs.python.org/3.5/library/asyncio-task.html (search for 'async def' on the page -- it's mentioned about 13 times) Yury ___ Python-Dev mailing list [email protected] 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 492 documentation
Hi, No, not a browser cache issue. I was looking for "async" or "await" in the table of contents, so I didn't notice the new "coroutines" sections. Sorry for the noise. -Nikolaus On Aug 02 2015, Yury Selivanov wrote: > Nikolaus, > > Strange. PEP 492 changes are fully documented since b3. > > Here are just few examples: > > https://docs.python.org/3.5/whatsnew/3.5.html#pep-492-coroutines-with-async-and-await-syntax > https://docs.python.org/3.5/reference/datamodel.html#coroutines > https://docs.python.org/3.5/reference/compound_stmts.html#coroutines > > Perhaps, it's a browser cache issue? > > Yury > > On 2015-08-02 12:38 AM, Nikolaus Rath wrote: >> Hello, >> >> Looking at the language reference for 3.5.0b4, I noticed that it >> mentions neither async nor await. >> >> Is this still going to get updated, or will the only documentation >> consist of the PEP itself? I think having a Python release recognize >> keywords that are not mentioned in the language reference would be quite >> unfortunate (even if they're treated specially to preserve backwards >> compatibility). >> >> Best, >> -Nikolaus >> > -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] updating ensurepip to include wheel
So, pip 7.0 depends on the wheel module for its automatic wheel building, and installing pip from get-pip.py, or the bundled copy in virtualenvs will automatically install wheel. But ensurepip doesn't bundle wheel, so we're actually installing a slightly crippled pip 7.1, which will lead to folk having a poorer experience. Is this a simple bug, or do we need to update the PEP? -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] updating ensurepip to include wheel
On August 2, 2015 at 8:47:46 PM, Robert Collins ([email protected]) wrote: > So, pip 7.0 depends on the wheel module for its automatic wheel > building, and installing pip from get-pip.py, or the bundled copy in > virtualenvs will automatically install wheel. > > But ensurepip doesn't bundle wheel, so we're actually installing a > slightly crippled pip 7.1, which will lead to folk having a poorer > experience. > > Is this a simple bug, or do we need to update the PEP? > Personally, I think it's not going to be worth the pain to add wheel to ensurepip. We (pip) already have a somewhat rocky relationship with some downstream vendors because of the bundling of pip and setuptools that I'm not sure that wheel makes sense. Especially given that I want the optional dependency on Wheel to be a temporary measure until we can just implicitly install wheel as a build time dependency within pip and no longer need to install it implicitly in get-pip.py or virtualenv. In the future I expect setuptools to be removed as well at a similar time when we can implicitly install setuptools as a build time dependency of an sdist and do not require end users to install it explicitly. That being said, I think the PEP would need to be updated (and possibly a new PEP?) since we explicitly called out the fact that setuptools would currently be included until pip no longer needed it to be installed seperately. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
