[Python-Dev] http://bugs.python.org/issue3628
I'm getting an error similar to that in http://bugs.python.org/issue3628 when I try to run python2.6 and cherrypy 3.1.1. I'm too new to see any connection between the symptom and the cure described in the above issue... I'd guess that somehow threads imply an extra parameter? It also seems that the SetDaemon call simply does what the replacement code does, so I don't understand how the fix fixes anything, much less how it fixes a parameter count in a seemingly unrelated function. In any case, the issue is against 3.0, where it claims to be fixed. I don't know enough about the tracker to find if it was fixed in 2.6 concurrently, but the symptom appears there. I tried hacking all the references I could find to XXX.SetDaemon(True) to XXX.daemon = True but it didn't seem to help. So can you help? -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ 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] [patch 0/8] [RFC] cross compiling python 3.0
Hi Antoine, [sorry for the double post, the mails didn't show up in the archive and my procmail had missing slash at the end of the rule...] > Thanks for those patches, but please post them to the issue tracker instead > (http://bugs.python.org/). If each patch is for a distinct purpose, then open > separate issues, otherwise please merge the patches into a single one. Yup, will do. I suspect that some of the design decisions need discussions; should that also take place in the issue tracker, or here on the mailing list? rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ 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] [patch 0/8] [RFC] cross compiling python 3.0
On Fri, Jan 9, 2009 at 9:24 AM, Robert Schwebel wrote: > > Yup, will do. > > I suspect that some of the design decisions need discussions; should > that also take place in the issue tracker, or here on the mailing list? For the distutils part, you can use the distutils mailing list if you wish, http://www.python.org/community/sigs/current/distutils-sig/ Regards Tarek ___ 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] http://bugs.python.org/issue3628
Hello, On Fri, Jan 9, 2009 at 09:07, Glenn Linderman wrote: > I'm getting an error similar to that in http://bugs.python.org/issue3628 > when I try to run python2.6 and cherrypy 3.1.1. Please use the issue tracker for this. For help with python, you should ask on the comp.lang.python newsgroup. Be prepared to provide the complete error output: I fail to see how a crash in IDLE 3.0b3 would be similar to some problem with cherrypy! -- Amaury Forgeot d'Arc ___ 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] I would like an svn account
On Sun, 04 Jan 2009 18:50:09 +0900, Stephen J. Turnbull wrote: > "Martin v. Löwis" writes: > > > If "switching to a modern DVCS" means that users now need to start > > compiling their VCS before they can check out Python, > > It doesn't mean that. All of the DVCS contenders have Windows and Mac > OS installers (usually from 3rd parties, but working closely with the > core). I'll notice that git-win32 is totally bad for any serious Windows developers. At least 4 months ago which is the last time I tried it. You'll have a very hard time persauding the experienced Windows developers in this list that git-win32 is a good thing to use. -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ 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] compiling python2.5 on linux under wine
On Thu, Jan 8, 2009 at 9:07 PM, "Martin v. Löwis" wrote: >> i'd just ... much rather be completely independent of proprietary >> software when it comes to building free software. > > I guess my question is then: why do you want to use Windows in the > first place? ha ha :) the same question was asked when i started the nt domains reverse-engineering for samba, in 1996. the answer is: i don't. but there are a lot of users and developers who feel that they don't have a choice. or haven't been given one. so if it's possible for me, as one of the "under 1% of computer users i.e. linux" to compile stuff that will work on the "over 95% of computers used by everyone else i.e. windows" _and_ i get to stick to free software principles, that's gotta be good. take pywebkit-gtk as an example. the first-level (and some of the second-level) dependencies for pywebkit-gtk are roughly as follows: * libstdc++ * cairo, pango, gdk, fontconfig, gtk * libxml2 (which is dodgy) * libxslt1 (which is so dodgy and dependent on incompatible versions of libxml2 it can't be compiled on win32) * libicu38 * libcurl * libssl * webkit * python2.5 * python-gobect * python-gtk that's a *big* ing list that comes in at a whopping 40mb of _binaries_. webkit itself comes in at 10mb alone. libicu38 fails _miserably_ to cross-compile with mingw32. i was damn lucky to have beaten it into submission: it took two days and i couldn't run any of the tests, but actually managed to get at least some .libs, .dlls and .a's out of the mess. libxslt1 and libxml2 have compile errors in mutually incompatible versions on win32, plus, unfortunately, the versions that _do_ compile correctly (really old versions like libxslt-1.12 + libxml2-18 or something) are not the ones that can be used on webkit! i had to get the source code for gcc (4.4) because when linking webkit against the MSVC-compiled libicu38 gcc actually segfaulted (!). and that was tracked down to exception handling across process / thread boundaries in libstdc++-6 which had only literally been fixed/patched a few days before i started the monster-compile-process. i tried hunting down python-gobject and python-gtk for win32, but there is a dependency needed before you get to that: python25.lib. as i mentioned previously i tried hunting down a .lib for python25 but of course that would be useless unless i also have a libtool-compiled .a so there wasn't any point. so, all the hard work that i did cross-compiling up webkit for win32 was completely wasted because python itself could not be compiled on linux for a win32 platform. hence my interest in making sure that it can be. _then_ i can go back and revisit the monster compile process and finally come up with the goods, on win32, on the gobject-based DOM-model manipulation stuff i've added to pywebkit-gtk. i've got linux covered, i've got macosx covered. win32 is the last one. l. ___ 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] I would like an svn account
On Fri, Jan 9, 2009 at 1:48 AM, Giovanni Bajo wrote: > On Sun, 04 Jan 2009 18:50:09 +0900, Stephen J. Turnbull wrote: > >> "Martin v. Löwis" writes: >> >> > If "switching to a modern DVCS" means that users now need to start >> > compiling their VCS before they can check out Python, >> >> It doesn't mean that. All of the DVCS contenders have Windows and Mac >> OS installers (usually from 3rd parties, but working closely with the >> core). > > I'll notice that git-win32 is totally bad for any serious Windows > developers. At least 4 months ago which is the last time I tried it. > You'll have a very hard time persauding the experienced Windows > developers in this list that git-win32 is a good thing to use. Do you mean this one: http://code.google.com/p/msysgit/ or is git-win32 something else? Ondrej ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (01/02/09 - 01/09/09)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2304 open (+65) / 14418 closed (+24) / 16722 total (+89)
Open issues with patches: 797
Average duration of open issues: 698 days.
Median duration of open issues: 1 days.
Open Issues Breakdown
open 2279 (+65)
pending25 ( +0)
Issues Created Or Reopened (90)
___
wsgiref package totally broken 01/03/09
http://bugs.python.org/issue4718reopened pitrou
patch
invalid reST markup in several documents 01/02/09
CLOSED http://bugs.python.org/issue4811created gagenellina
patch
Junk in the decimals namespace 01/02/09
CLOSED http://bugs.python.org/issue4812created rhettinger
On OS-X the directories searched by setup.py for Tk are in the w 01/02/09
http://bugs.python.org/issue4813created MLModel
ftplib does not honour "timeout" parameter for active data conne 01/03/09
http://bugs.python.org/issue4814created giampaolo.rodola
patch
idle 3.1a1 utf8 01/03/09
http://bugs.python.org/issue4815created geon
patch, needs review
Patch of itertools.{combinations,permutations} for empty combina 01/03/09
CLOSED http://bugs.python.org/issue4816created TFinley
patch
PyOS_GetLastModificationTime is unused 01/03/09
CLOSED http://bugs.python.org/issue4817created eckhardt
patch
Patch for thread-support in md5module.c 01/03/09
http://bugs.python.org/issue4818created ebfe
patch
Misc/cheatsheet needs updating 01/03/09
http://bugs.python.org/issue4819created marketdickinson
ctypes.util.find_library incorrectly documented 01/03/09
http://bugs.python.org/issue4820created beazley
Patches for thread-support in built-in SHA modules 01/03/09
http://bugs.python.org/issue4821created ebfe
patch
Fix indentation in memoryobject.c01/03/09
CLOSED http://bugs.python.org/issue4822created pitrou
patch
idle height and place01/03/09
CLOSED http://bugs.python.org/issue4823created geon
test_cmd_line failure on Mac OS X for py3k 01/03/09
CLOSED http://bugs.python.org/issue4824created skip.montanaro
TypeError with complex.real() and complex.imag() 01/04/09
CLOSED http://bugs.python.org/issue4825created MagnetoHydroDynamics
exec() docstring bug about file objects 01/04/09
CLOSED http://bugs.python.org/issue4826created xverify
optparse: Callback example 1 is confusing01/04/09
http://bugs.python.org/issue4827created jkankiewicz
patch suggestion for webbrowser 01/04/09
http://bugs.python.org/issue4828created Yinon
patch
confusing error for file("foo", "w++")
Re: [Python-Dev] http://bugs.python.org/issue3628
Glenn Linderman wrote: > I'm getting an error similar to that in > http://bugs.python.org/issue3628 > when I try to run python2.6 and cherrypy 3.1.1. > > I'm too new to see any connection between the symptom and the cure > described in the above issue... I'd guess that somehow threads imply an > extra parameter? > > It also seems that the SetDaemon call simply does what the replacement > code does, so I don't understand how the fix fixes anything, much less > how it fixes a parameter count in a seemingly unrelated function. > > In any case, the issue is against 3.0, where it claims to be fixed. I > don't know enough about the tracker to find if it was fixed in 2.6 > concurrently, but the symptom appears there. > > I tried hacking all the references I could find to XXX.SetDaemon(True) > to XXX.daemon = True but it didn't seem to help. Fixed in http://www.cherrypy.org/changeset/2096. Robert Brewer fuman...@aminus.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
[Python-Dev] new pep index
This is just a note that the PEP index (PEP 0) is now automatically generated, so you need not bother to update any more. -- 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] new pep index
On Fri, Jan 9, 2009 at 09:50, Benjamin Peterson wrote: > This is just a note that the PEP index (PEP 0) is now automatically > generated, so you need not bother to update any more. Thanks for getting this done! -Brett ___ 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] exec documentation
in 2.6 and before execfile is listed in builtin functions, and is not marked deprecated, and exec is in the simple statements, and is not marked deprecated. in 3.0 execfile is not listed in builtin functions, exec is. exec is not listed in simple statements. I guess this is an intended 3.0 change, but is this the proper way to document it? What I was really trying to figure out is how I could specify the encoding of a file to be execfile'd in 2.6... but didn't find it so thought I'd try 3.0 to see if it would assume UTF-8, but had forgotten execfile doesn't exist in 3.0 (if I knew it; I'm new here). -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ 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] Meet your next release manager: Benjamin Peterson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Now that Python 2.6 and 3.0 are in maintenance mode, it's time to start thinking about Python 2.7 and 3.1. While I've enjoyed my redux service as your release manager for 2.6 and 3.0, I believe it's time to get some new blood in here. To that end, I'm happy to say that Benjamin Peterson will be the release manager for Python 2.7 and 3.1. I will be mentoring him through the process, but it'll be his ball of snake wax. Please join me in helping him make the 2.7 and 3.1 releases as great as 2.6 and 3.0! I will continue to RM 2.6 and 3.0, and I want to start planning for a 3.0.1 release this month. Cheers Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSWfObXEjvBPtnXfVAQI8IgQAqIcJf5SogGu7uYVU7esbZ7osXmYhy0Nx m2hr1r+1/ohzfTlty0VyfwbKsFjoGAjn9X5feMNpFQ/5Kwv3JO3s217rrqCgTeeH CPhefuQAMeZ7lZs/hg/uzK48L2r/KdFMCD0Xuj7ewqT0xbtopR2P9OgLiwj8p8H8 //OgcOxFAeE= =t1tg -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] exec documentation
Glenn Linderman wrote: in 2.6 and before execfile is listed in builtin functions, and is not marked deprecated, and exec is in the simple statements, and is not marked deprecated. Because they are not going away in 2.7. in 3.0 execfile is not listed in builtin functions, exec is. exec is not listed in simple statements. All as appropriate. I guess this is an intended 3.0 change, but is this the proper way to document it? This is really a python-list/c.l.p question: Anyway... What's new 3.0: "exec() is no longer a keyword; it remains as a function."..."Removed execfile(). Instead of execfile(fn) use exec(open(fn).read()). " ...Yes. What I was really trying to figure out is how I could specify the encoding of a file to be execfile'd in 2.6... but didn't find it so thought I'd try 3.0 to see if it would assume UTF-8, but had forgotten execfile doesn't exist in 3.0 (if I knew it; I'm new here). Ditto - how to use current 3.0, not how to develop 3.0.1/3.1. Anyway, specify encoding in the open function. tjr ___ 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] exec documentation
On approximately 1/9/2009 3:40 PM, came the following characters from the keyboard of Terry Reedy: Glenn Linderman wrote: in 2.6 and before execfile is listed in builtin functions, and is not marked deprecated, and exec is in the simple statements, and is not marked deprecated. Because they are not going away in 2.7. Ah, that's the missing piece! I keep thinking 2.5, 2.6, 3.0, and forgetting that someone might make a 2.7 :) I bet I wasn't the first one to be confused by this, nor am I likely to be the last. in 3.0 execfile is not listed in builtin functions, exec is. exec is not listed in simple statements. All as appropriate. Sure, given a 2.7 I guess this is an intended 3.0 change, but is this the proper way to document it? This is really a python-list/c.l.p question: Anyway... What's new 3.0: "exec() is no longer a keyword; it remains as a function."..."Removed execfile(). Instead of execfile(fn) use exec(open(fn).read()). " ...Yes. What I was really trying to figure out is how I could specify the encoding of a file to be execfile'd in 2.6... but didn't find it so thought I'd try 3.0 to see if it would assume UTF-8, but had forgotten execfile doesn't exist in 3.0 (if I knew it; I'm new here). Ditto - how to use current 3.0, not how to develop 3.0.1/3.1. Anyway, specify encoding in the open function. execfile( "file.py" ) Where is the open function? I have it working under 3.0, not sure how to specify the encoding for 2.6, though, and this question is now off-topic for Python-Dev. -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ 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] exec documentation
Glenn Linderman wrote: > On approximately 1/9/2009 3:40 PM, came the following characters from > the keyboard of Terry Reedy: >> Glenn Linderman wrote: >>> in 2.6 and before execfile is listed in builtin functions, and is not >>> marked deprecated, and exec is in the simple statements, and is not >>> marked deprecated. >> >> Because they are not going away in 2.7. > > > Ah, that's the missing piece! I keep thinking 2.5, 2.6, 3.0, and > forgetting that someone might make a 2.7 :) I bet I wasn't the first > one to be confused by this, nor am I likely to be the last. Not might - there *is* going to be a 2.7 (that will probably come out at the same time as 3.1) and we're already working on it: http://docs.python.org/dev/whatsnew/2.7.html 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] Meet your next release manager: Benjamin Peterson
On Fri, Jan 09, 2009, Barry Warsaw wrote: > > To that end, I'm happy to say that Benjamin Peterson will be the release > manager for Python 2.7 and 3.1. I will be mentoring him through the > process, but it'll be his ball of snake wax. Please join me in helping > him make the 2.7 and 3.1 releases as great as 2.6 and 3.0! Great news! How many cases of beer did you feed him before he agreed? -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian W. Kernighan ___ 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] Getting importlib into the standard library for 3.1
OK, since no one has really said anything, I am going to assume no one has issues with importlib in terms of me checking it in or choosing a name for it (I like importlib more than imp so I will probably stick with that). So I will do some file renaming and reorganization, get the code set up to be run by regrtest, and then check the code in! I am going to set PyCon as a hard deadline such that no matter how much more file churn I have left I will still check it into py3k by then (along with importlib.import_module() into 2.7). On Thu, Jan 8, 2009 at 11:06, Brett Cannon wrote: > My work rewriting import in pure Python code has reached beta. > Basically the code is semantically complete and as > backwards-compatible as I can make it short of widespread testing or > running on a Windows box. There are still some tweaks here and there I > want to make and an API to expose, but __import__ works as expected > when run as the import implementation for all unit tests. > > Knowing how waiting for perfection leads to never finishing, I would > like to start figuring out what it will take to get the code added to > the standard library of 3.1 with hopes of getting the bootstrapping > stuff done so that the C implementation of import can go away in 3.1 > as well. I see basically three things that need to be decided upfront. > > One, does anyone have issues if I check in importlib? We have > typically said code has to have been selected as best-of-breed by the > community first, so I realize I am asking for a waiver on this one. > > Two, what should the final name be? I originally went with importlib > since this code was developed outside of the trunk, but I can see some > people suggesting using the imp name. That's fine although that does > lead to the question of what to do with the current imp. It could be > renamed _imp, but then that means what is currently named _importlib > would have to be renamed to something else as well. Maybe > imp._bootstrap? Plus I always viewed imp as the place where really > low-level, C-based stuff lived. Otherwise importlib can slowly subsume > the stuff in imp that is still useful. > > Three, there are still some structural changes to the code that I want > to make. I can hold off on checking in the code until these changes > are made, but as I said earlier, I know better than to wait forever > for perfection. > > And because I know people will ask: no, I do not plan to backport all > the code to 2.7. I want this to be a carrot to people to switch to > 3.x. But I will backport the import_module function I wrote to 2.7 so > people do have that oft-requested feature since it is a really simple > bit of Python code. > > -Brett > ___ 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
