Re: [Python-Dev] build problem
> Adding an extra set of quotes around the command seems to fix > this. I've attached a patch. This is puzzling: a) AFAICT, the code works on all other system as it stands, and b) putting this many quotes into the command line is not plausible. Do you have any strange settings on your computer, such as using a non-standard cmd shell? Regards, Martin ___ 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] web framework for py3k
Am 22.01.2011 19:16, schrieb yeswanth: > I would want to help porting some web framework for py3k .. I want to > know to know which one is good and which can be ported easily . Also i > would require some guidance for this work as I am just a beginner here .. Yeswanth, Terry already indicated that this is the wrong list. The right list would be the python-porting list: http://mail.python.org/mailman/listinfo/python-porting As for which framework can be ported easily: that is, unfortunately, difficult to tell in advance. I'd expect that sheer number of lines gives a good indicator: the smaller the framework, the more easy should it be to port it. HTH, Martin ___ 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] r88147 - in python/branches/py3k: Misc/NEWS Modules/_pickle.c Tools/scripts/find_recursionlimit.py
On Sun, 23 Jan 2011 18:12:26 +0100 (CET) antoine.pitrou wrote: > Author: antoine.pitrou > Date: Sun Jan 23 18:12:25 2011 > New Revision: 88147 > > Log: > Issue #10987: Fix the recursion limit handling in the _pickle module. I forgot to mention that it was ok'ed by Georg, so there it is. Regards Antoine. ___ 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] Beta version of the new devguide
On Sat, Jan 22, 2011 at 23:56, Mark Summerfield wrote: > Hi Brett, > > On Sat, 22 Jan 2011 17:08:00 -0800 > Brett Cannon wrote: >> http://docs.python.org/devguide/ > > Personally, I found the first paragraph of "Contributing" a bit > off-putting. > > How about replacing: > > People who wish to contribute to Python must read the following > documents in the order provided. You can stop where you feel > comfortable and begin contributing immediately without reading and > understanding these documents all at once, but please do not skip > around within the documentation as everything is written assuming > preceding documentation has been read. > > With something like: > > The Python core development team always welcomes new contributors, > so we are very glad of your interest! Please read the following > documents---in the order shown---to ensure that you understand how > Python's development process works. This will ensure that your > contributions are considered purely on their merit and don't get > rejected due to missing or incorrectly performing a step in the > process. > I'll see what I can do. > In "Getting Set Up" it describes how to build a pydebug build. Is that > really necessary for those who plan only to contribute by working on > pure Python code? > Yes, there is actually a laundry list of reasons even people only working on the stdlib should use a pydebug build. > I had a quick skim over the rest and got the feeling that no clear > distinction is made between C and Python work. Personally, I feel that > more of a distinction should be made since not everyone will be > confident or interested in C. (And maybe more distinction should be made > between working on CPython and the standard library?) I don't see where the distinction between extensions and Python code would serve a purpose beyond clouding the documents by adding more details. People who know both are fine and the people who don't can start off ignorant and work there way up. As for CPython/Python distinction, they are so intertwined at the moment that the distinction is once again not worth it beyond what I have already done. When the stdlib is separated from CPython then the delineation of one over will become worth it. > > Overall I think this document is *extremely welcome* and I am very glad > you have done it. I'm sure that once it starts to get known it will help > add to the pool of people contributing to Python as well as helping to > keep the processes clear:-) =) That's the hope. -Brett > > -- > Mark Summerfield, Qtrac Ltd, www.qtrac.eu > C++, Python, Qt, PyQt - training and consultancy > "Advanced Qt Programming" - ISBN 0321635906 > http://www.qtrac.eu/aqpbook.html > ___ 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] build problem
Le dimanche 23 janvier 2011 à 19:18 +0100, "Martin v. Löwis" a écrit :
> > Adding an extra set of quotes around the command seems to fix
> > this. I've attached a patch.
Hey! I already wrote exactly the same patch! But I didn't propose it
upstream because I was unable to reproduce the bug.
> This is puzzling: a) AFAICT, the code works on all other system as it
> stands,
I had this issue already twice, but later (after a reboot? I don't
remember) it worked again (without the patch). It might be related to an
upgrade of TortoiseSVN (try to upgrade TortoiseSVN without rebooting).
> b) putting this many quotes into the command line is not plausible.
""c:\path\to\subwcrev.exe" arg1 arg2 ..." just works. I don't understand
why (strange syntax), but it works :-)
When I had the problem, it worked with extra quotes, but not without. It
is strange because the program ("c:\path\to\subwcrev.exe") existed!?
Victor
___
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] build problem
> ""c:\path\to\subwcrev.exe" arg1 arg2 ..." just works. I don't understand
> why (strange syntax), but it works :-)
>
> When I had the problem, it worked with extra quotes, but not without. It
> is strange because the program ("c:\path\to\subwcrev.exe") existed!?
I'd really like to understand it before changing it. The part "it
sometimes works, then fails" is particularly puzzling, and indicates
that the *actual* problem is entirely unrelated to the quoting.
Regards,
Martin
___
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] r88147 - in python/branches/py3k: Misc/NEWS Modules/_pickle.c Tools/scripts/find_recursionlimit.py
On 1/23/2011 1:58 PM, Antoine Pitrou wrote: Issue #10987: Fix the recursion limit handling in the _pickle module. 12 hours after the report! I am still curious why a previous exception changed pickle behavior, and only in 3.2, but I would rather you fix another bug than speeding much time to get me up to speed on the intricacies of _pickle ;-). -- Terry Jan Reedy ___ 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] Beta version of the new devguide
On 23/01/2011 20:22, Brett Cannon wrote: [snip...] I had a quick skim over the rest and got the feeling that no clear distinction is made between C and Python work. Personally, I feel that more of a distinction should be made since not everyone will be confident or interested in C. (And maybe more distinction should be made between working on CPython and the standard library?) I don't see where the distinction between extensions and Python code would serve a purpose beyond clouding the documents by adding more details. People who know both are fine and the people who don't can start off ignorant and work there way up. I think a lot of people assume that unless they know C they can't contribute to Python. I don't know where the best place is but it would be good to make it *clear* that this isn't true. All the best, Michael Foord As for CPython/Python distinction, they are so intertwined at the moment that the distinction is once again not worth it beyond what I have already done. When the stdlib is separated from CPython then the delineation of one over will become worth it. Overall I think this document is *extremely welcome* and I am very glad you have done it. I'm sure that once it starts to get known it will help add to the pool of people contributing to Python as well as helping to keep the processes clear:-) =) That's the hope. -Brett -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy "Advanced Qt Programming" - ISBN 0321635906 http://www.qtrac.eu/aqpbook.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] r88147 - in python/branches/py3k: Misc/NEWS Modules/_pickle.c Tools/scripts/find_recursionlimit.py
On Sun, 23 Jan 2011 18:45:50 -0500 Terry Reedy wrote: > On 1/23/2011 1:58 PM, Antoine Pitrou wrote: > > >> Issue #10987: Fix the recursion limit handling in the _pickle module. > > 12 hours after the report! > > I am still curious why a previous exception changed pickle behavior, and > only in 3.2, but I would rather you fix another bug than speeding much > time to get me up to speed on the intricacies of _pickle ;-). It was not about a previous exception. The issue is that pickle detected the recursion overflow but returned a successful status after having set the exception. This is the kind of mistake that produces strange "delayed" exceptions. Regards Antoine. ___ 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] r88147 - in python/branches/py3k: Misc/NEWS Modules/_pickle.c Tools/scripts/find_recursionlimit.py
> I am still curious why a previous exception changed pickle behavior, and > only in 3.2, but I would rather you fix another bug than speeding much > time to get me up to speed on the intricacies of _pickle ;-). IIUC, the code change made pickle actually aware of the exception, rather than just setting it in the thread state, but then happily declaring that pickle succeeded (with what would turn out to be incorrect data). As for why an explicit exception breaks the reporting, and omitting it makes it report the exception correctly: the report that it gave wasn't actually correct. I got raceback (most recent call last): File "a.py", line 4, in for i in range(100): RuntimeError: maximum recursion depth exceeded while pickling an object So the exception is reported on the range call, or the for loop. After the change, we get Traceback (most recent call last): File "a.py", line 7, in _pickle.Pickler(io.BytesIO(), protocol=-1).dump(l) RuntimeError: maximum recursion depth exceeded while pickling an object So it appears that the interpreter would actually pick up the exception set by pickle, and attribute it to the for loop. When you add an explicit raise, this raise will clear the stack overflow exception, and set the new exception. So the error manages to pass silently, without being explicitly silenced. I wonder whether we could sprinkle more exception-set? checks in the interpreter loop, at least in debug mode. It's a design flaw in CPython that there are two ways to report an exception: either through the thread state, or through the return value. I don't think this flaw can be fully fixed. However, I wonder whether static analysis of the C code could produce better detection of this kind of bug. Regards, Martin ___ 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] r88147 - in python/branches/py3k: Misc/NEWS Modules/_pickle.c Tools/scripts/find_recursionlimit.py
On Mon, 24 Jan 2011 01:28:26 +0100 "Martin v. Löwis" wrote: > > I wonder whether we could sprinkle more exception-set? checks in > the interpreter loop, at least in debug mode. Yes, this would be nice. Nicer if it can be centralized, of course. That said, it probably wouldn't have helped here, since the code which exhibited the bug (the find_recursion_limit.py script) is basically never run automatically, and very rarely by a human. Regards Antoine. ___ 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] build problem
On Sun, Jan 23, 2011 at 2:10 PM, "Martin v. Löwis" wrote:
>> ""c:\path\to\subwcrev.exe" arg1 arg2 ..." just works. I don't understand
>> why (strange syntax), but it works :-)
>>
>> When I had the problem, it worked with extra quotes, but not without. It
>> is strange because the program ("c:\path\to\subwcrev.exe") existed!?
>
> I'd really like to understand it before changing it. The part "it
> sometimes works, then fails" is particularly puzzling, and indicates
> that the *actual* problem is entirely unrelated to the quoting.
I used ProcMon to track down the actual command that the system() call creates.
The unmodified code produces this:
C:\Windows\system32\cmd.exe /c "C:\Program
Files\TortoiseSVN\bin\subwcrev.exe" .. ..\Modules\getbuildinfo.c
"E:\coding\py3k\PCbuild\Win32-temp-pgi\pythoncore\\getbuildinfo2.c"
whereas my patch produces this:
C:\Windows\system32\cmd.exe /c ""C:\Program
Files\TortoiseSVN\bin\subwcrev.exe" .. ..\Modules\getbuildinfo.c
"E:\coding\py3k\PCbuild\Win32-temp-pgi\pythoncore\\getbuildinfo2.c""
I pasted those two lines on the command prompt. The first results in
the error "'C:\Program' is not recognized .. ". The second one
does the right thing.
It would be great if someone could run ProcMon on a "normal" system
and see what command is created.
Thanks
Prasun
___
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] Import and unicode: part two
"Martin v. Löwis" writes: > Actually, as long people only involve Windows, or only involve Mac, > it will all work just fine. It's only when they use non-Mac Unix > (such as Linux), or try to move files across systems using sub-prime > technology (such as your typical Windows zip utility) they will run > into problems. I believe that the kind of thing that Ishimoto-san has in mind is things like "smart cameras" that will upload your photos to your blog with one touch on the cameras screen and other "Web 2.0 for the rest of us" apps. What with the popularity of Linux and *BSD for such sites, it's easy to imagine problems of the kind he describes occurring between those (which will probably be using Shift JIS in Japan) apps and the websites. Why people with the skills to be actually using Python would have a problem like that, I don't know, but my experience with Japanese vendors is no different from anywhere else: they put the blame for bugs in systems on any convenient component other than their own or close business partners'. Open source is especially convenient because of the NO WARRANTY section prominently displayed in all licenses. > So the more people get confronted with the poor support of non-ASCII > file names in tools, the faster the tools will improve. It took PKWARE > many years to come up with a reasonable Unicode story - but now it's > really the tools that need to catch up, not the spec. I still agree with this point of view, but there is some scope for discussion of whether these tools should be "included batteries" or not. (Unfortunately I'm not in a position to volunteer to help with them for some time. :-( ) ___ 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] Import and unicode: part two
On Sun, Jan 23, 2011 at 6:33 PM, Stephen J. Turnbull wrote: > "Martin v. Löwis" writes: > > Actually, as long people only involve Windows, or only involve Mac, > > it will all work just fine. It's only when they use non-Mac Unix > > (such as Linux), or try to move files across systems using sub-prime > > technology (such as your typical Windows zip utility) they will run > > into problems. > > I believe that the kind of thing that Ishimoto-san has in mind is > things like "smart cameras" that will upload your photos to your blog > with one touch on the cameras screen and other "Web 2.0 for the rest > of us" apps. What with the popularity of Linux and *BSD for such > sites, it's easy to imagine problems of the kind he describes > occurring between those (which will probably be using Shift JIS in > Japan) apps and the websites. Really? I would have thought that cell phones have long been the platforms most supportive of Unicode. IIRC Nokia's Python port to S60 *required* Unicode strings for all system interfaces. Android, using Java, also is pretty much all Unicode inside. Am I naive to generalize from these two examples? (This is not meant as a rhetorical question -- I may well be missing something and am genuinely curious about the answer.) -- --Guido van Rossum (python.org/~guido) ___ 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
