[Python-Dev] Python-Dev Digest, Vol 149, Issue 38
Rajneesh N. Shetty
shettyrajneesh at yahoo.com.au
Mon Dec 21 12:51:21 EST 2015
hello everybody, I am new to this group. Always knew that you were good for a long time, but never really used your technology as such, because my father who passed away recently never wanted me to own a computer in his lifetime. He relented in 2003-04 (cannot remember exactly), due to my pestering him (he was a mechanical+electrical, village boy by background (farmers)) , but he bought me a HP Pavilion with two Intel CPU's (not dual-core) running MS Media Centre edition (full NTFS implemention was only released in this version & first in India). I took it to Australia with me & finally gave it away after it refused to run certain versions of Linux. Attached is my profile & I can assure you I will need lots of help to familiarise myself with your engine.
regards,
rajneesh
tel :+61402350315
weblog : www.vishagotra.wordpress.com
www.rns-thoughts.blogspot.com
--------------------------------------------
On Tue, 22/12/15, python-dev-request at python.org <python-dev-request at python.org> wrote:
Subject: Python-Dev Digest, Vol 149, Issue 38
To: python-dev at python.org
Received: Tuesday, 22 December, 2015, 4:00 AM
Send Python-Dev mailing list
submissions to
python-dev at python.org
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.python.org/mailman/listinfo/python-dev
or, via email, send a message with subject or body 'help'
to
python-dev-request at python.org
You can reach the person managing the list at
python-dev-owner at python.org
When replying, please edit your Subject line so it is more
specific
than "Re: Contents of Python-Dev digest..."
Today's Topics:
1. Re: New poll about a macro for safe
reference replacing
(Nick Coghlan)
2. Re: Change the repr for
datetime.timedelta (was Re:
Asynchronous context manager in a
typical network server) (Random832)
3. Re: Change the repr for
datetime.timedelta (was Re:
Asynchronous context manager in a
typical network server)
(Guido van Rossum)
----------------------------------------------------------------------
Message: 1
Date: Tue, 22 Dec 2015 01:37:48 +1000
From: Nick Coghlan <ncoghlan at gmail.com>
To: Serhiy Storchaka <storchaka at gmail.com>
Cc: "python-dev at python.org"
<python-dev at python.org>
Subject: Re: [Python-Dev] New poll about a macro for safe
reference
replacing
Message-ID:
<CADiSq7c5hB-G8mox1aLCvcZtBR7rq41Fmz8aAUf=1w6k5GT2WQ at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On 21 December 2015 at 23:46, Serhiy Storchaka <storchaka at gmail.com>
wrote:
> On 16.12.15 16:12, Serhiy Storchaka wrote:
>>
>> Please put your vote (a floating number from -1 to
1 including) for
>> every of proposed name. You also can propose new
name.
>
>
> Thank you all for your votes.
>
> Results of the poll:
>
> Py_SETREF: +5 = +5 (Victor, Steve, Yury, Brett,
Nick) +0 (Ryan, Martin)
>
> Py_REPLACE_REF: +2.5 = +2.5 (Ryan, Victor, Steve,
Martin) -0 (Nick)
>
> Py_REPLACE: +0 = +1 (Martin) -1 (Ryan) +0 (Nick)
>
> Py_RESET: 0 = +1 (Ryan) -1 (Martin)
>
> Py_DECREF_REPLACE: -2 = +1 (Ryan, Martin) -3 (Victor,
Steve, Nick)
>
> Py_SET_POINTER, Py_SET_ATTR: -5 (Ryan, Victor, Steve,
Martin, Nick)
>
> Therefore Py_SETREF is the winner.
>
> But I want also to remember objections against it
formulated in previous
> discussion.
>
> 1) By analogy with Py_INCREF and Py_DECREF that
increment and decrement the
> reference counter of the object, Py_SETREF looks as it
*sets* the reference
> counter of the object.
>
> 2) By analogy with PyList_SET_ITEM, PyTuple_SET_ITEM,
PyCell_SET, etc, it is
> not expected that Py_SETREF decrement the refcounter of
the old value before
> overwriting it.
Avoiding those misleading associations is a good argument in
favour of
Py_REPLACE over Py_SETREF - they didn't occur to me before
casting my
votes, and I can definitely see them causing confusion in
the future.
So perhaps the combination that makes the most sense is to
add
Py_REPLACE (uses Py_DECREF on destination) & Py_XREPLACE
(uses
Py_XDECREF on destination) to the existing Py_CLEAR?
Regards,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane,
Australia
------------------------------
Message: 2
Date: Mon, 21 Dec 2015 10:39:09 -0500
From: Random832 <random832 at fastmail.com>
To: python-dev at python.org
Subject: Re: [Python-Dev] Change the repr for
datetime.timedelta (was
Re: Asynchronous context manager in a
typical network server)
Message-ID: <87h9jbdd5u.fsf at fastmail.com>
Content-Type: text/plain
Guido van Rossum <guido at python.org>
writes:
> I'm sure that one often catches people by surprise.
However, I don't
> think we can fix that one without also fixing the
values of the
> attributes -- in that example days is -1 and seconds is
86340 (which
> will *also* catch people by surprise). And changing
that would be
> much, much harder for backwards compatibility reasons--
we'd have to
> set days to 0 and seconds to -60, and suddenly we have
a much murkier
> invariant, instead of the crisp
>
> 0 <= microseconds < 1000000
> 0 <= seconds < 60
I don't really see it as murky:
0 <= abs(microseconds) < 1000000
0 <= abs(seconds) < 60
(days <= 0) == (seconds <= 0) == (microseconds <=
0)
(days >= 0) == (seconds >= 0) == (microseconds >=
0)
The latter are more easily phrased in english as "all
nonzero
attributes have the same sign". I think the current
behavior is
rather as if -1.1 were represented as "-2+.9". The
attributes
probably can't be fixed without breaking backwards
compatibility, though. How about "-timedelta(0, 60)"?
------------------------------
Message: 3
Date: Mon, 21 Dec 2015 07:47:03 -0800
From: Guido van Rossum <guido at python.org>
To: Random832 <random832 at fastmail.com>
Cc: Python-Dev <python-dev at python.org>
Subject: Re: [Python-Dev] Change the repr for
datetime.timedelta (was
Re: Asynchronous context manager in a
typical network server)
Message-ID:
<CAP7+vJKRKCE7zRKXMKN-bchg6+9kE=GCeKPRskkKv9Yha0hMNA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
We're now thoroughly in python-ideas land.
On Mon, Dec 21, 2015 at 7:39 AM, Random832 <random832 at fastmail.com>
wrote:
> Guido van Rossum <guido at python.org>
writes:
> > I'm sure that one often catches people by
surprise. However, I don't
> > think we can fix that one without also fixing the
values of the
> > attributes -- in that example days is -1 and
seconds is 86340 (which
> > will *also* catch people by surprise). And
changing that would be
> > much, much harder for backwards compatibility
reasons-- we'd have to
> > set days to 0 and seconds to -60, and suddenly we
have a much murkier
> > invariant, instead of the crisp
> >
> > 0 <= microseconds < 1000000
> > 0 <= seconds < 60
>
> I don't really see it as murky:
>
> 0 <= abs(microseconds) < 1000000
> 0 <= abs(seconds) < 60
> (days <= 0) == (seconds <= 0) == (microseconds
<= 0)
> (days >= 0) == (seconds >= 0) == (microseconds
>= 0)
>
> The latter are more easily phrased in english as "all
nonzero
> attributes have the same sign". I think the
current behavior is
> rather as if -1.1 were represented as "-2+.9".
The attributes
> probably can't be fixed without breaking backwards
> compatibility, though. How about "-timedelta(0,
60)"?
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20151221/2e75f815/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev
------------------------------
End of Python-Dev Digest, Vol 149, Issue 38
*******************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rajneesh.pdf
Type: application/pdf
Size: 278094 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20151221/e5442261/attachment-0001.pdf>
More information about the Python-Dev
mailing list