Re: [Python-Dev] Are PyCFunctions supposed to invisibly consume self when used as a method?
Christian Heimes, 13.06.2010 01:22: Am 13.06.2010 01:15, schrieb Guido van Rossum: Hey! No borrowing the time machine! :-) Too late Get the irony? Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] debug and release python
> -Original Message- > From: Amaury Forgeot d'Arc [mailto:[email protected]] > Sent: 15. júní 2010 21:24 > To: Kristján Valur Jónsson > Cc: [email protected] > Subject: Re: [Python-Dev] debug and release python > > I remember having the same issue years ago: > http://mail.python.org/pipermail/python-list/2004-July/855844.html > > At the time, I solved the issue by compiling extension modules with > pymalloc options turned on > (which it fortunately the default, so this applies to the supplied > proprietary .pyd), > and I added a (plain) definition for functions like > _PyObject_DebugMalloc, > even when PYMALLOC_DEBUG is undefined. > > Since the python_d.dll is a custom build anyway, adding the code is > not too much pain. > It is not too much pain, once you realize the problem, no. But I just got bitten by this and spent the best part of a weekend trying to solve the problem. On Windows, you get an import failure on the .pyd file with the message: "Procedure entry point not found". I had come across this previously, some three years ago perhaps, and forgotten all about it, so I was sufficiently annoyed to post to python-dev. We use python27_d.dll a lot and typically have WITH_PYMALLOC disabled in debug build to for the benefit of using the debug malloc libraries present on windows. I've solved the issue now by making sure that obmalloc.c always exports _PyObject_DebugMalloc(), much as it always exports PyObject_Malloc() whether WITH_PYMALLOC is defined or not. My suggestion for python core would be the same: expose these always for existing python versions, and remove them from the API in new python versions. K ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] debug and release python
> -Original Message- > From: "Martin v. Löwis" [mailto:[email protected]] > Sent: 15. júní 2010 21:20 > To: Kristján Valur Jónsson > Cc: [email protected] > Subject: Re: [Python-Dev] debug and release python > > Am 15.06.2010 14:48, schrieb Kristján Valur Jónsson: > > What I mean is that a third party software vendor supplies a > > foobarapp.pyd and a foobarapp_d.pyd dlls that link to python2x.dll > > and python2x_d.dll respectively. But the latter will have been > > compiled to match a certain settings of the objimpl.h header, which > > may not match whatever is being used to build the local > > python2x_d.dll. And thus, you get strange and hard to debug linker > > errors when trying to load external libraries. > > Ok. But your proposed change doesn't fix that, right? > > I.e. even with the change, it would *still* depend on objimpl.h (and > other) settings what ABI this debug DLL exactly has. > I think it does. My proposal was perhaps not clear: For existing python versions, always export _PyObject_DebugMalloc et al. irrespective of the WITH_PYMALLOC and PYMALLOC_DEBUG settings. (PyObject_Malloc()) is always exported, even for builds without WITH_PYMALLOC) On new python versions, remove the _PyObject_DebugMalloc from the ABI. Make the switch internal to obmalloc.c, so that you can turn on the debug library by recompiling pythonxx_d.dll only (currently, you have to recompile the .pyd files too!) > But there are tons of ABI changes that may happen in a debug build. > If you want to cope with all of them, you really need to recompile the > source of all extensions. Are there? Can you give me an example? I thought we were careful to keep the interface shown to pyd files constant regardless of configuration settings. K ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Release manager/developer (10 years + experience) would like to help and volunteer time if needed
Hi, I have worked 10 years at Adobe Systems as a Release Developer for the LiveCycle ES team and am now employed as a Release Manager (for a team of one, me ;) ) at Nuance Communications since last March. I have put lots of effort to keep Python alive and well at Adobe by providing complete build/release solutions & processes, automation and tooling in my favourite language, Python. I have been promoting, planning and implementing a completely new build/release infrastructure at Nuance, where my expectation is have a 100% python shop to manage builds and releases. I would very like to offer any help you may require, provided I am a good fit. I can provide references, resume, etc. if requested. In hopes of pursuing further discussions, please accept my best regards, Martin Senecal Gatineau (Quebec) Canada___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Release manager/developer (10 years + experience) would like to help and volunteer time if needed
Welcome! You might just want to hook on to the process mentioned at http://www.python.org/dev That's it. -- Senthil On 16 Jun 2010 16:44, "Mart" wrote: Hi, I have worked 10 years at Adobe Systems as a Release Developer for the LiveCycle ES team and am now employed as a Release Manager (for a team of one, me ;) ) at Nuance Communications since last March. I have put lots of effort to keep Python alive and well at Adobe by providing complete build/release solutions & processes, automation and tooling in my favourite language, Python. I have been promoting, planning and implementing a completely new build/release infrastructure at Nuance, where my expectation is have a 100% python shop to manage builds and releases. I would very like to offer any help you may require, provided I am a good fit. I can provide references, resume, etc. if requested. In hopes of pursuing further discussions, please accept my best regards, Martin Senecal Gatineau (Quebec) Canada ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/orsenthil%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Release manager/developer (10 years + experience) would like to help and volunteer time if needed
On Wed, Jun 16, 2010 at 3:45 PM, Mart wrote: > > I have put lots of effort to keep Python alive and well at Adobe by providing > complete build/release solutions & processes, automation and tooling in my > favourite language, Python. > I have been promoting, planning and implementing a completely new > build/release infrastructure at Nuance, where my expectation is have a 100% > python shop to manage builds and releases. Hi Martin, With that kind of background there are likely a number of ways you could contribute. From a general Python programming point of view, I'd start with Brett's intro to CPython development at http://www.python.org/dev/intro/ and the other links in the dev section of the web site. There are plenty of bug fixes and feature requests relating to pure Python components of the standard library that always need work (even comments just saying "I tried this patch and it worked for me" can be very helpful). Specifically in the area of automated build and test management, Martin von Loewis may have some suggestions for improvements that could be made to our Buildbot infrastructure that he doesn't have the time to do himself. It may also be worth checking with Dirkjan Ochtman to see if there is anything in this space that still needs to be handled for the transition from svn to hg that will hopefully be happening later this year. With any luck, those two will actually chime in here (as they're both python-dev subscribers). We don't go in for automated binary releases for a variety of reasons - I definitely advise trawling through the python-dev archives for a while before getting too enthusiastic on that particular front. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Release manager/developer (10 years + experience) would like to help and volunteer time if needed
Hi Nick, That sounds great! I assume since python-dev has been cc'ed that both Martin von Loewis ans Dirkjan Ochtman are listening on this thread. If so, then let me know if there is anything specific that either of you would need a hand with. I would be more than happy to take on some of your "still TODO but no time" items. Meanwhile I will take a closer look @ http://www.python.org/dev/intro and see where/if I can roll up my sleeves and lend a hand. Thanks for the reply & info and I look forward to contributing! Mart :) On 2010-06-16, at 9:19 AM, Nick Coghlan wrote: > On Wed, Jun 16, 2010 at 3:45 PM, Mart wrote: >> >> I have put lots of effort to keep Python alive and well at Adobe by >> providing complete build/release solutions & processes, automation and >> tooling in my favourite language, Python. >> I have been promoting, planning and implementing a completely new >> build/release infrastructure at Nuance, where my expectation is have a 100% >> python shop to manage builds and releases. > > Hi Martin, > > With that kind of background there are likely a number of ways you > could contribute. From a general Python programming point of view, I'd > start with Brett's intro to CPython development at > http://www.python.org/dev/intro/ and the other links in the dev > section of the web site. There are plenty of bug fixes and feature > requests relating to pure Python components of the standard library > that always need work (even comments just saying "I tried this patch > and it worked for me" can be very helpful). > > Specifically in the area of automated build and test management, > Martin von Loewis may have some suggestions for improvements that > could be made to our Buildbot infrastructure that he doesn't have the > time to do himself. It may also be worth checking with Dirkjan Ochtman > to see if there is anything in this space that still needs to be > handled for the transition from svn to hg that will hopefully be > happening later this year. With any luck, those two will actually > chime in here (as they're both python-dev subscribers). > > We don't go in for automated binary releases for a variety of reasons > - I definitely advise trawling through the python-dev archives for a > while before getting too enthusiastic on that particular front. > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sharing functions between C extension modules in stdlib
On Mon, Jun 14, 2010 at 7:09 PM, "Martin v. Löwis" wrote: .. > So it's clearly intentional. I doubt its desirable, though. If only > __PyTime_DoubleToTimet needs to be duplicated, I'd rather put that > function into a separate C file that gets included twice, instead of > including the full timemodule.c into datetimemodule.c. Thanks for your research, Martin. I've opened an issue for this at http://bugs.python.org/issue9012 . ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] email package status in 3.X
[copied to pydev from email-sig because of the broader scope] Well, it looks like I've stumbled onto the "other shoe" on this issue--that the email package's problems are also apparently behind the fact that CGI binary file uploads don't work in 3.1 (http://bugs.python.org/issue4953). Yikes. I trust that people realize this is a show-stopper for broader Python 3.X adoption. Why 3.0 was rolled out anyhow is beyond me; it seems that it would have been better if Python developers had gotten their own code to work with 3.X, before expecting the world at large to do so. FWIW, after rewriting Programming Python for 3.1, 3.x still feels a lot like a beta to me, almost 2 years after its release. How did this happen? Maybe nobody is using 3.X enough to care, but I have a feeling that issues like this are part of the reason why. No offense to people who obviously put in an incredible amount of work on 3.X. As someone who remembers 0.X, though, it's hard not to find the current situation a bit disappointing. --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) > -Original Message- > From: [email protected] > To: "R. David Murray" > Subject: Re: email package status in 3.X > Date: Sun, 13 Jun 2010 15:30:06 - > > Come to think of it, here was another oddness I just recalled: this > may have been reported already, but header decoding returns mixed types > depending upon the structure of the header. Converting to a str for > display isn't too difficult to handle, but this seems a bit inconsistent > and contrary to Python's type neutrality: > > >>> from email.header import decode_header > >>> S1 = 'Man where did you get that assistant?' > >>> S2 = '=?utf-8?q?Man_where_did_you_get_that_assistant=3F?=' > >>> S3 = 'Man where did you get that =?UTF-8?Q?assistant=3F?=' > > # str: don't decode() > >>> decode_header(S1) > [('Man where did you get that assistant?', None)] > > # bytes: do decode() > >>> decode_header(S2) > [(b'Man where did you get that assistant?', 'utf-8')] > > # bytes: do decode(), using raw-unicode-escape applied in package > >>> decode_header(S3) > [(b'Man where did you get that', None), (b'assistant?', 'utf-8')] > > I can work around this with the following code, but it > feels a bit too tightly coupled to the package's internal details > (further evidence that email.* can be made to work as is today, > even if it may be seen as less than ideal aesthetically): > > parts = email.header.decode_header(rawheader) > decoded = [] > for (part, enc) in parts: # for all substrings > if enc == None:# part unencoded? > if not isinstance(part, bytes):# str: full hdr unencoded > decoded += [part] # else do unicode decode > else: > decoded += [part.decode('raw-unicode-escape')] > else: > decoded += [part.decode(enc)] > return ' '.join(decoded) > > Thanks, > --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) > > > > -Original Message- > > From: [email protected] > > To: "R. David Murray" > > Subject: Re: email package status in 3.X > > Date: Sat, 12 Jun 2010 16:52:32 - > > > > Hi David, > > > > All sounds good, and thanks again for all your work on this. > > > > I appreciate the difficulties of moving this package to 3.X > > in a backward-compatible way. My suggestions stem from the fact > > that it does work as is today, albeit in a less than ideal way. > > > > That, and I'm seeing that Python 3.X in general is still having > > a great deal of trouble gaining traction in the "real world" > > almost 2 years after its release, and I'd hate to see further > > disincentives for people to migrate. This is a bigger issue > > than both the email package and this thread, of course. > > > > > > 3) Type-dependent text part encoding > > > > > > > ... > > > So, in the next releases of Python all MIMEText input should be string, > > > and it will fail if you pass bytes. I consider this as email previously > > > not living up to its published API, but do you think I should hack > > > in a way for it to accept bytes too, for backward compatibility in the > > > 3 line? > > > > Decoding can probably be safely delegated to package clients. > > Typical email clients will probably have str for display of the > > main text. They may wish to read attachments in binary mode, but > > can always read in text mode instead or decode manualy, because > > they need a known encoding to send the part correctly (my client > > has to ask or use configurations in some cases). > > > > B/W compatibility probably isn't a concern; I suspect that my > > temporary workaround will still work with your patch anyhow, > > and this code didn't work at all for some encodings before. > > > > > > There are some additional cases that now require decoding per mail > > > > headers today due to the str/bytes split, but these are just a > > > > normal art
Re: [Python-Dev] email package status in 3.X
On Thu, Jun 17, 2010 at 6:48 AM, wrote: > I trust that people realize this is a show-stopper for broader > Python 3.X adoption. Why 3.0 was rolled out anyhow is beyond > me; it seems that it would have been better if Python developers > had gotten their own code to work with 3.X, before expecting the > world at large to do so. > > FWIW, after rewriting Programming Python for 3.1, 3.x still feels > a lot like a beta to me, almost 2 years after its release. How > did this happen? Maybe nobody is using 3.X enough to care, but > I have a feeling that issues like this are part of the reason why. > > No offense to people who obviously put in an incredible amount of > work on 3.X. As someone who remembers 0.X, though, it's hard not > to find the current situation a bit disappointing. Agreed, but the binary/text distinction in 2.x (or rather, the lack thereof) makes the unicode handling situation so hopelessly confused that there is a lot of 2.x code (including in the standard library) that silently mixes the two, often without really testing the consequences (as clearly happened here). 3.x was rolled out anyway because the vast majority of it works. Obviously people affected by the problems specific to the email package and any other binary vs text parsing problems that are still lingering are out of luck at the moment, but leaving 3.x sitting on a shelf indefinitely would hardly have inspired anyone to clean it up. My personal perspective is that a lot of that code was likely already broken in hard to detect ways when dealing with mixed encodings - releasing 3.x just made the associated errors significantly easier to detect. If we end up being able to add your email client code to the standard library's unit test suite, that should help the situation immensely. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
