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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4