Re: [Python-Dev] Python 3.0.1
Just my 2 eurocents: I think version numbers communicate a couple of things. One thing the communicate is that if you go from x.y.0 to x.y.1 (or from x.y.34 to x.y.35 for that matter) you signify that this is a bug fix release, and that the risk of any of your stuff breaking is close to zero, unless you somehow where relying on what essentially was broken behavior. It's also correct that a .0 anywhere indicates that you should wait, and that a .1 indicated that this should be safer. Of course, you can end up where these two things clash. Where you need to make a major change that breaks something, but you at the same time don't want to flag "Yes, this will be as bugfree as you normally would expect from a .1 release." My opinion is that in that case, the first rule should win out. Don't make potentially incompatible changes in a minor version increase. So it seems to me here that a 3.0.1 bugfix release, and then a 3.1 with the API changes and C IO is at least the type of numbering I would expect. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
2009/1/31 "Martin v. Löwis" : > Notice that bdist_wininst doesn't really work in 3.0. So you likely > won't see many packages until 3.0.1 is released. Ah, that might be an issue :-) Can you point me at specifics (bug reports or test cases)? I could see if I can help in fixing things. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
Martin v. Löwis wrote: >> I can see how "svn resolved ." gets it right (now that I understand how >> the conflict is being produced and then fixed automatically by svnmerge, >> but not actually marked as resolved). >> >> I still don't understand how "svn revert ." can avoid losing the >> metadata changes unless svnmerge is told to modify the properties again >> after they have been reverted. Or am I misunderstanding SVN, and the >> revert command doesn't actually revert property changes? > > Oops, I meant "svn resolved ." all the time. When I wrote > "svn revert .", it was by mistake. Ah, in that case we now agree on the right way to do things :) With the explanation as to where the (spurious) conflict is coming from on the initial merge to the maintenance branch, I'm now happy that the only time the revert + regenerate metadata should ever be needed is if someone else checks in a backport between the time when I start a backport and when I go to check it in (which is pretty unlikely in practice). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
> Can you point me at specifics (bug reports or test cases)? I could see > if I can help in fixing things. See r69098. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.0.1/3.1.0 summary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 30, 2009, at 11:50 AM, Mark Dickinson wrote: On Fri, Jan 30, 2009 at 4:03 PM, Barry Warsaw wrote: To clarify: cruft that should have been removed 3.0 is fine to remove for 3.0.1, for some definition of "should have been". Just to double check, can I take this as a green light to continue with the cmp removal (http://bugs.python.org/issue1717) for 3.0.1? Yep, go ahead. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSYRVrHEjvBPtnXfVAQK9SQQAiJct3mWt/+ZIOkI7DDRoBdz8yFvrmbLX 6AnbW+owvnnlzB9QX5PyDfTaTJa5pLJuoiWYRb7vCzxH1daW9KuFvF9qnaYXUhiO TLkyaO/R40aarB79NkE6J8wyRjYRyMoZgz10/GzxWkQgvTg38ESeKh3b6YRyph0N uo18odqAGEs= =QDP8 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.0.1/3.1.0 summary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 30, 2009, at 1:56 PM, Brett Cannon wrote: On Fri, Jan 30, 2009 at 08:03, Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 30, 2009, at 12:53 AM, Martin v. Löwis wrote: 1. Barry, who is the release manager for 3.0.1, does not like the idea of the cruft that is being proposed removed from 3.0.1. I don't think he actually said that (in fact, I think he said the opposite). It would be good if he clarified, though. To clarify: cruft that should have been removed 3.0 is fine to remove for 3.0.1, for some definition of "should have been". Great! Then should we start planning for 3.0.1 in terms of release dates and what to have in the release so we can get this out the door quickly? How about Friday February 13? If that works for everybody, I'll tag the release on my evening of the 12th so that Martin and other east-of- mes will be able to do their thing by my morning of the 13th. I've added this to the Python release calendar. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSYRWRXEjvBPtnXfVAQI/+wQAm95gTGojwZXSU8qfBtNXgD/lALMi1ncK ctEOhueAwnRBCnFg9UyqgX8dcmogWL7M+pikpOjVeH/TUiArXDIlcY+glkVzgMo4 7DizBu5b6SpJq8h1iTvniqsT7SDZeE1S1FhPBIi5cIja78fD2F5Ny5OGV2K377TP GhjZxX8gepw= =OPBI -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.0.1/3.1.0 summary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 30, 2009, at 3:07 PM, Benjamin Peterson wrote: On Fri, Jan 30, 2009 at 1:56 PM, Brett Cannon wrote: Great! Then should we start planning for 3.0.1 in terms of release dates and what to have in the release so we can get this out the door quickly? I think considering there's only two release blockers we should plan for about a week or two from now. I'm not sure if we want to do a release candidate; we didn't for 2.6.1, but maybe it would be good to see if the community can find any other horrible problems. Let's JFDI. No release candidate. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSYRWa3EjvBPtnXfVAQIVpgQAo1tb/RJ81WFBJHH1GhdhtKagrB5p9MSl U+GfnLx9mEtqBqQ9rnXaQQaPpJjvNmXc10K+8oDdwCJHSX3k66JbK4U4BOBqWgc3 0PTrdIn5/4PqfexT3HWNmH/mZCZXb36HDcE6fxW5CWxuxHbNLypBY7P52XgVJIBW hqMBQVVNxgw= =Zq3w -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Subversion upgraded to 1.5
I have now upgraded subversion to 1.5.1 on svn.python.org. Please let me know if you encounter problems. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: Partial function application 'from the right'
Begin forwarded message: From: Ludvig Ericson Date: January 31, 2009 16:43:50 GMT+01:00 To: Alexander Belopolsky Subject: Re: [Python-Dev] Partial function application 'from the right' On Jan 31, 2009, at 04:02, Alexander Belopolsky wrote: On Fri, Jan 30, 2009 at 7:42 PM, Antoine Pitrou wrote: .. If one writes X = partial.skip, it looks quite nice: split_one = partial(str.split, X, 1) Or even _ = partial.skip split_one = partial(str.split, _, 1) Or even … = partial.skip split_one = partial(str.split, …, 1) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
2009/1/31 "Martin v. Löwis" : >> Can you point me at specifics (bug reports or test cases)? I could see >> if I can help in fixing things. > > See r69098. Thanks. So 3.0.1 and later will be fine - my apologies, I hadn't quite understood what you said. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 374 (DVCS) now in reST
a Mercurial "super client" http://blog.red-bean.com/sussman/?p=116 Figured I would link to this for the people doing the HG investigation ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
Guido van Rossum schrieb: > Frankly, I don't really believe the users for whom those rules were > created are using 3.0 yet. Instead, I expect there to be two types of > users: people in the educational business who don't have a lot of > bridges to burn and are eager to use the new features; and developers > of serious Python software (e.g. Twisted) who are trying to figure out > how to port their code to 3.0. The first group isn't affected by the > changes we're considering here (e.g. removing cmp or some obscure > functions from the operator module). The latter group *may* be > affected, simply because they may have some pre-3.0 code using old > features that (by accident) still works under 3.0. > > On the one hand I understand that those folks want a stable target. On > the other hand I think they would prefer to find out sooner rather > than later they're using stuff they shouldn't be using any more. It's > a delicate balance for sure, and I certainly don't want to open the > floodgates here, or rebrand 3.1 as 3.0.1 or anything like that. But I > really don't believe that the strictest interpretation of "no new > features" will benefit us for 3.0.1. Perhaps we should decide when to > go back to a more strict interpretation of the rules based on the > uptake of Python 3 compared to Python 2. +1. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
On Fri, Jan 30, 2009 at 7:38 PM, Calvin Spealman wrote: > I am just replying to the end of this thread to throw in a reminder > about my partial.skip patch, which allows the following usage: > > split_one = partial(str.split, partial.skip, 1) > > Not looking to say "mine is better", but if the idea is being given > merit, I like the skipping arguments method better than just the > "right partial", which I think is confusing combined with keyword and > optional arguments. And, this patch already exists. Could it be > re-evaluated? +1 but I don't know where the patch is. -- Cheers, Leif ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.0.1/3.1.0 summary
> How about Friday February 13? Fine with me (although next Friday (Feb 6) would work slightly better) Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Removing tp_compare?
Here's a question (actually, three questions) for python-dev that came up in the issue 1717 (removing cmp) discussion. Once the cmp removal is complete, the type object's tp_compare slot will no longer be used. The current plan is to rename it to tp_reserved, change its type to (void *), and raise TypeError when initializing any type that attempts to put something nonzero into that slot. But another possibility would be to remove it entirely. So... Questions: (1) Is it desirable to remove tp_compare entirely, instead of just renaming it? (2) If so, for which Python version should that removal take place? 3.0.1? 3.1.0? 4.0? and the all-important bikeshed question: (3) In the meantime, what should the renamed slot be called? tp_reserved? In the issue 1717 discussion, Raymond suggested tp_deprecated_compare. Any thoughts? My own opinion is that it really doesn't matter that much if the slot is left in; it's just a little annoying to have such backwards-compatibility baggage already present in the shiny new 3.0 series. A little like finding a big scratch on your brand-new bright yellow Hummer H3. Or not. N.B. The same questions apply to nb_reserved (which used to be nb_long) in the PyNumberMethods structure. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing tp_compare?
On Sat, Jan 31, 2009 at 3:07 PM, Mark Dickinson wrote: > Once the cmp removal is complete, the type object's tp_compare > slot will no longer be used. The current plan is to rename it to > tp_reserved, change its type to (void *), and raise TypeError when > initializing any type that attempts to put something nonzero into > that slot. But another possibility would be to remove it entirely. > So... I think we should keep as tp_reserved in 3.0.1. In 3.1, as I mentioned in the issue, I'd like to reuse it as a slot for __bytes__. Confusion could be avoided still raising a TypeError for a non-null tp_reserved slot unless the type has Py_TPFLAGS_HAVE_BYTES flag set. After a while, we could just make it default. > > N.B. The same questions apply to nb_reserved (which used > to be nb_long) in the PyNumberMethods structure. IMO, it's fine to keep them around, just in case. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing tp_compare?
> (1) Is it desirable to remove tp_compare entirely, instead of > just renaming it? No. > (2) If so, for which Python version should that removal take place? > 3.0.1? 3.1.0? 4.0? If it is removed, it definitely shouldn't be removed in 3.0.1; that would be a binary-incompatible change. > (3) In the meantime, what should the renamed slot be called? > tp_reserved? In the issue 1717 discussion, Raymond suggested > tp_deprecated_compare. tp_reserved sounds fine. In 3.0.1, filling it with a function pointer should give no error, since that would be a binary-incompatible change. > Any thoughts? My own opinion is that it really doesn't matter > that much if the slot is left in; it's just a little annoying to have > such backwards-compatibility baggage already present in > the shiny new 3.0 series. A little like finding a big scratch > on your brand-new bright yellow Hummer H3. Or not. Well, there is also PY_SSIZE_T_CLEAN. I asked before 3.0, and was told that it was too late to remove it. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Subversion upgraded to 1.5
I'm seeing the following when trying to svn commit: Transmitting file data ...Read from remote host svn.python.org: Operation timed out svn: Commit failed (details follow): svn: Connection closed unexpectedly ... That was with subversion 1.4.4; copying my changes to a different host with subversion 1.5.1 has the same result. svn update works fine on both hosts in the same sandbox i'm trying to commit from. fwiw, they are both connecting to svn.python.org using IPv6 but that should be irrelevant to svn+ssh as the tcp6 ssh connection works fine. any ideas? -Greg On Sat, Jan 31, 2009 at 7:47 AM, "Martin v. Löwis" wrote: > I have now upgraded subversion to 1.5.1 on svn.python.org. > > Please let me know if you encounter problems. > > Regards, > Martin > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing tp_compare?
Martin v. Löwis v.loewis.de> writes: > > > Any thoughts? My own opinion is that it really doesn't matter > > that much if the slot is left in; it's just a little annoying to have > > such backwards-compatibility baggage already present in > > the shiny new 3.0 series. A little like finding a big scratch > > on your brand-new bright yellow Hummer H3. Or not. > > Well, there is also PY_SSIZE_T_CLEAN. I asked before 3.0, and was told > that it was too late to remove it. Are all modules PY_SSIZE_T_CLEAN? Last I looked, _ssl.c still used int or long in various places instead of Py_ssize_t. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing tp_compare?
> Are all modules PY_SSIZE_T_CLEAN? Last I looked, _ssl.c still used int or long > in various places instead of Py_ssize_t. That's probably still the case. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Subversion upgraded to 1.5
> any ideas? Assuming you reported this right after it happened - sorry, no. I can't find anything relevant in the log files (although a precise time of failure would have helped). Does a plain "ssh python...@svn.python.org" still work? What path did you try to check into? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing tp_compare?
Antoine Pitrou wrote: > Martin v. Löwis v.loewis.de> writes: > > > > > Any thoughts? My own opinion is that it really doesn't matter > > > that much if the slot is left in; it's just a little annoying to have > > > such backwards-compatibility baggage already present in > > > the shiny new 3.0 series. A little like finding a big scratch > > > on your brand-new bright yellow Hummer H3. Or not. > > > > Well, there is also PY_SSIZE_T_CLEAN. I asked before 3.0, and was told > > that it was too late to remove it. > > Are all modules PY_SSIZE_T_CLEAN? Last I looked, _ssl.c still used int or long > in various places instead of Py_ssize_t. _ssl.c does indeed use int or long in various places. I'm not sure how far it can go with Py_ssize_t -- is OpenSSL 64-bit clean? Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing tp_compare?
Bill Janssen parc.com> writes: > > is OpenSSL 64-bit clean? I'm afraid I'm completely incompetent on this subject...! Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Subversion upgraded to 1.5
I'm just trying to commit the following to trunk: SendingLib/test/test_socket.py SendingMisc/NEWS SendingModules/socketmodule.c Transmitting file data ... I have another svn commit attempt which appesrs to be hanging and destined to timeout running right now. ssh -v python...@svn.python.org works fine. -gps On Sat, Jan 31, 2009 at 2:04 PM, "Martin v. Löwis" wrote: > > any ideas? > > Assuming you reported this right after it happened - sorry, no. > I can't find anything relevant in the log files (although a > precise time of failure would have helped). > > Does a plain "ssh python...@svn.python.org" still work? > > What path did you try to check into? > > Regards, > Martin > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Subversion upgraded to 1.5
fwiw, I just turned off IPv6 and it worked fine. That makes no sense to me given that the ssh connection worked fine either way. Does svn itself try and log source addresses somehow when using svn+ssh and balk on IPv6 addrs? Weird. regardless, this is presumably not related to your subversion upgrade. I don't think I've done any commits from these hosts since I got IPv6 connectivity, only updates. -gps On Sat, Jan 31, 2009 at 2:49 PM, Gregory P. Smith wrote: > I'm just trying to commit the following to trunk: > > SendingLib/test/test_socket.py > SendingMisc/NEWS > SendingModules/socketmodule.c > Transmitting file data ... > > I have another svn commit attempt which appesrs to be hanging and destined > to timeout running right now. > > ssh -v python...@svn.python.org works fine. > > -gps > > > On Sat, Jan 31, 2009 at 2:04 PM, "Martin v. Löwis" wrote: > >> > any ideas? >> >> Assuming you reported this right after it happened - sorry, no. >> I can't find anything relevant in the log files (although a >> precise time of failure would have helped). >> >> Does a plain "ssh python...@svn.python.org" still work? >> >> What path did you try to check into? >> >> Regards, >> Martin >> > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Subversion upgraded to 1.5
> fwiw, I just turned off IPv6 and it worked fine. That makes no sense to > me given that the ssh connection worked fine either way. Does svn > itself try and log source addresses somehow when using svn+ssh and balk > on IPv6 addrs? No. subversion ignores the network layer. > Weird. regardless, this is presumably not related to your subversion > upgrade. I don't think I've done any commits from these hosts since I > got IPv6 connectivity, only updates. That alone can't be the problem. I tried to commit something over IPv6, and it worked just fine. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Subversion upgraded to 1.5
> Weird. regardless, this is presumably not related to your subversion > upgrade. I don't think I've done any commits from these hosts since I > got IPv6 connectivity, only updates. I got some messages in kern.log which might be relevant Jan 31 23:55:36 dinsdale kernel: IPv6: sending pkt_too_big to self Jan 31 23:55:36 dinsdale kernel: IPv6: sending pkt_too_big to self Feb 1 00:02:57 dinsdale kernel: IPv6: sending pkt_too_big to self Of course, it is five minutes off your connect attempt (IIUC), so it also might be irrelevant. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing tp_compare?
> _ssl.c does indeed use int or long in various places. I'm not sure how > far it can go with Py_ssize_t -- is OpenSSL 64-bit clean? That's irrelevant for the issue at hand (PY_SSIZE_T_CLEAN). What matters is that s# etc converters output Py_ssize_t (unless in deprecated compatibility mode); if you think you then need to truncate to 32 bits, there should be explicit code that tests for truncation and raises a Python exception if appropriate. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Should execv() call _run_exitfuncs()? If not, should _run_exitfuncs() be private?
As a hobby I've been writing a debugger. One of the commands,"restart", works by calling an execv(). You may need to do this when the program you are debugging is threaded or when one needs to ensure that all program state is reinitialized. Recently, I added remote debugging via TCP sockets and noticed that execv() in Python doesn't arrange exit hooks to get called. Should it? One can run _run_exitfuncs() from the atexit module, but the leading underscore of the function call suggests it is private. Should it be? Thanks ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Partial function application 'from the right'
Ludvig Ericson wrote: > Begin forwarded message: >> From: Ludvig Ericson >> Or even >> >> … = partial.skip >> split_one = partial(str.split, …, 1) That won't work: >>> ... = 1 File "", line 1 SyntaxError: can't assign to Ellipsis Like None/True/False, "..." is a constant that can't be modified (you can assign to the *name* Ellipsis, but the "..." syntax will always refer to the specific object). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should execv() call _run_exitfuncs()? If not, should _run_exitfuncs() be private?
On Sat, Jan 31, 2009 at 4:55 PM, Rocky Bernstein wrote: > As a hobby I've been writing a debugger. One of the > commands,"restart", works by calling an execv(). You may need to do > this when > the program you are debugging is threaded or when one needs to ensure > that all program state is reinitialized. > > Recently, I added remote debugging via TCP sockets and noticed that > execv() in Python doesn't arrange exit hooks to get called. Should it? > > One can run _run_exitfuncs() from the atexit module, but the leading > underscore of the function call suggests it is private. Should it be? Depending on the use for the exit function you might or might not want it run at the occasion of exec*(). E.g. I imagine that in a typical fork() + exec*() scenario, calling the exit functions in the child process would be a mistake. So I don't think the hooks should be called by default. However you are welcome to call the function (leading underscore and all) if it helps in your case. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should execv() call _run_exitfuncs()? If not, should _run_exitfuncs() be private?
Rocky Bernstein wrote: > As a hobby I've been writing a debugger. One of the > commands,"restart", works by calling an execv(). You may need to do > this when > the program you are debugging is threaded or when one needs to ensure > that all program state is reinitialized. > > Recently, I added remote debugging via TCP sockets and noticed that > execv() in Python doesn't arrange exit hooks to get called. Should it? > > One can run _run_exitfuncs() from the atexit module, but the leading > underscore of the function call suggests it is private. Should it be? One of the advantages in Python handling 'private' APIs by convention rather than having it enforced by the compiler is that for some applications (like debuggers), a higher degree of coupling is more appropriate than sticking strictly to the public, guaranteed stable API. So I'd say call the private API anyway. While in theory it *could* change, it probably won't, and the use case is too esoteric to justify the overhead of making it public. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
