Re: [Python-Dev] Multiprocessing on Solaris
According to the user's experience multiprocessing should not compile and run correctly unless this patch is applied. Can this please be more qualified? I can confirm Scott's observation: for the trunk, it compiles just fine, using SunPro CC on Solaris 10, on SPARC. Also, test_multiprocessing passes. IIUC, incorrect setting of HAVE_SEM_TIMEDWAIT to 1 should cause a compile failure, as sem_timedwait would be called but not defined. However, sem_timedwait *is* defined on Solaris. Likewise, for HAVE_FD_TRANSFER=1 to work, SCM_RIGHTS must be defined (and implemented); it is defined in sys/socket.h, and documented in socket.h(3HEAD). So there must be going on something else at the user's machine. 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] PEP 380 (yield from a subgenerator) comments
P.J. Eby wrote: (I'm thus finding it hard to believe there's a non-contrived example that's not doing I/O, scheduling, or some other form of co-operative multitasking.) Have you seen my xml parser example? http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/ Whether you'll consider it contrived or not I don't know (contrivedness being such a subjective property) but it illustrates the style of programming I'm trying to support with the return-value feature. In any case, you didn't address the confusion issue: the inability of generators to return a value is there for a good reason, It's there because formerly there was nowhere for the return value to go. If there is somewhere for it to go, the restriction will no longer be needed. Things like this have happened before. It used to be forbidden to put a yield in a try-finally block, because there was no way to ensure that the finally would be executed. Once a way was found to do that, the restriction was lifted. As for confusion, we ignore the return values of function calls all the time, without worrying that someone might be confused by the fact that their return value doesn't go anywhere. And that's the right way to think of a yield-from expression -- as a kind of function call, not a kind of yield. If there's anything confusing, it's the presence of the word 'yield'. Its only virtue is that it gives a clue that the construct has something to do with generators, but you'll have to RTM to find out exactly what. Nobody has thus far suggested any better name, however. -- Greg ___ 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 380 (yield from a subgenerator) comments
On Sun Mar 22 09:11:29 CET 2009 Greg Ewing wrote: As for confusion, we ignore the return values of function calls all the time, without worrying that someone might be confused by the fact that their return value doesn't go anywhere. And that's the right way to think of a yield-from expression -- as a kind of function call, not a kind of yield. If there's anything confusing, it's the presence of the word 'yield'. Its only virtue is that it gives a clue that the construct has something to do with generators, but you'll have to RTM to find out exactly what. Nobody has thus far suggested any better name, however. The PEP doesn't seem to contain a list of unacceptable names and reasons in the section where the problem with the name is mentioned. So I wonder why the obvious 'delegate to' is not acceptable? (Because adding a keyword would make it less likely to be accepted?) -- R. David Murray http://www.bitdance.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] PEP 380 (yield from a subgenerator) comments
Greg Ewing greg.ewing at canterbury.ac.nz writes: When the iterator is another generator, the effect is the same as if the body of the subgenerator were inlined at the point of the ``yield from`` expression. Furthermore, the subgenerator is allowed to execute a ``return`` statement with a value, and that value becomes the value of the ``yield from`` expression. If it's really enough to understand and debug all corner cases of using yield from, then fair enough. (I still don't like the PEP and feel it's much too specialized for a new syntactic feature. The language should try to be obvious rather than clever, IMO) ___ 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] an unimportant question, ...
... but I'm curious.
Hi Guido,
while working on Psyco, I stumbled over a log entry in modsupport.h:
19-Aug-2002 GvR 1012Changes to string object struct for
interning changes, saving 3 bytes.
The change to stringobject was this (rev. 28308):
Before:
typedef struct {
PyObject_VAR_HEAD
long ob_shash;
PyObject *ob_sinterned;
char ob_sval[1];
} PyStringObject;
After:
typedef struct {
PyObject_VAR_HEAD
long ob_shash;
int ob_sstate;
char ob_sval[1];
} PyStringObject;
Now, the internals are very clear to me. What I don't understand
is where the three saved bytes should be.
Thinking of the time where this change was made, I cannot imagine
that this comment was about the size diff between pointer and int,
and if this was meant, I still don't get how this could save three
bytes?
With unaligned ob_sval, structure packing and ob_sstate being
unsigned char one could save 3 bytes, but we don't do that.
Well, as said, this is no important question. I am just asking
myself what I don't see here, or if the comment is just sub-optimal :-)
all the best -- chris
p.s.: won't make it to PyCon this time, see you soon at the piggies
--
Christian Tismer :^) mailto:tis...@stackless.com
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key - http://wwwkeys.pgp.net/
work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.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] PEP 380 (yield from a subgenerator) comments
At 08:11 PM 3/22/2009 +1200, Greg Ewing wrote: P.J. Eby wrote: (I'm thus finding it hard to believe there's a non-contrived example that's not doing I/O, scheduling, or some other form of co-operative multitasking.) Have you seen my xml parser example? http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/ Whether you'll consider it contrived or not I don't know (contrivedness being such a subjective property) but it illustrates the style of programming I'm trying to support with the return-value feature. I find the parser *without* yield-from to be much easier to follow what's going on, actually... and don't see what benefit was obtained by the additional complication of using send(). In any case, you didn't address the confusion issue: the inability of generators to return a value is there for a good reason, It's there because formerly there was nowhere for the return value to go. If there is somewhere for it to go, the restriction will no longer be needed. But that's begging the question (in the original meaning of the phrase) of why we *want* to have two ways to return data from a generator. As for confusion, we ignore the return values of function calls all the time, without worrying that someone might be confused by the fact that their return value doesn't go anywhere. And that's the right way to think of a yield-from expression -- as a kind of function call, not a kind of yield. But it's not a function call -- it's multiple *inverted* function calls, followed by special handling of the last iteration of the iterator it takes. The control flow is also hard to explain, as is the implementation. If there's anything confusing, it's the presence of the word 'yield'. Its only virtue is that it gives a clue that the construct has something to do with generators, but you'll have to RTM to find out exactly what. Nobody has thus far suggested any better name, however. Perhaps this is because it's not that interesting of a feature. As I said, I wouldn't fight a yield-from statement without all this return-value stuff, although it still seems like too much trouble to me. ___ 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] an unimportant question, ...
Christian Tismer wrote:
... but I'm curious.
Hi Guido,
while working on Psyco, I stumbled over a log entry in modsupport.h:
19-Aug-2002 GvR1012Changes to string object struct for
interning changes, saving 3 bytes.
The change to stringobject was this (rev. 28308):
Before:
typedef struct {
PyObject_VAR_HEAD
long ob_shash;
PyObject *ob_sinterned;
char ob_sval[1];
} PyStringObject;
After:
typedef struct {
PyObject_VAR_HEAD
long ob_shash;
int ob_sstate;
char ob_sval[1];
} PyStringObject;
Now, the internals are very clear to me. What I don't understand
is where the three saved bytes should be.
Thinking of the time where this change was made, I cannot imagine
that this comment was about the size diff between pointer and int,
and if this was meant, I still don't get how this could save three
bytes?
With unaligned ob_sval, structure packing and ob_sstate being
unsigned char one could save 3 bytes, but we don't do that.
Well, as said, this is no important question. I am just asking
myself what I don't see here, or if the comment is just sub-optimal :-)
At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. :-)
Michael
all the best -- chris
p.s.: won't make it to PyCon this time, see you soon at the piggies
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
___
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] an unimportant question, ...
Now, the internals are very clear to me. What I don't understand is where the three saved bytes should be. If you look at the various patches in http://bugs.python.org/issue576101 then there is a three-byte saving in all versions from 1 to 6. Consequentially, the API was changed in those versions (but only starting from version 5, i.e. the first version created by Guido). For some reason, the saving was then removed from the patch that got actually committed (#7). I guess the comment just stayed. 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] an unimportant question, ...
On 3/22/09 8:01 PM, Martin v. Löwis wrote: Now, the internals are very clear to me. What I don't understand is where the three saved bytes should be. If you look at the various patches in http://bugs.python.org/issue576101 then there is a three-byte saving in all versions from 1 to 6. Consequentially, the API was changed in those versions (but only starting from version 5, i.e. the first version created by Guido). For some reason, the saving was then removed from the patch that got actually committed (#7). I guess the comment just stayed. That's very impressive! Thank you very much for the enlightment. Whow! cheers - chris -- Christian Tismer :^) mailto:tis...@stackless.com tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/ 14109 Berlin : PGP key - http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.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] Multiprocessing on Solaris
Martin v. Löwis schrieb: According to the user's experience multiprocessing should not compile and run correctly unless this patch is applied. Can this please be more qualified? I can confirm Scott's observation: for the trunk, it compiles just fine, using SunPro CC on Solaris 10, on SPARC. Also, test_multiprocessing passes. IIUC, incorrect setting of HAVE_SEM_TIMEDWAIT to 1 should cause a compile failure, as sem_timedwait would be called but not defined. However, sem_timedwait *is* defined on Solaris. Likewise, for HAVE_FD_TRANSFER=1 to work, SCM_RIGHTS must be defined (and implemented); it is defined in sys/socket.h, and documented in socket.h(3HEAD). So there must be going on something else at the user's machine. The user doesn't respond to my inquiries anymore. According to his initial message he is using Solaris 5.8 with GCC 3.4.6 on a Sun Fire machine. Here is a link to his mesage: http://permalink.gmane.org/gmane.comp.python.general/615802 Christian ___ 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] an unimportant question, ...
On 3/22/09 8:01 PM, Martin v. Löwis wrote: Now, the internals are very clear to me. What I don't understand is where the three saved bytes should be. If you look at the various patches in http://bugs.python.org/issue576101 then there is a three-byte saving in all versions from 1 to 6. Consequentially, the API was changed in those versions (but only starting from version 5, i.e. the first version created by Guido). For some reason, the saving was then removed from the patch that got actually committed (#7). I guess the comment just stayed. Yes, funny, actually. At least, I don't find any comment why the char was turned into an int, after all. Are char pointers not on a word boundary problematic on some platforms? Or was it maybe to just keep the string layout on many common platforms compatible, in order to save rebuilding so many windows extension modules? If the latter is true and the only reason, I vote for reclaiming the three bytes. Maybe it saves a tree or two. Maybe it hurts very little if done for Python 3000. In any case, use the version that saves the most energy. :-) not kidding - ciao -- chris -- Christian Tismer :^) mailto:tis...@stackless.com tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/ 14109 Berlin : PGP key - http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.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] an unimportant question, ...
On Sun, Mar 22, 2009 at 20:38, Christian Tismer tis...@stackless.comwrote: On 3/22/09 8:01 PM, Martin v. Löwis wrote: Now, the internals are very clear to me. What I don't understand is where the three saved bytes should be. If you look at the various patches in http://bugs.python.org/issue576101 then there is a three-byte saving in all versions from 1 to 6. Consequentially, the API was changed in those versions (but only starting from version 5, i.e. the first version created by Guido). For some reason, the saving was then removed from the patch that got actually committed (#7). I guess the comment just stayed. Yes, funny, actually. At least, I don't find any comment why the char was turned into an int, after all. Are char pointers not on a word boundary problematic on some platforms? Or was it maybe to just keep the string layout on many common platforms compatible, in order to save rebuilding so many windows extension modules? If the latter is true and the only reason, I vote for reclaiming the three bytes. Maybe it saves a tree or two. Maybe it hurts very little if done for Python 3000. In any case, use the version that saves the most energy. :-) not kidding - ciao -- chris Actually, we should use the version that breaks the ABI the least. The change you're referring to actually (comparatively silently!) broke the ABI for 64-bit Python builds (at least, on LP64 and LLP64 systems, which is most of them.) You can normally relatively safely use an extension module built for Python 2.2 in Python 2.4, but not so for 64-bit builds. Let's try to keep the ABI compatible, and at least make it an error (not a warning) to load a truly incompatible ABI version. -- Thomas Wouters tho...@python.org Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] an unimportant question, ...
Christian Tismer tismer at stackless.com writes: Or was it maybe to just keep the string layout on many common platforms compatible, in order to save rebuilding so many windows extension modules? If the latter is true and the only reason, I vote for reclaiming the three bytes. Maybe it saves a tree or two. Maybe it hurts very little if done for Python 3000. In any case, use the version that saves the most energy. Well, if you want to make the str type in py3k smaller, there is a more massive saving to be done by making it a PyVarObject, rather than allocating the storage separately. A patch has existed for that for a long time now, it probably needs updating if anyone is interested: http://bugs.python.org/issue1943 ___ 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] GSoC: Core Python development tools
Hi, I'd like to bring up the general idea of using a PSF slot in GSoC2009 to improve the Python development infrastructure. I also happen to have two concrete proposals for that (such a coincidence!). But I assure you the general idea is more important than my proposals :) General: Solving issues that get in core devs' way when they work on Python development could be a nice PSF GSoC project. I believe there are enough code related tasks that would greatly improve Python development workflow but lack manpower to complete. E.g., ISTM that a student working on svnmerge in past SoC editions would've been able to mitigate some painful shortcomings. If the core developers could come up with a list of peeves that would be solvable in code (in existing tools), that would allow for a very useful GSoC proposal. Proposals: These might fit the description above, and they're both tracker related (yep, one-trick-pony here). The upside is that at least one potential mentor is available for each, and I'd be able to offer support to the student. First, the PSF could invest a slot on integrating different tools of the development workflow. Variations of 'file issue at bug tracker, submit code for review' or 'branch locally to virtualenv, upload failing testcase to tracker, upload patch to tracker' command line utils. If these could be developed as general tools (i.e., not deeply tied to Python dev infrastructure), Ali Afshar from PIDA is willing to mentor it. I'd be available to help with Roundup and Rietveld (integration in progress), but would like to see it work with Launchpad, Bugzilla, Google Code and Review Board :) The other proposal is to use a slot in Roundup proper and the Python tracker instance. This could have a core Roundup developer as mentor, under the condition it's focused on Roundup itself. IMO, are some missing/broken core features in Roundup that would have a positive impact on our tracker, mostly those relating to searches, security and UI. I'd have a lot to contribute to the Python tracker part, based on ongoing work. Even if neither is considered worthy, I'll keep them on my to-do list and hope to slowly and hackishly work towards both proposals' goals. Barring feedback saying that they're out of scope, stupid and downright offensive, I'll post details on each to this thread very soon. So, if the PSF was to use a slot on improving the way you work on Python development, what would you like to see fixed or implemented? Best regards, Daniel ___ 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] GSoC: Core Python development tools
On Sun, Mar 22, 2009 at 07:30:01PM -0300, Daniel (ajax) Diniz wrote: - Even if neither is considered worthy, I'll keep them on my to-do list - and hope to slowly and hackishly work towards both proposals' goals. - Barring feedback saying that they're out of scope, stupid and - downright offensive, I'll post details on each to this thread very - soon. Given the relative paucity of core Python GSoC ideas, I think you should go for both of these, *especially* if you have a mentor up front. So, write 'em up, add 'em to the GSoC page, and let's see who we get... If we get good applications for both, then I think we can fund both of them. I do think you should be prepared for pushback from python-dev on any such ideas ;). Don't get too ambitious about writing up *your* way of fixing things, but rather make sure you and the students are prepared to adapt to what people on python-dev think. Mind you, ultimately the people doing the work should make the decisions, but input from python-dev is usually pretty useful even when it's contradictory! cheers, --titus -- C. Titus Brown, c...@msu.edu ___ 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] Issue workflow doc is now live
I sent this out as a Google Doc a while back, but I just did a proof-reading, converted it, and pushed it live to the python.org: http://www.python.org/dev/workflow/ . So now people who ever triage issues have a guide to follow if they are not sure how to set things. -Brett P.S.: Doing this doc has made me realize that our issue workflow still feels off and SF-influenced. If people want to talk at PyCon about it just let me know. I might try to get a discussion going during the language summit or at the sprints as I have some ideas on how to simplify thing but make it usable for more people (preview: I like how http://code.djangoproject.com/querydoes their tickets). ___ 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 380 (yield from a subgenerator) comments
Antoine Pitrou wrote: If it's really enough to understand and debug all corner cases of using yield from, then fair enough. In the case where the subiterator is another generator and isn't shared, it's intended to be a precise and complete specification. That covers the vast majority of the use cases I have in mind. Most of the complexities arise from trying to pin down what happens when the subiterator isn't a generator, or is being shared by other code. I don't know how the specification could be made any simpler for those cases while still being complete. Even so, the intention is that if you understand the semantics in the generator case, the behaviour in the other cases should be something reasonable and unsurprising. I certainly don't expect users to memorize either the expansion or the full text of the English explanation. -- Greg ___ 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] issue 2170 review
Instead of looking at a bunch of issues last week the way I'd originally intended, I wound up doing a review of a particular patch submission, issue 2170. This is a refactoring of the 'normalize' method of xml.dom.minidom. I wound up redoing the patch with a different refactoring after finding out that the submitted patch was slower than the original code. The revised patch is faster than the original code (completes in 1/2 the time of the original code when run on a decent sized document that needed no normalization done). I think the issue stage should be set to 'patch review', as in, it is ready for developer review. The author of the original patch has reviewed my revised patch and concurs. The patch includes additional tests. Now that I've learned more about how the tracker is organized, and read the most-helpful http://www.python.org/dev/workflow/ document, I would be happy to go through and triage issues for which that hasn't yet been done, if I can be given permission to do so. -- R. David Murray http://www.bitdance.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] Core projects for Summer of Code
On Fri, Mar 20, 2009 at 03:18:00PM -0700, average wrote: - Summer of Code is ramping up. ?Every year the common complaint is that not - enough Python core projects get proposed by students, and of course a big - reason for that is often the only encouragement we offer prospective - students is a link to the PEP index. - - The challenge is finding project ideas for them that could reasonably occupy - them for the entire Summer and which the results of their work can be - demonstrated. ?They're being paid for specific projects so Spend the Summer - fixing bugs on the tracker is a no-go, and Google has outlined that Summer - of Code is about code, not documentation. - - Improve doctest by allowing it to be aware of nested test scopes such - that a variable defined at class-level scope (i.e. the variable b - defined at the class-level doctest b=Bag(abacab)) can be - used in method-level scopes without re-defining it every time for - each method's doctest (each method would reset the given variable (if - used) to its original state rather than live mutated between - equal-level scopes). - - Would be a great improvement for doctest in my opinion--both in - ease-of-use, and reduction of redundant, error-prone (did you define - your test variable the same in each method?) code)--as well as other - benefits. - - Appreciate any consideration... Hi Marcos, my primary concern here would be that the student would do all this work and then python-dev would reject it for incorporation into core! Plus it's probably not a summer-long project. If, however, you wanted to suggest a general gather disparate doctest features and integrate them, for consideration for the core project, I would definitely recommend posting that as a possible project on the Python GSoC site. I know that zope has done some good doctest stuff, for example; the 'testing-in-python' list would be a good place to go for finding out more. Note, you don't have to offer to be the mentor to post it, but it would help ;) cheers, --titus -- C. Titus Brown, c...@msu.edu ___ 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 380 (yield from a subgenerator) comments
Greg Ewing wrote: As for confusion, we ignore the return values of function calls all the time, without worrying that someone might be confused by the fact that their return value doesn't go anywhere. And that's the right way to think of a yield-from expression -- as a kind of function call, not a kind of yield. If there's anything confusing, it's the presence of the word 'yield'. Its only virtue is that it gives a clue that the construct has something to do with generators, but you'll have to RTM to find out exactly what. Nobody has thus far suggested any better name, however. If the yield in 'yield from' does not make the function a generator, then perhaps 'return from' would be clearer. ___ 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] issue 2170 review
On Sun, Mar 22, 2009 at 18:49, R. David Murray rdmur...@bitdance.comwrote: Instead of looking at a bunch of issues last week the way I'd originally intended, I wound up doing a review of a particular patch submission, issue 2170. This is a refactoring of the 'normalize' method of xml.dom.minidom. I wound up redoing the patch with a different refactoring after finding out that the submitted patch was slower than the original code. The revised patch is faster than the original code (completes in 1/2 the time of the original code when run on a decent sized document that needed no normalization done). I think the issue stage should be set to 'patch review', as in, it is ready for developer review. The author of the original patch has reviewed my revised patch and concurs. The patch includes additional tests. I have set the stage. Now that I've learned more about how the tracker is organized, and read the most-helpful http://www.python.org/dev/workflow/ document, I would be happy to go through and triage issues for which that hasn't yet been done, if I can be given permission to do so. 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
Re: [Python-Dev] Multiprocessing on Solaris
Christian Heimes wrote: Martin v. Löwis schrieb: According to the user's experience multiprocessing should not compile and run correctly unless this patch is applied. Can this please be more qualified? I can confirm Scott's observation: for the trunk, it compiles just fine, using SunPro CC on Solaris 10, on SPARC. Also, test_multiprocessing passes. Sorry, I mistakenly said without issue and then copied the issues below. I meant to say not without issues. _multiprocessing does *not* build on Solaris 8. IIUC, incorrect setting of HAVE_SEM_TIMEDWAIT to 1 should cause a compile failure, as sem_timedwait would be called but not defined. However, sem_timedwait *is* defined on Solaris. Likewise, for HAVE_FD_TRANSFER=1 to work, SCM_RIGHTS must be defined (and implemented); it is defined in sys/socket.h, and documented in socket.h(3HEAD). So there must be going on something else at the user's machine. The user doesn't respond to my inquiries anymore. According to his initial message he is using Solaris 5.8 with GCC 3.4.6 on a Sun Fire machine. Here is a link to his mesage: http://permalink.gmane.org/gmane.comp.python.general/615802 I can confirm his build issues on: $ uname -srvmpi SunOS 5.8 Generic_117350-51 sun4u sparc SUNW,Sun-Fire-280R $ gcc -v Reading specs from /usr/local/gnu/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/specs gcc version 2.95.2 19991024 (release) My build output from within the trunk is the same as his modulo the details of being part of a trunk build instead. Is Solaris 8 really a supported platform? If so, I can investigate the changes he suggested. -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu ___ 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] GSoC: Replace MS Windows Console with Unicode UI
One of the disappointments of CPython 3.0 on Windows is that the switch to unicode for text (str), coupled with the continued use of a unicode-oblivious (obtuse) user interface (MS 'Command Prompt'), means that print can no longer print all str strings, or all legal Python code (as in a traceback). Different people have tried and failed fix this bug by fiddling with 'Command Prompt' configeration. This would make a useful summer project, though I don't know if it would involve enough coding. Call the project something like 3.0 Unicode UI Improvement. I see two possibilities. 1) Find an C-coded open-source C-P replacement whose author will license to PSF and, as needed, modify or integrate it with CPython. 2) IDLE does much better but its support seems to still be imcomplete. Upgrade tk/tkinter/IDLE (wherever the problems lie) and make IDLE's shell an alternate UI. If Windows (or other OSes) (to be investigated) does not reliably come with a full unicode font (at least current BMP), is there a public domain or open license font that we can include? Terry Jan Reedy ___ 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] GSoC: Replace MS Windows Console with Unicode UI
On approximately 3/22/2009 8:48 PM, came the following characters from the keyboard of Terry Reedy: One of the disappointments of CPython 3.0 on Windows is that the switch to unicode for text (str), coupled with the continued use of a unicode-oblivious (obtuse) user interface (MS 'Command Prompt'), means that print can no longer print all str strings, or all legal Python code (as in a traceback). Different people have tried and failed fix this bug by fiddling with 'Command Prompt' configeration. This would make a useful summer project, though I don't know if it would involve enough coding. Call the project something like 3.0 Unicode UI Improvement. I see two possibilities. 1) Find an C-coded open-source C-P replacement whose author will license to PSF and, as needed, modify or integrate it with CPython. 2) IDLE does much better but its support seems to still be imcomplete. Upgrade tk/tkinter/IDLE (wherever the problems lie) and make IDLE's shell an alternate UI. If Windows (or other OSes) (to be investigated) does not reliably come with a full unicode font (at least current BMP), is there a public domain or open license font that we can include? One can, of course, set CMD into Latin-1 mode (chcp 1252)... not sure how Python reacts to that, as I've only used it with Perl, until I gave up on Perl's Unicode support (which someone finally seems to be fixing, but then there is CPAN to improve). But that doesn't solve the font problem, nor characters above 255. One can set CMD into Unicode mode (chcp 65001)... not sure how Python reacts to that either. But even then... CMD will only use fixed-width fonts, and none of the standard XP ones seem to contain all of Unicode. Not sure if that has improved on Vista or 7, as they don't run here. It _would_ be nice to get this resolved, somehow. -- 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] How to Contribute to Python doc now online
In preparation for Pycon and the sprints I quickly pulled together a doc explaining how people can help out with Python's development: http://www.python.org/dev/contributing/ . -Brett P.S.: Just so people know, I will be taking a month or two off from Python development (i.e. heavy coding) after PyCon to redo my father's web site and simply to take a slight breather after all the importlib stuff. Plan to keep plugging away at the DVCS PEP, though. ___ 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] tracker status options
Hi Daniel, That would be great. It occurs to me that if we wanted to use Stage settings, it would be easy to search for issues which are not closed by literally searching for 'not closed' rather than 'open'. I think it's also unclear whether the 'pending' stage means 'suspended pending additional user feedback' or 'resolution of this issue is impending'. My understanding was that it meant 'pending additional feedback' in the sense of awaiting, rather than imminent. In any case, let me know when the tracker is online and I will suggest the tag alterations that I think would be appropriate. Regards, -Tennessee On Fri, Mar 20, 2009 at 10:53 AM, Daniel (ajax) Diniz aja...@gmail.comwrote: Martin v. Löwis wrote: In addition, I would like to see a specification of the exact labels to be used, plus a one-line description that should be attached to the labels. Tennessee, If you'd like to test those additional status options, I'm setting a test instance of the Python tracker up at http://bot.bio.br/python-dev/ . It might be frequently offline for a while, but once things are stable it'll be reliable enough to perform such experiments. If it's easy on resource usage, I might have one instance following the Python tracker code closely and a more bleeding-edge one :) Regards, Daniel ___ 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/tleeuwenburg%40gmail.com -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ Don't believe everything you think ___ 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] GSoC: Replace MS Windows Console with Unicode UI
Terry Reedy tjre...@udel.edu writes: If Windows (or other OSes) (to be investigated) does not reliably come with a full unicode font (at least current BMP), is there a public domain or open license font that we can include? The GNU Unifont at Unifoundry URL:http://unifoundry.com/ is designed for this purpose. -- \ “For my birthday I got a humidifier and a de-humidifier. I put | `\ them in the same room and let them fight it out.” —Steven Wright | _o__) | Ben Finney ___ 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
