I wrote this little Python program using CPython 3.5.2. It's ...
interesting ... that we apparently don't need comments or pass
statements any more. Anyone else think it might be worth tightening up
the grammar definition and parser a bit?
def empty():
"""Don't do anything"""
def helloWorld()
On Mon, May 15, 2017 at 7:38 PM, Hugh Fisher wrote:
> I wrote this little Python program using CPython 3.5.2. It's ...
> interesting ... that we apparently don't need comments or pass
> statements any more. Anyone else think it might be worth tightening up
> the grammar definition and parser a bit
On 14 May 2017 at 17:12, Abdur-Rahmaan Janhangeer wrote:
> Whatever you all propose,
>
> coming from a java and c++ background, OOP in python is quite cumbersome.
>
> if you tell that i am not a python guy, then consider that current oop style
> does not reflect python's style of ease and simplici
On Mon, May 15, 2017 at 07:38:29PM +1000, Hugh Fisher wrote:
> I wrote this little Python program using CPython 3.5.2. It's ...
> interesting ... that we apparently don't need comments or pass
> statements any more.
I'm not sure what you mean by "any more". The code you give works,
unchanged, a
On Mon, May 15, 2017 at 08:13:48PM +1000, Chris Angelico wrote:
> On Mon, May 15, 2017 at 7:38 PM, Hugh Fisher wrote:
> > I wrote this little Python program using CPython 3.5.2. It's ...
> > interesting ... that we apparently don't need comments or pass
> > statements any more. Anyone else think i
On Mon, May 15, 2017 at 11:00 PM, Steven D'Aprano wrote:
> On Mon, May 15, 2017 at 08:13:48PM +1000, Chris Angelico wrote:
>> On Mon, May 15, 2017 at 7:38 PM, Hugh Fisher wrote:
>> > I wrote this little Python program using CPython 3.5.2. It's ...
>> > interesting ... that we apparently don't nee
I think it would be nice to have a generic NamedTuple interface in python:
from typing import NamedTupleType
def test(
arguments: NamedTupleType
) -> NamedTupleType:
return SomeType(**NamedTupleType._asdict)
The rationale is that named tuple exposes a common API, and it would be
nice
On 15.05.17 16:00, Steven D'Aprano wrote:
There's also cases where
if x > y:
pass
else:
code
is *not necessarily* the same as
if not (x > y):
code
This is not true.
if not cond:
stmt1
else:
stmt2
always is equivalent to
if co
This should be worked into a PEP, instead of living on as a bunch of
python-ideas posts and blogs.
I find the attrs documentation (and Glyph's blog post about it) almost
unreadable because of the exalted language -- half the doc seems to be
*selling* the library more than *explaining* it. If this
I guess maybe if you overload the operators to return broken objects, maybe
then they would be different?
--
Ryan (ライアン)
Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else
http://refi64.com
On May 15, 2017 9:50 AM, "Serhiy Storchaka" wrote:
> On 15.05.17 16:00, Steven D'
On Mon, May 15, 2017 at 6:30 PM Guido van Rossum wrote:
> This should be worked into a PEP, instead of living on as a bunch of
python-ideas posts and blogs.
...
> Will someone please write a PEP?
If by "this" you mean adding to stdlib something like
@record
class Point:
x: int
y: int
o
Something broken like this?
import inspect
def cond():
if 'not cond' in inspect.stack()[1].code_context[0]:
return False
return True
if cond():
print('yes')
else:
print('no')
if not cond():
print('no')
else:
print('yes')
On 5/15/17, Ryan Gonzalez wrote:
> I gues
I expect that we will need someone with a really good sensibility for
Pythonic language/API design to lead the PEP writing.
On Mon, May 15, 2017 at 9:03 AM, אלעזר wrote:
> On Mon, May 15, 2017 at 6:30 PM Guido van Rossum wrote:
> > This should be worked into a PEP, instead of living on as a bun
On Mon, 15 May 2017 at 08:30 Guido van Rossum wrote:
> This should be worked into a PEP, instead of living on as a bunch of
> python-ideas posts and blogs.
>
> I find the attrs documentation (and Glyph's blog post about it) almost
> unreadable because of the exalted language -- half the doc seems
On Mon, May 15, 2017 at 9:50 AM, Brett Cannon wrote:
>
> On Mon, 15 May 2017 at 08:30 Guido van Rossum wrote:
>
>> This should be worked into a PEP, instead of living on as a bunch of
>> python-ideas posts and blogs.
>>
>> I find the attrs documentation (and Glyph's blog post about it) almost
>>
On 15.05.17 18:46, Ryan Gonzalez wrote:
I guess maybe if you overload the operators to return broken objects,
maybe then they would be different?
No. The compiler generates an equivalent bytecode for both cases.
___
Python-ideas mailing list
Python-i
On Mon, 15 May 2017 at 10:32 Guido van Rossum wrote:
> On Mon, May 15, 2017 at 9:50 AM, Brett Cannon wrote:
>
>>
>> On Mon, 15 May 2017 at 08:30 Guido van Rossum wrote:
>>
>>> This should be worked into a PEP, instead of living on as a bunch of
>>> python-ideas posts and blogs.
>>>
>>> I find t
17 matches
Mail list logo
